Magazine article CMA - the Management Accounting Magazine

A Common-Sense Approach to Managing Legacy Applications

Magazine article CMA - the Management Accounting Magazine

A Common-Sense Approach to Managing Legacy Applications

Article excerpt

The systems we have inherited over the past three decades won't quickly go away. We need to learn from them and ensure that they effectively co-exist during the transition to new client/server applications. Here's how.

There are two ways of looking at legacy systems. The first, simplistic, view is that they are bad news because dinosaurs wrote them using outdated technology. The second, more sophisticated view is that they won't and shouldn't go away. Like legacies in other parts of our lives - cultural and financial legacies, for example - we can't escape them, and they can be useful. The billions of lines of legacy code created over the past three decades can not be replaced overnight. As with other types of legacies, this presents both a problem and an opportunity. The problem is how to make the legacy systems co-exist with new client/server applications during a lengthy transition. The opportunity is to improve the transition by learning from the past and understanding how these legacies were constructed. This opportunity is the subject of this paper.

Application development in the '80s

One of the great ironies of application development in the '80s was that, even as MIS departments were working overtime to support rapidly changing business needs, their actions constrained their ability to support future change. Three key factors influenced development projects during this time:

1. Automation of business functionality that was beyond the bounds of traditional applications, but connected to those applications.

2. Addition of new and varied business processes.

3. Promotion of re-use by the corporate data and standards departments, especially in terms of data sharing.

These factors caused incredibly complex interdependencies. To illustrate, here is a typical scenario: system A feeds a transaction to system B for processing, in response to a feed from system C, and after checking data against system D, retrieving data from system E and sending an update to system F. In many cases these interdependencies between applications are so complex it is virtually impossible to distinguish boundaries between systems.

This complexity has placed serious constraints on flexibility, as changes to one application require changes to several related applications, which in turn often cause further changes to their interfacing systems. The constrained flexibility, in turn, has caused the following application development/maintenance (AD/M) problems:

1. Increased cost.

2. Increased cycle time (analysis, development, testing and implementation).

3. Increased risk of project failure.

4. Increased defect rate.

5. Decreased systems availability.

6. Decreased client and end-user satisfaction.

7. Decreased morale.

Frustration with this inflexibility was clearly one impetus in the moves toward business process re-engineering and client/server. In one view, complicated application architecture represented a complex set of business processes that begged for simplification. In another view, the lure of client/server and object technologies, with their attendant tools and rapid development techniques, showed a better, faster way to support business change. Either of these views provided the impetus to unbundle the behemoth applications.

Learning from the past

Much of this complexity was inescapable since it supported required business functionality. However, in many cases, the complexity became excessive because MIS departments made two fundamental mistakes as they rushed to deliver this functionality.

Mistake 1. Applications were viewed in isolation. Most development teams heeded the urgings of the corporate data architects and other standards groups to "do it once," and began connecting their applications together. However, they still approached the work from the view of the application, and not the business process. …

Search by... Author
Show... All Results Primary Sources Peer-reviewed

Oops!

An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.