SOA is Dead; Long Live Services

Blogger: Anne Thomas Manes

Obituary: SOA

SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession. SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on “services”.

 

Once thought to be the savior of IT, SOA instead turned into a great failed experiment—at least for most organizations. SOA was supposed to reduce costs and increase agility on a massive scale. Except in rare situations, SOA has failed to deliver its promised benefits. After investing millions, IT systems are no better than before. In many organizations, things are worse: costs are higher, projects take longer, and systems are more fragile than ever. The people holding the purse strings have had enough. With the tight budgets of 2009, most organizations have cut funding for their SOA initiatives.

It’s time to accept reality. SOA fatigue has turned into SOA disillusionment. Business people no longer believe that SOA will deliver spectacular benefits. “SOA” has become a bad word. It must be removed from our vocabulary.

The demise of SOA is tragic for the IT industry. Organizations desperately need to make architectural improvements to their application portfolios. Service-orientation is a prerequisite for rapid integration of data and business processes; it enables situational development models, such as mashups; and it’s the foundational architecture for SaaS and cloud computing. (Imagine shifting aspects of your application portfolio to the cloud without enabling integration between on-premise and off-premise applications.) Although the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever.

But perhaps that’s the challenge: The acronym got in the way. People forgot what SOA stands for. They were too wrapped up in silly technology debates (e.g., “what’s the best ESB?” or “WS-* vs. REST”), and they missed the important stuff: architecture and services.

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. The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In each of these success stories, SOA was just one aspect of the transformation effort. And here’s the secret to success: SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it.

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. Like Bechtel. It’s interesting that the Bechtel story doesn’t even use the term “SOA”—it just talks about services.

And that’s where we need to concentrate from this point forward: Services.

Comments

[Andrej]

Hi Anne,
Here's my response: http://www.andrejkoelewijn.com/wp/2009/01/06/soa-is-not-dead-were-still-in-the-early-adaptor-fase/
Regards,
Andrej

[nebupolzar]

Lol! SOA is dead, ah!

Let's create one more name for something what is the same, but sounds different, but also with service.
"A, B, C, D...."
"stop"
"L"
"Late, Lost ... hmmm, "
"Long Life Service!"
"Spectacular, spectacular!"

[Maurizio]

I once went to a prospect who claimed to have implemented a "SOA", but he was complaining everything was now much more fragile: Basically before they had a rudimentary but well-decoupled and robust system, it was possible for sales people to work off-line and then reconcile the day while at home, but it was hard to maintain and integrate new things. The new self-proclaimed SOA was based on the single silly idea of putting synchronous SOAP Ws everywhere, so at the end the whole new system is totally synchronous and fragile, as the failure of one single component means the stop for all the processes (as I said everything has been made synchronous). Of course they now blame SOA for that and want the previous fault tolerance back...

Now is that the failure of SOA of the plain defeat of intelligence?

[Alex Neihaus]

I am not sure why this blog doesn't take trackbacks; our response is at http://www.vosibilities.com/soa/giving-soa-a-terminology-niptuck/2009/01/06/.

Alex Neihaus
Active Endpoints, Inc.

[R.Sierra]

SOA is not dead, just change the name. If you ask me which name, I don't know.
I agree with many of the comments, SOA is a very particular way to redefine your application portfolio and more: Change the way of IT and business units are related and exchange information. Maybe the flow between this two guys are the complexity of SOA and generate bad feelings about SOA.

[Mark Little]

Hi Anne. I don't think SOA as a set of core principles is dead. Sure the term has been hijacked by many people (analysts included), but that doesn't mean it's dead. That's not what I'm seeing in the field either. Anyway, I thought I'd add something here http://markclittle.blogspot.com/2009/01/soa-is-dead-again.html

[Craig]

I would say that SOA might not be dead yet but I am hearing of alot of SOA projects being delayed or killed off. It might be more appropriate to say that SOA may be going into hibernation for a bit.

[Sebastian]

Trackback also not worked for the following post on the ARIS BPM Blog:

http://www.arisblog.com/2009/01/07/technical-soa-is-dead/

[Anne Thomas Manes]

Trackbacks work -- I just have to approve them. -- Anne

[Dan Creswell]

SOA is dead because a long time ago, engineering discipline died.

The death of engineering discipline is what led to people believing that deploying technology solved architectural problems, that vendors are the experts and know it all and that there's no need to worry about maintaining clear definitions of terms and acronyms such as SOA or Web 2.0

IT has long sought to have any warm body at a keyboard, sweeping aside the idea of appropriate qualification, experience and expertise in favour of being up-to-date with whatever are the "hot" technologies, architecture in a box such as J2EE and the idea that cranking code as fast as possible is all that matters.

IT has once again shot itself in the foot, blamed the tools and run over the hill to the next shiney thing. I'm betting that'll happen all over again real soon....

[Jochen]

What a stupid article. Only nonsense. I wanted to write an answer but then I say the reply from Harvey. I totally agree with him. There are two many people discussing about this topic who have absolutly no idea. SOA was always a shift in thinking, never a technology. Just because some did it wrong this does not mean that SOA is dead. In fact it is not what I can confirm from my day to day practice.

[Jim Kita]

A bittersweet emotion came over me when I heard that some of the most renowned of industry experts, even those heavily invested into the SOA movement, have now declared that SOA officially died on 1 Jan 2009...

more:
http://geekswithblogs.net/MSARCH/archive/2009/01/07/128458.aspx

[Erik]

harvey said: "You do a shallow analysis, which often is incomplete and lacks any real substantiative details, and then proclaim it as some newly discovered wisdom."

...and, like sheep, many form a flock and follow along without question.

[vikas]

I think what Anne means is ESB or service bus is dead. Long live the service cloud.

[Carl Parziale]

Anne, as a Service Owner, I will offer you my support of your premise. I run a service owning team in a large enterprise and have spent a lot of wasted time evaluating, reevaluating, and re-reevaluating SOA-branded products that solve many imaginary problems. Its cost my team thousands of hours of distractions to work with the SOA-driven outside influences, usually ignoring the context and purpose of the actual Services. Many of the products add dubious value but cost significant time and money.

Much of 2006-2008 we've spent building up our service inventory using a manufacturing paradigm migrating into a managing and operating paradigm ( indecently, we've chosen Software Product Lines as our manufacturing paradigm), we've built unit cost models and proven reuse savings with little interest from our executive leadership who are typically more enamored with the SOA vendor product rather then the details about the Service. From a manufacturing standpoint, it only makes sense to focus on the actual product, LEAN manufacturing prescribes removing the waste factors, focus on the basics necessary to manufacture and manage the core product first, then move into the more exotic areas later. SOA started backwards, pay for all the exotic infrastructure, repositories, 'buses', etc.. first.

As you stated the "why you're doing it?" part was never just to do SOA. We built our Services specifically with other goals in mind, we were retiring older integration technology, leveraging price brakes on new technologies, decoupling between user applications and Core data owning systems, adding alternate availability architecture options, etc... We have been very successful at all those goals, hence we believe we have success. Added benefits are that new delivery efforts move a lot faster using services then older integration methods, and we hope next generation projects can leverage BPM and Mashup technologies.

However, we did waste a lot of time on the shiny new SOA things. Had we invested in the service inventory instead of the shiny-new things we would have a more robust inventory.

Overall...good advice...focus on the Service first.

Let the exotic come later.

[Nick Gall]

Since trackback didn't work, please see my response here: http://blogs.gartner.com/nick_gall/2009/01/06/long-live-the-web/

[Paul Wallis]

Anne,

My post "Understanding SOA" from last April sheds some light on a few of the issues raised in this thread. It discusses:

SOA definition
ARCHITECTURE
SOA ARCHITECTURE PRINCIPLES
TECHNOLOGIES
SERVICE DISCOVERY
IDENTITY MANAGEMENT
CONCLUSION

http://www.keystonesandrivets.com/kar/2008/04/understanding-s.html

PJW

[Mike]

SOA has a different context in the commercial world than it does in the Federal space. SOA within the DoD includes but not limited too: The adoption of Open Source Methodologies, Best Patterns and Practices, and Standards. The fall of the economy forces the Government to anaylze how and where they can begin to cut cost. The cost is reduced dramatically when SOA is applied to Software Projects withing the DoD. What a concept, expose all data and apps via services between agencies. SOA is not dead within the DoD as it may be within the commercial space. We still have a long way to go within the Federal Space.

[Pierre Fricke]

Anne, I see your recession, raise to a depression and still contend SOA will remain important. Happy New Year! :-)

http://blogs.jboss.com/blog/pfricke/2009/01/06/Economic_Depression_and_the_Rise_of_Open_Source_SOA_and_Business_Rules.txt

[Piet Jan Baarda]

Good discussion! Here's an article I wrote on the true value of SOA - its business services: "Your SOA needs a business case"
http://www.via-nova-architectura.org/files/magazine/Baarda.pdf

[Pierre de Leusse]

Interesting article, however like many here I fail to understand how SOA can be dead when you promulgate the raise of service. If you have services you need architectural models to use and manage them in.

So yes, maybe changes in the way it’s sold and evolution of its structure (let’s face it we’ll never stop arguing over the pros and cons of architectural models or technologies), but death of an IT domain is a bit stretch… for the death of a buzz, only time will tell us.

[Amin Abbasopour]

'Anne' is a new word in dictionary meaning 'insight + courage'.

http://aminsblog.wordpress.com/2009/01/08/soa-is-dead-long-live-service-oriented-architecture/

[Duc Nguyen]

Ah! yes! A decent new resolution for all!
Seriously, however, most organization fail on SOA due to the "wishful" thinking of "one-stop shopping" solution. There are two main areas for SOA to succeed: (1) Service alignment between business and IT, (2) Service development within IT. And... we all know about the "openness" or lack thereof of the folks in the two disciplines to collaborate. If that hurdle can be overcome, then the service contracts hit the IT department just to find that IT may not be ready to complete it. Such simple things as UDDI registry or SOAP stack etc. are not there just yet - remember IBM came out with WSSR due to their claim of UDDI's inflexibility in an agile and actionable SOA environment. So now... Anne is right then? Even with its demise, SOA still left a decent framework for IT - don't you think? Ask Mr. Erl?

I like Tobias' breakdown of the components for a "pre-SOA" environment, but prefer in the following sequence:
(1) BPM (most platforms seem mature.)
(2) Services (web or not)
(3) ESB (for legacy systems)
(4) maybe SOA - at least something close to it.

At least these are my 2009's resolution!
-Duc

[Fred Cummins]

SOA is not dead though it's reputation has been tarnished by exploitation and misguided attempts at implementation. See my blog "SOA Is Not Dead--Just Misunderstood" at http://www.eds.com/sites/cs/blogs/eds_next_big_thing_blog/archive/2009/01/06/soa-is-not-dead-just-misunderstood.aspx?CommentPosted=true#commentmessage

[Sebastian]

Trackback: http://www.arisblog.com/2009/01/07/technical-soa-is-dead/