"SOA is Dead; Long Live Services," proclaimed Amy Thomas Manes on January 5th, 2009.

Now you may be sitting there reading this thinking "OK… that was back in January. Why are you still writing about it now?"

Well since then the blogosphere has been on fire with people chiming into this debate asserting that "SOA is too complicated" or "ESBs have failed" or "businesses cannot afford SOA" or some other statement along those lines, implying (sometimes directly stating) that SOA was a bad idea and that it deserves to die.

Even people like Brent Foody at Progress Software agreed with Ms Manes when he wrote about this in his post. As Progress is normally pretty good at ensuring that its own corporate blogs meet the business goals of the company and given they own Sonic Software, vendor of the Sonic ESB, it is surprising that they allowed a posting prematurely acknowledging the demise of an architecture that they promote. Add to that the fact that Mr Foody’s comments contradict David Chappell’s own thoughts on the matter and you can see why I am surprised. Remember, David was pretty much the architect of SonicMQ and the brains behind SonicESB.

But even those were posted way back in January. As late as last week, though (July 23rd), there was still fall-out from this post. ZapThink hosted a ZapForum entitled "Night of the Living SOA Dead" where people would get the chance to argue the whole thing out. So this story has had legs for nearly 7 months.  

When I read Ms Manes’ post, I felt like the person standing on the sidewalk in a movie. The camera is focused on me and someone (SOA) steps out into the street. From the side of the screen, off-camera, a bus comes careening past and the person that stepped into the street is hit and taken completely out of camera and I’m left standing with my jaw on my knees.

Of course, if you carefully read Ms Manes’ post, you have to agree with at least some of what she is saying:

• The economy cannot support SOA projects that do not provide good ROI in a fairly short period of time;
• There is nothing to be gained by SOA for the sake of SOA;
• SOA is not the hammer for every nail;
• SOA is best viewed as part of an application modernization strategy for breaking up the monolith; and
• SOA is not the silver bullet that will fix everything your organization.

Ms Manes’ argument that the state of the economy would lead to the demise of SOA leaves me more than a little perplexed. Sure. Companies will cancel SOA projects that do not have significant ROI in the short or medium term in order to focus financial resources where they are most needed, but that does not spell the demise of SOA. Rather, it does what needed to be done in the first place – focuses business priorities on the highest ROI first.

Many vendors have bandied the SOA acronym around as the mechanism for selling their wares - from ESBs to high-cost consulting gigs; from application servers to expensive monitoring tools, all in the name of a service-oriented architecture. There is no doubt that a number of companies have excellent products that are intended to assist in building out your service-oriented solution, but just because you have an ESB does not mean that you have a service-oriented architecture. Neither is it true that because you have deployed several WebServices you now have a service-oriented architecture.

Ms Manes’ arguments are actually not new. In fact, many of her comments very much echo the sentiments of Thomas Erl, author of "Service-Oriented Architecture – Concepts, Technology and Design".

Back in July 2005, Mr Erl contended that "the rise of the false SOA [one characterized by the idea that a set of deployed WebServices represents a service-oriented architecture] has distorted the vision of the ideal SOA. Not only is the false SOA divergent from the ‘true path of service-orientation,’ it reinforces SOA anti-patterns by extending and further entrenching the traditional distributed computing model to which SOA offers an alternative." Essentially, Mr Erl makes the point that unless your implementation of SOA follows a well architected strategy, you are doing nothing more than creating a more complex distributed computing system.

With the amount of money that has been thrown at SOA, business has a right to expect that the problem that SOA was intended to resolve has been resolved. The issue is that there have been too many snake oil salesmen delivering products to a site and then leaving the organization to find its own way. Sometimes, the ’snake oil salesman’ actually sold a very good technology into the site with an offer of professional services to establish a competency center, but the customer failed to understand the importance of a supervised architectural change to the environment. As Mr Erl observes, "A real SOA requires real change, real foresight, and real commitment. Most of all, though, it requires guidance." – (Italics my own).

This brings me to my disagreement with Ms Manes’ point of view. Ms Manes states "Successful SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates." She follows this up by saying "The latest shiny new technology will not make things better. Incremental integration projects will not lead to significantly reduced costs and increased agility. If you want spectacular gains, then you need to make a spectacular commitment to change." In these statements Ms Manes’ is asserting that business somehow expects an overnight change and that a successful service-oriented architecture can only come from turfing your existing architecture and replacing it with a new SOA-based solution. Not only is that not true, but it is also hopelessly unrealistic.

Yes, SOA requires a different way of thinking and paradigm shifts are not going to come overnight. And yes, deploying a new technology and building service interfaces does not constitute a service-oriented architecture, but it is an extremely important transitional step in moving a commercial environment to a more service-oriented architecture.

Ms Manes ends her post by saying "And that’s where we need to concentrate from this point forward: Services." In so doing, Ms Manes is opening us up to the same "false SOA" that got us into this mess in the first place.

Ultimately, a thorough service-oriented architecture has proper governance and standards in place across all deployed services to ensure the abstraction of the underlying components. If that governance and standardization is not in place, services are simply distributed components.

So, no. SOA is not dead. A service-oriented architecture is something that businesses definitely need to aspire to achieve. It’s probably safe to say, though, that the ’snake oil’ SOA days are over.