In retrospect, the history of Service-Oriented Architecture (SOA) over the last fifteen years or so is decidedly mixed. Some enterprises achieved varying levels of success with something they called SOA to be sure – but in the majority of cases, those successes were hard-fought and expensive.
Many other SOA initiatives, unfortunately, fell more into the failure column – perhaps delivering some services, but overall failing to achieve the goals set out for them.
This SOA mixed bag resulted in large part from confusion over what SOA actually was: architecture or implementation style?
In one camp, architectural purists claimed SOA was about abstracting software capabilities and data to provide greater agility, independent of any particular technology choices.
In the other camp, middleware vendors, frantic to keep their gear relevant to an increasingly fickle enterprise buyer, redefined SOA as the Enterprise Service Bus (ESB), or at best, something you do with one.
The vendors largely won that battle – and SOA became little more than an excuse to buy more middleware.
Then along came the cloud. And everything changed.
Achieving Clarity on ‘Legacy SOA’
The rise of the cloud in the late 2000s shifted the enterprise focus away from on-premises infrastructure, and introduced or expanded architectural priorities like elasticity and resilience.
Within this evolving enterprise architectural context, new and updated technologies like containers and microservices are now coming to the fore, and with them updated architectural principles we are now calling Microservices Architecture (MSA).
Some of the tenets of MSA unsurprisingly hearken back to SOA. In truth, SOA principles have continued to evolve, and now find themselves intertwined with the principles of MSA.
But don’t be fooled – SOA and MSA are two very different approaches targeting largely distinct problem sets.
In fact, arguments over the relationship between SOA and MSA are largely red herrings. What matters isn’t what SOA should have been, or even what modern SOA would look like now. For those enterprises who achieved some measure of success with SOA, SOA as implemented is far more important than how SOA should have been implemented or how it would be implemented today.
Make no mistake: there’s plenty of SOA-as-implemented to go around: implementations of SOA dating mostly from before the cloud took off, what I’m going to call legacy SOA.
Legacy SOA depends upon middleware, typically an ESB – or more generally, several pieces of middleware from different vendors and vintages, somehow chained together into what’s now an inflexible mess.
And then there are the services: SOAP-based Web Services to be sure, but there are plenty of legacy SOA deployments out there with REST-based services as well.
As with most legacy, these services are still perking away. They’re providing the same value they provided the day they were deployed, regardless of the type of service.
Legacy SOA vs. MSA: Different Tools for Different Times
There is widespread confusion over the relationship between SOA and MSA, in large part because people don’t understand what’s happened to the word service.
In the legacy SOA days, a service was an abstraction: a discoverable, composable interface to existing software assets. The goal of legacy SOA was to increase business agility in the face of heterogeneous software and data assets to support dynamic business requirements.
In other words, legacy SOA was in large part about dealing with legacy assets – making them more consumable and flexible in order to simplify integration.
A microservice, in contrast, is a unit of execution. In fact, Intellyx’s definition of a microservice is a parsimonious, cohesive unit of execution. Instead of being an abstraction like the services of days of yore, a microservice is the software itself.
We can thus expose microservices with RESTful interfaces we might call services, but that namespace collision is beside the point. The real lesson here is that microservices are primarily for building new software, while legacy SOA was for taking existing software and making it easier to integrate.
Repositioning ‘Enterprise Services’
From the standpoint of modern, digital initiatives, the legacy SOA that remains in place exposes what organizations are increasingly calling enterprise services. Such services might be Web Services, RESTful services, or even other, less common types of interfaces, but they are unlikely to be microservices.
Instead, enterprise services represent interfaces to legacy assets – assets that may be essential to today’s modern digital efforts.
Enterprise digital initiatives, after all, rarely live exclusively on the customer-facing front end of the organization. Instead, supporting modern customer priorities requires that IT organizations bring end-to-end capabilities to bear.
The archetypical example: mobile banking. True, the mobile app is what customers interact with – but most transactions have to make the full round trip to the mainframe and back.
If such a bank has legacy SOA in place, then much of the heavy lifting to make those back-end system of record transactions available to front-end apps has already been done. Legacy SOA not only exposes those back-end transactions as services, but typically manages their performance and security as well.
In other words, legacy SOA enables modern enterprises to plug legacy, on-premises application and data assets into modern, digital efforts in a straightforward, managed, and secure manner.
The Intellyx Take: When to Retire Legacy SOA
If you have legacy SOA in place and the enterprise services it provides are still providing value, then count yourself lucky – and be sure to follow the all-important IT maxim ‘if it ain’t broke, don’t fix it.’
Not every organization is so lucky, however. Legacy applications and systems can suffer from a plethora of maladies, from obsolete functionality to expiring maintenance contracts to retiring support personnel.
Sometimes the right call is to update the legacy assets. Developers can often maintain and update mainframe software in particular, thus extending the value of such platforms well into the future.
In other situations, an IT shop will realize that some old system or application has finally reached the end of the line and needs to be relegated to the scrap heap.
The good news: if you’ve exposed any of these legacy assets via legacy SOA, the presence of the architecture simplifies any decisions regarding the disposition of your legacy assets. The better the abstraction, the easier it is to make changes beneath it.
However, if the middleware that runs your legacy SOA deployment is the target of your modernization efforts, the situation is more complex. It’s rarely practical or cost-effective to switch out older middleware for a newer integration solution without making more extensive changes to your architecture, even if you’re shifting to Integration-as-a-Service in the cloud.
The good news: when the time comes to retire those ancient ESBs, you’ll likely be good and ready to rework your legacy architecture in any case. Modern, cloud-based alternatives to legacy SOA beckon. Perhaps it’s time to heed their call.
Copyright © Intellyx LLC. Intellyx publishes the Agile Digital Transformation Roadmap poster, advises companies on their digital transformation initiatives, and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credit: Gawler History.
