Clara Jiménez Arias

The data architecture nobody designed Every company has a data architecture, even if nobody designed it. It lives in the integrations each project created in a hurry, in the spreadsheets that stand in for reports whose figures do not reconcile and in customer records duplicated across multiple systems. The question is whether that architecture reflects a strategy or has been left to chance. For years, that accidental architecture was a cost businesses could absorb. Today, it is no longer sustainable. Artificial Intelligence is only as reliable as the data that feeds it, and regulations such as the GDPR, the AI Act or the Data Act reinforce the need to understand the origin, processing and use of data. The most widely adopted reference framework for data management, DAMA-DMBOK, defines data architecture as the bridge between business strategy and technology implementation. This article covers the five steps needed to build that bridge: principles, the current-state map, the target architecture, data flows and integrations, and the roadmap. Every company has a data architecture, even if nobody designed it. Data architecture principles An accidental architecture is the sum of many reasonable decisions made without a common set of criteria. Principles provide those criteria: a small set of rules, written in business language, that help guide decisions when two projects have different requirements or when a quick solution creates long-term constraints. They do not specify which technology to use, but what any technology selected must ensure. The essentials can be summarised in three commitments. Figure 1. Architecture principles grouped into three commitments. Data belongs to the business It does not belong to the project that creates it or the area that uses it most. Each domain has an owner who is accountable for its definition and quality, and each master data entity has a single authoritative source from which any copies are synchronised. This directly addresses data silos and multiple versions of the same customer. Data must be trustworthy Trust is not declared: it is built. Each term has the same meaning across the company thanks to a shared data model and glossary. Data quality is controlled at source, rather than corrected downstream. Data lineage is documented so that any figure can be traced back to its origin. And each person accesses only what they need, following the principle of least privilege and in accordance with the GDPR. The architecture evolves in a controlled way Every data asset has a defined lifecycle, from capture through to archiving or deletion, with clear retention periods that reduce both cost and legal risk. Technology is selected according to the data zone and use case, as part of an agreed plan rather than because it is the latest trend. ■ A principle is useful only if it changes decisions. That is why these principles should be approved by the relevant Data Governance body and used as decision criteria in every architecture review: a proposal that departs from one of them is not automatically rejected, but the exception must be justified. Reviewing them periodically prevents them from becoming merely a statement of intent. Common principles prevent isolated decisions about data. Mapping the current data architecture The current-state map answers a simple question: what data do we have today, where is it held, how does it move and what level of quality does it have? Without this map, any target architecture is guesswork. It is built by bringing together existing documentation, validating it with the teams that know and use each system, and completing it through automated metadata extraction. It is best to start with data that is critical to the business and to regulatory compliance. At a minimum, the map should cover five elements, summarised in Figure 2. Figure 2. How the current-state map is built and what it produces The same symptoms almost always emerge: ■ The outcome is not simply an inventory, but a prioritised list of gaps that feeds into the roadmap. To design the future, you first need to understand the data you have today. Target data architecture The target architecture is a layered platform with cross-cutting data governance, in which every data asset has an authoritative source and every consumer accesses validated data. It describes capabilities rather than products: technology is selected afterwards and should be able to change without forcing a redesign of the architecture. Figure 3. Conceptual reference architecture: ingestion, refinement, consumption and governance Data enters through a controlled ingestion process, is refined from one zone to the next and is made available for consumption once certified. The zones are the key building blocks: Landing (bronze): data as it arrives, with one schema per source system. Transformation and master data (silver): cleansed, integrated and unified data held in a master record (golden record), with one schema per domain. Aggregations and data marts (gold): consumption-ready models, with one schema per use case. Sandboxes: a flexible space for data science, never accessible to applications. This is the structure of a governed data lake, or lakehouse, combining the flexibility of a data lake with the control of a traditional data warehouse. Within this framework, each company decides how much to centralise: a central platform works well when there are relatively few domains, while a data mesh, in which each domain publishes its data as products, is better suited to large, mature organisations. Many organisations start with the former and evolve towards the latter. ■ The blueprint for all of this is the enterprise data model: a conceptual view of the key entities and rules that is translated into logical and physical models, as well as dimensional models for analytics. All of these are maintained in a version-controlled repository that serves as the authoritative record of approved changes. The architecture defines the capabilities; the technology comes afterwards. Data flows and integrations Data flows define how data moves from its source to where it is used, with what latency and under which controls. The practical rule is to choose the latency the business needs, not the lowest latency the technology can deliver. But the most important decision is not the technology; it is the topology. When every system connects directly to every other system, the number of interfaces grows quadratically: with 10 systems, as many as 45 connections may be required; with a hub, only 10 are needed. Figure 4. Point-to-point integration versus a hub, with six systems ■ A hub works best with a canonical model, a common format for each entity, and with data contracts: versioned agreements between producer and consumer covering schema, quality and service levels. To understand what is happening at any point in the flow, data flows are documented using a CRUD matrix, which shows which process creates, reads, updates or deletes each entity, together with automatically captured data lineage that makes it possible to trace any figure back to its source. Latency should be driven by business needs. A roadmap for evolving the data architecture The roadmap turns the gap between the current-state map and the target architecture into a phased plan, delivering value at each stage. It is typically designed around a three- to five-year horizon, starting with foundational data that other data depends on, such as master data. Figure 5. Illustrative roadmap: four phases and three control milestones Four criteria should guide prioritisation: dependencies first, measurable business value, regulatory risk and at least one visible deliverable per quarter. Migration is incremental: the new environment coexists with the legacy environment until it is ready to replace it. Progress can be measured using a small number of well-chosen indicators: the percentage of critical data with an assigned owner, data catalogue and lineage coverage, the quality score for critical data, the number of point-to-point integrations retired, and the number of days required to make data available for a new use case. ■ None of this works without executive sponsorship, cross-functional business and technology teams, and a committee that reviews the plan every quarter. The architecture evolves in phases, delivering value at each one. Conclusion Good data architecture is not measured by the technology chosen, but by the company's ability to trust its data and adapt without having to rebuild everything. That is the difference between an architecture that holds the business back and one that enables it to move forward: with the former, every new project begins by searching for data, reconciling figures and negotiating integrations; with the latter, it begins directly with the business question. And this is not achieved in a single step: the five steps in this article form a cycle, and every roadmap review begins by updating the current-state map and checking that the principles remain valid. And the time to start is now. Artificial Intelligence is multiplying the value of well-governed data and, at the same time, the cost of data that is not properly governed: a model fed with data of uncertain provenance inherits all of its flaws and amplifies them at scale. Companies that design their data architecture today are building the foundation on which they will compete tomorrow. Ultimately, every business has a data architecture. The only real decision is whether to leave it to chance or design it deliberately. Good data architecture turns data into a reliable foundation for the business. ______ Reference: DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition. Technics Publications, 2017. AI & Data Data Governance as the hub connecting every discipline September 24, 2026

Data lakes promise flexibility at scale, but without governance controls the lake becomes an unusable data swamp. In this article, we explore the challenges organisations face and a range of solutions that can help pave the way to success. The three major challenges of managing data without governance: data discovery, trust, and duplication. The challenge Why data quality and governance matter more than ever The low cost of cloud storage has made data ingestion significantly easier. However, this creates a paradox: storing information is now easier than organising, validating or deleting it. As a result, datasets accumulate without a clear owner, with inconsistent structures and lacking metadata. This leads to: Loss of productivity: analysts spend up to 40% of their time validating data before they can use it. Regulatory risk: data without traceability or retention controls complicates audits and legal obligations. Hidden costs: queries on poorly organised data drive up compute costs and make expenditure difficult to predict. Duplication of effort: without confidence in available data, teams rebuild processes and create uncontrolled copies. Governance Governed data, smarter decisions. The control plane of the data lake Data governance is not a documentation layer. It is the control plane that defines who can ingest data, modify schemas, grant access and manage the data lifecycle. Without this control plane, a data lake inevitably tends to become a data swamp. Mandatory data ingestion contract The most effective way to prevent chaos is to require every ingestion process to comply with a minimum contract. When this contract is optional, the data lake quickly becomes a repository with no traceability or context. Distributed accountability model Centralising responsibility within the platform team creates bottlenecks and weakens accountability. Source system: defines and ensures data quality rules at source. Platform team: technically enforces governance policies. Domain owners: oversee semantic consistency within their area. Ingestion owners: implement validation controls at the point of entry. Data quality Data quality is your most valuable asset. Six dimensions that must be measured, not assumed Quality is not a binary condition. It is a multidimensional concept with objective criteria, acceptable thresholds and metrics for continuous monitoring. Quality gates at ingestion Quality must be assured at the point of entry into the data lake. Post-ingestion validation alone is not enough to prevent errors from spreading. Schema validation: data types, mandatory fields and constraints. Referential integrity checks against related systems. Detection of duplicates and management of late-arriving data. Automated monitoring with alerts when thresholds are breached. Invalid records are quarantined — they are never silently discarded. Metadata The DNA of data. The operational index of the data lake Metadata is not optional documentation; it is an essential operational index that reduces discovery times and prevents duplication of effort. But what exactly is metadata? Metadata provides the descriptive framework that enables an organisation to understand what data it owns, how it originates, where it resides and what it means to the business. It includes information about technical and business processes, rules and constraints, as well as both logical and physical data structures. This knowledge spans three areas: The data itself: databases, elements, models and schemas. The concepts they represent: business processes, systems, code and infrastructure. The connections between them: relationships, dependencies and flows. — There are three types of metadata (TON):      Technical: Where is the data stored?      Organisational / Operational: Who generates the data?      Business: How is the data classified? Metadata is the invisible thread that connects technical data to its business meaning: without it, we only see the tip of the iceberg. Organisational value Integrated management of these three types of metadata enables: Traceability from data origin through to consumption Governance based on clear responsibilities Interoperability across systems and teams Trust in the quality and meaning of information — Without metadata, data is simply volume without context.     With metadata, it becomes a strategic asset that can be understood and governed. Lifecycle The alpha and omega of data. Retention is not infinite Many data lakes are designed on the assumption of indefinite retention, which is unsustainable due to regulatory requirements and storage costs. Every dataset requires a retention class with a clearly defined outcome: Deletion: scheduled removal once the defined retention period has expired. Archiving: immutable cold storage with an auditable chain of custody. Legal hold: suspension of all actions while a legal or regulatory obligation remains in force. — The system must be able to demonstrate at any time:      What data existed.      Who accessed it.      Why it was deleted or retained.      Without this, any audit or e-discovery exercise becomes a manual process with high levels of risk. Security Security, the non-negotiable asset. Least privilege by design The concentration of data within a lake increases the attractiveness of privileged access. Access control must be derived from data classification, not its location. Policy-based: access rules are derived from data classification and purpose, not from manually maintained user lists. Just-in-time: elevated privileges are granted temporarily, with justification and full traceability. Segregation of administrative privileges: no single role has unrestricted access to all data. Centralised auditing: consolidated records of who accessed what, when and in what context. Diagnosis Analysis is key. Symptoms and root causes Five different symptoms, one underlying cause: the lack of data governance carries an operational cost that is paid every day. Recommendations Practical solutions for every company. Practical actions Implement ingestion contracts before scaling: do not onboard new domains unless metadata capture and quality validation are mandatory. Define data owners: the platform enables, but responsibility for accuracy rests with the business. Automate quality gates: manual validation does not scale. Controls must be integrated into ingestion processes from day one. Make retention policies executable: the system should automatically archive or delete data when retention policies expire. Monitor cost by workload: separate exploratory computing from production analytics to avoid budget overruns. Integrate security with data classification: access controls should be driven by information sensitivity, not by physical location. Conclusion The data lake is not an option; it is a necessary evolution. An evolution that must embrace data governance without compromise, not only to understand what data exists and where it resides, but also to take a significant step forward in data utilisation and Artificial Intelligence. Governance + intelligence = success Where, Governance: data governance ensures consistency, quality, traceability and trust, establishing the rules that underpin and strengthen the entire data ecosystem. Intelligence: Artificial Intelligence interprets data, learns from it and creates value from it, unlocking its full potential while relying on trusted and reliable foundations.   AUTHORS Héctor García Data governance specialist Clara Jiménez Data governance specialist * * * AI & Data From suspicion to trust: the real journey to better Data Governance May 20, 2025