How Technical Debt Influences Digital Sovereignty

The wild weeks of the election campaign kept us on our toes for a long time in the winter of 24/25. A major topic in the contest between the parties was the debt brake. On the one side of this debate were the advocates of the black zero. Often with the (poor) Swabian housewife in tow, they argued that debt should not be incurred under any circumstances, as it would be a burden on future generations. On the other hand, however, there was a very nice argument that allows us to use this analogy for -on our tech blog.

According to those who campaigned for the abolition of the debt brake, it was said: We have the debt brake, but of course we are in debt! How is that supposed to work without it? The thesis was as follows: Although the debt does not appear financially in the budget, it is outsourced to the existing infrastructure. For example, through bad bridges or delayed trains. And this is exactly how an IT system can behave.

In software development, we understand technical debt as expenses that are shifted into the future. These expenses often arise from design decisions that provide a short-term advantage, such as a faster release, but mean additional expenses in the long term - in other words, the expense is interest-bearing. It is important to understand that these technical debts of an IT system can arise not only in the code, but also in decisions regarding the system components used, software tests or poor documentation, which also lead to technical debt.

The specific reasons for technical debt can be many and varied. Following are a few examples:

1. Inadequate conventions: If the software artifacts are named without structure, developers will find it more difficult to fix bugs or add new functionalities in the future.
2. Outdated Components: In a system, a framework is used as a platform for implementation and provides an abstraction for a database system. The framework is not updated for a longer period of time. When updating the database software, the framework of my application must first be updated before the database can be addressed.
3. No suitable overall architecture: In the context of the overall architecture, it is always important to check whether the overall structure still corresponds to the strategy and vision of my system. Services are often initially developed as a small piece of software to which additional functions are gradually added. If the process and user behavior changes, the overall architecture should also adapt. This allows new features to be implemented permanently without major dependencies.
4. Bad knowledge management: IT systems can quickly become highly complex. If I don't reduce this complexity through appropriate knowledge management, my technical debt increases rapidly. Many of us must have experienced the situation where colleague Ahas to be asked before we can work on a new feature. This dependency represents technical debt.

The consequences of technical debt can manifest themselves in various ways. As a rule, you notice that technical debt has accumulated when the capacity for innovation in the IT system dwindles. PRs for the development of new functionalities take longer and longer, and their implementation becomes more and more complex. The training period for employees is also a good indicator. Increasing complexity and many dependencies make it more difficult for new employees to find their way around the system. After short-term successes, poor handling of technical debt leads to slower development of an IT system.

Now that we have looked at the problem from different perspectives, one question remains: what to do? As has already been explained several times, technical debt can occur in different places and at different levels. Accordingly, there are also a number of countermeasures. And these also work at different points and at different levels.

The overall structure of a system also provides a good basis for efficiently avoiding technical debt. If I cut my system into meaningful modules (or microservices), complexity can be reduced. In the short term, it helps developers to find their way around the code and to understand the functionality of certain components more quickly. Furthermore, clean modularization also helps with the testability of the system. On the one hand, modern CI/CD structures allow me to check fully automatically how good the test coverage of a module is and these tests can then also be executed automatically as unit, E2E, or regression tests.

Another function for reducing technical debt in a CI/CD pipeline is static code analysis. Established services enable organizations to automatically check whether a developer has adhered to the conventions of my development. If they have not, the artifact is not released.

In addition to the elements within the release, the platform also plays a role in the creation of technical debt. If the organizations develop their IT system on a public cloud and support the architecture with PaaS services, it has no ability but also no responsibility to update certain components. They rely on their provider to carry out the updates promptly. However, the tasks do not remain in the backlog.

The solutions outlined so far represent various ways of avoiding technical debt in specific situations. However, if we zoom out a little when looking at the system, a look at the classic software development process gives us much more leverage to avoid technical debt. Planning my next sprint is all about: Prioritization. And this is also the most effective way to avoid existing technical debt. The first step is to create an awareness of technical debt among all those involved. In particular, this involves making the long-term consequences transparent. The next step is to find a compromise. This means reserving capacity for development planning to avoid technical debt, but of course, also looking at how new functionalities can be implemented in order to remain attractive to users. In a third step, this compromise must then be reliably transferred to the development process. Be it agile - or in a waterfall model.

Digital sovereignty is self-determination in the digital space for Arvato Systems. Both technical debt and digital sovereignty deal with potential actions in the future. Technical debt has an influence on the self-determination of an organization. If technical debt forces an organization to carry out certain activities at a certain time in the future or if the flexibility of a system has decreased, this restricts alternative courses of action. Accordingly, high technical debt results in less sovereignty.