What Matters in IT, Part 2: Solving Legacy with ACM

This article is the second in a series of three on ACM — architecture for continuous migration. Click here to read part one: [Click here to read part 1: What Matters in IT: the Power to Change.]

Established companies have several generations of applications, each designed to technologies that were both state-of-the-art for their time and appropriate to the business needs of the time. In the first generation — the mainframe environment — large computers held all the information necessary for computing, including the database, application logic and user interface: information was centralized.

Ravi Koka, Polaris Software Labs Inc.

The early 1990s brought a shift to the client-server model, where application logic and the user interface moved out to the desktop-PC clients. This enabled a high degree of customization and data manipulation, but the powerful distributed client base created islands of information that were largely disconnected. This has required major data synchronization efforts to provide an enterprise-wide view of a company at any given point in time, which is counter to the goals of the real-time Web environment.

Further developments have added further complexity. As newer, better technologies became available over the years — or as business requirements changed — new applications were bought or built on new platforms. As a result of this ongoing development, a typical older legacy enterprise today is actually a siloed collection of disparate systems that work independent of others. Adding to the issue, in many cases redundant applications have been acquired through mergers and acquisitions.

The result of this IT evolution — as you can see in the sidebar — is a patchwork of systems built in a variety of incompatible architectures that require a broad range of technical skills and resources for maintenance and enhancement. It is fragile, complex and difficult to untangle.

A major attempt to simplify, standardize and unify operations actually began during the mainframe era, when Enterprise Resource Planning (ERP) systems were introduced by companies like Oracle and SAP as an alternative to custom built applications. ERP solutions have remained popular but they have multiple drawbacks. While common functions like general ledger and payroll can be significantly standardized, the core systems that represent the way a particular business operates still need extensive customization. Upgrading an ERP package to meet changing business and technical requirements is costly and time consuming, too. Packaged ERP applications have the same issue with architecture as the systems they’re meant to replace, since the user interface, business logic and data access layers are tightly coupled as custom built applications.

In the insurance industry, there are several policy administration packages in use and they have the same limitations as ERP or custom legacy systems. It is typical to see companies using multiple systems due to product and line-of-business variations or due to mergers and acquisitions. One of the insurers I worked with had six policy administration systems, two claims systems and four different portals to cater to different user channels.

Nor are such problems confined to the insurance industry The technical landscape in any large enterprise will present a similar picture: siloed application architectures with varying technical requirements and proprietary data formats. The integration of these systems to provide a consistent user experience is an expensive proposition. In a second major attempt to solve legacy problems once and for all, companies have invested significant sums in Enterprise Application Integration (EAI) and in middleware such as IBM Websphere, Oracle Fusion, and TIBCO. Yet this has actually compounded the legacy problem, as the maintenance and enhancement of this layer has added to the total cost of ownership — and has further delayed the IT response to changes in business requirements and capabilities.

The dilemma for most companies and CIOs is how to be more agile without disrupting the current operations, which are legacy based. A “big bang” replacement is risky and expensive — the few firms that have tried it did not have much success — and given that business and technical requirements will keep changing, it would be prohibitive to do big-bangs repeatedly. Few recommend such a solution today, and in most cases we certainly would not.

Meanwhile, the need for true real-time capability is increasing with the growing ubiquity of wired and wireless networks. Just about every process has got to be web-centric and customer-centric. The method of choice for meeting these needs up to now has been the EAI approach, integrating existing applications as driven by customer demand. But this has not allowed organizations to realize the full potential of customer-centric processes and systems. The only alternative to Enterprise Application Integration is to replace existing systems by building all-new, customer-centric systems from the ground up. While technically feasible, this is not economically practical for companies with significant investments in existing systems. It also does not guarantee that the new system would be future proof. New technologies will emerge and business models and requirements will continue to change.

An approach that allows continuous migration is therefore the only practical way to deal with the legacy dilemma. In order to support this approach, application architecture needs to follow certain guidelines. Investing in ACM is not an extravagance. In fact it can be much less expensive than other ways of making a major change or upgrade. Recently my colleagues and I advised a client to consider a ACM approach to its legacy issues in lieu of an ERP solution. The client opted for the ERP package, which was not a disaster; in many respects it may work out well. However the implementation alone will cost upwards of $200 million. Implementing the ACM solution set that we advised for this particular firm would have come to about $50 million to $70 million over five years. And, in our view, it would have been better operationally for the long term, since the ERP solution itself will become legacy as it gets customized without following the ACM best practices.

The underlying philosophy of ACM is “to accept change as the process.” And accepting change as the process means changing systems in a manner that allows for further change. As Vinod Khosla put it in his paper: “The goal for IT transformation should not be radical transformation but rather continuous migration of systems, transforming the enterprise into an adaptive enterprise.”

The key to achieving this is the use of appropriate application architectures — not the purchase of particular software products, but taking a flexible and extensible approach to their selection and use. It also entails heeding to the five core principles of ACM, such as “loose coupling” of the layers of system architecture, and as mentioned earlier, having an externalized rulebase.

About the Author: Ravi Koka is CTO, Insurance & Portals, of Polaris Financial Technology Limited, a provider of enterprise software for the banking and insurance industry. Prior to joining Polaris Koka founded SEEC Inc. and successfully completed the company's IPO on Nasdaq in 1997. Koka started his career with System Development Corporation (originally a division of RAND) and was an adjunct associate professor at CMU. Polaris Software labs acquired SEEC in 2008.