Many modern systems are replaced or undergo major changes every 3 to 5 years. It is very common, however, to see the architecture of a COBOL-based Mainframe application remain largely untouched for 10, 15, even 20+ years! As I explained in my article, The Root of All Evil (in software), legacy systems have a high degree of tight coupling that makes it difficult to improve or upgrade the system over time. Typically, organizations choose one of two options.

  1. Big Bang – Spend a very large amount of time and money to get off the legacy software in one big bang initiative. These initiatives are often contain a great deal of risk and almost always last longer than originally projected.
  2. Black Box – Leave the legacy system as it is and instead focus on building around the mainframe. This usually means a combination of screen scraping, MQ interfaces to “online” mainframe programs and/or other means of using the mainframe as a back-end to more modern middleware and UI-based systems.

The problem with the Big Bang approach is that it is often not a feasible option for organizations short of time, money or resources. The other major option, Black Box, does help to a degree, but there is only so far you can go building wrappers around a legacy system. With Black Box, you are not solving the core problem and it will continue to cause issues in terms of slowing down and/or preventing the implementation of business change requests. Most organizations don’t realize that there is a third option:

  • App Marketplace – Using my definition of an App Marketplace, you can set up an iterative sequence of changes that focus on moving components from the legacy system to your new marketplace-based architecture piece-by-piece. As I mention in my previous blog, the term “App Marketplace” is really just a way of describing a well-designed, SaaS-based system.

The App Marketplace approach to modernization has 4 primary steps.

Step 1 – Paint a Picture

With all the challenges involved in legacy modernization, it is interesting that the most difficult one when you start out is purely mental. Namely, before the effort can get off the ground, you first need to get all the core team members on the same page.

  1. Explain the Pain Points – Over a series of meetings and discussions, ensure that everyone understands what is wrong with the current system.
  2. Challenge the Team – Give the team time to try to come up with their own solutions to solve the problems you presented. You may have some ideas and the general direction, but a successful modernization effort requires everyone to be actively involved and contributing.
  3. Present the Vision – Lay out the high level goals and concepts. No need to get into every detail, but focus on getting the team behind the first set of changes you are targeting.
  4. Training/Recruiting – The acceptance of the vision (as well as the execution of it) requires that the team members involved either have the skills and knowledge of the new technologies or they must be able to learn quickly. I will not dive that much into this aspect of modernization in this article, but training and recruiting is a huge part of any modernization effort.

Remember that we are not doing Big Bang, so there is no need to create a detailed project plan that defines every detail of the modernization process. Just establish the vision and a high level idea of the modernization process.

Step 2 – Enable Change

Before any functionality is migrated off the legacy system, there is some prep work that is needed.

  • Move Source Code to TFS or Subversion - Many legacy systems utilize an older all-in-one source control system that is tightly integrated to the host environment. The problem is that from a modernization effort these all-in-one legacy SCMs typically don’t support the advanced branching functionality that exists within TFS and Subversion. As a result, it becomes extremely difficult to make major refactorings and manage multiple parallel efforts.
  • Remove Dead Code – This is typically something that developers of legacy systems are afraid to do. Even though they are pretty sure the code is not used anymore, they would rather leave it there so that they don’t break anything. While it is true that QA may need to do some extra regression testing, it is important to reduce as much as possible the code that the team has to analyze and migrate to a new environment.
  • Export Data to SQL Server or Oracle - It usually doesn’t take that much work to dump data from a legacy database to some export files. If you can set up a nightly process to do this, you can start to slowly and incrementally build an off-host read-only data source. Reports and some read-only programs can then written in .NET or Java on top of the off-host SQL Server or Oracle database. Also, you can eventually start to add transformations to the export process so that the data in SQL or Oracle is in more of a relational format.
  • Test ODBC Access – The databases used for many legacy systems can be accessed by external programs via ODBC. The ODBC drivers may have some limitations, but the more you can reduce code on the mainframe the better. The key is to understand what the limitations of the ODBC access is for your legacy system and establish guidelines for when and how it can be used.
  • Create the Marketplace – Build the foundation for your target platform which includes setting up the physical infrastructure (i.e. servers, network, etc.), creating core APIs that will be utilized by all services and documenting standards for how the new platform will be used.

In addition to setting the stage for the iterative migration process, these changes will also have the side benefit of getting everyone prepared mentally for the next step in the process.

Step 3 – Start the Migration

One of the appealing aspects of the App Marketplace modernization approach is that it can take place alongside business-as-usual activity. In fact, the the initial set of services migrated off the legacy system should be done in conjunction with the business-as-usual change requests.

  1. One of the business change requests is chosen from the product backlog.
  2. Analysis is performed to determine what it would take to satisfy the business request through services on the marketplace platform instead of the host legacy system. This analysis includes variations of possible solutions with time and resources needed for each variation.
  3. The core team determines which variation should be implemented.
  4. In most cases (especially in the beginning of this process), the solution chosen will have a mix of new functionality on the new platform in addition to legacy system changes.

Depending on which solution is chosen by the core team, the service created on the new platform can take different forms:

  • Fully Decoupled Service – This is the ideal case where all the logic for a given service is migrated to the new platform and all the data used by that service is migrated to an off-host database.
  • Logically Decoupled Service – Logic is moved off host, but the service must use an ODBC connection to get data from the legacy database.
  • Service Wrapper – Logic remains on the legacy system and the new platform simply has a wrapper service around a legacy program (i.e. connecting via MQ, COMS, etc.). This is really part of the Black Box approach, though, and should be avoided in lieu of better alternatives if possible.
  • Event Listener – For certain workflow driven logic, you can create an off host service that polls the legacy database until a particular event occurs and then take the appropriate action.
  • Offline Service – Logic moved to off host service which connects to a SQL Server or Oracle database that gets exports from the legacy database. This is typically used for reports.

One of the biggest challenges with doing fully or logically decoupled services is that it is often difficult to cleanly separate the logic for that service from those tight dependencies on the legacy system. You can get around at least some of this by having the legacy system call out to the new platform. The benefit of doing this is that even if you can’t migrate an entire lump of intertwined code, you likely can find smaller services within the execution path that can be cleanly separated. For example, it may be difficult to move an entire legacy module that processes customer payments, but perhaps you can just move the customer notifications piece of the payment module, move that to the new platform and have the legacy system call out to that new notification service. Note that outbound calls to off host services are also vital in the situations where users still access the legacy system green screens (i.e. so that the green screen UI can call out to the external service).

The types of services and ways to migrate functionality from the legacy system to the new marketplace platform can vary depending on your environment and needs. Regardless of which options you chose, the primary goal at this stage of the modernization process is to make some relatively low-risk changes and build up momentum. So, until you get some momentum try to avoid getting stuck into high-risk refactorings within the legacy system that take an extremely long period of time to complete. Once you have some success and confidence within the team is high, then you can tackle the bigger challenges.

Step 4 – Take the Plunge

You could theoretically continue the iterative, low-risk approach for an extended period of time, but the problem is that the more difficult parts of the legacy system are typically the areas of greatest technical debt. While it is great to focus on the low-risk items to build momentum, the payback on those items is small compared to when you are able to resolve some of the bigger challenges. So, as soon as you have some momentum you should focus your energy on one of these challenges. This does mean that you will have to step outside the business-as-usual and justify the prioritization of a large, modernization driven change. Once you get support behind tackling this large change, here are some tips on how to proceed:

  • Keep it Iterative – Even though you are attacking a larger part of the legacy system, it still helps to find ways to do the migration in an iterative fashion.
  • Build a Switch – If possible, it helps alleviate some risk by building a component into the new solution where clients of the service being migrated can easily point to either the new platform or the legacy platform. If there are problems with the new service, the clients can quickly move back to the old service.
  • Migration Now, Perfection Later – It is much easier to refactor .NET than COBOL. Don’t worry as much about making your new service and data schema perfect. Even if you move the legacy database tables untouched to SQL or Oracle and make only minor changes to the core logic when you write your middleware services, it accomplishes the goal of getting the functionality off the legacy system. The only caveat with this tip is that you will want to spend the time to remove any tight coupling between the new service and any other program. Within the service itself is where you can leave some imperfections to fix for later.

The great thing about removing a major source of technical debt from the legacy system is that it opens up all sorts of doors to new opportunities for change. Once you tackle one of these larger efforts, your modernization effort will be in high gear and it is only a matter of time before you reach the finish line.

Conclusion

Everyone’s environment is different and there is absolutely no way to accurately predict how long any initiative will take, much less a modernization effort.  However, if you follow this approach you will have at least the following accomplishments in about a year:

  1. An established, iterative modernization process
  2. Team members with a new mindset that are cross trained on the new platform technologies
  3. A working SaaS platform that has at least a few services
  4. Momentum established to continue migrating bigger and bigger services to the new platform
  5. Majority of the development team’s work is focused on new platform (i.e. moving from the old to the new)

That is a lot more than you are going to get from the alternative approaches. With the Black Box approach, the legacy system remains largely untouched. In fact, often you have to go in the opposite direction and build new programs into the legacy system in order to support clients treating it like a black box. With the Big Bang approach, you very likely will have nothing to show for your efforts after a year other than some documentation and code that is sitting on the operating table in development. The value of this approach is that you will have a lightweight, iterative process in place that provides value very early on in the modernization process. These early wins can be built upon to accelerate the overall process and put you in a position to start tackling the larger issues sooner than you may think. The best part is that even if something comes up to delay the initiative (i.e. lack of funding, higher business priorities, etc.), you will still have a strong foundation that has already been implemented in production and is already providing value.

Jeff is the CTO of MESH01, a co-collaboration platform that enables brands to utilize a global community of designers, testers and other experts to produce products that rock. He is also an avid soccer fan, family man and loves to write in his spare time. Follow Jeff on Google+.
Jeff Whelpley
View all posts by Jeff Whelpley
Jeffs website