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. It shows how architecture decisions stop being an informal conversation and become an explicit process that still works when both the product and the number of teams keep growing. That process has already been rolled out and is used at T-Bank.
Why scale architecture decision-making
Decisions start crossing the boundaries of multiple teams, products, and platforms.
The cost of a bad choice grows faster than the ability to fix it locally.
Teams need a shared process that preserves context without slowing delivery to a crawl.
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
Architecture sets the corridor of acceptable choices and the direction in which the system can evolve safely.
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
Technology Radar helps teams see what is in use, what should be limited, and where the platform is heading next.
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
Teams can revisit decisions deliberately instead of reconstructing forgotten context from scratch.
Decentralization depends on clear boundaries
Team speed holds up when the organization has explicit boundaries, artifacts, and revision signals.
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.