Recap: Architecture Advice Process - Tech Talk by Eric Doernenburg

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 here: centralized architecture boards in large organizations typically cause massive bottlenecks without improving quality. The DORA research backs this up.

The Core Concept

The solution presented is Andrew Harmel-Law’s Architecture Advice Process. The core principle is that 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 in the matter. 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 is that it’s advice, not permission. By default, if there’s disagreement, the person asking for advice wins. This flips the power dynamic from traditional architecture boards where by default the architect wins.

What’s clever is how it naturally provides feedback. If you need to consult 20 or 30 people, that’s a warning sign the decision is too big. Break it down into smaller steps. If you only need to ask two or three people, you know it’s probably a smaller decision and you can move faster. The process itself tells you about scope.

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 powerful.

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

Modern Additions to ADRs

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: This shows you did your homework and prevents the “I’m so smart, 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, you’ve probably got bias there. Same if you list three options and one has only positives while others have only negatives.

Practical Storage Considerations

Source control: Keeps ADRs close to code which developers like, but makes them hard to find across repos (discoverability problem)

Wiki/Confluence: Makes them searchable which the organization likes, but developers tend to avoid these systems so ADRs won’t get written or maintained

Hybrid approach: Store in source control, automatically publish to central platform (like Backstage) via CI/CD. This gives you the best of both worlds.

The key is picking one approach and staying consistent with it.

Important Distinctions

Not everything hard to change is architecture. Internal API between your React frontend and Node backend maintained by the same team? That’s an implementation detail, not an “API” needing formal design review. Treating it as such just slows you down. For public APIs you absolutely need proper design processes, but for internal APIs with two consumers, skip the ceremony.

Microservices made this harder, not easier. 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.

You should be cautious about 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 about information sharing and diverse input, not consensus or decision-making. 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. Better to skip it if the culture isn’t ready.

Complementary Practices

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

Tech radar: At places like Zalando it has governance aspects. Something in “hold” status isn’t banned but sends a clear 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 was to not make meetings longer than necessary. If people are bored during updates, stop giving those updates. The facilitator should watch for this and cut things not adding value.

There was a concern about this being just a paper trail for “I told you so” later. That’s definitely 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 for next time.

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

On experiments: sometimes you have to make decisions with incomplete information. But if you can do small time-boxed experiments to gather data, absolutely do it. Just keep them focused, don’t spend three weeks prototyping before deciding.

What I’m Taking Away

Decentralized decision-making with structured advice-seeking and lightweight documentation feels right for where we are. It acknowledges that teams closest to the problem often have the best context, while still leveraging experience from 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.” This is why process matters. The goal isn’t perfect specifications or architects dictating solutions. It’s surfacing assumptions early, getting them challenged through advice, and documenting 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 decisions that don’t? How do we prevent ADRs from becoming box-checking rather than learning tools?

Architectural principles and a tech radar seem like the answer to the first question (lightweight governance without permission). Still thinking through the others.

Good talk that challenged assumptions about how architecture should work in larger organizations and gave concrete ideas to experiment with.

Resources

#Architecture #Tech Talks #Personal