Architecture Review: One Table Instead of Pinball

Anton joined almost ten years earlier, when the company was still called Tinkoff Credit Systems. He started as an analyst, a role called a technologist internally, then worked in payments, business banking, and marketing automation. He now helps build the architecture function across the group.

Alexander connects quality and reliability concerns with sustained growth after the startup stage. Anton divides the story around the geopolitical changes of the preceding two or three years: before them, divisions followed their own rules without a shared approach.

Then three external forces converged. Hardware: servers can no longer be bought in the usual volumes or from the usual suppliers, so the company experiments with whatever the market offers. Bans: some widely used technologies were closed off for critical infrastructure, and some licences cannot be bought owing to restrictions on the international market. And customers: in the two years after those events the audience grew roughly two and a half to three times.

Load rises, scaling horizontally by simply adding hardware and instances is out of reach, and meanwhile bricks are pulled out of the wall to be replaced from an approved list. Handling that with scattered groups across separate divisions is too costly, hence a central process and Anton's group. Alongside runs an internal project codenamed Prometey: new data centre formats able to work with the hardware available.

The process starts with documentation: the team states its requirements, draws the change it plans and how the system works today, and adds deployment diagrams from the internal list asked of every team. Experts then look for weak spots and challenge the design: some of what they dislike is a deliberate trade-off with sound reasoning, the rest a weakness the team failed to recognise for lack of exposure. After the rework they agree how the solution will be monitored during the build and by what steps the team reaches the target design.

Alexander asks about the bottleneck straight away; Anton says the intake is narrowed on purpose: review takes changes that need scarce hardware in quantity, touch technologies on the restricted list, or belong to Mission Critical systems. The rest is left to the divisions' own filters, still a work in progress: in some the filter grew historically, in others it appeared once people saw the process and copied it.

Review is not only architects: infrastructure, security and capacity management engineers join too — expensive specialists, hard to pull in singly. Otherwise a design beautiful on paper runs into the topology and bandwidth of the data centre network, or into rules on where data may live: sometimes a rack closed with seals, with a single cable leaving it.

Previously a team went round every group in turn and got what Anton calls volleyball: one approves, the second demands changes, and after the rework the first withdraws approval. Alexander says it is more like pinball, and recalls the parable of the sages and the elephant: in a joint meeting they describe it at once, in one place.

A recent case: a team that designed a rework three or four years ago won a large reserve of resources, saw it run out six months ago and asked for hundreds of terabytes — units or tens could have been shaken loose elsewhere, hundreds could not, and the technology goes under import substitution late next year. A redesign swapping a couple of components made the system more reliable and scalable and freed resources.

Anton calls that a normal engineering challenge rather than a ban: teams that bristle at the first check prepare documents happily after two or three iterations, so his group pushes them to come while still designing.

The joint meetings had a pleasant side effect: security now understands how systems are built and finds attack vectors faster, and its inventory of every compute node — technologies, open ports, processor counts — now feeds analytics for Anton's team.

An IT director once called the reviewers gatekeepers blocking his project. Anton took no offence: meeting process requirements without suitable tools is expensive.

Usually C4 at levels L1 and L2 is enough — how a system sits in the landscape and what happens if a module goes away. The repository tools Anton examined build their models from documentation. He identifies two risks: descriptions lag behind code and can contain errors from the outset. Alexander adds that the honest name is architecture documentation as code, not architecture as code, and recalls the caste of architect-elders keeping knowledge of the system.

Anton's hypothesis: L1 and L2 can be assembled from internal systems — the development platform with its planned deployment artefact and dependencies, the compute inventory, and the platform for logs, metrics and traces, which, Alexander adds, was written to replace Splunk after it left Russia. Parts of the model would be inferred rather than certain; this is work in progress, not a complete operational map.

Alexander splits those sources into static — which bricks exist and which accesses between them have been requested — and dynamic: the request path, SLO breaches, and potentially modelling which services would fail if one brick disappears.

A separate line is RFCs and ADRs. Several years ago it had become unclear why a given system was built as it was, while similar changes ran in different divisions independently; hence a space where significant changes are brought for comments. Resistance lasted a long time, but RFCs now exist in roughly 90 per cent of the divisions Anton works with. Teams sometimes remove requirements and alternatives from the template; reviewers have to restore those missing parts of the argument.

ADRs followed: a decision with its rationale and expected results, a record you can return to a year later — otherwise, both note, all that is left is the phrase that things just turned out that way. A revision gets a new record, preserving the earlier context and explaining which changed requirements made the new decision necessary.

Anton explains his path through a habit of never stopping at the first solution and a mild impostor complex: he read the code of core libraries, keeps a popular gadget on his desk taken almost down to the individual chips, still writes code, and notes that a best practice of ten years ago can become an antipattern. His full career path is not a prerequisite: many engineers grow within development, while adjacent disciplines broaden the solutions they can draw on.