CxO’s often ask why didn’t we see this coming when their LOB applications start to break down. The easy answer is you overlooked inherent aspects of the software development life cycle (SDLC).
Software has a natural tendency to age over time. At a certain moment, incremental maintenance projects will make no sense anymore and modernization programs are investible.
Software is subject to the laws of Maintenance Crisis:
- Software matures through usage: running in a production environment the smallest remaining bugs will be found over time.
- Law of continuous change: change will make software progressivity less useful over time until the cost for maintenance is greater than the cost of replacement.
- Changes introduce more complexity as structure (architecture) will deteriorate over time: unless the structure is changed or complexity is lowered.
Why will maintenance not resolve the problem?
Because maintenance does not change the foundation of the application the most fundamental issues are not considered.
- Maintenance entails changing the business logic (algorithms) or adding now features triggered by internal stakeholders (the business) or by external stakeholders (law, government).
- Maintenance in contradiction to Software Evolution will not change or evolve the underlying architecture.
How to recognize systems that exceeded their expiry date:
- No or outdated documentation
- No or few component tests
- Original development team is gone
- Break down become critical: failures will fail the business
- Third party hardware or software maintenance is expired
- Compiling the system takes a lot of time
Some derived issues:
- Knowledge of system’s architecture is gone
- Limited understanding of the system operations
- Different variations of the system exist
- Small maintenance tasks take a lot of time
- Backlog of change request and the backlog keeps on growing
- Source code contains duplicates but nobody dares to clean them up
Software modernization follows the Horseshoe Model that works in 3 phases:
Source: https://www.researchgate.net/figure/285760060_fig1_Fig-2-SEI-Horseshoe-Model-8
- Reconstruction:
Reconstruct the missing part of the old system in terms of business knowledge, missing information models and business process models.
This is a bottom up approach from source code and data bases back to functional and enterprise architecture.
- Transformation:
Map the old on the new: make sure that the new business processes contain the same technical and functional requirements as the processes. The bases need to be covered?
Complete the gaps: add the missing functionalities accumulated in the project backlogs.
- Refinement
This is a normal SDLC again: go from high-level requirements back to specifications and to new code to be developed.
Reconstruction is costly and can take up 50% to 90% of the overall effort!
To plan modernization projects, we need slice and dice the efforts. This can be done by:
- Analyzing dependencies: what needs to move together what can be migrated separately.
- Program slicing: what UI elements, business logic, code and information sources support a business activity.
- Top-down and button-up: trace the functional and technical requirement from model to code and vice versa.