SOA: A New Answer to the Legacy Challenge

By Jason Bloomberg and Ron Schmelzer

IT fads come and go, so-called paradigm shifts take place with annoying regularity, but legacy systems seem to stick around forever. What large company doesn’t have some important legacy application running on some aging piece of hardware, tucked away in their data center? Legacy comes in many forms: custom-coded applications with long-lost source code, unsupported packaged applications, or mainframe-based programs with proprietary interfaces. While these systems might be showing their age, there’s no arguing that they perform vital, often irreplaceable functions for the company. Legacy systems wouldn’t be such a cause for consternation, if it weren’t for the fact that so much business value resides on these systems—both in the form of essential data as well as critical business logic.

Nevertheless, business continues to require ever increasing levels of agility from the IT infrastructure. Competitive pressures, regulatory mandates and the unceasing search for greater business efficiency all drive IT to be better able to respond to a changing business environment. With every new technology endeavor, however, it seems that IT slips further away from meeting business imperatives. Something must be done! Rip and replace won’t work: It’s too expensive and risky. More middleware sure won’t help—who needs more glue for their glue? And simply throwing more applications or hardware at the problem isn’t going to solve anything—after all, the last thing we need is more legacy. What companies desperately need today is a new architectural approach for squeezing more value out of heterogeneous legacy resources, with enough agility to support an increasingly dynamic business environment. What companies need is service-oriented architecture.

Leveraging Legacy in SOA

Service-oriented architecture (SOA) attracts more than its fair share of hype. Such hype predictably leads to equal measure of anti-hype, which propounds that SOA paints a pretty picture, but once you roll up your sleeves and get into the dirty business of service-enabling legacy applications, you’ll find that the agility, reuse and efficiency benefits that SOA promises are forever out of reach, since services are simply interfaces to existing functionality. The truth, while less sensational, clearly lies between these two extremes.

In fact, there are three basic approaches for incorporating legacy applications into SOA implementations: accessing the data locked inside legacy systems directly, accessing business logic through APIs or other programmatic means, and emulating user interaction through terminal emulation, a.k.a. screen-scraping. As Joe Gentry, vice president of enterprise transaction systems at Software AG points out, “Legacy systems are still very prevalent. Today there are more than 200 billion lines of useful COBOL and other legacy code. Customers are looking for an adaptive approach for using legacy data directly, APIs, or going at screens.”

The choice of which approach to take depends on the specific requirements and technical limitations at hand. While the programmatic approach seems best, since it allows access to the functionality and information directly, in many cases the APIs are inaccessible or inappropriate for direct access. Many companies must therefore resort to screen-scraping. Fortunately, as Gentry points out, “screen-scraping has changed dramatically over the last five or six years. We can take a multi-screen user session and expose it as a service, allowing for sophisticated modernization projects.”

Bottom-Up and Top-Down SOA

Now, these integration approaches are familiar to most data integration specialists. The new twist to the story is that we can leverage them as we move to SOA. The first step to leveraging legacy within SOA is to wrap those systems with service interfaces. However, simply exposing legacy assets as services—what you might call the bottom-up approach—does not by itself provide SOA. Basically, all we’ve done is turn a box of random toys into Lego blocks, so that now they all fit together nicely. But give that box of blocks to some three-year-olds, and there’s no telling what they’ll create. To build that big Lego Godzilla you always wanted, you’ll need a plan and the discipline to follow it. When we let those Legos represent service-enabled legacy assets, the plan—as well as the discipline—constitute SOA.

In fact, you need a high-level plan that can guide the whole SOA initiative, so that you can evolve your technology in a way that meets ongoing business needs, rather than heading off into the weeds. The best way to build SOA involves combining a top-down approach with the bottom-up one. The top-down approach starts with the architects on the project putting together a long-term architectural design. It’s important to have the right level of detail in this plan, since too much detail can slow down the project, and too little can lead to poor architecture. SOA, however, should be bottom-up, as well. If you only take a top-down approach, you’re likely to recommend building Services that are too technically difficult or complex to implement. On the other hand, solely taking a bottom-up approach can yield unnecessary or redundant services.

SOA is no magic cure-all, but if you take the correct combined top-down/bottom-up approach to creating and rolling out the new architecture, then you can achieve dramatic business value, and one of the primary sources for such value is the legacy assets in the organization. Indeed, most large organizations are well on their way to planning and implementing SOA initiatives of one sort or another—and most of these initiatives depend on legacy systems. According to Theo Beack, chief SOA architect at Software AG North America, “In the last 18 months, 80 percent of Software AG customers in North America pursuing integration and modernization projects have centered on SOA. They’re beyond the learning phase now. Instead, they want to know about the ‘how’ and how SOA can help.” In fact, there are no viable alternatives to SOA on the horizon: It’s not a matter of “SOA or what?” but rather, “SOA: when and how.” SOA, therefore, is no flash-in-the-pan IT fad. It’s challenging, to be sure, but there’s no question SOA is here to stay.

Jason Bloomberg and Ron Schmelzer are senior analysts at ZapThink LLC.