🔗 Architectural debt is not just technical debt

When I was a developer, half of our frustrations were about technical debt (the other were about estimates that are seen as deadlines).

We always made a distinction between code debt and architecture debt: code debt being the temporary hacks you put in place to reach a deadline and never remove, and architectural debt being the structural decisions that come back to bite you six months later.

While I agree that implementing software patterns like the strangler pattern or moving away from singletons is definitely software architecture. Architectural debt goes way beyond what you find in the code.

How I see technical architectural debt these days.

As an enterprise architect I still mostly complain about architectural debt and estimates that are seen as deadlines. That much certainly hasn’t changed.

These days, I’m less concerned with how the software itself works. That’s just not feasible when your organization has hundreds of applications 1. My main concerns are more about how these applications interact with the rest of the landscape. How the data flows, where data lives, whether there are bottlenecks, who’s going to maintain it, and what role will this application have in the future.

In an enterprise environment this is inevitable. There are so many applications and more than half of them are 3rd party SaaS applications. You need to keep on top of what you can control and let go of the parts you can’t.