Source
Architecture to scale
Talk by Alexander Polomodov, author of system-design.space, at ArchDays 2020. This process has been rolled out and is used at T-Bank.
This chapter is based on a talk by Alexander Polomodov (author of system-design.space) at ArchDays 2020. The architectural decision process described in it has been rolled out and is used at T-Bank. As the product and teams grow, architecture ceases to be the “personal zone” of one architect. You need a process that helps you make and record important decisions while maintaining speed and context.
Why scale decision making
Multiple clients and product lines: solutions cross team boundaries.
Rapid product and team growth increases the cost of bad decisions.
Distributed teams with different contexts make communication difficult.
Two optics architecture
Architecture = expensive solutions
Architectural solutions are those that are expensive to change. The cost of change is a practical filter.
Architecture = boundaries and trajectory
The architecture sets the corridor of feasible solutions and the direction of system evolution.
Three levels of architecture
Software Architecture
Structure and key solutions of specific systems and products.
Solution Architecture
Solutions at the product or system cluster level for a business problem.
Enterprise Architecture
A framework for company-wide technologies and approaches.
They differ in the level of abstraction, notations, tools and interaction context.
The role of the architect in the organization
Where the role is justified
- There are decisions that impact many teams and products.
- The cost of change is high and requires a conscious choice.
- You need frames to balance speed and stability.
What an Architect Doesn't Do
An architect does not “draw arrows.” It helps determine which decisions are truly architectural and how to capture them.
Decision making at scale
Principle
Decisions are made in a decentralized manner, but with transparent boundaries and rules. This reduces bureaucracy and maintains speed.
Decision Artifacts
RFC
Draft solution, discussion with interested teams.
ADR
Recording the decision, context and alternatives.
Decision log
The history of decisions and their reasons is for re-understanding.
Visual decision map
Decision flow
Signal
1/5Growth, pain or risk that requires discussion.
RFC
2/5Context, options and interested teams.
ADR
3/5Capturing choices, consequences and trade-offs.
Decision log
4/5Decision memory and grounds for revision.
Technology Radar
5/5Easy governance and overall trajectory.
Level of influence
Software
Commands and specific systems.
Solution
Product solutions and integrations.
Enterprise
Standards, platforms, trajectory.
Problems and practices
Typical problems
- Involving the right participants too late.
- Decisions are not recorded and context is lost.
- Centralized bureaucracy slows down teams.
- A mixture of design and architectural solutions.
What helps
- Decentralization: decisions are made by teams with clear boundaries.
- RFC/ADR as lightweight artifacts for discussion and memory.
- Transparent rules: what is considered an architectural solution.
- Minimal governance instead of heavy committees.
Enterprise architecture without bureaucracy
Problem of perception
Classic enterprise architecture models often look bureaucratic and alienate teams.
Easy governance
Technology Radar helps you see what is being used, what is going out of use, and where the platform is heading.
Relationship to evolutionary architecture
Evolutionary architecture = managed change
The decision process reduces the cost of change and prevents degradation.
Decision log as an evolution mechanism
Decisions can be revised, versioned and context preserved.
Decentralization with boundaries
Team speed is maintained if there are clear boundaries and artifacts.