SOA's Funny Hat

One of our frequent failings in IT is the inability to recognize when what looks like a shiny, new, exciting and difficult problem requiring great innovation and finesse is really a stodgy, old, well-understood problem wearing a funny hat.

Service-oriented architecture is this in spades. SOA isn't the real problem; it's the funny hat. The real problem is software reuse.

At one time, ten years ago and more, we dreamed of composing applications from libraries of modular business components, built by domain experts, offering that magical combination of being just specific enough for our needs, and just general enough for everyone else's.

It didn't happen. Bedeviled by the intricacies of requirements variance, platform incompatibility, code dependencies, and a host of management headaches, we moved on. Instead, we now dream of composing applications from modular business services.

Technically, the idea isn't as far-fetched as it once was, as SOA offers two critical advantages over direct code reuse: platform independence and location independence.

If I want to reuse code as a component, I am obliged to use the hosting platform and framework / container, else it won't give me the time of day (even if it's a time-of-day component.) Otherwise, I have to shoehorn the framework into my established, pristine application architecture, or jettison mine and rebuild.

If I want to reuse code as a service, it's different. With web services, for instance, I send an XML message over HTTP.

And I'm done.

The impact on my application is minimal. I can use only what I need and ignore the rest. The code can be hosted anywhere and I can call it from anywhere else. You can upgrade the code a hundred times a year, change development platforms, push it out into the cloud or drag it back in-house; if the interface contract is honored, my client won't care. (Well, it won't care, modulo the odd glitches from half-wit SOAP stacks.)

Small wonder people remain excited about SOA, that even after ten years of hype and high-profile failures, we are still willing to beat our heads against this wall. It's worth the effort. When you get it right, the cost to reuse is nearly zero.

Technically, that is. SOA may have taken most of the platform issues out of software reuse, but it has done nothing to solve the far more challenging issues in managing reuse. These are well understood, but they still give reuse all the approachability of a feral pig. SOA is a beast for much the same reasons.

• Reuse isn't just a different style of programming. It takes a highly disciplined approach, like feature-oriented domain analysis, to partition application functionality and identify critical reusable parts, and then focus investment on those parts. In SOA, it's about partitioning business functions and business processes, potentially re-engineering what's broken, and investing in those with the greatest potential.

• Reuse brings disruptive change to the development organization. Talent is split between component builders and application builders, creating competition for who builds what. Same with SOA: you have service providers and service consumers.

• Vendors are eager to portray technology as the solution. Reuse is achievable if only you will use our repository product, our base framework, our architecture planning tools, our software assessment suite. Likewise SOA: you can have it out of the box if only you purchase our ESB, our service registry, our governance solution, our data integration engine. Always eager for silver bullet solutions, IT managers get suckered time and again.

• Reuse demands a different funding model. Component consumers are developers, not business users, and business sponsors are loath to pay for development of software that customers can't see and touch, or that isn't tied to specific projects. Developing an effective ROI model requires a high level of maturity in project management and accounting. The same goes for services.

• Reuse also demands changes in business product planning. IT can't just be an order taker for the business, building applications in silos. Long-term ROI demands the reusable component base be a foundation for future products, and product planning must run in parallel with a roadmap for the components. Same with services.

Common pitfalls abound: trying to run the reuse teams like any other project , instead of like an internal product organization; use of shady ROI metrics like # of lines of code reused; failure to train developers and architects in new skills; ambitious executives over-selling pet platforms and methodologies as the key to success.

It's all too familiar. Sadly, SOA is just different enough from component reuse that we see it as a unique problem, and costly lessons from the halcyon days of software reuse go unheeded.

We ought to take another look at SOA and say, "Wait a minute… I recognize that guy."