Disoriented and Disenchanted

I recently attended a seminar on service-oriented architecture (SOA) mainly to discover why, given it's already been around for a few years (an eternity in IT management time), people are still holding seminars on it.

My younger colleague remarked that oriented was an unusual word and suggested it was probably coined by a consultant. It turns out he was spot on. SOA was lobbed onto the acronym court in a 1996 research paper by a Gartner boffin, although the term didn't become widely used until around 2002.

SOA associates new terminology with concepts that have been around for some time such as CORBA, DCOM and DCE. SOA's new concept is the concept that it is new, while in reality it's just re-using ideas that were the Next Big Thing a decade ago. But the IT industry has never let history get in its way, so with a shiny new acronym SOA is now this decade's Next Big Thing.

Earlier this year, a joint research project by Computerworld and Hydrasight on local adoption rates of SOA revealed 44 percent of companies surveyed had already started or piloted SOA projects. A different measure of its success is the survey by Network Computing that found SOA was the most despised buzzword last year.

Not only is SOA a buzzword itself, descriptions of SOA are jam-packed with buzzwords. Orchestrate, granularity, composability, componentization, centre of excellence, proven international governance standards, control objectives and (my personal favourite) SOA reference architecture. Wow, two architectures in the one buzz phrase. The best buzz comes from OASIS (Organization for the Advancement of Structured Information Standards), which defines SOA as "a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains". Which, aside from the admirable use of the former buzz champion paradigm, doesn't actually say anything.

Although everyone tells me that SOA is a definition and not just a set of products, I might find it a wee more credible if the people telling me were not all software vendors pushing their set of SOA products.

Page Break

Perhaps it's the time of year, but vendor SOA claims, when read together, remind me of a traditional Christmas get-together with a dysfunctional family that's the polar opposite of The Waltons. Members of this extended SOA clan don't mingle much during the year, but when they do get together they each try to outdo each other boasting how they've been most active making the SOA name successful.

According to Grandpa Zeb Wiki, who everybody believes (and vice versa), there are eight SOA guiding family principles. These are encapsulation, loose coupling, contract, abstraction, reusability, composability, autonomy, optimization and discoverability. Like company value statements, these principles are widely admired and instantly forgotten by its members. As children are wont to do, each of the kids has his own take on what's most important in SOA, and family principles be damned.

Like all family members, they do have their similarities. To get to the SOA gathering, everyone agrees the first requirement is essential, which is to engage the company chauffeur who they call their business driver.

The oldest, IBM-Boy, thinks there are only five important aspects: model, assemble, deploy, manage and governance. IBM-Boy's deploy includes transport, event and mediation services, which would be fantastic if I was deploying a national conference on family law. For Christmas, IBM-Boy has a brand new SOA sandbox to play in, which he's happy to share with others. IBM-Boy boasts an SOA Industry Accelerator, which sounds like it's going to obsolete company marketing and sales strategies as a means of promoting business. I can just press down on the Industry Accelerator pedal and the money should roll in.

The second born is the wise one of the family (they usually are) fittingly called Mary Ellen Oracle. She differs a little from her big brother's SOA views, preferring to just build, deploy, and manage. Mostly she just talks about furniture, rearranging the components of her suite.

Jason-Mike Rosoft left his Christmas planning to the last minute, and has only recently been spruiking his new SOA plans. Apparently, he's moving to Oslo, which he says will be fantastic in the long run, but didn't say when this journey would eventuate. The rest of the family somewhat rudely suggested the name Oslo was chosen because it was so far away.

The next sibling, SOA Erin Software (who put her family name first for added recognition), is nothing if not inventive. Not three steps like Oracle, nor five steps like IBM, she's created seven steps called expose, register, secure, manage, visualize, govern and integrate. To me, this sounds like the lifecycle of porn sites - which cater for a quite different orientation.

Jim-Bob Tibco, or little Tibby as the others call him, was always the conciliatory one. He keeps trying to integrate with the other kids, to get everyone talking under the one roof - his. He identified a requirements communication gap, which he manages by continually talking in the hope he can personally bridge the gap. His message of leave, layer and leverage seems to perfectly describe the approach for serving Christmas cake.

Page Break

Despite their petty quibbles and trying desperately to look independent, all the SOA kids seem to be in violent agreement with each other about what's important. So, at their family gathering, they all take part in being service consumers (receive Christmas presents), service providers (give presents) with a service bus (the Christmas tree under which the presents are exchanged).

Their conversation at these times often harks back to their plans for the big compliant homestead, built using the SOA Reference Architecture, which they've been talking about for years. So far they've got a worked design of an SOA implementation, detailed architecture diagrams, component descriptions, detailed requirements, design patterns, opinions about standards, patterns on regulation compliance and standards templates. But no house. Still, it keeps everybody talking (or as they call it - consulting).

Next year's Christmas party might also include the family next door. They've been neighbours for a few years, but have recently changed their name from the increasingly foreign real-time enterprise (RTE) to the currently more acceptable service-oriented infrastructure (SOI). They have a background in manufacturing, but now specialize in making tools, particularly skilled in handling fluctuating demand. I foresee some difficulties ahead. The two families will start to get each other's mail as the postman, along with most of the IT community, gets confused between the two names.

There may also be romance across the fence, with SOI and SOA members courting each other and spending increasing time together. Even so, I thought the comment last month by the co-chair of Open Group's SOA-SOI project was a bit voyeuristic. He said: "SOA and SOI can exist on their own, but when you marry them, you see the big-bang achievement."

It would certainly be a fascinating Christmas party (and by fascinating, I mean dull), but what have I learned about SOA? I'm hopeful it could save me when called to account by the Boss after my SOA implementation. Her criticism "but you said we would have a services architecture" could be deflected by my response "no, no . . . it's service oriented. But don't worry, we'll get there."

And I'm certain we will - or at least somewhere in the vicinity.

Bruce Kirkham is a veteran IT satirist and professional speaker ­specializing in leading edge technologies and scepticism, who views the IT industry not so much as "dot com" as "dot comedy"