Architectural debt

Architecture is what’s expensive to change, so most organizations have accumulated debt in this area without realizing it.

30 years after the fall of the Berlin wall,¹ ⊕ ¹ The Berlin wall fell in 1989 but I have no idea when this photo is from, I should check whether this is still true. East and West are still divided by different bulbs in streetlights. There are probably lots of ways it would be easier to have the streetlights all be the same, but who has the time or money to replace them all?² ⊕ ² I like this metaphor because this debt accumulated in the most common way for digital architectural debt to accumulate, in my experience- mergers and acquisitions. Two countries merged to become one, but they didn’t merge in every way. My apartment has three electric panels; we’ll probably never merge the systems, it’s not worth it.

An edge persists.

Common signs of architectural debt:

• Menus/lists that have gotten too long
• Headers that should be fields
• Fields that should be taxonomies
• Many words for one thing
• One word that’s actually used for lots of things
• Different taxonomies in different places
• Multiple ways of showing the same kind of content
• Things that are just taped together, rather than integrated

Most of all: Places where complexity is being lost in its translation to the experience.³ ⊕ ³ To be honest, this one was a hard sell for me, but I’ve come around on it. Dan Klyn first introduced me to this idea when I was on his podcast, and I thought, “God, I want to get rid of some complexity. Later, I heard it reiterated in Domain Driven Design and it clicked for me. Many things we (as humans) do assumes the world has “a kind of mathematical smoothness,” as Andrea Resmini puts it. Complexity is roughness, and it’s fundamentally our job to grapple with it.

References

Khononov, Vladik. Learning Domain-Driven Design . 1st edition, O’Reilly Media, Inc., 2021.

How to do a strategic analysis of a business: 1. Identify the business domains and subdomains. 2. Evaluate the design of each component. A. Tactical: What patterns are used? Does the solution fit the complexity of the problem? B. Strategic: Chart the context map as if each of these components were a bounded context and track the relationships. Is there duplication? Multiple teams all working on one thing? The wrong types of subdomains being outsourced? Places where domain knowledge is being lost? 3. Identify opportunities to modernize: Where can you align system boundaries with subdomains? Where are models in conflict? Where are there collaboration patterns that aren’t working? Where is there a mismatch between the complexity of the system and the complexity of the model? 4. Cultivate ubiquitous language