Hoe je architectuurbeslissingen neemt zonder het team te vertragen — een terugblik op mijn sessie bij het Agile Congres 2026 in Groningen.

Imagine a tool running quietly in the background. Nobody’s quite sure what it does, who built it, or why it still exists. It has no clear owner, no trusted documentation. Yet somehow, it serves around 250,000 clients every year. It works, so people leave it alone.

Until one day, it crashes.

Suddenly, this forgotten tool becomes urgent. The operations team scrambles to bring it back, but there’s nothing to go on. No README, no diagrams, no code comments. Just a PDF from 1999 called something like System Overview (Final_v3_new).docx.

We’ve all seen situations like this. Systems that are important, but are barely understood. No one really owns them, and no one keeps track. And when something goes wrong, everyone’s left guessing.

It’s a reminder: when architecture lives only in someone’s head, or in no one’s, it becomes a risk.

The answer isn’t to go back to the old “ivory tower” way of working, where one architect makes all the decisions alone and writes everything down in a big document. That doesn’t help the team, and it doesn’t scale.

Instead, we need a practical approach. One where architecture is part of everyday work. Shared by the team. Visible in the code. Easy to find and easy to update.

This article spotlights three building blocks that support that way of working:

1. Diagrams that explain the system on different levels
2. Documentation that shows why key decisions were made
3. Fitness functions that check if the architecture remains compliant with the rules

Each of these should be supported by easy-to-use tools. In this article we take a look at the C4 Model for diagrams, ADRs for decision making, and ArchUnit to test architectural rules in code.

This approach makes architecture a team effort. Everyone can understand it. Everyone can help keep it healthy. And we’re less likely to be caught off guard by systems no one remembers.

Shared responsibility & effort on your software architecture builts great teams & better products.

Last May, I found myself in charge of something I’d never done before: creating the entire programme for a developer conference. SoJava 2025 was my first shot at conference organizing. The event was set for May 15th at the Forum in Groningen, and while I was part of the broader organizing committee, I had one clear responsibility: build a programme that Java developers would actually want to attend.

Hey there – welcome to Pragmatic Architect, this site is my personal corner of the internet to share thoughts, ideas, and lessons learned about software architecture.