# Data architecture principles for a modern data platform > Shareable, governed data, an open lakehouse, fewer copies, curation and a common vocabulary: the principles behind a modern, value-driven data architecture. - Date : 2022-09-21 - Lecture : 8 min - Catégorie : data - Tags : Data architecture, Data platform, Lakehouse, Apache Iceberg, Data governance, Data products, Data quality, Data security - URL : https://www.adservio.fr/en/insights/articles/principes-d-architecture-de-donnees ## TL;DR - Data architecture refers to designing, structuring, managing and securing the data infrastructure, now also in the service of AI systems. - Data must be a shareable, governed asset: silos removed, fine-grained access controls applied as close as possible to raw data, federated governance. - The open lakehouse is taking over: Apache Iceberg has become the standard table format, read and written by every major engine through interoperable REST catalogs. - Reducing copies and data movement, zero-copy sharing, federation, cuts costs, inconsistency risks and the exposure surface. - Curation, data contracts and a common vocabulary turn raw data into reliable, understandable products, reusable by teams and AI agents alike. ## Data architecture, the foundation of analytics and AI Data architecture covers the design, structuring, management and security of the data infrastructure, with the aim of extracting value from it. Far from being a mere technical diagram, it determines what the organisation will actually be able to do with its data: decision-making analytics, real-time steering and, increasingly, feeding AI systems, from model training to RAG applications and agents querying the platform autonomously. That last use case has changed the game. An architecture designed to produce weekly dashboards is no longer enough when AI pipelines consume data continuously and the slightest quality error propagates into an assistant's answers. The historical principles, sharing, security, fewer copies, curation, common vocabulary, remain valid, but the way they are implemented has evolved deeply: open lakehouse, federated governance, data managed as products. Contemporary approaches therefore rely on flexibility, scalability and proactive design: anticipating uses rather than reacting after the fact. Here is how these principles play out today. One sign does not lie: data architecture now sits at the top of investment committees' agendas, no longer as an infrastructure topic but as the precondition of AI initiatives. Organisations that fail to industrialise their data foundation see their AI projects plateau at the prototype stage, for lack of reliable, accessible and governed data, while those that have done so roll out new use cases within weeks. ## Making data a shareable, governed asset The first principle is to treat data as a shareable asset. Organisations must remove the silos between departments so that every stakeholder can access the information needed to produce analyses and an overall view of the business. Lifting these barriers between business units is the condition for genuinely effective use of data, and the prerequisite for any serious AI initiative, which needs broad, legitimate access to the company's data. ### Security as close as possible to raw data This sharing cannot come at the expense of security. Modern unified platforms, Snowflake, Databricks, BigQuery, Microsoft Fabric, apply policies directly onto the data: role-based and attribute-based access control, dynamic masking of sensitive columns, row-level filtering. The challenge is to reconcile self-service with built-in safeguards: users explore freely, but only ever see what their policy allows. ### Federated rather than centralised governance Governance itself is evolving: rather than a central committee approving every access, mature organisations define global standards, classification, retention, compliance, and delegate their enforcement to the business domains that own their data. This federated governance, tooled with catalogs and policy as code, scales where centralised control becomes a bottleneck. This governance rests on a living data catalog: an inventory of datasets, identified owners, sensitivity classifications and end-to-end lineage. Without this map, sharing remains wishful thinking: you can neither find the data, nor know whether you are allowed to use it, nor assess the impact of an upstream change on downstream uses. > Related read: [Data governance in digital transformation](https://www.adservio.fr/en/insights/articles/gouvernance-des-donnees-transformation-digitale): Components, obstacles and implementation steps for data governance: what makes a figure accurate, traceable and safe to use. ## The open lakehouse: table formats and interoperable catalogs The structuring principle of recent architectures is the separation between storage and compute engines. Apache Iceberg has established itself as the standard table format of this model: its version 1.11, released in May 2026, and the V3 specification, now supported in production by the major players, bring ACID transactions, schema evolution and time travel directly onto object storage. Snowflake, Databricks, AWS, Google and Microsoft all read and write the format: data is no longer captive to any single engine. ### The REST catalog, the key to interoperability What holds it all together is the Iceberg REST catalog: a standard interface that lets Spark write a table, a SQL engine serve it, DuckDB explore it and an AI agent query it, on a single copy of the data, with a single governance model. Open source implementations such as Apache Polaris, which became a top-level Apache project in February 2026, make this neutrality concrete. For the architect, the consequence is direct: choosing an open format and catalog is no longer an activist bet, it is the path that preserves the freedom to evolve engines, analytics, streaming, AI, without migrating the data. The open lakehouse also unifies real time and batch: event streams from Kafka and streaming platforms land directly in Iceberg tables, queryable both by analytical workloads and by real-time engines. The historical boundary between the data warehouse, the lake and the streaming platform fades in favour of a continuum built on the same storage and the same governance model. > Related read: [The five data modernization strategies for business success](https://www.adservio.fr/en/insights/articles/les-cinq-strategies-de-modernisation-des-donnees): Five concrete strategies to align data with business goals, modernize without a big-bang rebuild, and turn data into a lasting competitive advantage. ## Interfaces fit for every use, from SQL to AI agents Each profile needs an interface suited to its role: SQL for analysts and engineers, notebooks and Python for data scientists, APIs for applications, self-service BI tools for business users. This usage-driven accessibility directly increases the value of the asset that data represents, data that is inaccessible in its format of use is data that does not exist. ### AI agents, the platform's new consumers A new category of consumers has arrived: AI assistants and agents, which query the platform in natural language through protocols such as MCP or text-to-SQL interfaces. For their answers to be correct, they must rely on a semantic layer, metric definitions, relationships, descriptions, rather than raw tables, and inherit the same access policies as the human users they serve. Data architecture thus becomes the reliability foundation of enterprise AI. This diversity of interfaces must not fragment the truth: whatever the entry point, SQL, BI, API or agent, all consumers must end up on the same governed tables and the same metric definitions. That is precisely what distinguishes a coherent platform from an archipelago of juxtaposed tools. ## Reducing copies and data movement Every copy of data adds storage and synchronisation costs, multiplies the risk of inconsistency between versions and widens the exposure surface in the event of a security incident. Minimising copies and movement therefore remains a cardinal principle: the less data circulates needlessly, the more the organisation gains in agility, compliance and trust in its numbers. ### Zero-copy sharing and federation Modern mechanisms make this principle practical: zero-copy sharing grants a partner or another team governed access to a table without duplicating it, and federated query engines interrogate several sources without moving them. The open table format amplifies the effect: where each engine used to demand its own copy of the data, all of them now work on the same Iceberg table. Replication pipelines still exist, but as a deliberate choice, latency, resilience, rather than a technical inevitability. This principle also has a direct economic dimension: data egress fees between clouds and synchronisation pipelines often account for a significant share of the data budget. Every copy avoided is a recurring cost removed, and one less compliance risk when the data concerned is personal or regulated. ## Curation, data contracts and a common vocabulary Data curation, producing, organising and managing datasets, prevents the disappointment of users faced with unusable raw information. It means cleaning data, modelling relationships and standardising dimensions and metrics; it also helps to master volumes that quickly become overwhelming and to ensure regulatory compliance, from GDPR to the AI Act for datasets that feed models. ### Data contracts to make exchanges reliable The industrialised version of this curation is the data contract: a versioned agreement between producer and consumers specifying schema, semantics, freshness and quality thresholds, verified automatically in the pipelines. Coupled with data observability, detecting drifts in volume, schema or distribution, these contracts turn fragile flows into reliable data products, with an identified owner and explicit commitments. Quality is measured continuously rather than discovered through incidents: completeness, uniqueness, validity and freshness are tracked as data SLOs, with alerts addressed to the owner of the product concerned. Mature teams publish these scores in their catalog, turning trust in data into verifiable information rather than reputation. Finally, a common vocabulary is essential: standardised terminology across departments, carried by a semantic layer where each key indicator is defined once, guarantees that marketing's "revenue" is the same as finance's. This shared foundation limits analytical disputes, smooths collaboration, and directly conditions the accuracy of AI assistants' answers. > Related read: [Data mesh: principles and benefits of a decentralised data architecture](https://www.adservio.fr/en/insights/articles/data-mesh-principes-et-benefices): Data mesh: four founding principles, data contracts, federated governance and a self-serve platform to decentralise data towards business domains at scale. ## The Adservio approach: an architecture built to last At Adservio, we design data architecture as a living system, built to last: open formats to preserve reversibility, elastic scaling, high availability, end-to-end security of data in transit and at rest, and continuous optimisation of cost and performance. Each principle is weighed against real business uses, analytics, real time, AI, never in the abstract. Our conviction: a solid architecture is planned before it is deployed. We support your teams in this upstream thinking, then in setting up a shareable, governed and curated platform that they keep control of, to draw lasting value from it. In practice, our engagements start with an assessment of the existing landscape, flows, copies, pain points, costs, followed by the definition of a target architecture based on open formats, then an incremental migration trajectory in which each step delivers measurable value. Modernising a data architecture is a programme steered over time, not a big bang. ## FAQ ### What is data architecture? It is the design, structuring, management and security of the data infrastructure, with the aim of extracting value from it, for analytics as well as AI systems. Modern approaches favour flexibility, scalability, open formats and proactive design. ### Why has Apache Iceberg become the standard table format? Because it brings ACID transactions, schema evolution and time travel directly onto object storage, and every major engine, Snowflake, Databricks, AWS, Google, Microsoft, reads and writes it: data stays on a single copy, with no vendor lock-in. ### Why should copies and data movement be limited? Because every transfer adds costs, multiplies the risk of inconsistency and widens the exposure surface. Zero-copy sharing and query federation now make it possible to grant access without duplicating the data. ### What is a data contract? A versioned agreement between the producer of a dataset and its consumers, specifying schema, semantics, freshness and quality thresholds, with compliance verified automatically in the pipelines. It turns fragile flows into reliable data products. ### How do you reconcile self-service and access control? By applying policies as close as possible to raw data, role-based and attribute-based control, dynamic masking, row-level filtering, and by federating governance: global standards, enforced by the domains that own their data.