The architecture of a large company almost never follows one master plan. This chapter tells the more honest story of how T-Bank moved through packaged software, in-house systems, platform engineering, and distributed architecture governance under pressure from growth, change cost, and new constraints.
Its practical value comes from showing architecture as a sequence of states rather than a single target diagram. Along that path, you can see why choices that fit a startup stop fitting a platform company, and why another layer of structure only appears once scale and organization become much more complex.
In architecture discussions, this chapter works as a strong evolution case. It gives you a concrete way to explain how business scale, team structure, and engineering constraints gradually reshape priorities, roles, and decision-making tools.
Practical value of this chapter
Platform evolution
Explains how architecture changes with business scale, org shape, and regulatory pressure.
Migration thinking
Teaches transition planning between architecture states without freezing product delivery.
Platform investment
Helps evaluate when central platform capabilities pay off versus local team autonomy.
Interview realism
Provides real evolution stories that strengthen architecture arguments in interviews.
Source
ArchDays 2024
Text version of the talk “Architecture at T-Bank: yesterday, today, tomorrow.”
The story of T-Bank’s architecture over 18 years: from a startup built on packaged software to a large technology company with its own developer platform and a distributed architecture process.
Evolution of T-Bank Architecture
A breakdown of Alexander Polomodov’s ArchDays 2024 talk
Related book
Continuous Architecture in Practice
Continuous architecture, quality attributes, and decisions that should be delayed until the right moment.
What architecture means here
Before the timeline starts, the chapter fixes its lens. Architecture is not just one diagram or one stack choice. It is the way a company defines system boundaries, records expensive decisions, and preserves a workable path for change as scale increases.
How the system is organized, what the main parts are, and how they interact.
Which details stay hidden and at what level interactions become discussable.
Several complementary views that make the system easier to reason about and evolve.
Policies, standards, and constraints that keep the architecture inside a coherent frame.
Choices that are especially expensive to reverse and therefore deserve explicit treatment.
Reusable ways of structuring systems so teams do not reinvent the same solution each time.
A practical way to align engineers, product stakeholders, and other decision-makers.
"To paraphrase George Box: all definitions are wrong, but some are useful."
Related discussion
A Philosophy of Software Design
A conversation about John Ousterhout’s book and why architecture usually outlives any local implementation detail.
Key metaphor
❌ Construction metaphor
In construction, it is unusual for the customer to reach the middle of a skyscraper and then decide to pivot and build the rest in a completely different direction. In IT, those shifts happen all the time, which makes a literal construction analogy too rigid.
✓ Plant metaphor
It is more accurate to think of architecture as something cultivated over time: grown, reshaped, and maintained gradually, often without knowing in advance which constraints will surface as the system expands.
Four phases of evolution
Phases of T-Bank architecture evolution
2006–2014
Packaged software
Startup stage: fast market entry on top of mature packaged systems.
1. Packaged software (COTS)
In its early years, Tinkoff operated like a fast startup. At that stage, packaged systems were a rational choice: they shortened the path to market and reduced the need to build basic capabilities from scratch.
Why this stage worked
- +Low initial launch cost.
- +Fast implementation of standard business flows.
- +Reliability of established vendor products.
- +External technical support from the vendor.
- +Regular upgrades without building everything in-house.
TDD — Technologist Driven Development
Products were shaped by technologists sitting between business analysis and project management. That matters because, in the packaged-software stage, architecture was still tightly coupled to product launch rather than to platform engineering as a discipline.
2. Moving to in-house software
As the company grew, packaged products started to hit real business limits. Total cost kept rising, flexibility kept shrinking, and the geopolitical shift of 2014 made outside dependencies even more visible.
What stopped working
- −Limited flexibility — packaged products adapted poorly to rapidly changing product flows.
- −Growing cost — user and core-based licensing scaled together with the business.
- −Vendor dependence — important change had to wait for someone else’s roadmap.
- −Integration complexity — more and more glue code accumulated around the packaged core.
- −Security exposure — popular products remained attractive targets for broad attacks.
Building in-house software did not remove complexity; it changed its shape. The company gained flexibility, but paid for it with migrations, legacy layers, and long transition periods where old and new systems had to coexist.
Spirit
Spirit platform
Official page of the internal developer platform.
Foundation
Containerization
Platform environments are usually built around containers and orchestration.
3. Platform engineering
By 2020, it was clear that endlessly multiplying local infrastructure solutions was too expensive. Teams could move fast on their own, but the company was losing reuse, standardization, and the economic upside of scale.
Growth in engineering teams
of engineers working on infrastructure instead of product delivery
A technology landscape that had become too heterogeneous
Spirit platform principles
- Repeatable and transparent code lifecycle.
- A consistent approach to code quality and codebase management at every stage.
- Internal reuse and shared engineering building blocks across teams.
- Focus on engineering outcomes rather than local infrastructure workarounds.
4. Megaprojects and architecture governance
The events of 2022 sharply accelerated the move toward a more mature architecture process. The company now had to evolve the platform, execute large migrations, reduce critical dependencies, and prepare for the next scale jump at the same time.
🔥 Project Prometheus
An import-substitution program focused on moving away from Oracle and other critical dependencies. It also accelerated the accumulation of technical debt that later had to be addressed while the company kept growing.
📈 The 100M program
Preparation for the next growth phase: more clients, more products per client, and more daily activity inside the broader ecosystem.
What became the working answer
- Move teams onto platform services where the XaaS model clearly pays off.
- Expand platform capabilities to support both scale and import substitution needs.
- Evolve systems step by step instead of betting on one revolutionary rebuild.
Related book
Fundamentals of Software Architecture
More on architect responsibilities, quality attributes, and mature architecture thinking.
Who does architecture
Who does architecture?
Own delivery pace, coordination, and the engineering environment
Take on hard architecture choices and drive them into working code
Design and implement at the level of complexity the team actually needs, no higher
Foundation
Virtualization: hypervisors and VMs
Data centers and internal platforms still rely on virtualization and hypervisors.
Where T-Bank is heading
The core conclusion is simple: in the long run, a bank has to invest not only in product features but in its own technical capability. Without that, the next stage of growth becomes too expensive to sustain.
Infrastructure base
Proprietary data centers, an internal developer platform, and a shared layer of platform capabilities.
Distributed ownership
Architecture choices move closer to the teams, while still staying inside common rules and standards.
Mature reuse
Platform services and standards should help teams move faster rather than strip away their autonomy.
Additional materials
Related chapters
- Continuous Architecture in Practice - shows how to turn architecture into a continuous decision process instead of a one-time project phase.
- Fundamentals of Software Architecture - provides the baseline on quality attributes, architect responsibilities, and the cost of architectural trade-offs.
- Architecture at Scale: How We Make Architectural Decisions - adds the organizational layer: RFCs, ADRs, decision logs, and lightweight architecture governance.
- Containerization - explains the infrastructure foundation behind platform engineering and standardized runtime environments.
- Virtualization - clarifies the data-center and infrastructure baseline behind a large internal platform.
- Infrastructure as Code - shows how infrastructure change scales through code review, reproducibility, and shared automation.
- GitOps - extends the platform approach with transparent deployments and Git-centered operational control.
- Brief overview of the T-Bank data platform - shows how the same evolution logic appears in large data domains, contracts, and platform services.
- ML platform in T-Bank: the common good or better not needed - adds the ML angle: how platform investments become an internal product for engineering teams.