Software Health Check

During the preparation phase, we plan the entire process of the software health check. Binding deadlines and time frames are set at this stage so that you know exactly how much time you and your employees need to plan and when the health check will be completed.

During the preparation phase, we also formulate your key questions together and record the identified goals.

Download the detailed agenda here:

The organizational preparation phase is followed by the understanding phase. In a kick-off meeting, all those involved are brought together and informed about the objectives and procedure of the software health check.

We continue with five consecutive workshops in which we examine the system so that no angle is left unconsidered. We involve all stakeholders such as the specialist department, developers and IT architects, scrum masters and IT operations, building on shared knowledge and taking people with us. As a result, our in-depth as-is analysis of the system forms the core of this section.

In this phase, we examine the quality of the software architecture and code in detail as well as their causes, which can usually be found in the development process. Among other things, we examine the functional system interface (business-IT alignment), identify dependencies and search for dependency cycles and code hotspots. These can be security vulnerabilities in libraries or proprietary code, for example, but also technically complex code that is frequently edited by different members of the development team and has low test coverage. Unfortunately, we find such ticking time bombs much more often than we would like.

In addition to commercial analysis tools, we primarily rely on CodeCharta, a tool we developed ourselves and published as open source, with which we can visually compare several metrics from different sources as "software maps".

This is because real hotspots only emerge when different aspects come together. For example, very complex code that is sufficiently tested and rarely subject to changes is evaluated differently than comparable code with a higher change frequency and therefore a higher risk of bugs arising in the future.

All these and other findings serve as input for a joint evaluation in workshops with your development and architecture teams.

This leads to the third phase: evaluating the system. Together, we identify the strengths and weaknesses of the software and derive clear recommendations for action. These are validated in a workshop with the existing team and checked for feasibility.

At the end of the evaluation phase of the health check, we examine which of the following options represents the optimal solution: refurbishment of the existing system, a completely new system or the use of a commercially available off-the-shelf product. Among other things, we take into account the future viability of the technology stack used, the availability of know-how (including on the job market), the strategic relevance of the project for your company and cost-benefit aspects.