Cloud architect

The cloud architect designs a technical architecture suited to the company’s needs. They connect business objectives with networking, compute, storage and security choices. Their role is to make these choices consistent with one another and with the existing information system, then support their implementation.

Their work covers a complete solution: the applications to integrate, the data they exchange and the resources needed to run them. They take account of business constraints, information system objectives and operating conditions. The organisation’s size, complexity and sector affect the scope of this responsibility.

To define the role, identify their decision-making counterpart within technical or IT management. Also specify the teams they will work with: development, operations, security and data. The title alone does not indicate how much implementation work they will be given. Depending on the role, the architect contributes directly to implementation or supports the teams deploying the solution.

Cloud architect, DevOps and security: who does what?

• Cloud architect: assign them responsibility for design consistency, integration choices and the solution’s technical rules.
• DevOps: agree with the team how automation and deployment responsibilities will be shared. The DevOps engineer profile provides more detail on this neighbouring role.
• Security: agree on the protection requirements to incorporate and the approvals to share with the relevant specialists.

Adapt this division of responsibilities to your organisation. It helps you set clear expectations: which decisions should the architect prepare, which can they approve and how far should they be involved in implementing them?

Architecture choices affect robustness, scalability, security, performance and cost control. For an executive, the challenge is to connect each choice to a real need: keeping a service available, supporting changes in usage or integrating an application into the existing environment.

A useful assessment of trade-offs makes its constraints explicit. Ask what the solution must support, which interruptions are acceptable and which data it must protect. These answers provide a framework for the design. They also allow a technical option to be discussed without making the provider or tool the starting point of the project.

Making trade-offs understandable

When an option is selected, ask for the expected benefits, limitations and consequences for the teams to be explained. An architecture must remain understandable to those who implement and operate it. Documentation can record the reasons for a choice so that subsequent decisions take this context into account.

Spending deserves the same level of explanation. Ask which assumptions underpin the choice and which uses might call it into question. To clarify responsibility for cloud costs, you can explore the scope of the FinOps engineer role.

Fictional example: a company wants to migrate an application that several teams depend on every day. Before choosing a target architecture, the architect examines exchanges with existing systems and continuity constraints. The decision must explain how these dependencies will be addressed during the migration.

• Analyse business needs, technical constraints and the components of the existing system.
• Assess migration risks and dependencies between applications, data and networks.
• Design the target cloud architecture and define the associated technical standards.
• Choose services and integration approaches according to security, performance and scalability requirements.
• Record decisions in the project’s architecture documents and diagrams.
• Support deployment and migration alongside technical teams, taking operational continuity into account.
• Analyse the effect of new technologies and changing needs on the architecture.

Education and training in information systems architecture can lead to a career as a cloud architect. In particular, these programmes develop an understanding of existing systems, needs analysis, target architecture design and component integration. A course title alone does not describe the responsibilities someone can take on.

What weight should certifications carry?

Vendor certifications attest to skills within their own environments. They provide an indication of the areas covered. The Microsoft framework covers identity, storage, continuity and infrastructure design, among other areas.

The conditions for obtaining them differ: Microsoft requires Azure Administrator Associate for its Azure Solutions Architect Expert certification, while Google lists no prerequisites for the Professional Cloud Architect exam. These conditions relate to certifications, rather than a common recruitment rule.

To assess a cloud architect, adapt the following steps to the decisions and constraints of the role you are hiring for.

1. Define the criteria before interviews

Describe the decisions the person will need to make: designing a target architecture, preparing a migration or ensuring consistency between several systems. Specify the expected share of implementation work.

Limit the assessment framework to around ten priority criteria. Distinguish those that can be assessed through career history from those that require a question or exercise, and assign an assessment method to each.

For this role, you could focus on understanding needs, technical consistency, trade-offs and handover to teams. Distinguish knowledge that is essential on arrival from knowledge that can be acquired.

Involve a business stakeholder in defining this framework. Ask them to express service constraints in their own words, so that the technical assessment remains connected to an understandable need.

2. Examine a past project

Ask the candidate to present an architecture they have actually worked on. Have them explain the context, their personal responsibility and the decisions made with other people.

Base the discussion on an anonymised diagram or a reconstruction. Ask: “Which constraints shaped this design?” Then: “Which option did you reject, and why?”

A positive sign is an explanation that connects components to needs and distinguishes known facts from assumptions. Probe an answer that focuses on tool names or leaves their contribution unclear.

3. Set a case close to the role

Fictional example: propose migrating an application that exchanges data with a system the company is retaining. Provide the known needs and continuity constraints.

Ask the candidate to formulate their questions before drawing a target architecture. Have them present the dependencies to examine and the choices they can already justify.

Invite them to explain how they would approach networking, access, data and recovery. Then introduce a new constraint and observe how they reconsider their proposal.

Assess the quality of their reasoning using your framework. A proposal that makes its limitations visible is a useful sign. Certainty maintained without addressing the new constraint warrants further examination.

4. Test communication and cooperation

Ask for a short presentation to a non-specialist. Observe whether the candidate explains the consequences of the choice and the decisions still open without losing the necessary precision.

Then explore a disagreement they have experienced with development, operations or security. Ask how the arguments were discussed and how the decision was communicated.

If the role includes coordination, assess this responsibility separately. Do not infer management ability from technical fluency alone.

5. Consolidate the assessment

Compare each assessor’s observations with the initial criteria. Record what has been demonstrated, what remains uncertain and what would require support when the person starts.

With the candidate’s agreement, a professional reference can shed light on unresolved points: place the skill in the context of the working relationship, then ask for a concrete example. For this role, the discussion can cover the role performed, cooperation and follow-through on decisions.

If your company lacks the necessary technical expertise, involve a specialist who can discuss the design. Keep the assessment of the business need and the scope to be assigned within the company.