Architecture at scale usually fails not on the diagram itself, but in the moment an expensive decision gets made without enough context, without a real comparison of options, or with the wrong people involved. This chapter turns that messy moment into an explicit engineering process.
For working teams, the useful part is the combination of RFCs, ADRs, decision logs, and lightweight governance that has been exercised at T-Bank. It speeds up important decisions, preserves the reasoning behind them, and avoids turning architecture into a centralized bottleneck.
During design reviews and interviews, the value is that the discussion moves beyond the target diagram. You can talk about ownership, option comparison, responsibility boundaries, and the signals that tell you a decision is ready to be revisited.
Practical value of this chapter
Decision process
Shows how to scale architecture decisions through RFC/ADR and explicit selection criteria.
Lean governance
Helps enforce decision quality without turning architecture review into delivery bottlenecks.
Traceability
Builds the habit of recording assumptions, rationale, and consequences for future revisits.
Interview seniority
Signals senior-level thinking about decision process, not only component diagrams.
Source
Architecture at Scale
Alexander Polomodov's ArchDays 2020 talk on how to make architecture decisions repeatable and scalable in a large organization.
This chapter is based on Alexander Polomodov's ArchDays 2020 talk. While there is one team, architecture decisions live in hallway conversations; as the product and the number of teams grow, that conversation gets lost — and the reasoning behind each choice goes with it. The talk shows how to replace it with a process that does not fall apart as you scale. That process has already been rolled out and is used at T-Bank.
Why scale architecture decision-making
Decisions stop fitting inside one team and start touching neighboring products and platforms.
The cost of a bad choice grows faster than the ability to fix it locally: the rework ends up pricier than it looked at the start.
Without a shared process, every team reinvents how to capture context — and loses either delivery speed or the memory of why a decision was made.
Two ways to look at architecture
Architecture as expensive-to-change decisions
Architecture usually shows up in the decisions that are especially expensive to change later. Cost of change is the most practical filter.
Architecture as boundaries and direction
The other lens: architecture marks out the corridor of acceptable choices and the direction the system can grow in without running into a rewrite at every step.
Three levels of architecture
Software Architecture
The structure and key decisions of one system, service, or product.
Solution Architecture
An end-to-end solution at the level of a product or a group of systems for a concrete business problem.
Enterprise Architecture
Company-wide guardrails for technologies, standards, and ways of working.
They differ in level of abstraction, notation, tooling, and interaction context.
The role of the architect in the organization
Where the role is justified
- There are decisions that affect many teams, products, and platforms.
- The cost of change is high enough that options need a deliberate comparison.
- You need guardrails that preserve both speed and long-term stability.
What an Architect Doesn't Do
An architect is not there just to draw boxes and arrows. The role is to clarify which decisions are truly architectural, who should be involved, and how the reasoning gets preserved.
Book
Software Architecture: The Hard Parts (short summary)
A practical chapter on difficult architecture trade-offs, service boundaries, and working frames for comparing options.
How to make decisions at scale
Principle
Architecture decisions should be made as close to teams as possible, but inside transparent boundaries and explicit rules. That keeps both speed and alignment.
Decision Artifacts
RFC
A discussion draft that captures context, options, and open questions.
ADR
A concise record of the decision, the context, and the rejected alternatives.
Decision log
A running history of major decisions and the reasons for revisiting them.
Visual process map
Decision flow
Signal
1/5A trigger to revisit the current approach: growth, team pain, or a new risk.
RFC
2/5The document that frames the context, options, and people who need to weigh in.
ADR
3/5A short record of the chosen option, the reasoning behind it, and the expected consequences.
Decision log
4/5Shared memory of key decisions that teams can revisit later.
Technology Radar
5/5A lightweight view of what should be promoted, limited, or phased out.
Level of influence
Software
Decisions inside one system or service.
Solution
End-to-end product solutions and cross-system integrations.
Enterprise
Shared technology rules, platforms, and company-wide direction.
Typical problems and useful practices
Typical problems
- Key participants join too late.
- A decision gets made, but the context and reasoning are never captured.
- Architecture discussions get mixed up with local design choices.
- Centralized review turns into a bottleneck for teams.
What helps
- Keep decision authority as close to teams as possible, but make the boundaries explicit.
- Write down context, options, and consequences briefly so the decision can be revisited later.
- Define clearly which topics count as architectural and who needs to be involved.
- Use lightweight governance: enough structure to keep direction, not enough to slow the organization down.
Enterprise architecture without bureaucracy
Problem of perception
Classic enterprise architecture models often look like bureaucracy for its own sake and alienate delivery teams.
Lightweight governance
It is cheaper to give teams a shared picture than to sign off on every choice. The Technology Radar shows what is already in use, what should be limited, and where the platform is heading next — replacing manual approvals with a visible reference point.
Book
Building Evolutionary Architectures (short summary)
A practical chapter on fitness functions and controlled architecture evolution through testable constraints.
Connection to evolutionary architecture
Managed evolution instead of heroic one-off redesigns
A good decision process lowers the cost of change and stops the architecture from quietly degrading.
Decision logs support informed revision
Once the context is captured, revision is cheap: a team argues with the past choice instead of reconstructing it from memory and chat history.
Decentralization depends on clear boundaries
Strip away the boundaries, artifacts, and revision signals, and decentralization quickly turns into teams drifting out of sync rather than moving fast.
Case
Evolution of T-Bank Architecture (2006–2024)
A production example of how architecture documents, ownership boundaries, and long-horizon decision evolution work inside a large company.
Where these principles show up in real life
If you want to see how RFCs, ADRs, decision logs, and explicit ownership boundaries work inside a real large company, continue with “Evolution of T-Bank Architecture (2006–2024)”. It is a long-horizon production case where the same principles are visible across many years of platform growth.
Sources
Related chapters
- Evolutionary architecture in practice - shows how to translate architecture decisions into testable constraints and everyday engineering workflows.
- Building Evolutionary Architectures - provides the baseline on fitness functions and managed evolution, so important decisions do not decay as systems grow.
- Continuous Architecture in Practice - explains how to make architecture decisions continuously without sacrificing product delivery speed.
- Decomposition strategies - helps define module and service boundaries so architecture-at-scale decisions remain implementable by teams.
- Evolution of T-Bank Architecture (2006–2024) - offers a long-horizon production case where decision logs, lightweight governance, and decision revision become visible in practice.