Executive Summary
In this paper, the authors identify the characteristics of legacy systems and explore why they are costly to maintain and support. The authors define legacy systems as “a system that is business critical and demonstrates one or more of the following characteristics: old age, obsolete languages, poor if any documentation, inadequate data management, a degraded structure, limited support capability and capacity, changed to meet business needs, increasing maintenance costs, and lacking the necessary architecture to evolve.”
For older organizations, legacy systems maintenance costs represent a high share of the IT budgets, which makes it critical to assess the state of these systems and to implement appropriate long-term solutions. Thus, the authors present a meta-model that helps senior management to make informed decisions by bridging the gap between technical and business issues.
Legacy System Assessment Model
The authors combined three existing models to cover business, technical, architectural and organizational factors that can impact legacy systems assessment.
Is the System a Legacy System?
The first step before analyzing the legacy system is to determine if the stakeholders consider the system to be legacy. This can be done by using the definition from the Executive Summary and by asking if it’s applicable (Yes) or not (No) to the system. The authors also include the option Maybe or Don’t know. Note that some of the questions below are subjective and might vary depending on the knowledge of the stakeholders:
- Is the system business critical?
- Is the system old?
- Has the system been changed to meet organizational needs?
- Is the system degrading as changes are made?
- Does maintenance costs increase as changes are made?
- Does the system use obsolete languages?
- Does the system have poor, if any, documentation?
- Does the system have inadequate data management?
- Does the system have limited support capability?
- Does the system have limited support capacity?
- Does the system lack the architecture to evolve to meet emerging requirements?
Depending on the percentage of Yes answered (>50%), stakeholders should continue the analysis with business, technical attributes.
Decision Matrix and Recommended Solution
For each attribute, the authors ask the stakeholders if they are used (Yes) or not (No) in the assessment of the legacy system. They then ask to put a value from very low to very high on the attribute, which they recode from 1 to 5. Don’t know is recoded as 0.
Business Attributes:
- Economic value: Market value, Profitability index, IRR;
- Data value: Percentage of mission critical archives, Percentage of application dependant archives;
- Utility: Business function coverage range, Actual usage frequency, Customer/user satisfaction metrics;
- Specialization: Percentage of highly specialized functions, Percentage of generic functions.
Technical Attributes:
- Maintainability: Lines of code, Function points, Control flow, Knots, Cyclomatic complexity, Dead code rate;
- Decomposability/architecture: Architecture modularity, Percentage of modules with separation of concerns, Extensibility, Interoperability, Architectural style, Consumption;
- Deterioration: Backlog increase, Defect rate increase, Response-time increase, Maintenance time per request increase;
- Obsolescence: System age, Operating system version, Hardware version, Technical support availability, Security, Legality, System evolution required for business goals.
To convert the business attributes and technical attributes into final values, the authors use the following equations:
The combined values can then be plotted on the decision matrix that indicates a recommended solution.
Organizational Attributes
Here, the authors use the same methodology then with technical and business attributes. The organizational attributes (Internal development & maintenance, Outsourced development & maintenance, Technical maturity, Commitment to training, Skill level of system support, Response to change) are used to identify gaps between the recommended solutions and the actual plans from the organization. For example, if the internal development and maintenance index is high compared to other attributes such as technical maturity or commitment to training, it might indicate that there is a gap in the organizational capabilities to deliver the recommended solution/plan.
Conclusion
This paper provides a holistic model to assess the state of legacy systems and shares a decision matrix that helps senior managers and technical people to implement the appropriate solutions in order to contain maintenance costs.
Many legacy systems were built in a time when efficiency took precedence over maintainability because of costly computer processing power and storage capacity. Furthermore, system degradation can be caused by poor documentation, version control and architectural decisions which inevitably cause an increase in maintenance costs.
It is important to remember that the assessment of legacy systems and the subsequent decisions of what needs to be done must be taken and supported by a broad range of stakeholders (both business and technical). It is also essential to consider organizational factors such as resistance to change and internal capabilities before implementing the solutions.
