Vision and leadership for developing and implementing information technology initiatives

Chief Information Officer

Subscribe to Chief Information Officer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Chief Information Officer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

CIO Authors: Jason Bloomberg, Jeffrey Abbott, Charles Araujo, Adrian Bridgwater, Ed Featherston

Related Topics: Cloud Computing, Agile Software Development, Change Leadership Journal, CIO, SOA Best Practices Digest, Microservices Journal

Agile Development: Article

What to Do with ‘Legacy SOA’

SOA became little more than an excuse to buy more middleware. Then along came the cloud. And everything changed.

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.

More Stories By Jason Bloomberg

Jason Bloomberg is a leading IT industry analyst, Forbes contributor, keynote speaker, and globally recognized expert on multiple disruptive trends in enterprise technology and digital transformation. He is ranked #5 on Onalytica’s list of top Digital Transformation influencers for 2018 and #15 on Jax’s list of top DevOps influencers for 2017, the only person to appear on both lists.

As founder and president of Agile Digital Transformation analyst firm Intellyx, he advises, writes, and speaks on a diverse set of topics, including digital transformation, artificial intelligence, cloud computing, devops, big data/analytics, cybersecurity, blockchain/bitcoin/cryptocurrency, no-code/low-code platforms and tools, organizational transformation, internet of things, enterprise architecture, SD-WAN/SDX, mainframes, hybrid IT, and legacy transformation, among other topics.

Mr. Bloomberg’s articles in Forbes are often viewed by more than 100,000 readers. During his career, he has published over 1,200 articles (over 200 for Forbes alone), spoken at over 400 conferences and webinars, and he has been quoted in the press and blogosphere over 2,000 times.

Mr. Bloomberg is the author or coauthor of four books: The Agile Architecture Revolution (Wiley, 2013), Service Orient or Be Doomed! How Service Orientation Will Change Your Business (Wiley, 2006), XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996). His next book, Agile Digital Transformation, is due within the next year.

At SOA-focused industry analyst firm ZapThink from 2001 to 2013, Mr. Bloomberg created and delivered the Licensed ZapThink Architect (LZA) Service-Oriented Architecture (SOA) course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, which was acquired by Dovel Technologies in 2011.

Prior to ZapThink, Mr. Bloomberg built a diverse background in eBusiness technology management and industry analysis, including serving as a senior analyst in IDC’s eBusiness Advisory group, as well as holding eBusiness management positions at USWeb/CKS (later marchFIRST) and WaveBend Solutions (now Hitachi Consulting), and several software and web development positions.