System Transformation Portal

Successful Deployment of Legacy-Dependent IT Initiatives Requires Phased Deployment

By William M. Ulrich

Management can reduce the risks and increase the odds of delivering business value from an IT project through a phased deployment approach. Risk is a result of delivering less than what was promised while spending more than what was anticipated. Value, on the other hand, is defined as the ability to increase revenues or cut costs as the result of a successful IT initiative. Phased deployment involves executing a series of small projects that deliver interim value while working toward a more strategic goal.

Legacy transformation strategies, in conjunction with business-driven projects, should be based on a phased approach. The reason for this is that assessing and understanding legacy architectures is a lot like peeling an onion. Legacy-dependent projects include major enhancements, package deployment, selective or wholesale replacement, front-end/back-end integration and a wide variety of related initiatives.

The concept of delivering a legacy-dependent project in phases is predicated on the complexity of legacy environments and the difficulty of upgrading, integrating or otherwise transforming those environments. As project teams move beyond the technical assessment to expose the underlying architecture and application functionality, more information is discovered that may require shifting the approach applied in subsequent implementation stages of that project.

A second reason for phasing in a legacy transformation project is purely pragmatic. Legacy transformation involves the application of a variety of techniques that affect the physical and logical aspects of a system, at the program and system level, from a business logic and data usage perspective. This multidimensional set of techniques and related project tasks is applied through a series of staged delivery windows, each of which delivers value in its own right. A phased approach:

• Provides ongoing and interim value to the customers and users of the system

• Reduces the risk of an all-or-nothing project approach common with a from-scratch rewrite or package deployment project

• Can be cost-justified in stages as well as in aggregate

• Successively moves an enterprise toward its final deliverable through a controlled series of value-added project phases

• Can be canceled at any number of defined checkpoints without losing the value delivered during previously completed project phases

The phased approach can also help alleviate the conflict inherent in the systems planning process. Managers who find themselves torn apart by individuals in varying camps are likely to be in this situation because multiple correct solutions have been proposed. In these cases, the team as a whole did not exercise a collaborative approach that considered each project option as a step in a multiphased project.

For example, an executive team may be seeking ways to consolidate a customer order handling and procurement situation that has been fragmented across multiple business units for a period of years. Many of the business units have common customers, and these customers want their orders consolidated for tracking and billing purposes. Different individuals have offered the following proposed solutions:

• Document, integrate and automate order handling and procurement business processes across disparate business units using business process automation software

• Create a data warehouse of summary-level information so customers can access the status of any order through an online interface

• Consolidate back-end data structures and modify the existing systems to access these structures as a way to integrate the customer view

• Create a new integrated order handling and procurement tracking application that replaces the individual applications currently in place

Each of these options may appear on the surface to contradict the other options. Planning participants may have taken strong positions and may be unwilling to listen to alternative arguments. The business process integration and automation (BPI/BPA) team sees the first approach as the best one from a business perspective. The data warehouse team sees the second option as the only way to go, while the application team wants to try approach three so it can retain control of the project. And certain managers may view option four--new development--as the "right" approach.

The irony of this situation is that, depending on the business requirements and underlying architecture, each of the options could be incorporated into a phased transformation strategy. Consider a strategy that applies the following steps as a multiphased approach to addressing this issue:

1.  The BPI/BPA team can collect requirements, draft a schedule, define the costs and prototype a set of business process automation solutions. The new front end could be deployed to users while triggering access to back-end legacy applications. Accomplishing this may involve using certain middleware on an interim basis.

2.  Data architecture and application personnel could concurrently create a plan to document, extract, rationalize and populate a warehouse with the data definitions from disparate applications.

3.  Application team members could then connect a Web-based query capability to the data warehouse for customers or for the customer help desk. This project phase would provide essential information to the customer without affecting the underlying architecture.

4.  In some cases, the new data model could be implemented and the existing applications could be modified to utilize that data model. This interim deliverable step may or may not be feasible, based on the structure of the original data and the applications that use the data.

5.  The new data model created in step 2 could be reconciled with the business process model built in step 1. Using this information, an application design team could define the new target architecture that integrates required functionality under a new, object-oriented design. Design efforts would be augmented through the analysis of legacy application and data structures.

6.  Finally, the new design could be populated with legacy application business logic. Developers can apply differing techniques to accomplish this, including defining reusable components from legacy business logic or populating an alternative design model.

This sample scenario offers executives the option of delivering phased value to customers while avoiding an all-or-nothing approach by trying to rewrite the system from scratch. If the team decides to exit the strategy at any point before proceeding to a subsequent step, customers and users will still have gained value from the work delivered up to that point.

While the phased approach intuitively appears to be the lowest risk and most pragmatic, there is a philosophical reluctance to use such an approach or to attempt to sell it to the individuals funding the project. This reluctance has a number of causes. Frequently, executives do not want to hear the details of a project plan. So the phased approach, which involves multiple versions of an application being introduced into production over a phased period of time, may present too much information or appear too complex.

Another reason is that large-scale consulting firms, particularly those that sell to the CFO and CEO, may not buy into a phased approach. This is due in part to the belief that the consulting firm would need to resell each subsequent phase of the project in increments. If that consulting firm could convince the CFO or CEO to sign up for the entire multimillion dollar project, then that project is theirs in its entirety through the implementation phase. To alleviate this issue, consulting firms can position a phased approach under a single contract.

Executives also tend to shy away from new ideas if they do not develop a comfort level with those concepts. The tendency in these situations is to gravitate back toward a more "traditional" strategy. Unfortunately, tradition in this case translates into an all-or-nothing approach to application replacement, package deployment or related initiatives.

In spite of a reluctance to pursue a phased approach, logic dictates that a series of smaller, low-risk projects--each of which can be cost-justified in its own right--makes more sense than one big project with few or no interim deliverables. The phased approach can be applied to any type of data and/or application migration, redevelopment, package deployment or smaller-scale project involving legacy architectures.