SOA benefits: too much reuse of reuse?

Myth of the galactic repository

Protecting against web application threats using SSL

Ever since the dawning of structured software development, arguments have been put forth that, if we only architected (fill in the blank) entity relationships, objects, components, processes, or services, software development organizations would magically grow more productive because they could now systematically reuse their work. The fact that reuse has been such a Holy Grail for so many years reveals how elusive it has always been.

And so Joe McKendrick summarized the recent spate of arguments over SOA and reuse quite succinctly: "What if you built a service-oriented architecture and nothing got reused? Is it still of value to the business, or is it a flop?" The latest discussions were sparked by a recent AMR Research report that stated that too much of the justification for SOA projects was being driven by reuse. McKendrick cited ZapThink's David Linthicum, who curtly responded that he's already "been down this road, several times in fact," adding that "the core issue is that reuse, as a notion, is not core to the value of SOA... never has, never will." Instead, he pointed to agility as the real driver for SOA.

To give you an idea of how long this topic has been bandied about, we point to an article that we wrote for the old Software Magazine back in January 1997, where we quoted a Gartner analyst who predicted that by 2000, at least 60 per cent of all new software applications would be built from components, reusable, self-contained pieces of software that perform generic functions.

And in the course of our research, we had the chance to speak with an enterprise architect on two occasions - in 1997 and again last year - who was still with the same organization (a near miracle in this era of rapid turnover). A decade ago, her organization embraced component-based development to the point of changing job roles in the software development organization:

  • Architects, who have the big picture, with knowledge of technology architecture, the requirements of the business, and where the functionality gaps are. They work with business analysts in handling requirements analysis.
  • Provisioners, who perform analysis and coding of software components. They handle horizontal issues such as how to design complex queries and optimize database reads.
  • Assemblers, who are the equivalent of developers. As the label implies, they are the ones who physically put the pieces together.

So how did that reorg of 1997 sink in? The EA admitted that it took several reorgs for the new division of labor to sink in, and after that, was adjusted for reality. "When you had multiple projects, scheduling conflicts often arose. It turned out that you needed dedicated project teams that worked with each other rather than pools. You couldn't just throw people into different projects that called for assemblers."

And even with a revamping of roles, the goals of reuse also adjusted for reality. You didn't get exact reuse, because components - now services - tended to evolve over time. At best, that component or service that you developed became a starting point, but not a goal.

So as we see it, there are several hurdles here.

The first is culture. Like any technical, engineering-oriented profession, developers pride themselves in creativity and cleverness, and consider it un-macho to reuse somebody else's work - because of the implication that they cannot improve on it.

The second, covers technology and the laws of competition:

1. During the days of CASE, conventional wisdom was that we could reuse key processes around the enterprise if we adequately modeled the data.

2. We eventually realized that entity relationships did not adequately address business logic, so we eventually went to objects, followed by coarser grained components, with the idea that if we built that galactic enterprise repository in the sky, that software functionality could be harvested like low-hanging fruit.

3. Then we realized the futility of grand enterprise modeling schemes, because the pace of change in modern economies meant that any enterprise model would become obsolete the moment it was created. And so we pursued SOA, with the idea that we could compose and dynamically orchestrate our way to agility.

4. Unfortunately, as that concept was a bit difficult to digest (add moving parts to any enterprise system, and you could make the audit and compliance folks nervous), we lazily fell back to that old warhorse: reuse.

5. The problem with reuse took a new twist. Maybe you could make services accessible, even declarative, to eliminate the messiness of integration. But you couldn't easily eliminate the issue of context. Aside from extremely low-value, low-level commodity services like authentication, higher-level business requirements are much more specific and hard to replicate.

What's amazing is how the reuse argument continues to endure as we now try justifying SOA. You'd think that after 20 years, we'd finally start updating our arguments.

This article originally appeared in onStrategies.

Copyright (c) 2007, onStrategies.com

Tony Baer is the principal with analyst onStrategies. With 15 years in enterprise systems and manufacturing, Tony specialises in application development, data warehousing and business applications, and is the author of several books on Java and .NET.

The next step in data security

More from The Register

next story
New 'Cosmos' browser surfs the net by TXT alone
No data plan? No WiFi? No worries ... except sluggish download speed
'Windows 9' LEAK: Microsoft's playing catchup with Linux
Multiple desktops and live tiles in restored Start button star in new vids
iOS 8 release: WebGL now runs everywhere. Hurrah for 3D graphics!
HTML 5's pretty neat ... when your browser supports it
Mathematica hits the Web
Wolfram embraces the cloud, promies private cloud cut of its number-cruncher
Google extends app refund window to two hours
You now have 120 minutes to finish that game instead of 15
Intel: Hey, enterprises, drop everything and DO HADOOP
Big Data analytics projected to run on more servers than any other app
Mozilla shutters Labs, tells nobody it's been dead for five months
Staffer's blog reveals all as projects languish on GitHub
SUSE Linux owner Attachmate gobbled by Micro Focus for $2.3bn
Merger will lead to mainframe and COBOL powerhouse
prev story


Providing a secure and efficient Helpdesk
A single remote control platform for user support is be key to providing an efficient helpdesk. Retain full control over the way in which screen and keystroke data is transmitted.
WIN a very cool portable ZX Spectrum
Win a one-off portable Spectrum built by legendary hardware hacker Ben Heck
Saudi Petroleum chooses Tegile storage solution
A storage solution that addresses company growth and performance for business-critical applications of caseware archive and search along with other key operational systems.
Protecting users from Firesheep and other Sidejacking attacks with SSL
Discussing the vulnerabilities inherent in Wi-Fi networks, and how using TLS/SSL for your entire site will assure security.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.