Does this sound familiar? You have some legacy application typically (but not necessarily) running on a mainframe. It's now several years old, and while it still serves a vital purpose within your organization, its inflexibility is becoming increasingly problematic. As time goes on, your faced with a double bind: keep the legacy app around, even though you'll need to pour more and more money into keeping it in line with changing business needs, or bite the bullet and come up with a way to retire the beast, even though that option is unquestionably high risk, and fundamentally, you don't really have any idea how to turn it off without jeopardizing your business.
Well, you're not alone. In fact, ZapThink recently visited an organization who had this same Catch-22. For the purposes of this ZapFlash, we'll combine their story with other similar stories and call the resulting fictional company "Smartco." Of course, Smartco had identified Service-Oriented Architecture (SOA) as a strategic initiative in their IT organization, as SOA is now widely recognized as being the mainstream best practice approach to achieving greater business agility in the enterprise legacy context. Simply putting SOA on their roadmap, however, didn't get them out of the Catch-22, and they were stuck. As a result, they called in ZapThink to help unstick their SOA efforts.
The Organizational Challenges of Legacy
What makes this story interesting is the fact that the fundamental challenges Smartco is facing are more organizational than technical. Sure, either maintaining or transitioning off of a legacy app both present technical challenges, to be sure, but Smartco had a reasonably good grasp of how to handle such issues. The challenges on the organizational side, however, were a different story.
This situation became clear when Smartco scheduled two meetings for us: the first at the management/architect level and the second at the developer/systems level. The people in the first meeting expressed a clear mandate from top management: nix the legacy app. True, they had a laundry list of specific business requirements which all essentially rolled up into a strategic business agility priority. But more to the point, management had identified the legacy app as the problem. Never mind that it was less than ten years old, and it continued to adequately address the requirements it was originally designed to meet. It had to go.
Furthermore, the managers and architects in the first meeting had identified SOA as a critical enabler of this transition. In essence, the point to this meeting was to ask the question, " how can SOA help us retire this legacy app?" The assumptions were that first, the business requirements necessitated that legacy app had to go, and second, that SOA was the best way to accomplish this feat.
The meeting with the techies was quite different. There was an immediate sense of tension in the air, as many of these people had been working on the legacy app for years. Furthermore, there were a good number of people who were technical experts in the specific technologies the application employed. These professionals felt threatened on two levels: the threat that retiring the app would make their skills unnecessary, and second, that they had invested so much time and effort into the app that it would be a waste to see it go.
The techies' perception of SOA was mixed as well. Many of them saw SOA as part of the "retire the legacy app regardless of whether it makes sense" position they felt that management was pushing on them, in spite of the fact that other people in the room pointed out that they had already made significant progress with their SOA initiative. In fact, they currently have exposed the legacy app with several loosely-coupled Services in production that support new business process requirements -- in other words, SOA.
SOA To the Rescue?
The first point we made is that SOA isn't taking sides in this spat. On the contrary, SOA can facilitate both legacy migration and legacy rejuvenation efforts. When an organization already has a business imperative to retire a legacy system, SOA can help with that migration by abstracting the interfaces of the older system. If the replacement supports those same Services, the migration transition can go more smoothly, thus reducing the risks of the migration somewhat. We sometimes call this the "heart-lung machine" option, because it's possible to switch out the legacy app without bringing down the Services.
On the other hand, the big win for SOA in legacy environments is rejuvenation: getting more value out of the legacy app by building Business Services that abstract the capabilities of the older system, and incorporating those Services into the broader SOA implementation in support of agile business processes. We call this the "teach an old dog new tricks" option, because organizations that succeed with legacy rejuvenation can get more value out of their legacy apps than perhaps the original developers intended.
The point here is that SOA doesn't tell you whether the heart-lung machine approach or old dog/new tricks approach is the right one for your situation. Instead, SOA can help in either case -- although in general, legacy rejuvenation is a bigger win than legacy migration, because the heart-lung machine approach can only lower the risks of migration to a certain extent. The bottom line is that business priorities, rather than the architecture, determine whether or not to retire a legacy application.
Two Answers for Two Audiences
Back to Smartco: if SOA doesn't help them decide whether to retire the legacy app or keep it around, then how should they make that decision? Interestingly enough, the answer was different in each of the two meetings. For the managers and architects who were responding to the mandate to retire the legacy app, migration was the approach we recommended. However, for the techie meeting, rejuvenation was our preferred option.
OK, so what gives? How can we recommend retiring a legacy app and keeping it around at the same time? There were a few people who attended both meetings, after all, so it wouldn't take them very long to figure out something was amiss, right?
Not so fast. In fact, we weren't recommending two conflicting approaches at all, because we weren't actually suggesting that Smartco actually retire the legacy app. Instead, we recommended to the first group that Smartco plan to retire the legacy app. After all, Smartco's architects estimated that it would take five to seven years best case to fully retire the application. During that time, they would have many opportunities to reevaluate the plan. Just because legacy migration is on the plan today doesn't guarantee it will be on the plan five years hence.
In the second meeting, we pointed out to the techies that our idea of putting the legacy app retirement on the plan actually gave them what they wanted. After all, the technical challenges for legacy migration and legacy rejuvenation overlap substantially, especially in the early phases of the project. Both approaches involve taking an iterative, top down/bottom up approach to abstracting the interfaces of the legacy app to better support the changing process requirements of the business. In the migration scenario, certain sets of Services eventually transition from the old app to some new system or systems, but not all at once, and not right away.
The techies also realized that retiring a legacy app is rarely a black-and-white affair, where at some specific point in time you get to power down the old box for good. In fact, they pointed out that the precursor system to the current legacy app was still functioning in Smartco's data center to this day! True, they were only leveraging a small percentage of that ancient system's capabilities, but they hadn't had sufficient business motivation to turn the thing off altogether. And if the older system was still around longer than expected, then why not the current legacy app?
The ZapThink Take
This analogy between the current legacy app and its precursor was not lost on this crowd. The business can jump up and down complaining about a legacy app, but it's the actual business needs -- not perceived business needs -- that end up determining which of the legacy app's capabilities should be transitioned to some new set of applications. Furthermore, SOA is the critical facilitator of this flexibility. After all, from the business perspective, IT should deliver capabilities and information in the form of Business Services that mask underlying technical details, including whether or not the underlying implementation is part of one application or another.
There is another important moral to this story as well: the business agility benefit of SOA can have a direct impact on long-term planning. With traditional tightly-coupled IT, diverging from plans is typically a costly, painful ordeal (even though we do it all the time). With SOA, however, you're building for change. Not only can long-term plans change, you now have the luxury to expect them to change. If you've implemented SOA properly, you'll be able to deal with changes as they occur, so feel free to plan accordingly.