Data Architect

The Data Architect is the professional who designs the technical organisation of data to support its use within the business. They define models, data flows and storage choices. Their work gives technical teams a framework for building solutions that meet users’ needs.

They start with the current situation: what data is available, where does it come from and how is it used? They compare this map with business expectations, then set out an architecture. This specifies the relationships between data, how it is exchanged and the constraints that must be considered to make it accessible. Diagrams and metadata help communicate these choices and examine the effects of a new integration.

The role involves working with information systems teams, data engineers and data scientists. Each organisation must clarify the reporting line and the decisions entrusted to the role. The title alone confers neither line management responsibility nor authority to approve all security or compliance rules. The architect incorporates standards and protection requirements with the relevant specialists.

Data Architect, Data Engineer and data leadership: who does what?

• The Data Architect is responsible for consistency across models and architecture choices. They explain technical decisions and their implications for how data is used.
• The Data Engineer develops and implements data flows. Designing integrations may be part of their work: the two roles share some skills.
• Data leadership defines the data strategy and leads its implementation. This remit does not automatically come with the Data Architect title.

When defining a role, distinguish between the recommendations expected, the decisions the person will be able to approve and the work assigned to other teams. This allocation helps avoid treating an architecture need as a development or leadership position.

Data architecture connects users’ needs with technical choices. A single project must take account of the available data, its format, exchanges between systems and access conditions. For a business leader, the challenge is to make these choices understandable before committing to implementation.

A platform may meet a storage need while being poorly suited to the expected response time. A model may work for a local use case and become difficult to share with other teams. The risk is discovering too late that a technical choice does not support the intended use. Ask for performance, hosting and access constraints to be made explicit in architecture decisions.

Documentation matters as much as the initial diagram. Models must be capable of being updated, including from an existing system. Metadata repositories help, in particular, to examine the impacts of an integration. Without this understanding of the current situation, a decision may overlook data or exchanges on which other users depend.

Hypothetical example: a company wants to bring together data from several applications for a new business use. Before choosing the platform, ask the Data Architect to explain the formats that need to be brought together, the flows required and the access conditions. Have them clarify the expected response times and the information still missing. You can then discuss technical options based on the actual need.

• Map existing sources and data to understand how they are organised.
• Gather users’ expectations to translate use cases into architecture requirements.
• Design and update data models, including from existing systems.
• Define flows, formats and storage choices suited to the technical constraints.
• Compare hosting and access options against performance needs.
• Document architecture choices and metadata useful for integrations.
• Incorporate standards and protection requirements with the relevant specialists.
• Explain technical choices to business teams and the teams responsible for implementing them.

Documented routes include a French diplôme d’ingénieur or a master’s degree in computer science, with a data-related specialisation. Knowledge of information systems and statistics is useful. These educational routes do not constitute a degree requirement for every role: assess what the candidate can design and explain.

Experience in data engineering or software architecture can prepare someone for the role. It becomes particularly useful when recruiting if the person can describe responsibilities they have held: understanding an existing system, proposing a model, comparing storage choices or documenting an integration. Experience in a related role does not, by itself, demonstrate the ability to take independent responsibility for an overall architecture.

When reviewing a candidate’s background, distinguish exposure to an environment from responsibility for a decision. One candidate may have helped implement a flow without choosing the overall architecture. Another may have designed a model and supported its development with technical teams. These experiences indicate different levels of autonomy, even if the tools listed on their CVs are similar.

Apec mentions TOGAF and ArchiMate among the additional training options for the big data profile. Consider them as aspects of a candidate’s background to put into context, without treating them as mandatory certifications or automatic proof of proficiency. For the proposed role, prioritise consistency between the candidate’s knowledge, the decisions they have already taken responsibility for and the responsibilities you wish to assign.

The foundations of GetPro’s assessment approach

GetPro structures assessment around a set of priority criteria. It distinguishes what can be verified from the candidate’s background from what needs to be explored in an interview. Each criterion is linked to an assessment method. Interviews use open questions and concrete examples to assess key skills.

Advice on assessing a Data Architect

The suggestions below are specific to this role and should be adapted to the responsibilities of the position. They do not describe a specific protocol used by GetPro for Data Architects.

1. Define the criteria before interviewing

Distinguish the decisions the candidate will need to make, the recommendations they will offer and the approvals assigned to other people. Link each expectation to observable work: a model, flow diagram, technical comparison or documentation.

Weight the criteria according to your environment. Give stream processing greater weight if your platform requires it, without turning this skill into a universal prerequisite. Also define the expected level of autonomy over models and integrations.

2. Examine a past architecture

Ask the candidate to present a project and their exact role. Have them clarify users’ needs, the available sources and the constraints known at the time the choices were made. Distinguish their decisions from those of the team.

Invite them to explain how they built or updated the model and documented the flows. Ask what they would change with the information available today. Look for understandable reasoning, with identified assumptions and acknowledged limitations.

An account that only describes the tools used calls for further exploration. Ask what those tools helped solve and which other options were considered. Do not infer autonomy from a simple list of technologies.

3. Set an exercise relevant to the role

Hypothetical example: propose connecting several sources to support a new business use, with access and response-time constraints. Ask for a simple diagram, followed by an explanation of the choices.

Observe the questions asked before the solution is proposed. Does the candidate seek to understand the existing data, formats and users’ expectations? Ask them to identify missing information and the assumptions they have made.

Have them compare two storage or hosting options. Introduce a budget constraint to examine how they explain trade-offs, without assigning them responsibility for budget approval. Ask which consequences need to be discussed with the relevant decision-makers.

The ability to link each choice to an explicit constraint is a positive sign. A highly detailed proposal that overlooks access conditions or use cases warrants a targeted follow-up question.

4. Assess communication and cooperation

Ask for the same decision to be presented to an engineer, then to a business manager. Assess the precision of the explanation and the ability to retain the relevant implications without overusing technical terms.

Explore a disagreement over a model or standard. Ask who was consulted and how recommendations were distinguished from approvals. Assess management skills only if the role includes explicit management responsibility.

5. Have the technical case reviewed and take up references

If your company lacks the necessary expertise, have the case reviewed by an experienced architect who can assess the assumptions and trade-offs. Give them the same criteria as the other assessors.

With the candidate’s consent, use references to clarify their role in the projects discussed, their autonomy and their cooperation with teams. Compare this information with the examples presented, without expecting a referee to reveal confidential information.