"SOA is dead; long live services."

This 3rd edition of "¡APIcryphal!" retells Anne Thomas’s 2009 declaration that "SOA is dead; long live services." With hindsight, was the explosion in online disagreement warranted?

Occasionally, among the daily business-as-usual, moments emerge that change the course of entire industries. The API landscape is a space as molded by legend as any other. While their accuracy to actual events remains debated, these tales remain the cornerstones of hallway tracks and executive talking points. These are API's apocryphal stories - the ¡APIcryphal!

TL;DR:

While the implementation has changed, the stories (and challenges) in implementing service-oriented architecture remain the same.

Observance

Throughout software's history, developers have sought new ways to connect multiple computers together. The need was especially acute at the dawn of the new century. After the dot-com crash and subsequent recession, businesses faced increasing global competition, growing legacy IT complexity, and rising pressure to reign in costs.

IT leaders sought more modularity and reusability from their software investments. What they found instead was a confluence of protocols, specifications, architectural ivory towering, middleware, vendor support, and analyst hype that together became known as Service-Oriented Architecture (or SOA).

While Gartner analyst Roy Schulte defined service-oriented architecture in 1996, it wasn't until the emergence of web services in 2002 that it became an adoptable architecture. Creating discrete, loosely-coupled functions and recombining them into interoperable, standards-based services required SOAP/XML messages exchanged via HTTP (program language interoperability via an increasingly ubiquitous, non-proprietary protocol). As this pattern proliferated, several vendors began providing an enterprise service bus (or ESB) to further loosely-coupled enterprise application integration.

By 2007, Anne Thomas already had a long and distinguished career advising large companies on application platform strategies. As a research director with the Burton Group, she frequently talked and wrote about software integration. In an interview at the time, she justified SOA this way:

"SOA is about reengineering the IT organization and changing the way you design systems and the way you manage your systems. Today about 80% of an organization's IT budget is spent on legacy systems and only 20% is spent on new development and innovation. And that 80% of the IT budget typically accounts for something like 70% of a corporation's capital expenditures per year. And what's really amazing is that most organizations never bother to look at this enormous allocation of funding. But that's actually where you want to apply your SOA principles, to that existing system. And if you think about how much money gets sunk into legacy systems you realize there are a lot of opportunities for us to fix IT and that's what SOA is about, it's about fixing IT. IT is fundamentally broken and you need to fix it and the only way to do that is by going in and reassessing and reengineering the IT process. And SOA is a completely different way to design systems that is no longer looking at it from an application project by project basis but looking at it in terms of very expensive assets that need to be managed more effectively."

Fueled by these arguments, enterprises embarked on large, multi-million dollar SOA "transformations". By early 2009, research and advisory company Forrester claimed that 27% of the largest enterprises surveyed currently had SOA in place, while another 33% were 'moving in that direction'. Likewise, the Harvard Business Journal reported that companies that embraced SOA "have eliminated huge amounts of redundant software, reaped major cost savings from simplifying and automating manual processes, and realized big increases in productivity".

While the analysts and business press painted a rosy picture, results in practice were harder. Many of these SOA efforts quickly ran into problems, failing to deliver either the flexibility or the promised cost savings. The pall of the Great Recession, starting in December of 2007 and spiraling through the rest of the decade, also led to significant corporate financial belt tightening.

By 2009, SOA's lackluster results and the darkening economic outlook became too much for Thomas to ignore. In January, on the Burton Group's blog, she declared, "SOA is dead. Long live services":

"Once thought to be the savior of IT, SOA instead turned into a great failed experiment—at least for most organizations. SOA was supposed to reduce costs and increase agility on a massive scale. 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. The people holding the purse strings have had enough. With the tight budgets of 2009, most organizations have cut funding for their SOA initiatives.

"It’s time to accept reality. SOA fatigue has turned into SOA disillusionment. Business people no longer believe that SOA will deliver spectacular benefits. 'SOA' has become a bad word. It must be removed from our vocabulary."

The response, especially among industry analysts who made their living from SOA-related offerings, was immediate. Follow-ups referred to the piece as "igniting a blogosphere firestorm". Harvey Stage, in a comment on Thomas's original piece, referred to it as "a boat load of regurgitated crap." David Worthington, who was in the process of producing a comprehensive report on how to make SOA implementations successful, derided Thomas as "the Ann Coulter of the analyst community" and referred to the piece as "a needless dalliance into sensationalism". SOACenter.org - a website that once promoted SOA best practices, renamed itself to "whatevercenter.com".

Interpretation

In her article and subsequent clarifications, Thomas's point is that services remained valuable - more now than ever. The problem, however, had become the fuzzy amalgamation marketed as SOA. From the same declaration that SOA was dead, she says:

"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."

And later:

"The latest shiny new technology will not make things better. Incremental integration projects will not lead to significantly reduced costs and increased agility. If you want spectacular gains, then you need to make a spectacular commitment to change."

This was not a new concern. Thomas had long maintained that mistaking ESB for SOA would end in disappointment. In that 2007 interview I previously cited, Thomas argues that technology was one of the least important factors when it came to SOA success:

"Where people are today? Well they're either just doing experimentation and they are really focusing mostly on the technology. Or they've gotten beyond that stage and they realize that SOA has nothing to do with technology and has everything to do with how you build systems. And they are at that point trying to figure out how to reign things in and get them under control. Or they have actually got to the point where they realize that governance is the main piece of making SOA work and there are not very many people at that point yet."

In the same way that the industry had misinterpreted SOA, so too was Thomas's message. In a follow-up conversation, Anne Thomas expressed disappointment that all too many interpreted her declaration to mean that big SOA would be replaced by "little SOA". If anything, she believed that the reason that SOA efforts failed was because companies didn't go big enough:

"But in all of our research last year, talking with people about their SOA initiatives, it wasn't the SOA that had succeeded, but the IT transformation effort. SOA was just one aspect of that transformation."

"SOA needs to be part of a major transformational effort if you want to get the spectacular gains that everyone is talking about. As I said in the blog, if you want spectacular gains, you have to make a spectacular commitment to change."

Notable among the commentary to Thomas's declaration is the large number of software architects. They, too, blame an underinvestment of enterprise architecture as contributing to the problem. With hindsight, the hand-wringing on display hints at an unstated unease with the larger changes transforming IT - changes that were also eroding the role of enterprise software architecture.

This period coincided with several approaches emphasizing developer empowerment at the expense of "traditional" top-down functionaries, like enterprise architects. The Agile and DevOps processes placed more of the architectural decision making in the hands of individual teams. Cloud and Platform-as-a-Service (PaaS) solutions allowed software developers to sidestep expensive and time-consuming processes set up to weigh in on larger capital expenditures, like architecture review boards. The proliferation of open source technology stacks and "mature enough" standards reduced the need for specialized architecture skill sets to get started.

This shift, in time, would reveal its own set of problems. However, in the harsh economic realities of the late-aughts, companies shied from efforts like Thomas's "spectacular commitment to change". Instead of seven-figure, big bang, enterprise spanning installations, software teams experimented with "small SOA". These REST-ful approaches - which may have been less feature-rich and limited- provided more immediate value in a shorter amount of time. These incremental, team-lead efforts were something that 2009's risk-averse enterprises could more easily stomach.

Ross Mason, who at this time was Mulesoft CTO, wrote one of the few positive vendor responses to Thomas's piece saying just as much:

"-the large vendors have sold this ‘massive-shift' to companies with a hefty license price tag and endless services engagements. The fact that SOA requires a fundamental change has been the undoing of traditional SOA initiatives. The main hurdle that is often overlooked is the natural human resistance to change. The challenge of SOA is to be able to demonstrate change in a way that is recognizable by the people it affects. It doesn't mean hooking together a suite of enterprise tools and dropping documents of new processes on people's desks."

Keys

For people who work in the distributed systems space, the parallels between the aspirations of Service-Oriented Architecture (SOA) and today's RESTful API tenets are striking. SOA celebrated loosely coupled services and platform-agnostic interoperability, the same outcomes as contemporary API architecture. SOA was more than protocol and design outcomes, however. It also grew to encompass governance, service-level agreements, metadata definitions, and registries. Much like mature API practice today, SOA came to represent a holistic approach, intertwining technology with organizational processes.

Yet, despite these admirable objectives, SOA's practical applications often fell short, leading many enterprises to abandon their significant investments eventually. SOA's spurning is not just historical trivia but a cautionary tale for our API efforts.

How did a good idea go bad? Here is a summary of key lessons:

• Big Bang Execution Creates Immediate Complexity: SOA's "entire company at once" (and thus every use case at once) often translated into unwieldy complexity while processes, controls, and understanding were still being formed. The proliferation of services, intricate service contracts, and convoluted interactions without the hardened means to handle them led to burdensome systems to manage and scale.
• Promoting SOA as an End in Itself: As SOA became a more prominent marketing and architectural talking point, it became overstuffed to the point of misinterpretation. Without an alignment with business objectives, meaningful ROI evaporated.
• Prohibitive Costs Raised Hesitation: Establishing a robust SOA infrastructure for the entire organization at once was often costly. The belief that a specialized middleware, like ESBs, was necessary compounded these expenses, deterring smaller or budget-constrained projects.
• Performance Bottlenecks Undermined Confidence: The heavy inter-service communication in SOA, particularly in distributed settings, introduced significant performance lags. This resulted in sluggish responses and diminished efficiency.
• Vendor Entanglement Led to Proprietary Pitfalls: Despite interoperability being a core principle, early SOA adopters discovered many vendor-specific solutions had limited standardization and lacked interoperability with other solutions. This vendor lock-in complicated component integration and hindered transitions to alternatives.

Taken together, an approach that had promised flexibility, reusability, and lowered overall complexity and IT costs for the organization ended up doing the opposite. Anything less than high execution across various SOA areas resulted in increased rigidity, leaving companies unable to adapt to evolving business demands.

As alternative approaches, like web-centric RESTful approaches and, later, microservices, companies were quick to adopt. These newer methods offered a blend of SOA's benefits with enhanced simplicity, flexibility, and scalability.

Reversal

Anne Thomas declared SOA dead in 2009. Only a few companies, such as Bechtel, British Telecom and MassMutual, were ever cited as having done SOA well - a shockingly small list of examples. It is also true that vendors aren't touting new SOA products, Analysts, like Gartner, long ago dropped SOA from their lexicon. However, paradoxically, it could be argued that we're using more service-based architecture than ever.

This apparent contradiction hinges on our definition of SOA. If we distill SOA to its essence – focusing on services and the architectural orchestration of business processes around these services – then it's evident that SOA, in spirit if not in name, is ubiquitous in contemporary corporate IT strategies.

However, such a broad definition of SOA has its problems. Our permissive definition could encompass a wide array of earlier technologies and approaches, extending even to the CORBA and DCOM integrations of the 1990s. While "service-oriented" in their own right, they bear little resemblance to today's agile, cloud-native paradigms. Avoiding this overgeneralization requires refining our understanding of what constitutes SOA in the modern context.

If we instead view SOA through a narrower lens – emphasizing not just the use of services but also specific attributes like loose coupling, interoperability, and a strong alignment with business goals – the picture changes. By this definition, what we often see today may diverge from traditional SOA, aligning more closely with microservices architecture, API-first design, and cloud-native development. While rooted in the principles of SOA, these paradigms represent an evolution of the concept, tailored to the demands of today's fast-paced, Internet-driven business environment.

SOA principles were not bad. But the specific implementation of those ideas was, and, unfortunately, that implementation became synonymous with the effort.

As Thomas said, "SOA is dead; Long live services".

Legacy

Anne Thomas continued her long and distinguished career. In 2013, she co-authored the book, "Web Services, Service-Oriented Architectures, and Cloud Computing, Second Edition: the Savvy Manager's Guide". She is now a VP and Distinguished Analyst at Gartner, who purchased the Burton Group a year after Thomas declared SOA dead.

The declaration that SOA is dead and the hand-wringing over definitions might lead to some very cynical conclusions. Steve Jones, writing at the time, stated:

"SOA is Dead is a headline that vendors need so they can start flogging Mashup Servers, Cloud Integration Platforms and the 'next big shiny thing'."

A more pragmatic take may be to understand the power of storytelling within modern business contexts - even when that story is a single acronym. The correct label can excite and energize. The wrong word comes loaded with baggage. That's not a technology challenge but a "soft skills" one. Mike Kavis put it this way:

"We lack leadership skills and emotional intelligence. When was the last time you saw IT leadership who excelled in Technology, Business, and People Skills? Your are lucky if they are good at two of these but to deliver transformational technology based initiatives they need to be skilled in all three (see The Missing Link in IT).

"But these are not SOA specific issues. IT has historically struggled with enterprise wide initiatives because they require more than just technology to implement. Look at IT's track record delivering ERP, CRM, new software development lifecycles (SDLC), agile, six sigma initiatives, etc. All of these require an organization, not just IT, to change behavior, standardize, and work in harmony to achieve a common set of goals."

SOA's legacy is complex and continually made more so through its modern reinterpretations. Whether we view SOA as a relic of the past or a foundational element of present-day IT architecture depends mainly on how we define it. SOAs principles continue to influence contemporary software design, albeit in forms that have adapted to the changing technological and business landscapes. While the names have changed, the story (and challenges) remain the same.

Update 2023-12-19: This article has been updated to reflect the name Anne Thomas, which is the current name used by Anne Thomas Manes.