Anne Thomas Manes put out an interesting post yesterday, declaring that SOA has failed, but there are a few FWBs (features with benefits), that we should still consider.
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."
I'm actually having Anne on the podcast this week to talk about this.
So, what do I think? In short, she may have something there, and I've been hitting on these issues for years now.
Indeed, while SOA is possible, and has a bunch of value, most of those out there tasked to implement SOA were doing so with all the talent of trained monkeys, and just could not get down to the basic issues of architecture, instead focusing way too much on technology and the hype. In short, the efforts were focused in the wrong directions and now there is little to show for it.
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.
I was actually hopeful that somehow, someway SOA would transcend some of the practice issues I saw around EAI. Indeed, most enterprises are dealing with a huge mess, and it's a good idea to begin to cleaning things up. Right? SOA was and is a great approach for doing that, but many charged with making SOA work just could not get out of their own way.
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.
So what went wrong?
First, there are not enough qualified architects to go around, and you'll find that most of the core mistakes were made by people calling themselves "architects," who lack the key skills for moving an enterprise towards SOA. They did not engage consultants or get the training they needed, and ran around in circles for a few years until somebody pulled their budgets.
Second, the big consulting firms drove many SOA projects into the ground by focusing more on tactics and billable hours than results and short- and long-term value.
Third, the vendors focused too much on selling and not enough on the solution. They put forth the notion that SOA is something they have to sell, not something you do.
Finally, the hype was just too much for those charged with SOA to resist. Projects selected the technology first, then the approach and architecture. That's completely backwards.
However, this failure does not diminish the need for SOA. Indeed, most enterprise architectures are a mess and are getting messier as the years go by. Moreover, if you just look at the inefficiencies within the current IT infrastructure you can easily make a case for SOA.
Although the word "SOA" is dead, the requirement for service-oriented architecture is stronger than ever.
Can't disagree with that. Good luck.