Part I: The Philosophy

Legacy applications are often the bane of an IT manager's existence. It's not simply because they're old and are no longer in alignment with the enterprise's requirements--if a particular legacy application was easy to modify, then the IT department would simply update the application to bring it in line with the organization's needs. Sure, that takes work, but if the application was designed for change, then the effort required is nothing extraordinary. Rather, the real problem is that many legacy systems are resistant to change, because they weren't developed with flexibility and scalability in mind. This makes maintenance and enhancement very difficult.

The solution is to migrate to newer, more cost effective, more flexible and ultimately more scalable systems. But, how do you go about effecting this migration? The philosophy behind migrating to scalable environments involves three critical concepts:

* The migration must occur incrementally;

* All components of the target environment must be scalable; and

* The application itself should be partitioned into smaller functional units.

Incremental Migration

Regardless of whether or not they're DSS or OLTP applications, the applications in question are usually systems that must remain available in order to keep your enterprise operating smoothly. The traditional approach to a migration is to build the new version of the application all at once, run both the new and the old (legacy) applications simultaneously for a little while, and then do a wholesale "cut-over" to the new environment over the nearest available three-day weekend. But, in reality, this approach very rarely works. The problem is too complex to solve all at once and, therefore, the approach is too risky.

To control this risk, the more sensible approach is to perform the migration incrementally. There are a number of advantages to the incremental approach. First, the task is broken up into smaller steps that are far easier to scope, plan, implement and manage. Second, if an incremental development step fails (that is, the resulting application does not meet requirements), then only that last step needs to be repeated, instead of having to start the entire development process all over. Third, this approach allows for the evolution of the organization's needs that will inevitably occur during the migration process. As needs change, each subsequent incremental implementation step can take the changed requirements into account.

Scalable Components

To ensure that the migration delivers a scalable environment, you must address scalability in three areas: the hardware, the database and the application. Regarding the hardware, your target platform must obviously be scalable. There are many architectural options here, including SMP, clusters, MPP and NUMA. Which one is best suited for your application is a question that is not trivial to answer (and would be the topic of a very long article). But, rest assured that without a scalable hardware platform, your migration project will simply be building your next inflexible legacy system.

Regarding the database, if you have scalable hardware, then you will need a database system that can take advantage of the hardware's capabilities. This means that the database must have parallel processing capabilities. As your organization's needs grow over time (causing the demands on the database to increase dramatically), a parallel/scalable database system means you can add more computing resources to your hardware platform, and the database will be able to use the additional resources to ensure that end-users' response-time requirements are still met.

Ensuring that the hardware and database in the target environment are scalable is not difficult--it's just a matter of purchasing the appropriate technologies. But, this isn't true for the application itself. The real work in migrating to a scalable environment involves ensuring that the target application is designed to be scalable.

Partitioning Applications

For the application to be scalable, it has to be partitioned into smaller functional units. For example, in a telecommunications application, rather than having one large application that handles issuing work orders for installing new phone lines, issuing maintenance requests for existing lines and disconnecting existing phone lines when tenants move, the scalable approach would separate these functions into three separate modules that interact with each other through well designed interfaces.

This is in stark contrast to mainframe application design which focuses on building large, monolithic applications. Given the monolithic nature of the mainframe platform itself, a monolithic development approach is optimally suited to those platforms. However, applications designed in this fashion are poorly suited to the scalable systems environment. In the scalable environment, the platform is comprised of multiple smaller resources all pooled together. A monolithic application cannot be easily divided into smaller components in order to be spread across these multiple resources and, therefore, cannot take advantage of the scalable platform. In concrete terms, if a system cannot have more than a single CPU, then it is often optimal to write the majority of the application as a single piece of code. However, on a scalable platform with multiple CPUs, this single monolithic application can only run on one processor at a time. To take advantage of the multiple processors, the application must instead be written as a collection of smaller functional components that can incrementally be added and which can be spread across the multiple processors.

Layered vs. Non-Layered Legacy Architectures

So, we've seen that the application we must end up with must be partitioned into smaller functional units. But, how easy it is to do this greatly depends on the legacy application's architecture. Different legacy environments organize the database and application areas in different ways. If you're lucky, these two areas are architected so that each has its own logical layer in the architecture and each has a defined interface for interacting with the other layer. In these architectures, the application is responsible for processing the data, and the database is responsible for manipulating and maintaining the data on disk. This ensures some amount of independence and insulation between the different areas, enabling you to minimize the impact that a change to one area (for example, the database) will have on the other. It is this layering that makes incremental change easier: you can change a part of the environment without changing everything.

However, often you aren't quite so lucky. In many of the older legacy systems, the application and the database are inextricably intertwined. In these situations, there is no real separate database. Instead, the applications often directly manipulate the data on disk. Therefore, far less of the insulation referred to earlier exists. This means that it won't be easy to change just one portion of the environment--other areas will also have to be involved. This is unfortunate, because it means that your incremental migration steps will have to be larger; therefore, your risk will be increased. However, with enough hard thinking, you can always find some way to partition things (although probably not as cleanly as if the legacy architecture were layered).

Next Steps

If we start with a legacy application and move it to another environment that is no more flexible than the original, all we've succeeded in doing is creating our next legacy environment. The key to avoiding this scenario is to ensure that the target environment is scalable so the solution will be flexible and adaptable.

In this month's column, I've focused on the philosophy behind migrating to scalable systems, and I've highlighted three concepts that are critical to such an effort. Next month, I'll discuss the basic techniques and the main steps to follow to actually carry out the migration.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access