In a follow-up post, Ms Manes pointed out that  "SOA is a bad word. And yes, doing SOA is a good thing. (And we need to keep doing it!) But no, we do not need to come up with a new name. Emphatically not."

This morning my RSS feeds had an update from Ms Manes’ blog again. She points to an article by Dan Woods of Forbes.com and says of his article that she is "pleased to see that Dan read beyond the first paragraph, and he understands the core message of my post (i.e., ‘SOA has been disappointing and that services should be a key focus’)" and then goes on later in her post to say:

"Dan recommends an incremental approach to SOA: Just build services as you need them on a project-by-project basis, and at some point in the future you can go back and consolidate the services you’ve built and somehow derive some architectural consistency. Unfortunately, this strategy invariably leads to Just a Bunch of Web Services (JABOWS) because the future consolidation step almost never happens. The result is too many services, too many moving parts, and too many brittle connections. Systems wind up being more expensive and more fragile than ever before."

I wonder if Ms Manes realizes that she advocated exactly the same thing that Mr Woods advocated and then went on to slam the idea? In her original post she argued that the focus should shift from SOA to building services, and yet here she is arguing that just building services will result in fragile, expensive systems. Ms Manes is just flat-out contradicting herself.

Without the overall service-oriented architecture you will not get a cohesive system. So recommending building services without an overall service-oriented architecture is a bad idea… as Ms Manes suggests.

At the same time, Ms Manes does not like the term "SOA" because of the negative connotation it has garnered thanks to a lack of understanding that business need to make a significant commitment to change and there are unscrupulous individuals trying to profit from a technology buzzword. For those reasons, Ms Manes believes SOA is dead. Ms Manes, however, does not believe we should get rid of the word "SOA".

In her latest post Ms Manes makes the statement that "One of the reasons SOA ‘died’…" Just stop right there!!!

Whether you like the term SOA or not, service-oriented architecture is a critical part of Enterprise 2.0 and requires a significant investment in both the architecture and development of services. Service-orientation has to drive the way that development teams build applications today and into the future.I hate to tell you this, Ms Manes, but SOA is not dead. There are numerous organizations who are still working extremely hard on a service-oriented architecture and many more are seeing the importance of it more and more with things like mashups and social networking becoming tightly integrated into the business.

I don’t disagree that SOA requires governance, management, leadership, skills, practices and a commitment to change. But remember that change is hard and takes time. In fact, it takes more time as the organization gets larger. A weak economy has caused businesses to refocus priorities and in many cases this has meant cutting projects that are not directly contributing to the bottom line. Companies are not willing to shell out several hundred thousand on projects for which the ROI may only be seen in 5 to 10 years. For some companies, that is the amount of change that SOA requires and simply buying an ESB is not going to resolve the issues.

A service-oriented architecture does not come from the presence of an ESB. It is definitely not characterized by the availability of a bunch of services in an organization. SOA is a paradigm shift like event-driven programming was a paradigm shift and object-orientation was a paradigm shift. All of them came with their share of snake oil salesmen too and nowadays those paradigms are standard in business.

SOA is alive and well… and growing.

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.