Aligning Strategic Systems with Legacy Environments
On one side of the wall sits the legacy application portfolio, millions of lines of code that keep the business running. On the other side of the wall is the development world, a world ruled by Java, XML, application servers, Web servers and component-based development environments. The limited connection between these two worlds is through integration tools that, if aimed in the right direction, allow e-business systems to selectively access legacy data and trigger back-end transactions.
Legacy systems in a large organization are comprised of tens of millions of lines of code with a replacement value in the billions of dollars. These application systems are essential to the continued operation of complex enterprises around the world. Most of these companies are also actively building new, Web-based systems to support e-business initiatives. These initiatives are strategic, but still require access to legacy data and transaction based systems. These new systems need to access legacy environments to leverage the intelligence embedded in these older systems.
Most companies address e-business and legacy systems integration by using certain application integration tools to selectively access legacy data or trigger back-end transactions. These tools address integration using after-the-fact solutions that effectively segregate new systems from legacy environments for the long-term. This approach offers limited flexibility and hinders long-term, large-scale upgrade options to new e-business systems and back-end environments.
A more effective approach to integrating strategic and legacy environments is to address this challenge during the design and development cycle. New systems leverage reusable components to streamline development and future upgrade tasks. Reusable component libraries are traditionally delivered by vendors or developed by Java programmers. Legacy systems, on the other hand, are a rich untapped reserve of business rules that can be componentized and reused as part of the development process.
Componentization of legacy systems requires decomposing systems into major functions and sub-functions and extracting and reconciling selected business rules from those systems. The next step requires categorizing extracted components for reuse and compiling them so that they can be made available to development and maintenance teams.
While this is not a simple endeavor, software tools and techniques have matured to the point where legacy componentization is feasible with commercially available technology. The benefits of this are significant.
Recreating the business rules contained in legacy systems would cost some companies more than their total fair market valuation. Some people argue that legacy business rules do not apply to new e-business requirements. On the contrary, back-end systems contain much of the business logic needed to enable high volume, scaleable e-business transactions. Legacy architectures just do not support cross-functional access to stovepipe data and transaction-based environments.
Componentization can change this dynamic by repackaging legacy intelligence so new systems can reuse legacy logic to meet strategic e-business requirements. Development efforts can meet new development requirements more quickly and more effectively by incorporating legacy components. This is far superior to attempting to replicate decades of embedded legacy business logic from scratch.
IT executives should enable developers to address new development and legacy systems integration under a single strategy that fully synthesizes integration into the systems design and development life cycle. Anything less compromises the future of e-business solutions in major enterprises.