In a previous post, I laid out the 13 categories of technical debt identified by Alves et al. In this post, I would like to dive into the first category: Architecture Debt. Let’s look at what it is, how it comes about and what to do about it.
What Is Architecture Debt?
The paper of Alves et al. defines architecture debt as “problems encountered in project architecture, […] which can affect architectural requirements (performance, robustness, among others).”
Architecture debt is not the same as being stuck with an architecture that is no longer considered modern. You can have architecture debt in a monolithic application as much as you can have it in a distributed system.
Rather, think about things like:
- violation of modularity: modules are tightly-coupled, making it difficult to apply changes without affecting other pieces of the application
- complexity in architecture: overly complex architectures may not be necessary (i.e. overengineering)
- an architecture not fit for your current needs: architecture has an important impact on how secure, performant and scalable your application is
- a badly implemented architecture: even if you’ve chosen a good architecture for your system, it may have been implemented suboptimally
- a wrong choice of technologies: using underlying systems that don’t provide the necessary features you need
Architecture debt points to problems in the architecture of the application, not in the code, although both are closely related.
Causes Of Architecture Debt
Like all types of technical debt, architecture debt can come about intentionally and unintentionally. Certain external pressures may push developers and architects to make architectural choices they know are suboptimal. On the other hand, they might choose an architecture that they believe is fit now, only to learn later that a better option exists (or existed), possibly because the requirements and the context in which the application is used have changed. Or maybe they didn’t think about the architecture at all!
Architecture debt can also be known debt or unknown debt. The team may be aware that a better option exists, but they may also not know about the better solution (yet).
Solving Architecture Debt
Solving architecture debt can be a significantly more difficult effort than solving technical debt in your code.
It requires a definition of the architecture you want to evolve to, and a roadmap for how to achieve this, with intermediate steps. It’s important that this roadmap be revised regularly and that stakeholders accept this will probably be a long-term effort. For some systems, we’re talking years of work.
Because, while modifying the architecture step by step, new features and bugfixes will still have to be released. A mature software development lifecycle is crucial to be able to pull this off. Think of practices like:
- automated tests
- continuous integration
- automated deployments
- monitoring and alerting
- automated rollback procedures
- good project management
The Business Case For Reducing Architecture Debt
Inevitably, every software system will have some amount of architecture debt. As applications evolve, area’s will emerge where modularity is insufficient or technologies become outdated.
The problem many companies face is explaining to stakeholders why this debt must be reduced. Where developers might be able to sneak smaller debt-reducing efforts into existing feature work, reducing architecture debt is usually too big to undertake without informing management.
It is often difficult to point to the business value of reducing the architecture debt. After all, if done correctly, the end user should not notice any changes in the application (except for perhaps performance improvements). That is why some software practitioners say there is no or little business value in reducing technical debt.
But the (great) value lies in the wins that can be made:
- faster future development
- a more stable product
- performance improvements
- and sometimes, better architecture enables implementing new features that were previously impossible
So while every product will have some amount of architecture debt, it’s worth identifying it in yours and taking time to reduce it.