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 where its decisions show up years later.
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 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.