A Software Architect decides where to draw the system's boundaries and what trade-offs to accept between speed of change, reliability, data consistency and team autonomy.
A Software Architect is not defined by producing the most elegant diagram. Their job is to make explicit the decisions that give lasting structure to a product or an information system: how responsibilities are split, the contracts between components, how data moves, how failures are handled, and the path along which things will evolve. Their work starts when several technically valid solutions lead to different consequences for the teams, for operations and for the business.
An experienced developer can design a component properly. A Software Architect has to understand what that design will cause at system scale: dependencies between teams, release frequency, difficulty of diagnosis, data consistency, and the ability to replace a technology or evolve a domain without regressions elsewhere.
The central tension of the job regularly pits global coherence against local autonomy. Too much centralisation slows teams down and turns architecture into a permission gate. Too much freedom produces incompatible contracts and fragmented operability. The assessment therefore looks less at knowledge of architectural patterns than at the ability to draw boundaries, arbitrate, and make a decision applicable.
Market benchmarks
The Software Architect title covers very different realities from one organisation to the next. Some roles sit close to a cross-cutting Tech Lead, others to a solutions architect or a platform lead. That variety sustains a market where experienced candidates are visible, but where people able to connect design, production, data, trajectory and influence remain rare.
The scarcity is sharpest in contexts of estate modernisation, product growth, distributed systems or regulatory constraint. Companies are looking less for a specialist in one technology than for a professional able to make durable decisions without slowing teams down.
Context
In an IT services firm, the Software Architect frequently works on an inherited estate, with several stakeholders, shared responsibilities and decision-making bounded by the contract. The assessment then leans on discovering what really exists, making dependencies visible, proposing a trajectory compatible with the commitments made, and handing over a decision that remains applicable after they leave.
Level 1
Junior
They identify the main responsibilities, apply existing conventions and can map immediate dependencies. They still reason readily by known solution or pattern. They find it hard to tell a structural rule from a design preference, and see little of the organisational consequences of their choices.
Click to read
Level 2
Mid-level
They compare several options, spell out assumptions, and handle contracts, data, errors and non-functional constraints. They can explain why a given decomposition suits the need. Their usual limit is producing a technically sound target state without always factoring in migration, operations, or the teams' real ability to adopt it.
Click to read
Level 3
Senior
They arbitrate between coupling, deadline, consistency, availability, running cost and available skills. They distinguish the desirable target from the realistic path to it. They anticipate old and new coexisting, the organisational dependencies, and what a decision does across several teams. They do not wait for a committee to name the risks on their behalf.
Click to read
Level 4
Expert
They are not the person who knows more patterns or technologies. They are the person who can decide to keep an imperfect architecture for a while, duplicate a capability, slow a transformation, or give up immediate consistency — and then name precisely what the organisation agrees to give up. They turn ambiguity into a decision and raise the teams' own capacity to decide.
Click to read
This category carries the main weight because the core of the role remains defining boundaries, responsibilities and contracts that let the system evolve without propagating every change across the whole estate.
A decomposition is only worth something if the exchanges, the data consistency and the behaviour under failure are under control. This category separates a well-drawn architecture from one that actually works under real conditions.
An unreachable target is not an architectural decision. This weighting measures the ability to organise modernisation, sequence changes and deal with debt.
An architecture the teams do not understand, cannot apply, or systematically work around exists only in the documents. This category measures the ability to get principles adopted.
Security, observability, diagnosis and degraded modes have to be built into the design, without turning the Software Architect into the sole specialist in those disciplines.
The method in action
The scorecard at a glance — hover an axis
Architecture & integration