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

January 05, 2009


Denny Boynton


Interesting post. After thinking through this for a few days, I decided to perform an autposy and determine the cause of SOA's death:


John Harby

I posted this on InfoQ also but for those who don't get over there:

I Disagree

Seems like every job description out there now has SOA in it, I don't see SOA as being dead at all. I do see issues with customers trying to implement large green solutions provided by vendors. As happens with any significant technology change, it takes the vendors time to perfect the solution in terms of quality, documentation, etc. As I wrote in an article here awhile ago, I'm not sure the ESB was a great idea but the ESB is not SOA so to pronounce SOA dead is not making sense to me right now. If you want to make statements due to the economy then just pronounce technology dead, no?

Bill Berger

My response: Please don't ask for more buzz-words...


Rainer Thiel

Your article title is misleading.

Your niggle appears to be with an acronym that has been abused, rather than the architectural paradigm itself.
You go to some length to show how the concept has been misrepresented by vendors and misunderstood by the business community. You remind us that the tail (technology) continues to wag the dog (business). But you agree that "the requirement for service-oriented architecture is stronger than ever."

Rainer Thiel

Steve Van Ausdall

Finally!! Can we go back to writing out CSV files for other applications now? Why not just scrap the computers too, and go back to paper - that would definitely reduce the IT budget!


Hi Anne,

Interesting article, but what is a SOA? If you ask 10 technologists, you will get 10 different answers. Worse yet, how do you ever explain it to a business person (i.e. the one with the money) and more importantly, why should they care? If you look at the Wikipedia definition of a SOA, it is some 10 pages long – ridiculous!

Fodder for another blog post: succinctly explain a SOA intended for a business audience in one paragraph so that business folks could understand what it means and why they would care. I don’t think it can be done. And that is why the TLA SOA is dead.

Having been involved in many “services” designs and implementations over the years, we never used that TLA because it would have been the end of the project as everyone would have hung themselves on it trying to figure out what it meant and why. As a software development professional, I am embarrassed that our industry came up with that TLA. I really hope it dies ;-)

Keep up the good writings!


SOA is to Information systems what cheap loans and low interest mortgages were to the financial world.Just hypes and lies aimed at misleading ignorants.Time to come back to earth. Pragmatism must replace all the hypes.

Glauco Reis

Is not better instead of kill the acronym just to fix the causes of the failure ? Otherwise, we are going to change the name every year, and the problem remain unsolved...

Johan den Haan

- better late than never ;) -

I don't think 'services' is the solution.
We should more look into the direction of Model Driven SOA! See http://www.theenterprisearchitect.eu/archive/2009/01/26/soa-is-dead-long-live-model-driven-soa

Selwyn Akintola

Great analysis.

Service providers and technology vendors tailor definitions of SOA to suit their particular market offerings. Many vendors describe their technology offerings as “SOA” simply because they have implemented a web service API. Similarly the acquisition of an enterprise message bus does not mean that the organisation now has SOA architecture. Web services and enterprise message buses are technologies SOA is a design philosophy, you cannot go out and buy a SOA nor can any vendor sell you one.

SOA is (or should be) a business initiative. The multiplicity of definitions has lead to unrealistic expectations.

Paraphrasing another contributor - lets scrap SOA and get on with SOA


SOA has fallen, victim of a civil war - evidenced in this very blog - among its own flagbearers. Like all civil wars, there were zealots and warriors who formed multiple opposing armies, each group ever arguing religion: "what's the best service," "bottom-up" versus "top-down," "granularity," "where is the business logic?" "SOAP" vs. "REST." Debate and purity are fine, but not when they get to the point of bringing real-world business initiatives to a standstill or, worse, bankrupt. In the end, no side won, and the SOA flag now has fallen into the dust. In my experience, it was the business people who always understood quite readily the value of SOA for Business Services, and who pleaded with the technology teams to please get on with it and deliver in a timely, cost-effective way. We failed them. We failed our companies and clients. If it's not too late to pick up that SOA flag again, let's hope we can do better the next time around and meet that essential need business was trying to communicate to us, and on-time and within budget.

george O

oh, please ms manes! stop listening to the salesmen! go ask the technocrats! this argument is too shallow!

Eddie Hartman

IMHO it comes down to the question, How do you eat an elephant? The larger the infrastructure/organization (re-)engineering project, the greater the risk of choking. So take small bites. And chew well.

Transitioning to SOA can happen service-by-service, minimizing risk. Lessons learned from service-enabling one process, system or store is then used to accelerate bringing new ones online, identifying orchestration requirements and shaping pragmatic, achievable design goals as the infrastructure evolves.

And significantly, business procedures and processes change step-wise as services become available. This lessens disruption of operations and allows assimilation of changes and fine-tuning of services/processes before continuing. And as mentioned above, re-aligning goals as reality is better understood.

In general, and whatever you call them, changes to the IT firmament should be approached with humility. Infrastructures are products of evolution - survival of the highest switching cost - and are as such a custom fit. Besides, what's in a name? JDBC by any other name is still not the be-all-end-all data access language it was harked as in the last millennium. But it's still a pretty good idea.


Praveen Jhurani

1. SOA strategy has got nothing to do with underlying technology and systems.
2. SOA has got nothing to do with webservices either. You can have one without the other.
3. You dont become SOA enterprise by just creating webservices.
4. SOA has to be thought in terms of business process building blocks and not IT systems centric.
5. Not every webservice artifact in an enterprise needs to be part of SOA. You need to add layers of abstraction to a webservice before you can think of making it part of SOA. Business groups/units would be the best folks to identify what they think as a "service" or step in a service.
6. SOA is not a one time implementation thing.
7. SOA needs time, money and resources.
8. If you start thinking in terms of IT systems while creating your SOA strategy, you are not thinking SOA.

Allen Guest


I think that Jeff Griffith hit the nail on the head. This is my findings and observations as well.

Basically a lack of understanding of the business aspects to determine what is reusable and what is not is a fundamental problem as SOA attempts to centralize business functionality and reduce integration points – and not knowing when that is right or wrong at a service level is difficult for technical people to communicate and business to conceptualize.

Business people think of the specific problem solution as opposed to IT's view of how the solution might be respresented in the business domain.

jordan braunstein

I just blogged that I think “Big SOA is Dead; Little SOA is Thriving” at: http://tinyurl.com/soa-today2 . Ok, maybe Big SOA isn’t “dead”, but certainly struggling to convince companies to invest in BPM, BAM, ESB (Big SOA) in today’s economic climate is a tough, academic sell when they can go Little SOA with positive ROI. Organizations want rapid results– they want SOA Today and not 6-9 months down the line!


I want to propose an alternative to an architecture based on co-operating services - "The Integrated Solution (tm)". With "The Integrated Solution (tm)", each component calls the public API of the component it wants communicate with. There is no potential network interaction protocol to define, no overhead of serialization, and minimal latency cost. The cost of connecting two functions with "The Integrated Solution (tm)" is lower than the cost in a service based approach.

This leads to lower IT cost, tighter integration, shorter time to market, higher performance, and lower system complexity.

Successful implementation of a system using "The Integration Solution (tm)" does not require a disruption to the status quo. Integration is simply a matter of deploying proven technologies - modules, components, API's, Software Design, Project Management, good HR practices. There is no required shift in the way IT operates, and no new technologies to learn. There is no need for a low cost, quickly delivered, high performance, application delivered with "The Integrated Solution (tm)" to be part of something bigger to deliver ROI.

"The Integration Solution (tm)" can be a journey, or not, depending on your business needs. "The Integration Solution (tm)" is something you do, not something you buy.

kambiz shahri

From the trenches:

Ann Thomas is SPOT on!!
Even the reply by the guys at ORACLE to her dissing SOA (i.e. the grandiose vision of SOA) only provide project examples that are integration in nature ONLY.

Unfortunately EVERY single project i have consulted on, where SOA is "supposed" to be the underlying architecture/ethos/whatever is only a means to integration.

The grandiose SOA concept requires the FULL cooperation of an enterprise, extensive planning and then coordination.
Sizeable organization simply do not have the wherewithal to carry out such an exercise.

Management continually look for the I.T. silver bullet, whether it be off-shoring, on-shoring, SOA...it simply does not exist.


My response is here: http://architecture-soa-bpm-eai.blogspot.com/2009/03/is-soa-dead-nope.html

Japanese words

This kind of technology is always difficult for companies. Mostly because it involves introducing a lot of change. Change is important, but it also adds risk. Something most companies like to try and avoid.

Peter Pascale

"SOA is dead" - Nietzsche, "Nietzsche is dead" - SOA "No, SOA is getting killed by a lack of SOA talent." - Linthicum "No, SOA is getting killed by a lack of SOA interest" - SOAFacts.

-- SOAFacts.com

Couldn't resist a SOAFacts reference, which I think represents in humor the nugget of your observation. All the hype, marketecture, and focus on big-dollar platforms has hid the value in services-thinking, and disillusioned many technologists.

Stephen Dougall

Good article. Thing is that the arcronim SOA turned into a brand for selling products and technologies. I don't have a problem with this but it does making things difficult when examining products with all the spin off terminology and concepts from different vendors. For me SOA is what Object Orientation was to the 90s. A great style of architecture which helps me build better software. When considering the costs, I think the question to be asked is not "do we need SOA" it's "are we selecting the right vendor/produts to meet our solution.".

Gaurav Sharma

Annne - This seems to be an over agrressive statement. SOA benefits are being underrated today because of its slow ROI. And if SOA journey begins with the right note it can bring lot of value to an enterprise.


Dave M

Services are like parts. It should be a simple matter for me to make some nails, hammers, buckets, springs, and bricks, and greatly improve my bottom line. Oh gee, something missing here? What fraction of a whole is comprised of loose parts? Half? A tenth? The discussions above use the words 'enabler' and 'mashup' amongst others. There is a gigantic gap in the thought processes that focus on development of parts, leaving for later the nature of the whole. This particular technology (It is not productive to name it) promotes wrong-headed emphasis on trivial characteristics, and the failures to succeed while using it (that I am aware of) grew directly out of its misbegotten philosophy. Value comes from a different place.

The Process Ninja

SOA is dead? Was it ever alive in the first place? SOA, in my humble opinion is the stuff of pipe dreams. For the vast majority of companies it is not achievable or realistic, rather it being the new plaything of the super-rich...and who is super rich anymore. I'm not saying the concept wasn't good (I even blogged on it myself http://www.theprocessninja.com/process/2009/04/mr-potato-head-explains-soa-bpm.html) but it just wasn't practical for the majority of companies...

The comments to this entry are closed.

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

Blog powered by Typepad