The sunset of legacy

Among the most persistent of humanity's aspirations is the quest for immortality. We are all too conscious of the limitations of our bodies and our lives and seek some religious faith, fountain of youth or cryogenic miracle that can sustain us forever. And yet, immortality is an unattainable goal. As such, we shift our ambitions for endless life to the things we do control: our IT systems and solutions that we implement in hopes they stay alive forever. We have long been trained to build our IT systems to last. However, this approach to IT ironically means that we are building things that by definition will become obsolete, given the constant, unpredictable changes in business and IT.

Service orientation, however, promises to change this build-to-last approach to IT. By building inherently flexible systems, maybe we finally have a way to unlock the shackles of legacy. The fact still remains, however, that no company will be able to simply throw out their old applications and systems once they become service-oriented. On the contrary, SOA enables you to get more value out of legacy, actually making it more practical to keep such systems around for longer. So, with service orientation we can keep the old stuff around longer. So, then, will we ever be rid of the old stuff? And more importantly, will SOA lead to technology that is flexible enough to avoid becoming legacy, or does SOA simply create even more legacy?

The Paradox of Legacy
Legacy comes in many forms: custom-coded applications with long-lost source code, unsupported packaged applications, or mainframe-based programs with proprietary interfaces. Some legacy has been around for years, but even more exasperating is the relatively recent kind of "modern" legacy applications, branded with that appellation because some change in business or IT priorities has abruptly relegated the once-current application to the realm of legacy. 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. Replacing these systems is simply not an option for most companies. After all, if it were easy to retire these systems, there wouldn't be nearly as many of them around.

The paradox of legacy is that for most enterprises, legacy systems are too old to justify ongoing improvements, but are nevertheless too important to retire. As a result, companies often continue to maintain their investments in legacy systems even though the returns they receive from those systems diminish over time. Yet, there must be significant value in the legacy systems to continue using them in the first place. Each legacy system traps some core business logic or functionality, awaiting some new technology to free that capability and allow the organization to finally retire their ancient systems.

No More Legacy in the Service-Oriented Enterprise
SOA is that new technology. Fundamental to service orientation is a separation between the business requirements and logic, defined in the form of business processes, and the technology, consisting of the infrastructure that underlies the services layer of abstraction, including all legacy applications and the business logic they have locked up inside them. In a properly architected SOA, business services represent the data available to the business and the core functionality of the underlying systems. Business people then compose those services into service-oriented processes, configure the processes based upon the applicable business rules and policies, and then expose those processes as services that other people can compose into new processes. The important point to understand is that service-oriented enterprises can gradually retire the business logic locked up in their legacy applications, so that eventually the service-oriented processes contain all of the business log ic in the enterprise. While certain logic will remain in the software infrastructure that supports the business services available to the enterprise, none of that logic should be business logic.

So, do we really believe that service orientation will lead to business logic belonging entirely in the hands of business, rather than in legacy applications? Probably not in the short term, since it will take some time for this IT vision to become a reality, and there are many roadblocks along the way to realizing this vision. However, in the long term, the only way to gain the business agility companies will continue to need is by making this shift. After all, business users should be in control of the applications, and the business logic in those applications shouldn't depend on legacy systems. As a result, the concept of legacy will transform in the service-oriented enterprise. The continual emphasis on composing new service-oriented processes and consuming third-party services will squeeze greater efficiency out of IT and help to retire systems that have outlived their usefulness.

However, because service orientation makes it easier to get value out of legacy systems, we're suggesting a gradual evolution of IT, instead of a quick, but difficult fix that companies will need to rush into. For this vision of the sunset of legacy to become a reality, therefore, we'll have to wait until companies gradually retire the legacy stuff in favor of fully service-oriented approaches. Eventually, however, business logic will finally be entirely in the hands of the business where it belongs.

Will Service Orientation Create More Legacy?
Whether or not you buy our prediction that service orientation will lead to the gradual retirement of today's legacy systems and applications, there still remains one important question: will today's service-oriented approaches be tomorrow's legacy? If anything, a service-oriented enterprise risks thinking of business processes, contracts, policies, and semantic metadata as legacy over time. Companies will continue to invest in processes and metadata until they no longer need them or their costs outweigh the benefits of their use. Many service-oriented organizations might indeed continue investing in legacy processes beyond their anticipated shelf-life, shifting the idea of legacy from the underlying systems to the processes themselves.

However, service orientation done right offers more than a shell game that simply shifts legacy from one layer of abstraction to another. It offers a way for companies to think differently about legacy in the first place. If companies can easily replace applications whenever they desire, then they'll never become legacy. Indeed, if legacy means that a technology is difficult to replace, then certainly services in an SOA implementation wouldn't qualify as legacy, since they are meant to be altered or replaced. services need never become legacy. In essence, SOA allows us to evolve or replace applications without the pain and cost associated with replacing legacy.

The Challenges of the Sunset of Legacy
While the sunset of legacy sounds good in theory, it poses significant problems for those in IT management. After all, budgeting for legacy systems is fairly straightforward, compared to an evolving SOA implementation. In many cases, IT managers can simply budget a flat fee or percentage of system cost on a year-by-year basis and plug that number into their planning spreadsheets for many years on end. This predictability provides some comfort when other IT projects continue to grow beyond their original scope and budget. However, a continuously evolving SOA project offers no such solace. No IT manager can place a fixed cost on the continual development and evolution of their services.

Furthermore, legacy systems allow companies to develop deep and long-lasting relationships with vendors. These relationships rely upon the trust between companies and their vendors, because the legacy systems are so core to the business that they can't afford to implement a system unless they trust the vendor behind it. After all, they make each legacy investment with the assumption that it will be around for a long, long time. However, companies should make no such assumption of longevity for service-oriented systems, so they will have to change the way in which they work with vendors.

The ZapThink Take
It's all too easy to fall into the good-versus-evil pattern of touting the flexibility of SOA over the brittleness of legacy. It's important, however, not to take this argument too far, or you risk changing the dichotomy to one of stability versus chaos. Legacy may be difficult to change, but most of it is stable, and stability is unquestionably desirable in high-risk environments like enterprise IT. Yes, SOA can provide agility and flexibility, but if we rush to discard the technology that provided us with stability, we risk creating an environment so dynamic that it leads to chaos.

The best path, of course, falls in between these extremes. We want stability without brittleness, and flexibility without chaos. For most organizations, then, successful SOA initiatives will include the ongoing preservation of legacy for the foreseeable future. Nevertheless, there will be fundamental changes in how legacy impacts the organization as a natural extension of the significant shift in IT culture, technology, and organization that service orientation represents.