They decide how to evolve the systems, identity, network and infrastructure-service foundations without compromising business continuity, security or the organisation's future ability to run them.
An Infrastructure Architect is not simply a Windows, Linux or Active Directory administrator who has gained experience. Their scope begins precisely where specialised expertise stops being enough: when a directory decision changes application access, when a network change undermines the backup strategy, or when a technically desirable migration becomes unrealistic given the existing estate.
The job is to bring coherence to a set of things that is rarely homogeneous: Windows Server and Linux systems, directories and identity federation, DNS, networks, virtualisation, storage, backups, monitoring, and sometimes cloud or hosted infrastructure. Technology sets the context, but it is not the criterion: the assessment watches whether they can decide where to standardise, where to tolerate an exception, what to migrate, and how to reduce a risk without interrupting services.
The difference between an experienced operator and someone genuinely holding the role shows in the dependencies they account for. A technically clean architecture may be unusable by the team in place, or impossible to migrate within the available windows. The job lives in that permanent tension between coherence, security, availability, cost, available skills and reversibility.
Market benchmarks
The French market has plenty of systems engineers or specialists in one ecosystem, but people able to reason across Windows, Linux, identity, network, storage, security and continuity are markedly rarer. The scarcity is sharpest in hybrid environments and older estates that have to evolve without major interruption.
Titles are also inconsistent: Infrastructure Architect, Technical Architect, Systems Architect and Platform Architect may describe closely related responsibilities. That variety makes assessment by declared technologies unreliable, and strengthens the case for a method centred on decisions.
Context
In an IT services firm, the assessment leans more on getting into several inherited estates, working with different standards, telling what falls under the contract from what falls under technical responsibility, and handing the client an architecture they can run. The candidate has to decide in a relationship where the people who design, fund, operate and use are not always the same.
Level 1
Junior
They understand an architecture within a bounded scope and apply existing standards correctly. They identify the main components and their immediate dependencies, but still often reason by product or by technical domain. They find it hard to tell a structural constraint from an operational preference.
Click to read
Level 2
Mid-level
They design a coherent subset: a systems foundation, an identity architecture, a storage service, a network segment or a virtualisation platform. They compare several options, make their assumptions explicit, and handle security, capacity and availability constraints. Their usual limit is producing a sound target without dealing sufficiently with migration or coexistence with what exists.
Click to read
Level 3
Senior
They systematically connect the target to a workable trajectory. They arbitrate between standardisation and continuity, security and business activity, modernisation and transition debt. They identify the dependencies between systems, network, identity, storage, backup and operations. They plan for periods of parallel running, maintenance windows and rollbacks.
Click to read
Level 4
Expert
They settle a structural trade-off and own its cost. They may decide to keep an imperfect system for a while, fund parallel running, accept bounded heterogeneity, or slow a migration in order to protect service continuity. They name explicitly what the organisation agrees to give up: simplicity, speed, uniformity, budget, or operational comfort.
Click to read
An infrastructure only holds if its foundations are coherent. This covers how Windows and Linux environments are structured, identity and access, the network, DNS and virtualisation. A weakness here produces invisible dependencies.
An infrastructure architecture is judged when a component fails, when data has to be restored, or when a site goes down. A backup that has never been restored is not an architectural guarantee.
An infrastructure estate is almost never replaced in a single operation. This category measures migration strategy, sequencing, and old and new coexisting.
Privileged rights, segmentation, hardening and logging have to be built into the design. A foundation that is secure but incomprehensible in production is still dangerous.
An Infrastructure Architect rarely decides the whole scope alone. An architecture nobody adopts exists only in the documents.
The method in action
The scorecard at a glance — hover an axis
Architecture & integration