Data architecture: from accidental to intentional

October 29, 2026

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.