ComputerWeekly.com recently ran an article on RBS Bank's recent IT failure, which led it to discuss the problems IT professionals face replacing legacy systems. As part of that story they showed this diagram:

Image via ComputerWeekly.com

It shows a typical core banking application system and its interconnections--nothing new if you have worked in financial systems. But what this article did highlight to me was this unspoken assumption that legacy systems are automatically candidates for replacement, and the above diagram was somehow supposed to act as a kind of emotional motivator.

I really take issue with that approach, and not only because I work in application modernization.

The Boeing 747 Jumbo: a "legacy" aircraft

Image via WAIC

Compare a banking system with a commercial aircraft; for example, the Boeing 747, first flown in 1970. Almost everyone who has done some international travel has been on one of these venerable aircraft at least once. Aircraft such as the 747 have wiring configurations that easily surpass the complexity of the banking diagram shown above--some 400-500 km worth of cables, with a total wire count of about 100,000.

The Boeing 747 is an old design. It's something that can safely be called "legacy" when compared to newer models with totally different technologies, such as fly-by-wire, 3D printed parts, composite materials, and so on. Yet the 747 is still being flown, and is still in production 45 years after its first commercial flight. By any measure, the 747 is comparable to mainframe legacy software.

So while newer models are out there and newer designs are coming online at a regular pace, the 747 is not going away. Why is that? There are many reasons--commercial airlines are subject to brutal economic competition, and moving from one model to a new one is not without cost.

Instead of  replacing the 747, airlines have discussed their changing needs with Boeing. As a result, Boeing has done something very common in the aircraft industry: it has "modernized" its aircraft, providing a total of five new variants over the years. Each variant comes with updated key components, increased size, and improved engine efficiency. But much of the core aircraft technology has remained the same (only the newest variant--the 747-8--will have a partial fly-by-wire system).

Modernizing instead of replacing

So I believe that equating "legacy" with "replacement" is an insufficient strategy when it comes to keeping systems relevant for business needs. Instead, as in the case of the commercial aircraft model, an equally viable alternative is modernization of legacy applications.

To consider modernization you need to understand what the assets actually comprise the legacy system. Classical architecture models consider three layers:

• Presentation
• Businessrules
• Data

In an ideal system implementation, these three layers are implemented separately, with clearly defined interfaces. In reality this is rarely achieved; sometimes for historical reasons, sometimes because of technical constraints.  The less these layers are implemented separately (and the more spaghetti-like the are), the harder any improvement becomes.

But when looking at any legacy system through the lens of these three layers, it's not uncommon to find that the data layer and the business rule layer actually function quite well. The years (or even decades) of maintenance have often resulted in code that is robust, performs well, and has very few defects. But what use is a functioning application when it cannot support the changing needs of a modern business? Typically what these systems lack are one of two (or both) aspects:

First, the systems were designed on the assumption that they were to be operated by trained in-house users. User interfaces were sequences of green screens that followed a predefined business process. As long as the business process stayed the same, users could become very proficient at operating these systems. That assumption however is no longer true--today's businesses tend to transfer much of the business process operation to its customers. Banks employ fewer tellers by letting customers doing their own banking. Retail shops allow customers do their own check-out, etc. Supporting this model cannot be done with green screen terminals, simply because there is no opportunity to train users. Instead, systems need to be flexible and interactive, guiding the users towards the objective they are trying to achieve.

The second problem is that systems can no longer work in isolation. An automobile insurance application system may want to Google the location where the vehicle is kept; a personal loan application system may want to run a reference check on an applicant by looking at their social media connections. Financial institutions already may have multiple accounts for one customer, and need to have a comprehensive understanding of the customer when making commercial decisions.

So we have applications that are functioning well when it comes to managing the facts of the business, but failing when it comes to supporting the changing pathways of interaction. To highlight this distinction, an alternative architectural view has been formulated that distinguishes between System of Record and System of Engagement:

System of Record

Focused on: Data processing, data validity, transaction performance, infrastructure style, representing the information asset

Priority: Trust, truth, stability, predictability

Outcomes: Robust systems, with predictable change dynamic, with a long life expectation

System of Engagement

Focused on: Interaction, Business Process, Collaboration, outsourcing, representing the dynamic side of the business

Priority: Change, Adaptation, Interaction, Flexibility

Outcomes: Highly dynamic systems, that change with the way the business changes.  Systems have comparatively shorter life cycles. Support of multiple channels of engagement

[box]

An alternative view is presented in a white paper  by the AiiM Community

[/box]

Interfacing a System of Engagement with a System of Record

When modernizing a legacy system, the primary focus is to build new systems of engagement using modern tools. The key is to interface the system of engagement with the system of record. As I pointed out before, legacy systems tend not to have clean architectural separations, and hence building a new system of engagement needs to be pragmatic. There are three pathways of doing so:

• Interface at the data layer
• Interface at the transaction layer
• Interface at the user interface layer

Each of these pathways has its own advantages and risks. A pragmatic solution may combine more than one path way, dependent on the nature of access:

Interfacing at the data layer

The data layer typically means accessing databases, record managers, or file systems. This gives direct access to data, providing the most flexibility when handling it. With this flexibility comes a downside in that much of the semantic meaning of the data may not be obvious. Business logic that the system of record has implemented is bypassed, resulting in the need to reverse engineer that business logic and re-implement it in this specific pathway. With this re-implementation comes the risk (or rather likelihood) of defects being introduced that the system of record itself does not have.

Additionally, the multitude of repositories may be an issue. Relational database are not the default data storage in legacy systems. Many mainframe systems still use record manager systems, which require technical knowledge that is restricted to those people who maintain the legacy systems, and not those that build the new system of engagement. A good strategy to manage this is by introducing a data visualization tool, such as Rocket Data.

Interfacing at the transaction layer

Some systems have the ability to provide access to business transactions minus the UI component. This is usually restricted to mainframe-based applications that use transactional environments such as CICS. These will need to be translated into APIs, such as Web services. Discovery of the semantic meaning is still non-trivial and requires careful identification, documentation and verification. Tools such as Rocket API provide critical capabilities to manage this process.

Interfacing at the user interface layer

Commonly called "screen scraping," this approach may appear pedestrian and does not give an architectural neatness to it. However; tools such as the LegaSuite Web and Rocket API product suites provide a sophisticated approach to managing the complexities that underlie the issue of simulating a human being operating a green screen user interface.

Once the technical issue of screen scraping is addressed, however, a number of advantages do appear. Firstly, this is the least intrusive approach to the system of record. From its perspective nothing appears to change at all.

Secondly, this approach preserves all the business logic that is implemented successfully in the system of record and which is a considerable asset--as noted above, this business logic tends to be well debugged over the decades of its use. There is no need to reverse engineer it nor to re-implement it, saving effort and avoiding logical defects which increasingly drive the costs of system replacement.

Summary: a path to modernize an application

To modernize an existing application (or more likely a system of applications) it is necessary to identify the systems of record (SoR) that should be preserved ,and to describe the system of engagement (SoE) that should be built. The system of engagement embodies new business processes, and new actors (e.g. customers, outsources). It needs to define how it intends to call on and operate the SoR. These are expressed as logical interfaces that often are hybrid interfaces, where an SoE interaction results in a multiple SoR interactions.

Using tools specifically for accessing legacy SoR such as Rocket Data, Rocket API and Legasuite Web, implementers can architect, implement and deploy actual implementations of the above logical interfaces. With the right approach these interfaces will provide the flexibility so demanded by SoEs, supporting new modes of business engagement while avoiding the costly and risky approach of replacing legacy systems.