Architecture & Tech Leadership

What this area actually covers

Architecture is the subset of technical decisions that are expensive to reverse: how a system is decomposed, where the boundaries fall, which component owns which data, how the parts integrate, and which quality attributes those choices are serving at the expense of which others. Decisions that are cheap to change are design, and they belong to whoever is writing the code.

That definition is doing real work, so it is worth pressing on. Reversibility is the test, not scope or seniority. Choosing a logging library is a big-sounding decision that you can undo in an afternoon, so it is not architecture. Deciding that two services will share a database is a small-sounding decision that will constrain every deployment, every schema change and every scaling conversation for years, so it is. The same reasoning explains why data decisions dominate: code can be rewritten, whereas data has volume, history, consumers you have not met and regulatory obligations attached to it. Almost everything genuinely irreversible in a system is irreversible because of where the data lives.

What an architect does that a senior engineer does not is mostly a matter of unit, horizon and audience. The senior engineer's unit of work is a merged change inside one system; the architect's is a decision and its written record, usually spanning several systems and several teams. The horizon moves from a sprint to quarters and years, which means the consequences of your work arrive long after you have left the room. And the audience widens to include finance, security, compliance and vendors, so an argument that only convinces engineers has not done its job. Most of the day is spent eliciting constraints nobody wrote down rather than solving the problem as stated.

Now the honest part, and the thing to establish before you accept an interview. Architect means wildly different things across companies, spanning at least four jobs.

Ask directly: do you write code in this role, what did the last person in it ship, do you own a delivery outcome or only advice, who can overturn your decisions, and are you in the incident review when your design fails. The answers change the job more than the title does. A candidate who takes an enterprise architect role expecting hands-on work, or the reverse, will be unhappy within a quarter, and the interview loops for the four archetypes are not interchangeable either.

The seven areas underneath

The seven subsections are organised around the parts of the job rather than around technologies, which is deliberate: technologies churn and the parts of the job have not changed in decades. Three of them are core reasoning skills, two are about execution, one is about money, and the last is practice material. Read trade-offs and quality attributes first, because everything else is downstream of them.

Architecture Trade-offs

This is the central subsection and the one most interview time is spent on. It covers articulating what a decision gave up, reasoning about reversibility, and holding a position under challenge without either capitulating or digging in. It exists separately because trade-off reasoning is a distinct skill from knowing patterns: plenty of candidates can describe an event-driven architecture and far fewer can say what it costs in debuggability, in operational burden and in the difficulty of answering "what is the current state of this order". Expect questions that push back on your first answer, because the pushback is the assessment.

Quality Attributes & NFRs

Eliciting non-functional requirements from people who have never been asked for them, prioritising attributes that conflict, and converting each into something measurable. It is a separate area because it is the input to everything else — you cannot evaluate a design without knowing what it is supposed to be good at — and because the elicitation half is genuinely uncomfortable work that engineers tend to skip. What you will find here is the discipline of turning "it must be reliable" into a scenario with an actor, a stimulus, a measurable response and a context in which the measurement holds.

Documentation & ADRs

Recording decisions so they outlive turnover, choosing a diagram's level of abstraction for its audience, and writing for readers who are not engineers. This exists as its own area because documentation is the architect's actual deliverable and is treated by most engineers as an afterthought. The interesting content is not the template but the judgement: what belongs in a decision record versus a design document, why the rejected options are the most valuable part, and how to write something a finance director and a platform engineer can both act on.

Migration & Modernisation

Strangler-fig sequencing, dual writes and reconciliation, data migration and backfill, cutover planning with a tested rollback, and de-risking a legacy replacement. It gets its own area because it is where most architects actually spend their careers, and because greenfield reasoning does not transfer. Everything is harder when the system must keep working: you cannot choose the ideal target if the migration path to it does not exist, and the sequencing question — what to move first so that the next step becomes possible — is a distinct skill with its own failure modes.

Cost & Efficiency

Cloud cost modelling, understanding where the money goes in a given topology, build-versus-buy reasoning, and defending spend to people who do not care about the technology. This is a separate subsection because cost stopped being someone else's problem: an architecture is a recurring bill, and an architect who cannot express a design's cost per unit of business volume is missing an argument they will be asked to make. Expect questions about a specific decision's financial consequence rather than about pricing pages.

Technical Strategy

Setting technical direction over quarters and years, managing technical debt as a portfolio rather than a backlog, standardising without ossifying, and aligning what engineering is doing with what the business is trying to become. It exists separately because it is the part of the role that is about influence rather than analysis, and because the failure modes are political. A strategy nobody follows is not a strategy, and much of this subsection is about how a technical direction gets adopted rather than about what a good one contains.

Architecture Scenarios

Situations to reason through: a rewrite that is failing, a vendor lock-in that has become a risk, a security mandate arriving mid-programme, two codebases merged by an acquisition. This is the practice subsection, and it exists because architecture interviews are overwhelmingly scenario-based. Reading about trade-offs is not the same as being handed an ugly situation with incomplete information and asked what you would do first, which is precisely the exercise. The value is in the reasoning path rather than the answer, and these scenarios are chosen because they have no clean one.

Where it sits in a real system

Architecture sits between commercial intent and running software, and the chain is worth tracing in one direction. The business states an outcome. That outcome implies quality attributes with numbers attached — latency, availability, recovery objectives, retention, data residency. Those attributes constrain decomposition, because you cannot make something independently scalable or independently deployable unless it owns its own data. The decomposition then implies team boundaries, or more often the team boundaries already exist and quietly dictate the decomposition, which is Conway's law arriving whether invited or not. The result is a deployment topology with a cost, and that cost is a real constraint sitting next to headcount and licences.

flowchart TD
    A[Business outcome] --> B[Quality attributes with numbers]
    B --> C[Decomposition and data ownership]
    C --> D[Team boundaries]
    D --> E[Deployment topology]
    E --> F[Recurring cost]
    F --> A
    E --> G[Operational reality feeds back]
    G --> B

Two edges do the interesting work here. The loop from cost back to the business outcome is the conversation most architects avoid and are then judged for avoiding. The feedback from operations back to the quality attributes is where you discover whether your numbers were requirements or wishes.

Two forces pull against every clean design. Data gravity means existing data is the hardest thing to move, so the migration cost of what you already have often decides the target more than the target's elegance does. And operational reality feeds back: the teams running the system discover whether your quality attributes were requirements or aspirations, which is why an architect who never sees a production incident is working from fiction.

The trade-offs you cannot escape

Quality attributes conflict pairwise, and the conflicts are structural rather than accidental — they do not go away with a better design or a newer platform. Holding a few of them explicitly is what lets you answer a design question with a position rather than a list of technologies.

The row people argue with is the last. Reuse is presented as an unqualified good, and it is not: a shared library or a shared service creates a coordination cost between every team that depends on it, and above a certain number of consumers that cost exceeds the duplication it was avoiding. Knowing where that line sits in a specific organisation is judgement, and it is exactly the sort of thing an interviewer probes by asking whether you would extract a common component from two similar services.

The corollary running through all of these is that simplicity is itself a quality attribute, and it is the one teams consistently underweight because it never appears on a requirements list. A design that a four-person team can operate is superior to a more elegant one that needs eight, and saying so out loud in an interview is usually a positive signal rather than a lack of ambition.

Who does this work

Software and solution architects working in-house own designs for a product or platform and usually a delivery outcome with them. Solution architects at vendors and consultancies work earlier in the cycle, producing proposals, reference designs and cost models, closer to presales than to engineering. Enterprise architects operate at portfolio level: which applications survive, which capabilities are duplicated across the estate, what the target state is in three years. Cloud, data and security architects are the same role narrowed to one domain. Alongside all of them, staff and principal engineers do a large share of real architecture without the title.

A day is less strategic than the word suggests. You read someone else's design document and find the assumption it rests on. You run a workshop to turn "it must be reliable" into a number somebody will own. You write an ADR. You sit in a cost review defending spend. You spike a risky integration to find out whether the vendor's documentation is true. You unblock a cutover at eleven at night. The people who build and operate the system — engineers, SRE, platform teams — are the ones who find out whether you were right, which is why the productive architects stay close to them.

The relationship with the roles around you is worth naming, because a lot of the difficulty in this job is other people's expectations. Product management owns what gets built and why; you own whether the shape of it will still work in three years, and the two of you will disagree about sequencing. Engineering management owns delivery and headcount, so a design that needs a team the organisation does not have is not a design. Security and compliance arrive with constraints that are non-negotiable and often late, which is an argument for involving them earlier than feels necessary. Finance owns the budget your topology consumes. An architect who has good working relationships with those four functions is effective; one who only talks to engineers is a senior engineer with an unusual title.

The interview loops differ as much as the jobs do, which is why preparing generically for "an architect interview" is a poor use of time.

The column that catches people out is the last one. An enterprise architecture loop rarely asks you to design a system, and candidates who prepare for a distributed systems exercise arrive over-prepared for the wrong subject and under-prepared for a conversation about rationalising forty overlapping applications.

Demand, adoption and how that is changing

Demand is high, and for identifiable reasons rather than general growth. A large amount of distributed architecture was built between roughly 2015 and 2022 with more services than the organisation could operate, and consolidating that back into something maintainable is funded work. Legacy modernisation programmes — mainframe, monolithic core systems, ageing vendor platforms — are multi-year and rarely cancelled once started. Cloud cost pressure since 2023 turned trade-off reasoning into a budget item, so someone must be able to defend an architecture in money. Regulation forces explicit architectural decisions: the EU's Digital Operational Resilience Act has applied to in-scope financial entities since January 2025 and puts concentration risk, exit plans and resilience testing on the architect's desk, and data residency and sovereignty requirements shape topology directly. And as AI-assisted coding raises the volume of code an organisation can produce, judgement about what should be built and where the boundaries go becomes the scarcer input.

That last point deserves expanding rather than asserting, because it is the live question in this field. If producing code becomes faster and cheaper, the constraint moves to everything code production was never the bottleneck for: deciding what should exist, agreeing what a system is responsible for, integrating with things that cannot change, and operating the result. Those are architectural activities. The corresponding risk is that a larger volume of code produced faster also produces a larger volume of poorly bounded systems, and clearing that up is architectural work of a less enjoyable kind. Both effects are plausible; neither is measured yet, and a candidate who states confidently which one dominates is guessing.

The honest counterweight: the review-board architect who only draws diagrams and approves other people's work is the most exposed role in a downturn, and several organisations have replaced that function with hands-on staff engineers. In many companies the architecture is in practice decided by whoever owns the platform, and a title without that ownership carries little. The trend favours architects who remain technically current and accountable for something shipping.

What makes it hard

Trade-off reasoning is the core skill and it cannot be memorised, because quality attributes conflict pairwise. Stronger consistency costs availability under partition and adds latency. Lower latency costs money, usually in redundancy or in caching complexity. Tighter security costs usability and developer velocity. Flexibility costs simplicity, and simplicity is itself a quality attribute that teams underweight. So architecture is choosing what to sacrifice in a specific context, and the same decision is correct at one company and negligent at another. Anyone who can recite patterns but cannot say what a pattern costs is not doing this job.

The corollary is that quality attributes have to become testable or they are decoration. "Highly available" is not a requirement. "99.9% monthly availability for the checkout path, measured at the edge, with a fifteen-minute recovery time objective and a five-minute recovery point objective" is a requirement, because it can be verified, budgeted, and failed. Extracting numbers like that from stakeholders who have never been asked for them is a large fraction of the real skill, and it is uncomfortable work.

Documentation is the deliverable, and this surprises engineers who expect the artefact to be a system. What survives you is the written record of what was decided and why, because the code shows the outcome but never the alternatives or the constraint that ruled them out. A decision record is cheap to write and enormously valuable two years later, when someone is about to undo a choice without knowing what it was protecting against.

Migration is where most of the real work is. Greenfield architecture is the rare and easy case; the common case is a system that already works, already earns revenue, and must become something else without an outage. That means strangler-fig sequencing, dual writes with a reconciliation process you can trust, backfills that take weeks, a cutover with a tested rollback, and the political problem that the programme ships no visible features for months while consuming the best engineers. Judging reversibility — which decisions are one-way doors and which can be undone cheaply — is precisely the thing experience buys, and the only way to acquire it is to have been wrong at scale a few times.

Distributed systems add a difficulty that is specifically architectural rather than technical. Once a call crosses a network, it can succeed, fail, or do neither observably, and a design that does not have an answer for the third case has a bug that will surface at the worst time. Retries create duplicates unless the receiver is idempotent. Timeouts have to be shorter going down the call chain than coming back up, or a slow dependency queues work everywhere above it. Partial failure means the system can be simultaneously up and wrong. None of this is exotic knowledge, and all of it is routinely absent from designs that look complete, which is why an interviewer will often accept your happy path without comment and then ask what happens when one call in the middle times out.

There is also a difficulty of authority that nobody warns you about. In most organisations an architect has responsibility without command: you can be accountable for a design that a team is free to ignore, and the mechanism by which your decision becomes their behaviour is persuasion, involvement and occasionally an escalation you would rather not spend. Engineers who move into the role expecting their conclusions to be implemented because they are correct find this genuinely disorientating. The architects who succeed treat adoption as part of the design problem — involving the people who will build it early enough that the decision is partly theirs — rather than as an administrative step after the thinking is done.

Which leads to the field's characteristic failure mode: architecture as an ivory tower. It looks like standards nobody follows, diagrams that stopped matching production two years ago, a review board that functions as a queue, and decisions made by people who will never be paged about them. It is caused by separating architectural authority from delivery accountability, and it is cured the same way in every organisation — by making the architect own an outcome, keep enough hands-on work to stay honest, and attend the incident review.

How a modernisation actually runs

Because migration is where the work is, it is worth walking one through end to end. The pattern that dominates is the strangler fig: rather than replacing a system in one event, you place something in front of it that can route each capability either to the old implementation or the new one, then move capabilities across one at a time until nothing is left behind the façade.

stateDiagram-v2
    [*] --> Legacy
    Legacy --> Facade: routing layer inserted
    Facade --> DualRun: new path built, both write
    DualRun --> Reconciled: outputs compared and agreed
    Reconciled --> Cutover: traffic shifted
    Cutover --> Retired: legacy path removed
    DualRun --> Facade: rollback if they disagree
    Retired --> [*]

The transition that decides whether the programme succeeds is DualRun to Reconciled. Running both paths is easy; proving they agree is not, and a programme that shifts traffic without a reconciliation it trusts is gambling. The edge going backwards matters just as much, because the ability to return to the old path cheaply is what makes the whole approach safe enough to attempt.

Two failures recur. The first is stopping halfway: the easy capabilities move, the hard one does not, and the organisation now operates two systems permanently at more cost than either alone. Sequencing to attack the hardest dependency early — usually the data — is the defence, and it is unpopular because it delays visible progress. The second is the retirement step never happening, because switching something off requires someone to be certain nothing depends on it, and certainty is expensive. Budgeting for decommissioning explicitly, at the start, is one of the few pieces of purely procedural advice in this field that reliably pays for itself.

Why study it

Study it if you like constraints and you like writing, because those two are most of the job. Study it if you want your influence to outlast your tenure, and if you are already the person whose door colleagues knock on with a design. The knowledge also compounds unusually well: technologies churn, but reasoning about coupling, data ownership and failure domains has held its value for decades.

There is a second, quieter argument. Architecture is one of the few technical disciplines where the primary skill is asking better questions, and that skill improves everything else you do. Learning to notice the unstated assumption in a requirement, to ask what happens when a dependency is unavailable, to demand a number where an adjective was offered — these make you better at reviewing code and at running a project, not only at drawing boundaries. Plenty of engineers study this material with no intention of taking the title and get most of the value anyway.

Do not take it if you want to keep writing code most of the day — staff engineer is the same seniority with far more building in it, and choosing it is not a lesser choice. Do not take it if writing documents and running stakeholder meetings sounds like the boring part, since that is the part. And if you are early in your career, this is not the fastest route to anything: architecture without operational scar tissue is just opinion held confidently, and interviewers detect that quickly. Architect interviews are design exercises, trade-off defence and scenarios, and the score comes less from your first answer than from how you handle it being challenged.

Your first hour

Write one architectural decision record for a decision already made in a system you know, ideally one you disagree with. The point is not the format; it is that the format forces you to name the drivers and the alternatives.

# ADR-014: Store outbox events in the orders database, not a broker topic

Status: accepted (2026-03-11)

## Context
Order service must publish OrderPlaced reliably. Postgres already in the
transaction; adding a broker write makes the publish non-atomic.

## Decision drivers
- No lost or duplicated events (correctness) - hard requirement
- Publish latency under 5s p99 (acceptable, not tight)
- One fewer system for a 4-person team to operate (simplicity)

## Options considered
1. Transactional outbox table + poller  - chosen
2. Dual write to broker inside the txn   - rejected: not atomic
3. Change data capture off the WAL       - rejected: no ops capacity yet

## Consequences
- Poller adds ~1s median publish delay; acceptable today.
- Outbox table needs pruning; add to the weekly job.
- If we later need CDC, the outbox becomes redundant work to unwind.

## What would change our mind
Sustained publish volume above ~2k/s, or a second consumer needing sub-second
delivery. Reversal cost: moderate - consumers are already idempotent.

If you have longer, do the second exercise, which is harder and more revealing. Take one vague requirement from a system you know — "the reports need to be fast", "we can't lose orders" — and turn it into a quality attribute scenario with five parts: who or what triggers it, what the trigger is, what the system is expected to do, how the response is measured, and under what conditions the measurement holds. Then take the number you wrote down and ask what it would cost to guarantee one order of magnitude better. Most of the time the answer is startling, and the conversation that produces it is the single most useful thing an architect does.

The artefact is one page a new joiner could read to understand why the system is shaped this way. Two lines carry most of the value and are the ones people omit: the rejected option with its reason, and the reversal cost. If you cannot state what would change your mind, you have recorded a preference rather than a decision.

What this is not

It is not diagrams. A diagram is a communication device; when it becomes the deliverable you get the ivory tower. Nor is it technology selection — picking a database is one decision among many, and architects who define themselves by their tool preferences age badly.

It is not a promotion from senior engineer, and it is not simply a better-paid version of the system design interview. Interview design questions reward breadth and fluency in forty-five minutes; the job rewards knowing which constraint to chase for a fortnight. Enterprise architecture is also a genuinely different discipline from software architecture, concerned with the application portfolio rather than a system, and the two are hired, interviewed and measured differently.

It is not pattern knowledge either, and this is worth separating from the point about tools. Knowing what a saga is, or a circuit breaker, or an anti-corruption layer, is vocabulary — useful, quickly acquired, and not the skill. The skill is recognising that this particular situation is the one where a saga's complexity is justified and the adjacent one is not. A candidate who reaches for a named pattern before establishing the constraints has demonstrated reading rather than judgement.

And it is not the same thing as being the most technically capable person in the room. The best architects are frequently not the strongest engineer on any given team, and they do not need to be. What they are is the person who has read the constraints nobody else read, spoken to the three parties who each held a third of the picture, and written down a decision the organisation can act on. Confusing architecture with technical depth is how organisations end up promoting their best engineer into a job they neither wanted nor were selected for.

Finally, it is not a role where you stop being wrong. It is one where being wrong is expensive and slow to discover, which is exactly why the written record and the honest statement of what you gave up matter more here than anywhere else.