Recap: Architecture Advice Process - Tech Talk

We recently had Eric Doernenburg from ThoughtWorks at our MOIA office for a tech talk on the Architecture Advice Process. Good timing because I’ve been thinking about how we make architectural decisions in our platform engineering team and where the friction points are.

The talk started with a familiar scenario: development teams need architectural decisions, but they go through a central architecture board. Initially it works fine, but as it scales the architect’s inbox piles up. They start sending standard documents instead of custom responses, teams wait in queues, urgent issues can’t jump ahead. Worse, the feedback loop breaks completely. When teams implement decisions and learn what works in practice, that knowledge stays siloed. It never makes it back to the architect.

The point: centralized architecture boards in large organizations typically cause bottlenecks without improving quality. The DORA research backs this up.

The core concept

The solution is Andrew Harmel-Law’s Architecture Advice Process. Anyone can make an architectural decision, but they need to seek advice from two groups first.

First, everyone meaningfully affected. If your change means another team has to put something in their backlog, they’re affected. If you’re breaking API backwards compatibility, consumers are affected. Same for cross-cutting concerns like InfoSec, legal, or design systems.

Second, people with expertise. Maybe your team wants to switch from Java to Kotlin, but there was probably a reason the company standardized on Java. The people who made that decision might know things you don’t. Doesn’t mean you blindly follow their advice, but you need to ask.

The most important part: it’s advice, not permission. If there’s disagreement, the person asking for advice wins by default. This flips the power dynamic from traditional architecture boards where the architect wins by default.

What’s clever is how it naturally signals scope. If you need to consult 20 or 30 people, the decision is probably too big — break it down. If you only need to ask two or three people, you can move faster. The process itself tells you something.

Architecture Decision Records

The second piece is documenting decisions with ADRs. These have been around since 2011 (Michael Nygard), but the combination with the advice process makes them more useful.

Basic format: title, context, decision, consequences, status.

Modern additions

Advice section — when you ask for advice, people write it down in the ADR. This creates a record of who was consulted and what they said, without making it about permission or blame. An expert can write “I strongly advise against this” and the team can still proceed, but it’s documented.

Options considered — shows you did your homework and prevents the “they didn’t think about X” problem. Someone thinks they found an obvious solution you missed, but you actually considered it and there was a constraint that ruled it out.

Explicit consequences (positive and negative) — if consequences are all positive, there’s probably bias. Same if you list three options and one has only positives while the others have only negatives.

Where to store them

Source control — close to code, which developers like, but hard to find across repos.

Wiki/Confluence — searchable, which the organization likes, but developers avoid these systems so ADRs won’t get written or maintained.

Hybrid — store in source control, automatically publish to a central platform (like Backstage) via CI/CD.

Pick one and stay consistent.

Important distinctions

Not everything hard to change is architecture. An internal API between your React frontend and Node backend maintained by the same team? That’s an implementation detail. Treating it as a formal “API” needing design review just slows you down. Public APIs with external consumers are a different story.

Microservices made this harder. Martin Fowler’s “you must be this tall” paper about prerequisites got mentioned — many organizations tried microservices without team autonomy and decision-making capability. You can’t have autonomous teams if they need permission from a central board for every decision.

The process assumes organizational maturity: psychological safety, trust, constructive advice culture. Just implementing the process won’t create these if they’re missing.

The optional architecture advice forum

Weekly one-hour session where team representatives, experts, and architects discuss decisions. Not mandatory, not about permission — just asking for advice.

Watch the power dynamics though. If the senior person says “so we are in agreement then” in a way that prevents disagreement, you’ve already lost. The meeting is for information sharing and diverse input, not consensus. Actual decisions happen through the advice process outside the meeting.

You don’t necessarily need this forum. It can help in the right context but can backfire if people think they can’t make decisions without it, or if junior people feel intimidated.

Complementary practices

Architectural principles — write down principles teams can reference when making decisions. These shouldn’t just come from architects. Example from a Hamburg company: for each instanceof operator you add, remove one. They had an anemic domain model and this forced behavior into domain objects.

Tech radar — at Zalando it has governance aspects. Something in “hold” status isn’t banned but sends a signal. When they put Rust, Haskell, and Clojure on hold, it was about hiring challenges and concerns that developers were more interested in cool tech than business problems.

Discussion highlights

Someone asked if advice forums feel repetitive with lots of ADR updates. The answer: don’t make meetings longer than necessary. If people are bored during updates, stop giving those updates.

There was a concern about this being a paper trail for “I told you so” later. That’s an anti-pattern to watch for. The advice section is written before the decision, by people actually giving advice. The point is to help the team decide better, not create ammunition for blame. Though there is some value: when teams ignore good advice and things go wrong, you can learn from it.

Timing matters: collect advice before making the decision, not after. You’re genuinely asking for input that will shape your thinking, not asking people to rubber-stamp something already decided.

On experiments: sometimes you have to decide with incomplete information. If you can do small time-boxed experiments to gather data, do it. Just keep them focused.

What I’m taking away

Decentralized decision-making with structured advice-seeking and lightweight documentation feels right for where we are. Teams closest to the problem often have the best context, but they still benefit from experience of people who’ve solved similar problems.

One thing that stuck with me: “It’s the developer’s assumptions that get shipped to prod, not even the requirements.” The goal isn’t perfect specifications or architects dictating solutions — it’s surfacing assumptions early, getting them challenged, and documenting the thinking so we can learn from it.

Questions for our context: How do we balance “anyone can decide” with legitimate needs for consistency? Where do we draw the line between architectural decisions needing this process and smaller technical ones that don’t? How do we prevent ADRs from becoming checkbox exercises?

Architectural principles and a tech radar seem like the answer to the first question. Still thinking through the others.

Resources

#Architecture #Tech Talks #Personal