« Palm's Nova | Main | Web Services Testing Forum: soapbuilders reloaded »

January 05, 2009



SOA is as SOA does. Great article, and timely. My company has embarked on a major SOA initiative, which (don't laugh) inspired me to write a song about SOA. This might, in fact, be the first rock-and-roll song ever about SOA. I call this new genre "Nerd Rock".

Have a listen: http://kompoz.com/6618


Steve Nimmons

I have conducted a Service Oriented Autopsy, including the important question "Was SOA Bunburying?".


Piet Jan Baarda

Here's another one on SOA during a recession: A RECESSION IS A BLESSING IN DISGUISE !!


Andras Szakal

SOA is the underlying implementation that enables Services. The goal has always been to create business services that are flexible enough to respond to changing business requirements without having to engage an army of programmers. I suggest readers take a moment to review the Open Group Service Integration Maturity Model http://www.opengroup.org/projects/osimm/doc.tpl?CALLER=index.tpl&dcat=14&gdid=17990 or just google OSIMM. OSIMM helps to provide the technology, business and governance requirements for successfully implementing services.

Dan Zrobok

So... The point is that the three letter acronym 'SOA' is 'dead', but everything that it stands for is right.. I don't see the need to waste time talking semantics..

I also don't understand why people think REST is some god-send, it's just Web Services without the SOAP Envelope and hijacking the HTTP protocol (HTTP PUT? Cmon) instead of just clearly defining your interfaces via WSDL.

Anyway, the real reason that projects (SOA/Non-SOA) fail is that IT consistently fails to talk about projects in a manner that the business can understand. There's a lack of corrleation between "If we, the business, give you $x for this project, what will the ROI be in x years?".

It's a larger IT issue, not one thats constrained to a particular approach.


Anne is correct about SOA being dead. It failed for the same reason that DCE failed - and the reasons are not technical. The reason for its failure is based on internal politics, culture and business rules complexity.

Everyone agrees that SOA requires big changes in culture and the internal workings of the company in terms of the way IT services are delivered. This translates to a big impact in terms of resources and $'s as well as a general consensus between IT and business units on the correct way forward.

So what does a company do when it says "we can not afford this and we actually want IT to reduce their budget next year by 10% or we will look at outsourcing"?

Smart IT people will recognize that using terms that few people really understand e.g. SOA, web services etc., is not going to sell well in 2009. Especially when the huge bulk of the companies prod applications use traditional 3GL's (Cobol, Basic, PL/1, VB6 etc).

Smart IT people will recognize that it will be much more efficient to sit down with the key staff of each of their BU's to really understand their issues and challenges. Once is done, then the IT staff need to determine, with open minds, whether it is better to use traditional methods (web enablng existing apps or create new ways with OO technologies (.Net, J2EE) or perhaps just plain and simple 3GL programming.

Its back to basics.


Anyone who believes "SOA is dead" needs to check out www.cio.com/document/pdfs/2009_state_of_the_cio_highlights.pdf
Looking at this report it is clear that SOA or "business process management" or the need to "align IT with business" are some of the top priorities of the CIO community.

Tim Bass

Hi Anne,

Well written. I agree. You have inspired me to blog about this again. In my last SOA post, What is SOA, Really…. A Sacred Omnipotent Acronym, I touched on a few of the reasons that SOA will die.


SOA might not be "pronounced dead" yet, and there are always a handful of analysts and seller who will continue CPR on the corpse-of-soa.

Yours faithfully, Tim

Tim Bass

Hi Anne,

OK, thanks for the motivation! Here is my follow-on one your excellent post!

SOA in Cardiac Arrest, Long Live Services



Yours faithfully, Tim

Chris Bird

We have come up with ever more expensive and elaborate ways of doing procedure calls.

Please indulge me for a moment. The first subroutine library I ever used was made up of individually coiled rolls of paper tape hanging on coathooks beside the computer. You wanted to use one? Take it off the hook, inline it into your own program on tape, coil it back up and replace it on the hook.

It's been downhill ever since! We have found more and more ways of invoking these - pushing the binding later and later, making them location/implementation independent, but all the time essentially using a call/return paradigm.

That simply isn't how the world works - at least for the most part. In most business and human interaction we work asynchronously. I tell you that something has happened - you take action (appropriately, I hope). We seem to use request/response to get information - "What's my balance?" - I want some info and am prepared to wait for it. Most of the time, however, while I may want things to happen, I don't necessarily want to stand there arms folded doing nothing else while it happens. Especially not using the kind of approach like, "Please go and tell our foreign exchange student to clean his room and I will wait here until he is done" - something I may have to do when I don't speak enough of the exchange student's language.

There's far too much friction in request/response and therin lies the major problem with most SOA experiments. Yes there have been lots of successes, but tightly coupling to a predefined interface and then using a heavyweight RPC is probably not what many had in mind when they started on the SOA journey.

So if we now step back and look at what we have been trying to do with SOA, we should divorce ourselves from the implementations - not think about SOA as the alphabet soup of SOAP/WSDL/WS* and refocus on business and business conversation. Using frameworks (thinking frameworkslike VPEC-T) to help us understand how to get the business and IT to focus on the same ends, determine the proper means is where we ought to be taking SOA. Remember the A in SOA is architecture.

Jonathan Ross

Thanks for this. Provocative, but necessary. IT executives will need many such clouts over the head to come to their senses, because the essence of SOA as you put it is just too scary: "SOA ... requires redesign of the application portfolio ... a massive shift in the way IT operates."

In a way this "demise" reminds me of the disillusionment we went through with software reuse, many years ago. Then, we dreamed of building applications from modular business components. Today, we dream of building applications from modular business services.

In both cases, we allowed ourselves to become consumed with the technology aspects of the problem and let the far thornier management and organizational issues sort themselves out, which of course they never did.

Reuse and SOA both demand dramatic shifts in organizational structure, project sponsorship / funding / management, and product planning. And they demand comprehensive, up-front domain analysis and disciplined, long-term planning for reuse, notions that are out of step with business managers' endless one-off demands of "Build this app for me right now."

Such a waste of education. So many lessons from the days of software reuse are applicable to SOA, and we dismiss them because the problem looks different enough to be new.

A tad more detail here, if interested: http://bluecollararchitect.blogspot.com/2009/01/soas-funny-hat.html


To Dan Zrobok: Every business gets the IT that it deserves! With business traditionally only focussed on very specific solutions without any regard for overall coherence, consistency and quality only very mature organizations will get SOA benefits. Don't feel quilty as an IT person. Immature businesses will chop off your head if you talk about coherence and architecture in general. Well... they got it coming. Business grow up!

Kadeer Beg, Prolifics CTO

I scanned the blog by Anne, SOA is not dead, in contrary I believe people will leverage it to look into optimizing their business processing by leveraging SOA practices to monitor events related to processes and business situations. I expect there will be greater focus on re-engineering to save cost, and to re-engineer they would need know the current situation and be more proactive. The new suite of technologies on business activity and events monitoring will assist the executives to have a dashboard to make those decisions proactively.

Rob Eamon

"SOA needs to be part of something bigger."

In other words, SOA doesn't "require" anything? For example, the view is "we need to restructure our business, and we've decided to use SO principles as the way to guide that restructuring." As opposed to "we want to 'do SOA' therefore we are going to restructure our business."

SOA isn't the goal. Its the means to an end. Right?

Robert S. Robbins

Shouldn't the dinosaur be labeled IBM?

Stanislav Sumbera

First of all - don’t worry - if Anne Thomas is saying SOA is dead, she means that SOA has already reincarnated under different ‘Avatar’ ...whole response here: http://blog.sumbera.com/2009/01/13/soa-reincarnation/

Mohamad  Afshar

SOA is dead. So, if we are lead to believe that something is dead, first we must try and understand what it is that is actually dead, then pursue the reasons as to why it died.

Too often we have been lead to believe that unless you pursue SOA with an enterprise-driven approach focused on building reusable services, then you are not doing SOA.

Thankfully, in the real world, there is a single way to do SOA - many customers start out with SOA with a Project-Driven or a Infrastructure-Driven approach to SOA.

So it may perhaps be true that the Enterprise-driven approach to SOA may be less common today. However, thankfully, the enterprise-driven approach is not the only way to do SOA, and so SOA is not dead afterall!

For more about the different approaches to SOA, you may want to read our article in SOA World Magazine entitled "Going Beyond Project-Driven SOA"


Anne Thomas Manes

Rsponding to Mohamad Afshar: Our research shows that project-driven SOA initiatives fail as frequently as enterprise-driven ones. Although you may execute a number of successful projects (typically SOI rather than SOA), from an overall standing, the IT department still does not gain significantly reduced costs or increased agility. Within 18-24 months, these project-driven initiatives tend to stall out because the business fails to recognize significant value from the effort. As I said, the only truly successful SOA initiatives are the ones that are part of a much larger IT transformation effort.

Kurt Cagle

Hi, Anne!

Excellent article, and one that (as you probably know better than most) expresses my sentiments about SOA as well. I've written a reply at http://broadcast.oreilly.com/2009/01/soa-is-dead-its-about-time.html.

Kurt Cagle

Tim Bass

This has been a great discussion with excellent comments, my favorite so far this year! I have recently posted something along the order of Capability as a Service (CaaS) is the "New SOA" in,

IT Infrastructure: Capability as a Service


Yours faithfully, Tim


Hi Anne,

You are dead-on right and I feel that the paradigm was never understood and rather misused by all including implementers and vendors, since I was involved with one of the first "Good" implementations in the industry that is still going strong on ROI. As you said, coming to think of it we were lucky since SOA was part of a big picture for an urgent hunger for integration thus not being fixated on SOA alone.
SOA might die as a buzz word but the services architectural approach it brought along is revolutionary and will become irreplaceable for businesses in the future. The economic recession will rather force firms to use these concepts given the rising mergers & acquisitions, the need to integrate the enterprises, and the competitive edge business will seek with faster than ever product delivery requirements due competition in the global economy.

I think this is the time for the visionary organization to invest in moving towards this capability and be ready for the onslaught when the recession eases, which we know has to. My take towards this is to always start grounds up putting in place the basics of service architecture capitalizing on existing investments ensuring at a minimum your services across systems can facilitate enterprise integration and can plug and play as the architecture matures for the enterprise, instead of top heavy investments into middleware vendors, protracted governance models, etc.

Stefan Ried, Ph.D.

Hi Anne,

I can’t believe that you are the same person that used to raise millions of VC in your former role as executive of Systinet. But that’s the beauty of being an analyst. You have to re-assess the market again and again and change your mind if the market (hype) changed.

There are many indications that Dinosaurs died in a big bang of climate change. And that’s my major point: The change of the economy and the climate change that killed the dinosaurs had nothing in common. So what has the SOAsaurus and the real dinosaurs in common then?
The dinosaurs and the SOAsaurus are significant proof of concepts for major innovations. The dinosaurs have been the first very large vertebrate with a backbone or spinal cord, a brain case, and an internal skeleton. Even though the direct further “development” of a pure dinosaur failed, the concept was a major breakthrough and paved the way for the vertebrates including human beings. (I am not a biologist; please take this as an analogy…).
I believe SOA has not suddenly died. Everybody who still believed (until your blog) that SOA would bring a cost saving or business value as a stand alone initiative missed the evolution of SOA of the past two years. SOA proofed that it is the outstanding concept of integration across application silos, across technology tanks and vendors. I totally agree with you that pure SOA has no return of invest, but this comes from the BPM, ERP, Business Event, BI and other systems that are directly related to business value contributions.
How many muscles would an upright walking animal or human being require without having a skeleton and backbone? Bones, Muscles, and a well protected brain, that’s the concept that survives in symbiosis. Therefore SOA will decline the hype – no question – but continue to be a major ingredient of future enterprise software concepts.

Stefan from Forrester

Dr. Yigal Gur

The picture will be better reflecting the situation if the "SOAsaurus" will be changed to "ESBsaurus". It is quite unfortunate that the SOA - which is the pattern of EA, became a synonym of ESB in the heads of CIOs.

Mike Alvarez


I couldn’t resist jumping on this thread. The term “SOA” ended up being an overly-hyped term created by software and analyst firms to get some air time and sell products.

Service Oriented design and approaches have been around way before the term SOA became popular. I published an article comparing object and service oriented approaches back in 2000.

The important aspect of SOA is the loosely coupled design that facilitated reuse. This takes experience, discipline, business understanding and some foresight to understand what will make a service reusable. It is not something you can buy off the shelf.

If someone sold their business an SOA initiative promising all the benefits that came along with the hype, then they were investing in technology for the wrong reasons and were setup to fail from the beginning because there is no way to deliver on the overinflated expectations.

I hope no one out there is selling their business something under the “Web 2.0” banner. IT professionals getting leading their business partners to invest in this manner are investing in technology for technology sake and plays into the already poor perception business users have of IT professionals as overbuilding propeller heads.

Anne, I think you were trying to say something similar but they way in which you say it also plays into the hype of what is a solid architecture practice. Now, I have to deal with business users who say we should not be doing SOA because it is dead.


Phil Bowker


An excellent, thought provoking article. But, whilst sadly the phrase SOA might be somewhat tarnished, I cannot accept that "SOA has failed to deliver its promised benefits". Possibly what you and I mean by SOA are two different things?

Whatever, I think that SOA suffers very much from the fact that it contains the word Architecture. This leads one immediately to think an SOA system simply (!) requires a new architecture.

That is not the case. SOA is a fundamental shift in the way most enterprises co-operate internally, and the reason SOA is perceived to have failed is because few enterprises have had the balls to change their management and communication structures to allow SOA to do what it does; deliver greater agility through a tighter coupling of business and IT. Yes, in this case, tighter coupling is a good thing!

I believe that companies typically deliver computer systems that broadly reflect their internal communication structures. Whilst these structures remain unchanged it is hardly surprising that SOA is perceived to have failed to deliver. I believe the truth is few have understood it and even fewer have implemented it.

Kind regards,

Phil Bowker

The comments to this entry are closed.

  • Burton Group Free Resources Stay Connected Stay Connected Stay Connected Stay Connected

Blog powered by Typepad