Given that Burton’s clients are mostly enterprises, I wonder how this will end. One of the most prominent headline-grabbers of the upcoming Catalyst conference is an entire track whose pitch reads as follows:

Track: SOA Is Dead; Long Live Services

Many service oriented architecture (SOA) initiatives have stalled or failed. And prospects for SOA look bleak in 2009. Most organizations have cut funding for their SOA initiatives. Except in rare situations, SOA has failed to deliver its promised benefits. It’s time to face reality: the term “SOA” now carries too much baggage. It’s time to declare that SOA is dead and move on to the more practical matter of bringing up its offspring. SOA’s untimely demise is tragic, but, fortunately, many aspects of SOA live on-particularly in the form of services. Services provide the fundamental building blocks that enable software as a service (SaaS), cloud computing, and business process management (BPM). This Catalyst track will examine the myths and misconceptions that derailed SOA efforts, provide guidance for salvaging value, and supply actionable direction for future efforts.

Face it. Your SOA initiative has failed. So where do you go from here?

• What went wrong with SOA?
• How can we salvage value from the wreckage?
• How do we prepare our systems to take advantage of the cost-savings promised by SaaS and cloud computing?
• Is BPM the answer?
• What about REST, ROA, and/or WOA? If we abandon the complexity of WS-*, can we revive SOA?

Some of us, including your’s truly, always felt like cringing when overzealous IT architects would sing SOA’s praises — long before anything got delivered to anybody that actually worked. Some risk factors were obvious:

• How can you hope to glue together system A and system B in any way unless you have a very clearly articulated and jointly managed cross-system information model?
• Same about event models, security models, etc.
• Far too little attention was paid to release management of services supposedly usable by other people. As a result, many composite applications were almost never up, because interfaces kept changing. This is not an easy one for corporate IT that does not usually have the funding or expertise for that kind of thing. (Side note: we now have the same problem, internet-scale, with OpenID, OAuth, and the like. Nobody has solved that one either, which is why often, "OpenID does not work" for some user who uses an unusual IdP/RP combination)
• Caching. Any production implementation has to consider that servant systems are not always going to be available, that they might not be able to bear the load at all times, that they may not always be fast enough, and that whatever information is obtained from them has to be related (and thus cached, and kept consistent!), to information in the client app. Otherwise there is no point to do it in the first place. Not an easy problem to solve.
• And so forth… but the worst part is that none of SOA’s problems that I’m listing here can be fixed with any of what the Catalyst track pitch mentions as possible solutions … so my belief is that not only may SOA be dead but its children will be dead on arrival, too, unless substantial new capabilities are available to them.

So it’s easy to glee. The harder question is what will replace it. There is clearly a need in the enterprise for "something", but far less clear what that is. Simply continuing as usual while calling SOA "Services" (as a mischievous reading of the conference track implies) is not going to get any better result, except for perhaps some breathing room before anybody notices. But what then?