Say it isn’t so.
Or, more aptly, say it isn’t SOA….
Anne Thomas Manes says that service oriented architecture — at least in the form we’ve known it — has finally hit the wall. It hasn’t been delivering ROI, and organizations need to move on to better and faster initiatives. She says the current economic downturn has driven a stake through the heart of a methodology that was, in her opinion, already barely clinging to life.
‘SOA’ a casualty of failed expectations, or of semantics?
Anne posted the following “obituary” for service oriented architecture:
“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 started this particular blog back in November of 2004, and have heard SOA declared dead over and over again through the ensuing years. (My favorite phrase — “SOA is DOA.”) Indeed, SOA has received more than its share of overblown hype, vendor over-promising and oversimplification, and market confusion. Are things any different now?
Anne says companies have been fiddling with SOA for some time now, and to little or no avail. SOA “turned into a great failed experiment—at least for most organizations. SOA was supposed to reduce costs and increase agility on a massive scale,” she explains. “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.”
In her post, Anne adds that the “people holding the purse strings have had enough. With the tight budgets of 2009, most organizations have cut funding for their SOA initiatives.” I haven’t seen any data that says this is so, even in recent months, and Anne doesn’t point to any. Economic turmoil could drive companies the other way — to seek better ways to leverage existing and align IT assets.
One of the challenges with SOA is that a successful implementation is a multi-year process, since not only do systems and interfaces need to be changed, but development methodologies and incentives need transformation, and the business itself needs to drive the process. Definitely not overnight stuff. As I understand from what I’ve heard about Burton Group’s own investigations, SOA initiatives show a lot of potential when they are first launched, but tend to fizzle after a year or two.
Anne points to the apparent failure of SOA to upend the rest of the business. “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.”
Well put — successful SOA is part of a transformative process that changes the way organizations are managed and do business. And some organizations just seem to “get it” right away. For many companies, however, what they may see as SOA is more JBOWS (Just a Bunch of Web Services) architecture. SOA is a methodology and philosophy. The mix of technologies and approaches employed to work toward SOA will shift. A few years ago, Web services was seen as the way, yesterday it was REST and Web or Enterprise 2.0, and now it’s cloud computing. The beauty of SOA is that it is meant to be independent of the underlying technologies or protocols.
What it comes down to — and Anne stresses this — is the term “SOA” itself gets in the way. (Acronyms really do tend to be counter-productive.) Organizations need to focus on delivering appropriate services to address business problems — and not be distracted by trying to deliver “SOA” as an end-all and be-all. Fix those inconsistent customer data issues, and use service-oriented architecture principles to deliver enterprise-focused services to the users that need them.
It’s all about the services. And the best way to deliver them most efficiently to the parts of the business that need them. But I don’t know about declaring SOA “dead.” SOA is a philosophy, methodology, and set of best practices or patterns that shapes the way enterprises and government agencies address problems through IT. You can kill off the associated technologies and products, but not the ideas and practices. It would be like declaring the sudden death of Agile development, business process management, data integration, re-engineering, or zero-based budgeting.
