An ARCHI-important Stage

The host recalls that many teams simply drop the architecture design stage, although it is the foundation of the house — hence the episode's title, a pun on architecture being archi-important. Alexander notes there are almost as many definitions of architecture as people who consider themselves experts: some talk about components and the links between them, others about decisions significant enough to be hard to undo, when you cannot simply revert a commit. His illustration is a building where, as he remembers the case, twenty floors were added on top of eighty while the lift shaft could not be extended: flats at the top sold cheaply because residents walked the last twenty floors. The host notes that projects add floors as they go too.

Before design itself, Alexander continues, comes the talk about requirements: the customer brings functional ones, while the complexity of the architecture is set by the non-functional half. A system design interview shows it at once: the candidate covers the functions, while load, availability, fault tolerance when power or network is lost, and maintainability stay out of the picture; then the security people arrive and requirements start competing — fast or secure. Non-functional requirements sell badly to a business that ordered functions, so they were renamed quality attributes and later architectural characteristics. Gather them concretely: how many people will arrive, where the data is stored, whether it may be lost — for advertising click statistics some loss is acceptable, for financial transactions none is — then prioritise into must have, nice to have, and what nobody cares about. The host remarks this looks like a shift left testing technique.

The host says her project has an architect who is far from involved in every task, and asks whether that is a position or a role. Alexander's stance, by his own admission, is not the most popular in the architecture community: it is a role, and not a single one. Software architecture is designing the system itself; solution architecture is a cross-cutting project where a set of systems has to be joined and several teams brought to agreement; and there is a third, mythical architect role, which at the "green bank" or the "blue bank" often earns the second name of PowerPoint architect. At Tinkoff, where Alexander curates part of the architecture agenda, architects' grades, and system design interviews, the bet is on an autonomous team with strong engineers inside. A dedicated person is needed when a project runs through half the organisation: an audit of the landscape, analysis of how such systems are built elsewhere, and options with their own cost and duration. A decision meeting only today's expectations he compares to shoes bought to fit a toddler exactly: three months later you need new ones.

For a team to move its architecture deliberately, clear rules of the game are needed — ADR and RFC. A request for comments is a proposal for discussion: someone describes an idea in a document, the others comment, and it is implemented, reworked, or dropped, while the series of documents becomes a map of decisions. Alexander's example: the document records that, say, on 14 September 2022 the team chose to split the monolith into such and such parts, and why; six months later the tasks change and the team walks the process again. Without that map, to the team and to the business alike it looks like a weathervane turning wherever the wind blows. The log also works against sunk cost: their own forms engine works and does a great deal, but the entry barrier for new developers is high while an open-source engine has matured over those years — so ask whether you would choose your own today, and whether you built a tool for the tool's sake. Memory is plastic and people edit their own history after the fact; a document does not. The host sums up: what matters is not who initiates a change but that the team can review it.

The host asks how swinging like a pendulum — split the app, merge it back, split it again — differs from development. Alexander recalls that solutions in IT recur: Tanenbaum shows it on virtualisation, which lived on mainframes, returned to x86 around the turn of the 2000s, then gave way to containers because of the overhead; they come back because the bottleneck moves. To manage that he offers fitness functions from the concept of evolutionary architecture, which he presented at the company conference last year: the architectural characteristics you singled out can be measured. Dynamic ones through SLOs, logs, and metrics; static ones through constraints on structure — how components are linked and what call chain serves a request. Otherwise you get a distributed monolith, fast on a developer's machine where everything runs in one environment and seconds per request in a real deployment. The point is convergence: with no external change the system should settle into a state you have nothing to add to.

The difference from the backend, which fought complexity by splitting into parts, is that a mobile app has a single executable: architecture here is about living inside one big application — organising components and going through abstractions rather than importing another team's concrete class. Otherwise a team owning a secondary feature inflates the binary with a dependency it dragged in, or stretches startup from one second to five while synchronously waiting for a resource; Alexander compares it to a Phystech dormitory where a forgotten frying pan fills the whole floor with smell. When the business asks for banking, payment, and non-financial products to be developed autonomously, the layered architecture is cut vertically and the pace is watched by platform teams; the payoff is a mini-build on which you run the scenarios of your own screens with another team's payments mocked. Asked about QA engineers, Alexander answers that non-functional requirements are checked through a proof of concept — a simplified system shows whether it digests the required volume of data and survives peak load or the loss of a data centre — while the engineer is expected to ask hard, awkward questions: how do we test a solution with eventual consistency, what happens when data is lost or users work concurrently. Of the books he recommends McConnell's Code Complete: an error is cheaper to find in the architecture than in production.