Legacy Information systems are the fountainhead of critical information and procedures about the organization‘s business. As over years they undergo functional bricks addition in order to be in track with the evolving business rules, they finally result in large, complex, technologically out of date and costly maintainable systems. In response to this, solutions have emerged from a simple legacy system wrapping with convivial software known as “frontware”, to a complete redevelopment from scratch.
Surely legacy wrapping, proudly supported by EAI frameworks vendors for their purses’” sake can bring a non intrusive web access to legacy, which can therefore be easily and quickly deployable; Nevertheless it doesn‘t address overloading, business scalability and costs reduction issues which are core concerns of any significant business.
Redevelopment from scratch on the other side promises drastic revolution, only after years of development. It not only increases failure risks but also disrupt operational and business environment during the cut-over phase. Such rip and replace solution is promoted by software packages vendors as a very convenient strategy while convenience has very little bearing on reality and the true nature of business (always evolving business conditions, legacy’s size, non documented dependencies, inexistence of specifications…)
Another way of coping with Legacy systems might be a piecemeal migration. The DARWIN [1] project from the University of California Berkeley introduced ―Chicken little as an approach to incrementally migrate legacy systems with the constraint of interoperability between legacy and target system. Here is the business for interoperability solutions vendors. Small resource, time allocation, risk and efforts to get each increment funded, better follow up and the ability for the business to be always “live” are the main arguments of the stepwise migration.
But how do we define the increments then? How do we set the order in which those increments will be cut-over? Identifying and delimiting IS components so as to form migratable IS blocks was the suggestion of the DARWIN project. Undoubtedly such approach will quickly show its limitation when it comes to black box or spaghetti-like legacy information systems. For large size legacy information systems, such migration will take years to complete and such initiative usually reflects business stakeholders’ will to either extend the business or enforce their position. Therefore, there’s a clear need of prioritizing the increments for the sake of the business at one side and for minimizing the migration cost at the other side.
Identifying the increments for a stepwise migration toward a modular target IS architecture (inspired by EKD CMM [2])
- Identify the business processes supported by the legacy and restructure them so as to form independent macro business processes blocks that can be migrated. The first challenge there is to keep in mind that these business processes when enacted on the target IS should be able to cooperate with the cut-over version of the legacy IS so as to keep the composite IS operational. This emphasis the criticalness of maintaining the right precedence order between the processes. The other challenge is to be able to clearly evaluate budget, time, resource allocation, and above all rate of return for each macro process identified.
- Prioritize those business processes: According to the business vision for the upcoming years some processes might be crucial than other one in that they enable enactment of new functions, or help whipping out legacy leaks and so on. Seen from another angle, the prioritization can also be done by aligning the available funds and the increments costs. What we emphasis on here is the need to identify a list of decisive criteria and so indices along which the increments migration order will be determined.
- Define the target modular architecture: Map the previously identified business processes into IS components (interfaces, application modules, database and data access services) at the information system level, following the three-tier architecture principles. Processes involving human computer interaction will imply graphical user interface at the presentation tier, while those who communicate with other systems might it be internal to the organization or external (partners) will require system interfaces. Business logics will be converted into application modules while data access and database management will be at the lowest level. Since legacy and target will need to communicate, necessary gateways are to be specified. These gateways could be software pieces bought from interoperability solutions vendors, home-baked software or legacy chunks that have proven to be useful.
Beyond offering a smoother way to complex legacy migration, the major contribution of this proposal is to drive the organization toward a state of business/IT alignment. In fact from the target IS enactment on, the business processes being executed in the organization can be better documented. Furthermore, if the target architecture is service oriented, the business processes can be explicitly represented in an executable model using BPM tools, what eases monitoring and improvement.
The challenge for nowadays‘CIOs is to change the view of IT as a cost center into a perception of IT as a profit center. This implies in a migration context:
- Rationalization of costs by means like maximum legacy components re-usability. Special care should be made about gateways in order to not explode costs for building them. The order in which increments are migrated has an impact on the complexity and thus the cost of building gateways.
- Focus on the business of making money: in order words prioritizing increments which actually create value for the business while submitting a migration plan to the top management.
However, we recognize discovering business processes from a non-documented legacy system is not an easy case to plead. Requirements engineering, process mining techniques might be worthy options.
Finally, the incremental approach to legacy migration also induces an ongoing piecemeal change which takes place as part of the organization‘s evolution and development. But more than a simple incremental change management, there is a clear need of periodic fitness analysis between the IS change between two increments of the migration, and what’s been done in terms of organizational change management. A framework for monitoring the alignment relationship between the two change process models would be welcomed.
[1]: DARWIN: On the Incremental Migration of Legacy Information Systems‖ – Michael L. Broadie, Michael StoneBraker – Mach 1993
[2]: Understand EKD-CMM Change Management Framework – http://crinfo.univ-paris1.fr/EKD-CMMRoadMap/UnderstandEKD-CMM.htm
[3]: Legacy IS migration by Chicken Little at Total Fuel Cards France – by Lookman SANNI