Earlier this year, service-orientated architecture (SOA) was pronounced dead by Burton Group analyst Anne Thomas Manes.
Manes' provocative “ obituary ” generated a lot of attention and sparked much-needed debate , but most commentators missed the point. While the title 'SOA is dead' certainly grabbed the most attention, it’s important to remember Manes' position: The approach of service-orientation is still needed, but the three letter acronym S-O-A has become associated with particular technology choices, project failure and unmet IT expectations. That is, says Manes, the acronym S-O-A should die and new approaches and commitment to service-orientation should be embraced.
The people that are burying SOA today are often the same who promoted it a few years ago when J2E was “dying”. How quickly people burn the idols they have created only to idolise another!
All new ideas need time to become accepted. But the global economic downturn may have tightened the vise, so-to-speak, and increased pressure for immediate return on investment, which leaves no time for service-orientation to mature.
Do we ever get something right in the first attempt? In other words, while initial attempts at SOA may fail, that doesn’t prove the principles behind the technology are wrong or without merit.
So what’s wrong with how we’ve been adopting SOA to date?
SOA has been more complicated than expected
Remember, the “S” in SOAP means simple! SOA was supposed to be easier than CORBA and J2E. But why did we expect SOA to be any less complicated than its predecessors?
When you want to design non-trivial business applications by assembling and deploying distributed components, you will likely have to deal with complexity.
Using HTTP / SOAP instead of IIOP and WSDL instead of IDL does not fundamentally change this. The problem is still intrinsically complex.
SOA has been too process-centric
Initial SOA projects have tended to focus on implementing business services in support of high-level business processes or system-to-system integration.