Blogger: Anne Thomas Manes
Thanks to Jeff Schneider for pointing this article out to me.
It's been more than 7 months since I published the "SOA is Dead" post, but responses are still coming in. Most recently (yesterday), Dan Woods published an article on Forbes.com entitled "Reviving SOA". I'm pleased to see that Dan read beyond the first paragraph, and he understands the core message of my post (i.e., "SOA has been disappointing and that services should be a key focus"), he nonetheless fell into a common trap of misinterpretation, as I described in my follow-up post, "SOA Obituary: Misinterpretations and Perceptive Enrichment."
Dan falls into the first and largest camp, "Big SOA is dead, but little SOA will survive." He also has a touch of Camp 2, "REST will fix everything." He claims that "REST" is now more popular than SOAP. By "REST" I can only assume that he means plain old XML (POX) over HTTP, because I can assure you that the REST architectural style is much less understood than SOA. And a recent survey of Burton Group clients (mostly F500 companies) clearly indicates that REST is not yet a popular topic among large enterprises -- as much as I try to promote it.
Dan recommends an incremental approach to SOA: Just build services as you need them on a project-by-project basis, and at some point in the future you can go back and consolidate the services you've built and somehow derive some architectural consistency. Unfortunately, this strategy invariably leads to Just a Bunch of Web Services (JABOWS) because the future consolidation step almost never happens. The result is too many services, too many moving parts, and too many brittle connections. Systems wind up being more expensive and more fragile than ever before. #FAIL
I've only encountered one company to date that has succeeding using this method -- and I must point out that they maintained strong architectural governance of all services as they were built.
In particular, Dan misinterpreted my comment, "If you want spectacular gains, then you need to make a spectacular commitment to change." He took this as a recommendation, when it was really intended as a warning.
One of the biggest reasons that SOA "died" is due to unrealistic expectations. The hype has suggested that all you had to do was deploy an ESB and use web services and miraculously you would gain reduced costs and increased agility. The truth, though, is that architectural improvement does not come for free. It requires a concerted effort to improve the application architecture. If you aren't willing to make that concerted effort, you won't gain spectacular results.
The Bottom Line:
The highly-touted benefits of SOA derive from architectural improvement, not from any particular technology. But architecture is hard. And it requires a fair amount of organizational maturity to accomplish. Organizational maturity is a function of five organizational dynamics:
- Governance: Establishing policies, guidelines, and decision-making authority
- Management: Enforcing policies and directing day-to-day operations
- Leadership: Inspiring people to perform
- Skills: Ensuring people know how to do what they need to do
- Practices: Establishing structure that helps people do what they need to do
Attempting to do SOA without also attempting to strengthen these five organizational pillars will invariably result in failure. Hence my warning: If you want a spectacularly successful SOA initiative, you must first address these organizational and cultural issues. Strengthening these organizational dynamics invariably requires a spectacular commitment to change.