When Architecture Actually Influences Decisions

I've never been comfortable with architecture that only documents what's already been done. To me, architecture has always been about contributing to better decisions. That's also given me clear architectural positions, not to be difficult, but because the consequences of architectural choices are real and tend to last.

Even so, a large part of my career has been less about the architecture itself, and more about the work of getting good solutions understood, prioritized, and actually chosen. Many times, other choices have won out, not necessarily because they were better, but because they fit the moment better, because someone was more persuasive, because the solution was easier to sell, or because various interests, relationships, or political considerations made certain choices easier than others.

A Recurring Pattern

Over time, I've noticed a pattern. Solutions chosen against sound architectural judgment often didn't hold up. They became too expensive to maintain, too complex to build on, or too fragile once scale and change arrived. In the end, often much later, teams tended to move back toward the solutions that had originally been proposed.

That builds trust over time, but it's an exhausting way to work, and it's the kind of fight that quickly turns personal. When architecture gets reduced to preferences and opinions, discussions quickly become about who people listen to, rather than what's actually most sustainable over time. Hidden connections and unspoken alliances make the landscape even harder to navigate, and the harder you push, the greater the risk that the architect gets seen as an obstacle rather than a resource.

How Does Architecture Actually Gain Traction?

Something shifted once I started reflecting on how architecture actually gains traction. I began to see that the problem was rarely the content of the architecture. The problem was the form. Architecture was treated as documentation, something people could read into their own context, nod along to, and then carry on as before.

That's when the shift happened: from architecture as explanation to architecture as decision support.

ADRs as a Decision-Making Tool

Working with ADRs became an important turning point, not because the format itself is particularly sophisticated, but because it forces explicit choices:

• Which alternatives were actually considered?
• Why was one option chosen over another?
• Which consequences are we knowingly accepting?

Provided, of course, that the work is done honestly and in good faith. An ADR used as after-the-fact justification has no value, but used properly, it makes architecture harder to ignore without becoming authoritarian.

Decision Matrices Sharpen the Thinking

Decision matrices have been an important complement, not just to help others, but to sharpen my own thinking. When criteria and weighting have to be made visible, it becomes harder, for yourself and for others, to cling to a solution just because it feels right.

Strategy Has to Be More Than Words

The same applies to strategy. Having a clear architectural strategy, and actually standing by it, has been essential, including when temporary solutions have to be used. The difference lies in being explicit about:

• what's temporary
• why it's temporary
• how you move forward from it

The Work Around the Decisions

Just as important has been changing how I work around decisions themselves. Good preparation before meetings makes architecture relevant when decisions are actually being made, fast follow-up after meetings reduces room for reinterpretation, and clear communication with the right people matters more than extensive documentation available to everyone.

Diagrams as Precision Tools

Diagrams have also taken on a different role, not as complete truths, but as precision tools. For example:

• simple flow diagrams where an overview matters
• sequence diagrams close to the team where interaction needs to be understood

Too much detail in the wrong forum creates noise, and too little detail where it's actually needed creates misunderstandings.

From Documentation to Decision Mechanics

Today I look at architecture through a different lens. Not as the fight to be right, but as the work of making decisions explicit, verifiable, and clear enough to hold up over time. When architecture is used that way, the need to fight is reduced, not because conflicts disappear, but because the decision space becomes clearer.

Architecture stops being documentation of what happened. It becomes part of the mechanics that determine what actually happens.