Architecture is the set of decisions that are expensive to reverse - boundaries, data ownership, integration style - chosen against conflicting quality attributes. The title means wildly different things across companies, so establishing which job is being hired is the candidate's first task.
High demand22 min readSoftware Architect, Solution Architect, Principal / Staff Engineer, Enterprise Architect, Cloud Architect, Data ArchitectUpdated 2026-07-27
Assumes you know: Several years building and operating a non-trivial production system, Comfortable writing prose for a mixed technical and commercial audience
Overview
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.
Archetype
Writes code?
Real deliverable
Failure mode
Hands-on architect (often titled staff or principal engineer)
Yes, prototypes and hard paths
Working reference implementations, designs they help land
Overload; becomes a bottleneck
Delivery-accountable software architect
Occasionally
Designs, ADRs, and a system that shipped
Pulled into every escalation
Solution architect (vendor or consultancy)
Rarely
Proposals, reference designs, sizing and cost models
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 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.
Subsection
What it is for
Architecture Trade-offs
Defending a decision and naming what it cost
Quality Attributes & NFRs
Turning vague requirements into testable numbers
Documentation & ADRs
Making decisions survive the people who made them
Migration & Modernisation
Changing a running system without stopping it
Cost & Efficiency
Arguing about architecture in money
Technical Strategy
Setting direction and managing debt as a portfolio
Architecture Scenarios
Situations to reason through end to end
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.
Loading diagram…
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.
Gain this
Pay for it in
Why the exchange is unavoidable
Stronger consistency
Availability and latency
Agreement between nodes takes time and can fail
Lower latency
Money and complexity
Redundancy, caching, and the invalidation that follows
Independent deployability
Operational surface
More moving parts to monitor, secure and upgrade
Tighter security
Usability and velocity
Every control is a step someone must take
Flexibility
Simplicity
Every extension point is code with no user today
Reuse across teams
Coupling
A shared component makes its owners a dependency
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.
Archetype
What the loop contains
What they are really testing
Hands-on architect
Design exercise plus real coding
Whether you can still build it
Software architect
Design, trade-off defence, scenarios
Whether your decisions survive challenge
Solution architect
Client scenario, sizing, presentation
Whether you can sell and cost a design
Enterprise architect
Portfolio case, stakeholder scenario
Whether you can steer without authority
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.
Loading diagram…
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)
Transactional outbox table + poller - chosen
Dual write to broker inside the txn - rejected: not atomic
Change data capture off the WAL - rejected: no ops capacity yet
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.
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.