Scaling the Practice of Architecture, Conversationally

When top-down architecture no longer fits

Traditional software architecture—the non-coding, decision-taking, diagram-drawing variety—struggles in an environment of continuously delivering, autonomous teams. The architect’s job becomes impossible: be everywhere at once, accommodate significant contextual differences across teams, and never become a bottleneck.

One response is to stop taking architectural decisions altogether. That sounds like abdication, but it is actually the foundation of a different model: architecture as a conversation, distributed across teams and supported by lightweight alignment mechanisms rather than imposed by a central few.

This matters because the trend toward team autonomy increases, not decreases, the need for architectural thinking. The challenge is how a small number of architects can serve many value-stream-aligned teams without being present everywhere. The answer is not more architects. It is a workable approach to the human-scaling problem of architectural decision-making under autonomy.

Architecture as a set of mechanisms, not a role

The shift is from architecture as a monologue—delivered top-down by a centralised few—to a series of conversations. These conversations are driven by a decentralised decision-making technique and supported by four learning and alignment mechanisms:

• Decision Records—capturing decisions in a structured, shareable format.
• Advisory Forum—a regular, open gathering where decisions and directions are discussed and ratified.
• Team-sourced Principles—principles that emerge from teams themselves.
• Technology Radar—a living view of the technologies teams are using or considering.

Together, these mechanisms create a structure where architectural decisions are made locally, but with visibility and scrutiny across the organisation. No single architect needs to be everywhere; instead, the practice of architecture is distributed and the conversation itself does the governing.

The Advice Process: Decision-Making at the Edges

If the goal is a maximally independent team, we still need a mechanism for architectural decisions. We need many centres of decision-making, but that runs against the grain of the classic top-down model with a select group of all-powerful architects. The skeptics are right: decisions still have to be made. The question is how to make them deliberately without a central master.

The answer here is the Advice Process. It is remarkably simple, comprising one rule and one qualifier:

• The Rule: anyone can make an architectural decision.
• The Qualifier: before making the decision, the decision-taker must consult two groups: everyone who will be meaningfully affected by the decision, and people with expertise in the area the decision is being taken.

That is the entire process. Those two consulted groups are not a veto committee: the decision-taker is not obliged to agree with them. What is required is that the decision-taker seeks them out, listens to them, and records their input. The point is not consensus; it is a broad range of voices.

The obvious objection is that meaningful consultation could snowball into demands on everyone’s time. A simple checklist mitigates this. Affected by InfoSec? Talk to the CISO. Touching PII? Engage Mary in data and Vanessa in legal. Changing an onboarding flow? Your UX lead. Adopting a new cloud service? The cloud architect. Altering an API? Speak to every lead on the teams consuming it. The list can be long, but that signals the decision’s size and import. Often, it forces the decision-taker to reconsider whether the decision can be split into smaller, more tractable parts. Many large decisions, when examined this way, shrink into a sequence of right-sized ones.

A further push: actively seek out those who will disagree. Without the burden of trying to convince everyone, the conversation can engage far more seriously, yielding both better decisions and deeper learning. The outcomes in practice are familiar to those who have tried it: better, faster, more accountable decisions—and crucially, decisions that are understood and owned by the people who implement them. The decision-taker is the one who needs the outcome and carries the accountability.

This broadens the pool of available decision-takers. Teams soon recognize a bias-to-action, knowing they can resolve their own problems, while the built-in consultation prevents impulsive moves. The approach removes the need for a fixed, permanent hierarchy or an abiding master decision-taker. That is why the Advice Process is the foundational element in any architecture aspiring to call itself anarchistic.

Conversations before Conventions

That does not eliminate the need for “traditional” architects. Far from it—the role simply changes. Before describing the supporting elements, it is worth pausing on what they have in common with the core element: an emphasis on conversation as the vehicle for shared understanding.

Alberto Brandolini’s quip—that it is the developer’s assumptions which get shipped to production—is apt. What lands in production is what a developer understands about an architecture, not the diagrams in the lead architect’s head. Decentralising architectural decisions inherently mitigates this risk. The architecture that lives in the heads of those writing the code is the architecture that matters.

But this confronts us with the classic architectural problem of coherence: if everyone is empowered to decide, how do we ensure the sum of the parts is a coherent whole? How do we fold in a longer-term perspective, and how do we support those newly empowered decision-takers? Ruth Malan put her finger on it:

[In order for an architecture to be successful] it is very much about ensuring that conversations that are needed to be happening are happening - not always initiating them, nor always helping to focus or navigate them, but ensuring they do happen […] and guiding when needed

The Advice Process puts conversations, responsibility for seeking expertise, and impact analysis at the centre of decision-making. The supporting governance elements exist to make those conversations as timely, focused, and effective as possible. There are four of them:

1. a thinking and recording tool;
2. a time and place for conversations;
3. a light to illuminate and guide towards a unified direction;
4. a means to sense the current technical landscape and climate.

Governance, Strategy, and Cross-Functional Requirements

Two things are deliberately not covered in the core approach: technical strategy and cross-functional requirements (CFRs). Both remain essential for software of any meaningful size. A well-evangelized strategy lets decentralised teams prioritise activities best aligned with the organisation’s maturity; clear, testable CFRs keep teams from focusing purely on local delivery to the detriment of the shared ecosystem.

However, technical governance refers to these rather than encompassing them—they contribute the context within which governance operates. Governance itself concerns what else is needed to ensure good technical decisions. The following elements describe the practical toolkit for that scaffold.

Element One: Decision Records as Thinking Tools

Architectural Decision Records (ADRs) anchor the whole approach. These lightweight documents, typically stored in the repository alongside the code they describe, form the first supporting element. Plenty of formats circulate among adopters, but a handful of core elements matter most in practice.

This minimal template unexpectedly doubles as a learning aid. The structure acts as a checklist, prompting the decision-maker about what they need to consider — and, more crucially, what they need to discuss with others. Teams frequently absorb the habit of making architectural decisions by simply following the ADR structure.

ADRs also reinforce the Advice Process by making it mandatory for authors to record the advice they receive. Encouraging authors to wrestle with that advice directly in their options section — rather than just collecting it — makes a meaningful difference. Capturing input is one thing; engaging with it actively usually produces better outcomes.

Patients across a series of ADRs form a visible decision history. Newcomers to architecture can browse past decisions, see how trade-offs were weighed, and understand why some were later reversed as circumstances evolved. In essence, the ADR set becomes a form of recorded thinking for the software, written by the people who shaped it.

Element Two: A Weekly Architecture Advisory Forum

The second element creates the container for the conversations the decision practice requires, in the form of a weekly, hour-long Architecture Advisory Forum (AAF). As a regular fixture, it gives advice-seeking a dependable time and place.

Attendees typically include delegates from each delivery team plus the key roles identified in the Advice Process checklist, but the invitation stays open. That openness encourages transparency and brings in perspectives outside the immediate team. Signals of a healthy AAF include conversations that are timely and substantive, and contributions from a breadth of participants.

A standing agenda keeps the session productive:

• Team representatives flag new spikes, which provide early warning of decisions likely to come and let the group share existing knowledge.
• Anyone presenting a proposed decision introduces it in the form of an ADR.
• A timeboxed revisit of other in-progress decisions, permitting teams to revise choices made with incomplete information.
• A review of engineering metrics and cloud spending trends.
• Open time for other business.

Superficially this resembles a standard architecture review forum — typically known as a Tech Advisory Board or Architecture Review Board — but there are pointed differences. Ownership of each decision remains with its originators.

Attendees at the AAF can only offer advice or suggest further people to consult, in keeping with the Advice Process. That draws in the individuals who are affected by, or knowledgeable about, the decisions under discussion — not just tech leads. Feature team members, including BAs, product owners, and QAs, commonly join from across programmes of work, along with UX, product, operations, and occasionally senior executives.

The conversations themselves mark the third and most significant distinction. Whereas Advice Process consultations often happen one-on-one, AAF discussions occur before an audience — inviting everyone to listen and learn. In practice these sessions deliver an unusual concentration of organisational, domain, and experiential sharing, making them among the best-attended and most engaged hours of the week. The forum intentionally normalises disagreement and treats decision reversals as learnings, broadening a shared understanding of the architecture until it reaches the delivery teams.

Element Three: Team-Sourced Architectural Principles

Architectural principles themselves are not original, but serviceable examples are rare. With highly autonomous teams they become essential — they are the tool by which a cohort of independent teams stays aligned without central control.

A solid architectural principle meets four conditions. It provides a criterion for evaluating decisions, which in practice means it must be specific, measurable, achievable, realistic, and testable. It supports the business's strategic goals. It spells out the consequences or implications it implies. And, across a set, principles number neither few enough to leave blind spots nor so many that teams can't remember them.

Common failures involve confusing principles with other things. Practices are methods — TDD, trunk-based development, or pairing — and, while valuable, they are not architectural principles. General principles like "keep it simple" are real principles but apply too broadly; they don't help with a choice among, say, implementing self-hosted Lucene on AWS versus Amazon Elasticsearch, or across the main integration tactics for micro-frontends. What teams need is something to steer architectural practice specifically toward the organization's strategic aims.

Consider how a principle articulated for a stream-aligned team model reads:

Title: Value independence of teams most highly

• Subtitle: Split solutions along team lines
• Rationale: Our strength in building and running products rests on team independence. Known downsides are acknowledged, but the upsides win out whenever predicting future needs is hard.
• Implications: It accepts duplication in both function and data as inevitable, embracing eventual consistency rather than resisting it. Combined licensing and support costs of separate third-party solutions may exceed one shared solution. Each team designs for its own needs, not those of other teams. Systems tend toward smaller size and more specific focus, with teams supporting what they adopt independently.

Further examples appear in the publicly available John Lewis Software Engineering Principles, although a few entries there shade toward general, non-architectural guidance such as "Understandability" and "Performance Importance."

Sourcing the principles is a collective activity, inspired here by the techniques in Abbot and Fisher's The Art of Scalability, which recognizes that delivery teams must feel ownership over any principle by which they are asked to judge their work. Given the business strategic goals, SMART criteria, and broad participation across technology and beyond — the AAF's invite list again proves its value — a group quickly converges on a viable eight to fifteen principles. Teams may capture adoption of each principle as an ADR, keeping the record light and focused on the rationale rather than echoing content.

Principles fulfill a subtler purpose too. They form the minimum set of shared understandings among otherwise autonomous teams. Because that autonomy is the point, ADRs must flag not just which principles a decision applies, but also where one is in tension with a chosen approach. Conflicts routed through the AAF pull broad perspectives into the ADR record, producing better decisions and — when a conflict persuades the group that the principle itself is wrong — a superseding ADR marking the change.

Element Four: A Custom Technology Radar

Architecture decisions depend on more than principles. What everyone else is doing, what skills the org holds today, and where the wider technology industry is headed all factor into the judgment call. The fourth element addresses the surrounding landscape: a custom Technology Radar.

ThoughtWorks' publicly available radar is an opinionated view of trends across techniques, tools, platforms, and languages and frameworks. Its insight derives from the visual layout, which shows the full current landscape and the shifting movements of "blips" within it.

Less widely known is that the radar can be self-built using the "Build Your Own Radar" (BYOR) tool. This configurable platform lets an organization capture its own version of the trends it lives with day to day. In one common setup the quadrants stay as techniques, tools, platforms, and languages and frameworks, while the rings trace how technologies pass through a team's delivery cycle: experimenting, adopting, holding, retiring.

As with principles, radar blips start life in a workshop that crowd-sources the data. The first session captures the organization's full existing inventory in a baseline sweep. Before running it, participants settle the scope: the full organisation or just one project, whether adjacent disciplines such as Ops and UX are included, and which quadrants apply. Fields can extend beyond the standard ones, though keeping the model simple is usually wise. First sessions can be lengthy — sometimes four hours or more — precisely because including every member of every team, not merely architects, is the point. What emerges is a wide-angle view of the landscape and climate, alongside plentiful discussion about where investment increases or recedes, and an aligning of collective understanding.

The radar's living usage matters as much as its initial chart. ADRs carry a section flagging relevant radar blips, and that field is useful not only for documenting which technologies being used align with the current radar, but also for anticipating changes that a decision will introduce to that picture — be it spiking a new framework or moving a technique from "experiment" to "adopt". These links fuel further AAF conversations, provide content for narrative in ADRs, and usually encourage the naturally occurring submissions of new ADRs without any process prompting, leaving teams engaged broadly with the architecture as it evolves.

Cadence for keeping a radar current varies. Quarterly and half-yearly intervals both function; the practical guide is how heavily the radar is referenced in AAF conversations, and whether that withers or persists will indicate when a refresh is due.

A Day in the Life of an Architectural Decision

When an architectural decision first surfaces, it’s usually vague and poorly understood. The instinct should be to open a fresh ADR template and start filling it in immediately, beginning with the “context” section. This forces you to articulate the “why” behind the decision and the forces at play, which often reveals gaps in your knowledge that require research.

That research should start with the architectural principles and the radar. Principles indicate the direction of travel; the ideal solution will align with as many as possible. If a principle can’t help you choose between two options, either the differences are negligible or the principle isn’t specific enough — a signal to revisit and refine it. If your inclination is to override a principle entirely, that’s acceptable, but it requires explicit justification in the ADR. Going against the grain means diverging from the established path, and the decision must be argued strongly. It may also be time to re-evaluate the principle itself in light of new information.

The radar is more advisory. It shows what’s currently standard in the problem space, what’s been tried before, and what other teams are experimenting with. Deviating from radar advice is less controversial, but any divergence should still be noted in the ADR.

With context in hand, you can define key evaluation criteria and list alternatives. If your research reveals significant unknowns, spin off a timeboxed spike; the ADR thinking will produce clear acceptance criteria. Otherwise, it’s time to seek advice — but not just from anyone.

The best discussions happen when you’re confident in your understanding of the problem but not yet attached to a solution. Prioritise conversations with people who will disagree with you — those with different mental models who can expose your blind spots. Challenge yourself by asking what’s weak about your preferred alternative. Share a rough draft of the ADR before meeting so your advisors have time to think. During the discussion, walk through every section of the template: context, principles, radar, evaluation criteria. Capture their advice and, crucially, ask why they’re suggesting what they are. That’s where the learning lies.

This targeted advice-gathering complements the Architecture Advisory Forum. For early decisions, it’s worth having these one-on-one or small-group sessions first so the ADR presented to the wider AAF is solid and focused, making those conversations richer.

Once you’ve gathered advice, you must record it in the ADR — even if you don’t take it. Highlight anything non-intuitive or surprising. If you disagree with key advice, say how and why. If your approach is novel, explain why the existing way fails. Use the principles to support your reasoning, or justify overriding them. The goal is a reader who understands exactly why this decision was made — not just what was chosen, but what was weighed and discarded. Well-written ADRs are essentially extended decision logs, like the classic “Why not Rust?” or “No, we don’t use Kubernetes” posts.

Finally, remember that every decision is point-in-time. Context and criteria that seem clear now will look different in hindsight. The record should let you revisit later and still feel good about the call — or learn precisely where your understanding failed.

Failure Modes to Watch For

Most failures in this model are actually healthy — the mini-failures of less experienced decision-makers. Those are good because the process surfaces them quickly, allows rapid correction, and creates learning moments for everyone. Call them out and celebrate them in the AAF.

The more insidious failure modes are harder to spot:

• Exclusion by habit. Early wins can feel like broad success — more people taking decisions, writing ADRs, contributing in the AAF. But check whether it’s really a wide group or just the usual suspects. Actively balance participation, amplify quieter voices, and ensure influence doesn’t track with tenure or hierarchy.
• Off-the-grid decisions. When decisions surface that never went through the process, treat them as opportunities to teach and learn, not to crack down. The decision-maker may not have recognised the significance, been under pressure, or feared being overruled. Improve the process rather than taking back control.
• Shadow architecture. The fatal one: continuing to make decisions behind the scenes while talking about trust and decentralisation. It reveals itself quickly — none of the benefits materialise because the architecture is still coming from the centre. Colleagues should be empowered to call this out. When you catch yourself frustrated that others don’t know what you know, you’ve missed the actual task — getting the right conversations happening with the right people at the right time.

The Five Elements, Revisited

What remains is a system of one core element — the Advice Process — with four supporting elements: the Architecture Advisory Forum, lightweight ADRs, team-sourced principles, and a custom Tech Radar. None of these may be novel on its own, but the power lies in their mutual reinforcement. The combination creates a conversational, learning-oriented backdrop where decisions are made quickly by those closest to the problem, with visible reasoning and transparent risk. This is what makes architectures that deploy successfully now — and remain adaptable into the future. It’s the practice of scaling architectural thinking itself.

Beyond the Framework

Teams that adopt this conversational approach to architecture often go further than the core practices suggest. Some naturally start building their own internal delivery platform before a dedicated Platform Team ever forms. Others introduce Architectural Fitness Functions — not just for run cost, but for broader architectural constraints — so they get early warning when the collective design drifts outside its intended boundaries.

The most significant outcome, though, is cultural. Once people are empowered, given a supportive environment, and their contributions are recognized, they begin thinking collectively about problems beyond what any single architect anticipated. That is the real payoff: access to the collective intelligence of the many, rather than dependence on the more limited perspective of the few.

Related Work

Two resources complement this approach well: Evan Bottcher’s “What I talk about when I talk about Platforms” and the Team Topologies work by Skelton and Pais. Both explore how delivery capabilities and team structures evolve in organizations moving away from centralized control.

For deeper thinking on the economics of decision-making, Donald G. Reinertsen’s The Principles of Product Development Flow covers the trade-offs in detail — particularly the Principle of Small Decisions, the First Perishability Principle, and the Subdivision Principle.

Footnotes

1. The John Lewis engineering principles include a few items that fall outside the strict definition of “architectural” principles used here — for example, “Understandability” and “Performance Importance.” That does not make those goals invalid; they simply do not qualify under the narrower architectural lens.
2. While the JADs (Joint Application Design sessions) and ARBs (Architecture Review Boards) described in some related material do not align perfectly with this approach, they do offer useful thinking on when to revisit and update principles, keeping them current through regular use and re-evaluation.
3. Different roles change how people evaluate decisions. Classic examples include developers who have had to hire and retain people, or those who have been on the receiving end of a decision, thinking differently about new technologies than they otherwise might.
4. Some excellent blog posts are essentially extended ADRs. “Why not Rust?” and “No, we don’t use Kubernetes” are strong examples of rigorous, anti-cargo-cult decision-taking in action.

Acknowledgments

Thanks to Martin Fowler, Nimisha Asthagiri, Nick Robinson, Rob Horn, Ian Cartwright, Tim Cochran, Carl Nygard, Marty Abbot, Mel Mitchell, Pete Hunter, and James Brown for their input and review.

Significant Revisions

• 06 March 2025: Fixed the link to the book
• 15 December 2021: Finished publication
• 13 December 2021: Published Tech Radar
• 09 December 2021: Published Architectural Principles
• 08 December 2021: Published Architectural Advisory Forum
• 01 December 2021: Published Decision Records
• 30 November 2021: Published The Advice Process