As I move about the industry talking about APIs (application programming interfaces) and the API economy — which hold important and transformative business opportunities — I’m frequently confronted with disparaging remarks about SOA (service-oriented architecture), as if it’s passé, gone, finito. It’s often in the way of (uninformed) assumptions about SOA. I hear things like, “SOA failed because it was too difficult” or “People do REST APIs now, they don’t do SOA” or other such bunk.

I’ll be the first to extol the importance and benefits of APIs, but the tales of SOA’s failure and demise are simply wrong (I really do like APIs; see this report). I had a powerful reminder of all this while attending IBM’s IMPACT conference this week. First off, I arrived late to one customer’s plain-vanilla “this is our enterprise SOA journey” session only to be refused entry because the room was over capacity. Glancing over the conference program, there were at least eight such sessions representing four continents and at least five vertical industries. I attended five of them and also had lunch with another SOA leader. The stories could all be summarized by the following plot line:

  • We saw the value in SOA. Whether the need was multichannel customer engagement, faster time-to-market, retiring legacy, getting past complex and costly point-to-point integration, dealing with duplicate applications, or some other business-technology problem, a core team recognized that SOA could make things better.
  • We slowly built SOA steam by delivering value from one project to the next. Whether by finding a modicum of support among executives or by working one-on-one with delivery projects, the core SOA team built small successes, then bigger successes, then gained a more-or-less enterprise commitment to SOA. On the whole, funding was on the backs of projects.
  • We realized early on that SOA needs a business approach. A technical approach to service design leads nowhere, generally speaking. The most valuable design point for services starts with queries and transactions that a businessperson can understand (see Business-Focused Approach to SOA)
  • We’ve learned a lot and built-up some important SOA best practices. These SOA success stories sounded only vaguely like the SOA hype of the 2000s. That’s because, like flossing your teeth and going to the gym, organizational maturity and discipline don’t make good hype (see SOA Governance Improves SOA Benefit Realization).
  • We still have struggles and there are ways we need to improve. Every organization recognized that, even though they had achieved great value from SOA, they still had problems. Paying close attention to service interface design and building interteam collaboration are deeply embedded in the Five Most Valuable SOA Practices.
  • It’s onward and ahead with SOA to greater maturity and more business value. Each of these organizations saw more, better, and deeper value through continuation and deepening of their investments in SOA (see the high SOA satisfaction from back before Forrester deemed SOA to be de rigueur and so stopped surveying about it)

For none of these major organizations at IBM IMPACT was SOA in any way passé, gone, or finito. Actually, I continue to get client inquiries about starting on SOA, or else on rebooting an SOA program that was previously built on theoretical, industry half-truths about SOA. . .for very good reason.

By picking on SOA struggles while ignoring the high levels of SOA satisfaction, the industry’s reverse-hype on SOA has been quite misleading. You should ignore it in the same way that it was right to ignore the over-hype that led some into shallow, theoretical approaches to SOA. From my many SOA conversations over the years, I’m convinced it’s the shallow approach to SOA that leads to the consistent 2% or 3% that say they tried SOA and didn’t like it. Let me say that a different way: Over years of surveys, only 2% to 3% of those trying SOA have decided to give it up.

For the strong majority, the value delivered by SOA has been quite large enough to overshadow the costs and pains and missteps of SOA struggles. They’ll carry on using SOA to deliver strong business agility, and then they’ll use APIs to extend their business agility into many new business contexts and scenarios (see my bit on Business Agility And API & SOA Maturity).