Architects: Becoming an Ideal Team Player

Alexander starts with his own classification: software architects work inside engineering teams and help their services evolve; solution architects assemble an end-to-end solution for a new business process out of many systems and teams; enterprise architects operate high-level frameworks such as TOGAF or Zachman. The third kind he sees as the CTO’s territory: a dedicated enterprise architect drifts from implementation detail into arrows, circles and presentations far removed from reality, a semi-mythical figure. Vladimir adds that a solution is many-sided — interfaces, mobile apps, web, near and far backend, storage, machine learning, analytics, build pipelines — so each domain needs its own specialists: mobile application architects, data architects who know the guarantees of different database families and the fine points of Postgres and Kafka, and system architects who own delivery and runtime, a term he has met at Microsoft and service companies such as Accenture.

The host assumes architecture descends from the top, but Vladimir climbs the ladder the other way: a developer ships features, then wants a whole application with layers and build times, then finds twenty-five more squares beside his own, and above that come solution, enterprise and CTO. The top step is planetary scale: in the cloud part of the conversation Google’s CDN is said to have 128 edge points: the speed of light alone makes a video from Moscow start several seconds late in Brazil, while the nearest point cuts the delay to about half a second; the host likens this to warehouses outside the ring road, the guests to IT warehouses. Alexander traces the profession back to building: one architect’s work on patterns in town planning, a brick of roughly a thousand pages, became the prototype for software pattern books, and Melvin Conway’s law about three departments and a three-pass compiler is more than fifty years old.

Vladimir shows the role through his own product: a seller on Wildberries has sold a batch, wants more stock and comes for two million roubles to earn three. Until September last year turnover was checked against bank statements — manual steps and days of waiting, though the department optimises time to yes, the time to loan approval. For marketplace sellers they built a separate product: they agreed terms with Yandex.Market, now the merchant presses a button right there and leaves a phone number, his merchant id passed across transparently, and the bank itself requests the turnover figures, loads, transforms and stores them, then calls scoring — a decision takes hours instead of days. His architect work was literal: gathering requirements — how many clients, how fast we decide, where and in what shape the data lives, whether the credit process is called synchronously or asynchronously — then choosing technologies with colleagues, drawing the outline diagram, writing down assumptions, estimating timings and agreeing the contract. The experiment became one of the bricks of a whole e-commerce direction.

Alexander’s story is a platform one. More than five years ago he was brought into online acquisition: customers arrived through web forms, the old solution was being retired by the end of 2016, and the attempt to move onto the new React front-end platform showed that analytics and event tracking did not work, and without server-side rendering there was no SEO. He stresses he did not do it himself: from him came a direction, usually written up as an RFC — this is where it pinches, here is a possible solution, let us discuss and commit. Breadth of reference, he says, comes from reading and applying what you read: seventeen-odd years ago he landed on a legacy project after the old team had left, felt the pain and started with Steve McConnell’s Code Complete. Vladimir compares it to driving: at first you have no idea what to grab, later you see Postgres will do here and there you must think. Practice alone is not enough, both hold: courses arrange knowledge into a tree, and their own school of architecture had to be built in-house for want of a complete enough vendor course.

The key book of the episode is The Ideal Team Player: Alexander says he absorbed its philosophy and tests three qualities at project interviews — hungry, humble, smart. The person has to want to achieve something, must not look down on juniors or colleagues from other specialisms, and must be socially smart, able to take in another point of view. For an architect this is critical: strategic work squeezes out hands-on work, there is no time left to try a new database or a service mesh, and all that remains is to consult those who do have that experience — a dialogue only between equals. Vladimir adds Leadership Without Authority — leading without formal authority: trust comes from admitting weaknesses in public and asking colleagues what they think. Alexander adds that an architect usually has no formal power to force decisions through, and if he has it, better not to use it. Vladimir prefers criticism as questions — not this will not work, but how will the system behave under these conditions.

Hence Alexander’s conclusion: decisions should be taken at the level where people can take them, and the process should be transparent and decentralised — a document stating the problem, the alternatives and the choice goes to the team for comments. That turns the architect into a playing coach whose impact grows with the team; an architect’s success is the team’s success, Vladimir sums up. He also recalls Simon Sinek’s The Infinite Game: the goal is not to win the quarterly report but to keep being able to play. And he lays out the growth branches: the scale of decisions, up to a three- to five-year technology strategy; people management up to director and vice president of engineering; delivery management with budgets and P&L in service companies; and product management. The downsides are named just as plainly: the deformation of saying it depends — Alexander’s basic course has a triangle of security, performance and cost where everything pulls against everything else — a result that proves itself only years later, and the temptation to blame predecessors instead of reconstructing why they decided as they did. The closing question is about childhood dreams: a cosmonaut, then a scientist for Alexander, astronomy for Vladimir.