A Solutions Architect decides how to turn business, technical, financial and regulatory constraints into a workable architecture — and then into a path the teams can actually follow.
A Solutions Architect does more than produce a target diagram. They determine how an application fits into an existing system: services, data, network, identities, infrastructure, operations, security and contractual constraints. They have to understand each area well enough to spot the structural dependencies, without taking the place of the specialists who implement them.
The difference between someone who describes an architecture and someone genuinely holding the role shows up in the trajectory. A technically coherent target can remain unusable if it assumes a big-bang migration, skills that are not there, a disruption nobody can absorb, or a running cost nobody has agreed to.
The job sits at the intersection of permanent tensions: standardisation against team autonomy, resilience against complexity, managed service against vendor dependency, modernisation against continuity. The assessment looks less at whether the candidate knows a pattern than at how they qualify those tensions, choose what to protect, and name what they agree to degrade.
Market benchmarks
The market carries very heterogeneous titles: Solutions Architect, Cloud Architect, Technical Architect and Application Architect may cover near-identical or very different scopes. Demand remains sustained in organisations modernising their information systems or building distributed platforms.
Genuinely senior profiles are rare, because they have to combine enough technical depth, the ability to make trade-offs, and cross-cutting influence. A large share of the talent pool works in consulting or independently, which makes it all the more important to assess whether someone can settle into an organisation for the long term.
Context
In an IT services firm, the Solutions Architect often works on an estate they did not choose, with several stakeholders, and inside a contract that may fix the scope, the date or the service level. The assessment then leans on investigating what exists quickly, making commitments defensible, and proposing a trajectory compatible with the client relationship.
Level 1
Junior
They describe a coherent solution within the area they came from, but still reason mainly by technology or by conformity to a target. They can apply a standard or propose an architecture without gauging the dependencies, the operating conditions, or the path needed to adopt it.
Click to read
Level 2
Mid-level
They design autonomously within the usual scope. They identify several options, make their assumptions explicit, and cover the main application, infrastructure, network and data impacts. They can defend an architecture, but may still underestimate the cost of transition or treat heterogeneous constraints as one uniform problem.
Click to read
Level 3
Senior
They no longer separate the target from the path to it. They rank risks, distinguish needs that are genuinely different, anticipate coexistence with what exists, and factor in available skills, operations, security, cost and reversibility. They can contradict a request, a peer or a director without turning disagreement into a clash of authority.
Click to read
Level 4
Expert
They are not the person who knows more technologies. They are the person who decides when every option has a cost. They may accept temporary debt, running two systems, a less immediate experience, or a narrower scope in order to keep the trajectory credible. They say publicly what will be lost, and turn the decision into a principle the organisation can reuse.
Click to read
Application architecture and how the system is split carry the most weight, because a badly split solution creates dependencies that infrastructure alone cannot make up for. This distribution forces a check that the candidate can connect the areas, rather than over-weighting the one they know best.
A solution is not robust because it spans several zones or several instances: it is robust once the failure modes, the freshness requirements and the data consistency have been explicitly decided.
This category separates an architecture you can draw from one you can execute. It measures the ability to sequence, to live with two worlds for a period, and to account for the total cost.
In this role, a contractual or regulatory requirement cannot stay a line in a document: it has to be turned into segmentation, access control or a technical guardrail.
An architecture nobody understands, funds or applies has no operational value. This category checks the ability to win agreement without diluting the decision.
The method in action
The scorecard at a glance — hover an axis
Architecture & integration