Anne Thomas Manes wrote a farewall for SOA in her blog post SOA is Dead, Long Live Services.  InfoQ asked for comment from SOA thought leaders and architects on this matter which created quite a stir and the usual amount of noise as well.  One of the most interesting responses I read was from Stefan Tilkov in his blog post Defending SOA.  Now I cannot resist, but give my perspective.
SOA is an attempt to create an architectural style that embodies the heart of the business – the domain.  In any business the domain is vast and so there are many subdomains or even very distinct domains.  In my workshop on Bootstrapping Your SOA Project, I defined a service very traditionally as providers and consumers connected by some execution context that hides implementation.  Now, I like to abstract it a bit more and think of services as business intentions.  These intentions cut right through the fat and get very close to the bone which is all about the domain.  That’s why I think DDD is at the heart of SOA.

Is SOA dead? Not yet but the vendors are doing a great job of killing it with implementations.

Should SOA die? No.  it’s an architectural style worth cherishing since it deals with legacy and new software at the same time, hence spanning multiple systems (like Stefan Tilkov nicely explains).

Does SOA need an ESB? Not necessarily. I think the ESB is just a pattern that happens to have an implementation called the ESB (vocabulary that sucks!).  I have seen some some really complex solutions with an ESB that would have worked just fine with, for example, a simple RMI call instead.

Is it about Business Process Management? Partially.  When you span multiple systems then you will likely do so with processes.  But it’s all about managing state across multiple systems and what nicer way is there than transferring state, i.e. being RESTful (and I am not talking about REST over HTTP).  This also suggests that you should think asynchronously as well.

Is SOA heavyweight? No.  But the vendors make it very, very heavyweight because that is the core of their economic model.  I like to think about all the little Unix command line tools that you can string together to solve a particular problem, like the FindAndDeleteAllOldLogs capability that is part of the FileManagementService 🙂

What is killing SOA? The lack of readiness for existing systems that comes from existing software development thinking in most teams.  SOA demands that you think about state, scalability, ownership, backward compatibility, testability … things that go towards creating decent API’s for your systems.  And the more vendor swagger we have, the less development teams think about API’s.

Is SOA Dead? Yes.  It was still born.  But it will be reincarnated as SOA when vendors focus on tools to help people discover domains and increase automation, and not creating heavyweight obstructions;  and when developers figure out that domain understanding is vital and writing good API’s  still count – more than ever before.