Software architects
Software architects are responsible for structure: how a system divides into parts, how those parts communicate, which properties the whole must uphold, and how it changes shape over years without being rebuilt. The decisions are comparatively few and comparatively expensive to reverse. This guide explains what the discipline covers, how it differs from senior engineering, and how to judge architectural reasoning during hiring.
What does a software architect do?
A software architect decides how a set of systems is structured and how that structure evolves. The work covers decomposing a domain into services or modules, defining the boundaries and contracts between them, establishing non-functional requirements such as availability, latency, throughput and recovery targets, selecting technologies against those requirements, planning migrations from what exists to what is intended, and recording the reasoning behind each choice so it can be understood and challenged later. Architects generally operate across several teams and over a multi-year horizon, and are usually less hands-on than the engineers implementing their decisions.
What separates architecture from good senior engineering is the cost of being wrong. Most engineering decisions are reversible within a sprint. Architectural ones bind the organisation: a boundary drawn in the wrong place is discovered eighteen months later, when three teams have built around it and the correction requires unpicking every integration that crossed it. That asymmetry is why architects spend disproportionate effort on which decisions are one-way and which can safely be deferred.
The discipline is applied constraint. An architecture that permits everything has decided nothing, and teams then rediscover the same questions independently and answer them differently. Useful architecture narrows the space — these are the boundaries, this is how services talk to one another, this is what a new component must satisfy before it goes live — while leaving enough room inside the constraints that teams retain genuine autonomy over their own work.
The recurring failure mode is well known and worth naming. An architect who stops encountering production, whose diagrams describe an intended system rather than the one that runs, and whose standards arrive as pronouncements rather than proposals will be politely ignored. The output that matters is not a document; it is a decision that teams actually build to, which usually requires the architect to have been present while the problem was being felt.
When organisations need this capability
Architecture is always happening — the question is whether anyone is doing it deliberately. These are the conditions under which the implicit version stops being sufficient.
Several teams are building against each other
Each team optimises its own delivery and the seams between them degrade: duplicated data with no owner, integrations built twice in incompatible ways, a change in one service breaking two others without warning. No individual team can fix this because the problem exists between them.
A monolith is being decomposed, or a decomposition is being reversed
Both directions demand the same scarce skill — knowing where the genuine seams are. Splitting on the wrong lines produces distributed systems with all the coupling of a monolith and none of its convenience, and that outcome is far more common than the reverse.
Non-functional requirements have become contractual
An enterprise customer, a regulator or an availability commitment turns latency, recovery time, data residency or auditability into obligations. Retrofitting those properties into a system designed without them is frequently harder than the original build.
A significant technology selection is imminent
A datastore, messaging backbone, identity provider or cloud commitment will be lived with for years. These decisions are typically made under time pressure by whoever is loudest, and their consequences arrive long after the person who made them has moved on.
A migration must run alongside delivery
Replacing a core system while continuing to ship requires a strategy for coexistence: what routes where during transition, how state is reconciled, what the rollback looks like at each stage. Migrations fail far more often on sequencing than on technology.
Nobody can explain why the system is the way it is
The people who made the founding decisions have gone and the reasoning left with them, so the current shape is treated either as sacred or as arbitrary. Both readings are wrong and both lead to expensive mistakes.
Core capabilities
System decomposition
Finding the boundaries that reflect how the business actually changes, so that a typical modification lands inside one component rather than across four. Boundaries drawn along technical layers rather than domain concerns are the usual source of systems where every feature requires coordinated releases.
Integration and contracts
Deciding how components communicate — synchronous or asynchronous, shared schema or translation at the edge — and defining contracts stable enough to depend on. Versioning, deprecation and backward compatibility are part of the design, not an afterthought once the first consumer breaks.
Non-functional requirements
Turning vague expectations into stated targets for availability, latency, throughput, durability, recovery, residency and auditability, then designing against them. Requirements nobody has quantified cannot be met deliberately, only accidentally.
Technology selection
Evaluating candidates against the requirements that will actually bite, including operational burden, hiring pool, licensing, exit cost and organisational fit. The relevant question is rarely which option is best in the abstract, but which is a good match for the constraints and the people who will run it.
Trade-off analysis
Stating explicitly what each option costs as well as what it provides, and being clear about which qualities are being sacrificed. An architecture presented as having no downsides has either not been analysed or is being sold rather than explained.
Migration strategy
Planning the route from current state to intended state in increments that each leave the system working, with coexistence, reconciliation and reversal designed in. The hard part is almost never the target design; it is the sequence.
Decision records
Writing down what was decided, what alternatives were rejected, what was assumed and what would justify revisiting it. The value appears years later, when someone must decide whether a constraint still applies or has quietly expired.
Failure and threat analysis
Reasoning about what happens when a dependency degrades rather than dies, where retries amplify load, how partial failure presents to users, and how trust boundaries and data flows expose the system to attack.
Cost modelling
Understanding what a design costs to run at expected and unexpected volumes. Architectures that are technically sound and economically unsustainable are common, and the discovery usually arrives with an invoice.
Influence without instruction
Getting teams to build to a decision they were not compelled to accept. This is the capability that determines whether the rest of the list produces anything, and it is the one most often missing in candidates with strong technical credentials.
How the discipline is practised
Architecture is not defined by a product list, so this section describes method rather than tooling. The practices, notations and artefacts below are those in common use across the industry — a description of the discipline generally, and not a statement about how anyone in particular works. Naming them is easy; the evidence worth seeking is whether the judgement they encode is present.
Modelling and notation
- C4 model
- Context and container diagrams
- Sequence diagrams
- Domain models and bounded contexts
- Data flow diagrams
Decision practice
- Architecture decision records
- RFC processes
- Architecture review forums
- Technology radars
- Structured trade-off analysis
Quality attribute analysis
- Latency and error budgets
- Availability and recovery targets
- Capacity modelling
- Threat modelling
- Failure mode analysis
Evolution and migration
- Strangler-fig migration
- Anti-corruption layers
- Contract versioning and deprecation policy
- Phased cutover and dual-running
- Backfill and reconciliation planning
Governance without gatekeeping
- Fitness functions
- Automated conformance checks
- Dependency and boundary rules
- Paved-road platform defaults
- Deviation and exception records
Evidence gathering
- Proofs of concept
- Load and soak testing
- Fault injection exercises
- Production telemetry review
- Run-cost analysis
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Product
- Business priorities
- Roadmap
- Architecture
- Sprint priorities
- Engineering standards
- Day-to-day technical collaboration
Talent.ID handles
- Employment relationship
- Payroll
- Employee benefits
- Talent administration
- Ongoing employee relationship
What to look for when hiring
Architecture interviews reward fluency and fluency is cheap. Candidates can describe patterns confidently without ever having lived with the consequences of choosing one, so the useful evidence is nearly always retrospective: what they decided, what it cost, and what they learned when reality disagreed with the diagram.
Evidence of consequences
Ask about an architecture they designed that was still running years later, and what turned out to be wrong with it. Architects who move on before their decisions mature never receive the feedback that makes the next decision better.
- Has stayed with a system long enough to see a design age
- Can name a boundary they placed badly and describe the symptoms it produced
- Distinguishes a design that failed from one that succeeded and was outgrown
Trade-offs stated in both directions
Present a design decision and ask what it costs. Anyone can advocate; the question is whether they will name the properties being given up and the conditions under which their preferred option becomes the wrong one.
- Volunteers the weaknesses of their own recommendation
- Identifies the conditions that would change the answer
- Treats operational burden as a first-order cost rather than an implementation detail
Proximity to running systems
The ivory-tower failure is real and mostly preventable at interview. Ask what the last production incident in their area taught them, and whether the architecture they designed matched what they found when they went looking.
- Has read production telemetry recently and can say what surprised them
- Knows what their designs cost to operate as well as to build
- Has revised a standard because teams could not reasonably follow it
Migration realism
A target architecture is the straightforward half. Ask how they would move an organisation to it while it continues to deliver, and listen for whether every intermediate step leaves a working system behind.
- Plans coexistence rather than a cutover event
- Designs the reversal for each stage, not only the destination
- Accounts for the period in which two models must both be maintained
How decisions become binding
Architecture that lives only in documents changes nothing. Ask how a decision of theirs actually reached the code — through review, tooling, defaults, conformance checks or persuasion — and how they detected drift from it.
- Prefers automated checks and sensible defaults to written rules
- Can describe finding out that teams had diverged, and what they did
- Writes decisions with rejected alternatives and expiry conditions
Quantifying the non-functional
Ask how they established an availability or latency target on a real system. The distinguishing answer traces it back to a business consequence rather than to a conventional number that sounded appropriately serious.
- Derives targets from consequences rather than convention
- Knows what the next increment of availability would cost
- Has argued a target down as well as up
Restraint
Over-architecture is at least as damaging as under-architecture and considerably harder to unwind. Ask about a time they chose the plainer option, and about a capability they deliberately did not build for.
- Can describe declining to introduce a technology they favoured
- Distinguishes reversible decisions that need no ceremony from those that do
- Designs for a plausible next stage rather than an imagined end state
Interview questions worth asking
Offered for use in your own evaluation process. Each is aimed at reasoning that is difficult to rehearse, and the notes describe what the answer tends to reveal rather than a correct response.
Describe an architecture you designed that is still in production. What has it made difficult that you did not anticipate?
What a strong answer shows
Whether they have received feedback from their own decisions. The specificity of the regret is the signal — a general reflection about complexity usually means they left before the bill arrived.
How do you decide whether a decision needs to be made now or can safely be deferred?
What a strong answer shows
Command of reversibility, which is the central architectural instinct. Look for deferral used as a deliberate technique to buy information, not as an absence of opinion.
Take a system you know well. Where would you draw the boundaries differently, and what evidence points there?
What a strong answer shows
Whether decomposition is reasoned from how the domain changes or from a diagram they have seen before. Strong answers cite change patterns, coupling observed in practice and the shape of the team structure.
You inherit a target architecture you disagree with, already partly built. What do you do?
What a strong answer shows
Judgement about sunk work and organisational reality. The concerning answers are at both extremes — accepting a genuinely unsafe direction, or restarting because it is not what they would have chosen.
How did you establish the availability target for a system you worked on, and what did the last increment cost?
What a strong answer shows
Whether non-functional requirements are derived or recited. The cost question separates people who have designed for a target from people who have quoted one.
Tell me about a standard you set that teams did not follow. What did you conclude?
What a strong answer shows
Response to being ignored, which every architect experiences. Look for curiosity about why compliance was hard rather than an account of insufficient discipline elsewhere.
What would you need to see before recommending we move away from a technology we currently rely on?
What a strong answer shows
Whether change is proposed on evidence or on preference. Strong answers set a threshold in advance and account for the cost of the transition itself.
Which of your architectural documents do you think people actually read, and how do you know?
What a strong answer shows
Honesty about the gap between produced and consumed. Architects who have confronted this tend to have shifted effort towards decisions, defaults and conversations rather than documentation volume.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- An organisation runs a core system that several teams extend concurrently. Integrations have been built independently, ownership of shared data is unclear, and a customer commitment has introduced recovery and residency obligations the current design was never intended to satisfy. A structural direction is needed while delivery continues.
- Approach
- Additional senior capacity works within the client’s own architecture practice — the client’s review forums, the client’s standards, the client’s decision records and the client’s technical direction. Structural authority stays where it already sits; the added capacity contributes analysis, documented options and implementation effort to decisions the client makes and owns.
- What this adds to the team
- The organisation gains experienced capacity for structural work while retaining architectural authority, product ownership and the final say on every decision that binds its systems.
Related disciplines
Frequently asked questions
- What is the difference between a software architect and a tech lead?
- Blast radius and horizon. A tech lead is accountable for one team’s technical work over weeks and months, stays close to the code, and can usually correct a poor call within a sprint. An architect works across systems and teams on a multi-year view, and a poor call propagates into everything built against it before anyone notices. The two roles are complementary: architecture sets the constraints between teams, and technical leadership makes good decisions inside them.
- Should a software architect still write code?
- Not necessarily in volume, but they need enough contact with running systems to keep their model of reality accurate. That contact can come through prototypes, reviews, incident participation or reading telemetry rather than routine feature work. An architect with no such contact begins designing for a system as it was described to them, which is the mechanism behind almost every ivory-tower complaint.
- Do smaller organisations need a dedicated architect?
- Frequently not as a separate post. With a single product and a couple of teams, architectural decisions are few enough to be held by experienced engineers and a technical leader. The need appears when decisions start crossing team boundaries, when several systems must interoperate, or when a commitment makes non-functional properties non-negotiable. Appointing an architect before there is cross-cutting structure to own tends to produce governance in search of a problem.
- What does an architecture decision record actually achieve?
- It preserves reasoning, which decays faster than code. A record states what was decided, which alternatives were rejected, what was assumed and what would justify a change of course. Its value arrives later, when someone must judge whether a constraint still holds. Records that document only the outcome, without the rejected options or the assumptions, provide very little of that value and are the reason many teams conclude the practice is bureaucratic.
- How do you tell good architecture from expensive architecture?
- By whether the complexity is answering a requirement that exists. Good architecture makes anticipated change cheap and states which changes it is not optimised for. Expensive architecture pre-builds flexibility for changes nobody has asked for, and charges for it in every feature delivered thereafter. The practical test is whether the architect can name the specific pressure each piece of structure exists to absorb.
- Can architecture be owned by a group rather than a person?
- Yes, and in many organisations it works better. A group of senior engineers making structural decisions together, with a clear method for closing them and a record of what was decided, produces decisions with more buy-in than an individual issuing direction. What a group cannot easily do is hold consistency over years without someone accountable for coherence, so the common shape is shared decision-making with a named custodian of the record.
- How does a software architect work with an existing engineering team?
- As a contributor to your architecture practice, not a replacement for it. Under a staff augmentation arrangement, your organisation retains architectural authority, technical direction, engineering standards, roadmap and product ownership; structural decisions are made and approved by your people, and your teams direct the work. On the Talent.ID side the arrangement covers employment only: the employment relationship itself, payroll, benefits for the employee, and talent administration. No architectural decision-making transfers with it.
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.