In many companies, much legacy software has accumulated in the system landscape over the years. Replacing them with new software is often not possible without further ado. In order to modernize these systems and prepare them for future requirements, we recommend a step-by-step approach in most cases. This approach might be best described as an iterative and incremental evolution of the legacy software’s architecture. Following this itinerary, we already have been able to lead numerous customer projects to success.
Why Big Bang Is Risky
Many initially successful projects [suffer from] the second system syndrome – the tendency of small, elegant, and successful systems to evolve into giant, feature-laden monstrosities due to inflated expectations. ― Neal Ford, Rebecca Parsons, Patrick Kua: Building Evolutionary Architectures
Big Bang in software development usually implies the idea of a completely new software being specified, designed, and implemented, aiming at replacing the old software entirely.
This approach involves certain risks:
- Inadequate requirements analysis: The old software is so complex that a specification for the new solution may turn out incomplete and incorrect.
- Inflated expectations: Since this is all about a new development, great hopes are placed in the new software. It is supposed to fulfil a lot of additional requirements ("second system syndrome").
- Error source: The new software certainly avoids known errors of the old software, but may contain new errors.
- Complex implementation processes: Implementing the new system requires detailed planning of the launch, a high number of dry runs and complex fallback scenarios.
- Data migration from the old to the new software is extremely demanding.
- Downtime on the user side: The specialist department may get almost no new features for a very long time (possibly years).
- Possible loss of know-how: If a new software is developed by a different team than the one already existing, the original development team may get frustrated, resulting in motivated employees possibly leaving the company.
Step by Step to Modernization
When customers engage ConSol, they often have already tried to replace their old software once or twice with a new solution the Big Bang way. We then focus on an iterative and incremental evolution of the architecture. In other words, we gradually modernize the legacy software instead of putting all our hopes in the Big Bang. This procedure has proven to be highly successful in practice.
Agile Approach Is Mandatory
Business people fear breaking change. If developers build an architecture that allows incremental change [...], both business and engineering win.― Neal Ford, Rebecca Parsons, Patrick Kua: Building Evolutionary Architectures
Agile process models such as Scrum or Kanban represent key elements in the iterative and incremental evolution of the legacy software architecture. Since agile methods work with software increments, the development team immediately starts solving existing problems. The old software is being improved regularly so that the customer or an (external) test team can check the results frequently. Due to the continuous, flexibly adaptable planning it is possible to consider change requests at any time.
Another mainstay of this procedure is the customer’s economic evaluation of costs and benefits of the improvements. This links any improvement of the legacy software’s internal quality as well as any modernization of the architecture to the creation of business value. The modernization can thus be controlled based on business parameters. The fact that the customer himself prioritizes the improvements, brings his most urgent problems into focus.
The agile approach also improves communication, enhanced by constant contact and exchange between the project partners: short, efficient communication channels enable quick feedback. Decisions are made jointly. Regular meetings as well as Sprint Backlog and Product Backlog ensure high transparency.
Proven Techniques for the Evolution of Architecture
Change is the defining characteristic of software. That change – that adaption – begins with release. Release is the beginning of the software’s true life; everything before that release is gestation. Either systems grow over time, adapting to their changing environment, or they decay until their costs outweigh their benefits and then die. ― Michael T. Nygard, Release It!: Design and Deploy Production-Ready Software
Software is never "finished". The demands it must meet as well as its environment will be ever changing. Therefore, the improvement of software architecture must be a continuous process, for which the following techniques are suitable:
Evolution by Modularization (Identification of Domains, Increase of Cohesion)
- Identify code components of the legacy software that belong to the common domain.
- Modularize these code components (by refactoring and applying CleanCode principles)
- Introduce an interface for the domain.
The identification of domains and modularization is a prerequisite for the division and targeted modernization of legacy software.
The disadvantage of this approach: Individual domains are often closely interwoven with other components of architecture. In order to successfully modularize, a good understanding of the domain and the legacy software’s code is required.