Network architect

A network architect designs the connections that allow an organisation’s equipment to communicate. They analyse user needs and existing networks, then propose a suitable architecture. They advise on the choice of solutions, equipment and operators. Their work enables information to flow at the required level of performance and security.

Their remit may cover local area networks (LANs), links between sites (WANs), Wi-Fi and remote access through VPNs. They examine project constraints before comparing several options, including their performance, security and cost. They then set out the chosen solution in architecture documents and diagrams that the teams deploying and managing it can understand.

The architect may take part in testing, commissioning and knowledge transfer. Depending on the organisation, they may also monitor how the network operates and propose changes. The boundary between design and operations is therefore not the same everywhere. Smaller organisations may combine several of these activities in one role, while a large company more often divides the work among specialists.

Network architect, network engineer and network administrator: who does what?

• Network architect: defines the target architecture, compares options and explains the choices made. Their involvement in deployment depends on the role.
• Network engineer: may handle technical implementation and testing, and sometimes part of the design. This division of work should be specified in the job advert.
• Network administrator: is mainly responsible for day-to-day network management and keeping it operational. In a smaller organisation, they may also contribute to design.

Hiring a network architect becomes a significant decision when a company needs to create new connections or develop a network that no longer meets its needs. The choices made determine how information flows between equipment, sites and users. They also affect service quality, security and the cost of the selected solutions. The need therefore extends beyond choosing an equipment brand.

The first decision is to define what the network must enable: which users to connect, which sites to link and which performance and security constraints to address. Without that brief, a candidate may propose a technically sound solution that poorly serves the actual need. The options must then be compared and their consequences explained, including for the teams responsible for operations. This brief provides criteria for justifying the chosen option and preparing checks. The decision must connect the identified constraints with choices about performance, security and cost, so that teams understand what they will need to deploy.

Coordination also matters during implementation. The architect must make their choices usable by technical teams and discuss constraints with the relevant suppliers or operators. Incomplete diagrams, unstated assumptions or poorly prepared tests complicate the move from design to implementation. Precise documentation and checks prepared around the chosen design make handover easier for those who will then manage the network. When hiring, the decisive point is therefore the candidate’s ability to connect needs, technical trade-offs, documentation and handover.

• Analyse user needs and the state of existing networks before defining the project scope.
• Design connection options for local networks, links between sites, wireless networks or remote access, according to need.
• Compare options on performance, security, service quality and cost.
• Choose technical solutions, equipment and operators suited to the project constraints.
• Document the chosen architecture and justify the decisions in written documents and diagrams.
• Take part in tests and checks before the network is commissioned.
• Support deployment and pass the necessary information to the teams that will operate the network.
• Examine the performance of the existing network and propose changes when the role includes this follow-up.

There is no single qualification that leads to network architecture. Apec cites specialised courses in networks and telecommunications ranging from the French Bac +2/3 to Bac +5 levels. Among its examples, CIDJ mentions a master’s degree and an engineering degree. These routes can provide technical foundations useful for network design.

Experience in network engineering or administration can prepare someone for the role when it includes analysing the current environment, comparing options and justifying a solution. Configuring equipment alone does not demonstrate autonomy in making architecture decisions.

Useful knowledge depends on the role. Design work draws on an understanding of local and wide area networks, routing and security mechanisms. For a project that includes deployment, being able to produce diagrams, prepare checks and explain decisions to the teams that will manage the network may also be useful. Knowledge of virtualisation, SDN or automation is relevant when the architecture to be designed actually uses it.

The expected level of autonomy depends on project size and the support available. Apec describes junior architects working on smaller projects or alongside experienced colleagues. A less autonomous professional may therefore suit a role that provides this support; a number of years alone does not show which decisions they can make.

To assess a candidate, start with the architecture decisions your organisation expects them to make. The steps below are guidance to adapt to the project and the level of autonomy sought.

1. Set the criteria before the interview

List the networks involved: LAN, WAN, Wi-Fi or VPN, depending on the role. Specify the needs to be translated into an architecture, the security and performance constraints, and the expected deliverables. Establish who will choose equipment and operators, who will carry out tests and who will operate the network. These criteria let you compare candidates against the same responsibilities.

A positive sign is an answer that connects a specific constraint with a choice that can be tested. Be wary of a list of technologies that has no connection to how the network will be used or to the project’s limitations.

2. Discuss a past project

Ask the candidate to describe a project they know well without disclosing confidential information. What were the requirements? What did they personally analyse, decide and document? Which solutions did they compare? Ask them to explain a trade-off between performance, security, service quality and cost.

Look for a redacted diagram or a description of the architecture, together with the reasoning behind the choice. A strong account distinguishes their contribution from those of engineers, administrators and suppliers. A vague answer about alternatives or personal responsibility calls for further questions.

3. Present a case relevant to the role

Describe a hypothetical need limited to the constraints that genuinely matter to your recruitment. Hypothetical example: two sites need to be connected, and some users access the network remotely. Ask what information is missing before designing the architecture. Have the candidate compare two possible approaches without requiring a particular brand or expecting a complete configuration.

Invite the candidate to draw a simple diagram, explain any relevant routing or security choices, then say what they would have tested before deployment. The expected outcome is a reasoned approach, not a single correct answer. It is a warning sign if a solution comes before any analysis of the needs.

4. Examine communication and handover

Ask how they would present their choice to an operations team and a manager who is not a specialist. What diagrams, configuration details and points to watch would they pass on? Check that they can explain the limits of their solution and the decisions still to be made with other specialists, particularly on security.

If the role includes coordination, ask how they work with deployment teams. A clear explanation and a documented handover are more useful than a general assurance that they ‘communicate well’.

5. Cross-check the evidence

Assess the practical case and the account of the past project against the same criteria. If you take references, obtain the candidate’s consent first, then ask for confirmation of the responsibilities they held, the quality of the documents they delivered and their collaboration with teams. Avoid treating a general opinion as evidence of technical competence.

If the company lacks the network expertise needed to judge the trade-offs, involve a suitably qualified specialist in preparing and assessing the case. The hiring manager can then assess the fit of the candidate’s experience, their autonomy and the clarity of their explanations, while the specialist examines the soundness of the technical choices.