They decide where data must live, who is accountable for it, how it moves, and what trade-off the company accepts between consistency, freshness, cost and delivery speed.
A Data Architect neither simply draws a platform, nor picks a storage engine, nor imposes a governance model. The job starts where several decisions become inseparable: the grain of a piece of data, its owner, its source of truth, how it moves, how long it is kept, who may access it, and the level of quality its consumers expect. A data architecture that is technically elegant but cannot say which figure is authoritative does not hold the role.
The difference between someone executing and someone genuinely carrying the function shows in how they handle contradictions. Centralising makes control easier but can slow domains down. Distributing ownership brings decisions closer to the business but multiplies the contracts to honour. Real time cuts latency but raises cost, operational complexity and the risk of disorder.
The role also commits to a trajectory. The Data Architect has to make the existing BI estate, operational applications, legacy flows, new analytical uses, data products and AI-driven needs live together. The target state is only worth something if it can be reached without interrupting usage, losing traceability, or leaving teams dependent on a handful of experts.
Market benchmarks
The French market is actively looking for people who can connect architecture, platform, governance and business usage. The title nonetheless covers very different backgrounds: some come from BI, others from data engineering, cloud, software architecture or governance.
Genuinely senior profiles are rare because the role demands technical depth, experience of transformation, and the ability to get cross-cutting decisions applied. Platform modernisation, preparing for AI use cases, regulatory pressure and cost control keep that tension in place.
Context
In an IT services firm, the assessment leans more on the ability to get into an inherited estate, to tell the target that was sold from the trajectory that is contractually feasible, to work with several stakeholders, and to make responsibilities for handover, operations and quality explicit. The Data Architect has to produce a defensible decision in a time-and-materials or fixed-price setting, without confusing compliance with the deliverable and viability of the system.
Level 1
Junior
The Junior level most often corresponds to someone experienced in data engineering, modelling or BI who is moving into architecture. They can reason within a bounded scope, apply conventions, identify the main sources and map immediate dependencies. They remain focused on the solution or the model they know, and still see little of the organisational, regulatory and operational consequences of their choices.
Click to read
Level 2
Mid-level
A Mid-level architect designs a coherent data domain or subset of the platform. They make the grain, the contracts, the quality rules, the responsibilities and the freshness constraints explicit. They compare several integration patterns and can connect a storage or processing choice to actual usage. Their usual limit is a target state that is technically sound but insufficiently connected to migration, operations, and adoption by producers and consumers alike.
Click to read
Level 3
Senior
A Senior architect connects the design to the trajectory. They arbitrate between centralisation and autonomy, freshness and cost, consistency and availability, standardisation and local needs. They distinguish the desirable target from the realistic path, anticipate old and new coexisting, organise data migration and surface dependencies between teams. They do not wait for a committee to name the risks on their behalf.
Click to read
Level 4
Expert
An Expert is not the person who knows more technologies. It is the person who settles a structural trade-off and owns its cost. They may decide to keep a duplication for a while, to accept lower freshness, to slow a migration, to cut scope, or to run two models in parallel. They name precisely what the organisation agrees to give up, and make the decision workable without leaving it dependent on them.
Click to read
The heart of the role is setting the grain, the boundaries, the responsibilities and the mechanisms by which data moves. A bad decision at this level propagates into every use.
A platform that rapidly ships data which is wrong, incomplete or impossible to replay accelerates the problem instead of solving it. Trust and operability weigh almost as much as the design.
Migration, coexistence, reversibility, cost and the skills actually available determine whether the architecture will be adopted rather than merely drawn.
A convention producers ignore, a contract consumers work around, or a responsibility nobody accepts does not exist. Data architecture has to become a collective way of working.
Access, sensitive data, retention, deletion, sovereignty and the ability to recover are not controls added after the design: they shape what it is possible to build in the first place.
The method in action
The scorecard at a glance — hover an axis
Architecture & integration