Data Architecture - Designing Company-Wide Data as Strategic

About this article

As the third installment of the “Enterprise Architecture” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains EA-perspective Data Architecture (DA).

While the Data Architecture chapter (40 series) handled “implementation of individual systems,” this article handles “cross-enterprise consistency.” For example, “centralizing the customer master” is this article, “which DB to place it on” is the 40 series’s job. This article covers MDM, data governance, company-wide data flow, and CDO / data steward roles - explained for CDO / data-department-head.

What is EA-perspective Data Architecture in the first place

Imagine a library’s classification system. If each branch organized its books using its own classification scheme, no one could instantly answer “which branch has this book?” Only with a shared classification and search system across all branches can someone at any branch find the book they need.

EA-perspective Data Architecture (DA) is the discipline of systematically organizing the entire enterprise’s data assets. While the individual-system DB design (40 series) handles “that operation’s data,” EA-DA draws a company-wide map of “which data exists where and how it flows.”

Without DA, the same customer data exists in different formats across departments, making company-wide analytics and AI utilization impossible.

Why DA is needed — the company where “this month’s revenue” differs by department

The 2nd EA layer (DA) systematically designs the company’s data assets. Different in viewpoint from the “DB selection / data foundation” handled in the data-architecture chapter, the goal is organizing at company level the types, relationships, flows, and owners of data the whole org handles.

While individual-system data architecture handles “data for running that operation,” EA’s data architecture handles all data as the company’s strategic asset. Draw on a single company-wide picture which system holds which data, where the original is, and where it flows.

Individual DB design = tactic, EA’s DA = strategy. Viewpoint one rank higher.

It integrates data that has gone into silos. When departments hold data in different systems, you reach the state of the same customer registered with 3 IDs. Need to organize data from company-wide viewpoint.

It is the foundation for data-driven management. To use company-wide data for management decisions, a map of where what is is needed. Companies without DA frequently see “numbers don’t match” problems in management meetings.

In management meetings, “this month’s revenue” from finance and “this month’s revenue” from sales differ by nearly 5%, with debates starting from there every month - reported scenarios. Tracing causes, returns / discounts / consumption tax / accounting timing are subtly different per department, with everyone’s numbers correct by their department’s definition. A typical example showing more serious than data itself is not aligning word definitions company-wide.

It is what makes regulatory and privacy compliance possible. For GDPR and Personal Information Protection Act compliance, a personal-info location map is required. DA setup is the premise of audit response.

Main DA components

EA’s data architecture captures company-wide data from multiple viewpoints. Beyond mere ER diagrams, it includes all viewpoints of strategy / operations / technology.

The conceptual data model is where it starts.

What draws major entities handled company-wide is the conceptual data model. “Customer / product / order / employee / partner” - express the core “things” of corporate activity in about 10-30 items. Granularity understandable by business departments matters.

[Customer] -- purchase -- [Product]
   |                          |
   |                          |
   +-- delivery to --[Address]-- inventory -- [Warehouse]

The iron rule for conceptual models is drawing in business language. Write “customer” not “user_account” - making it the common language of business and tech.

Data domains are how that model is divided up and owned.

Areas grouping related data are data domains. “Customer domain” / “product domain” / “finance domain” - splitting by business function and placing data owners on each is the modern approach.

In Data Mesh thinking, domains hold data ownership and responsibility, providing high-quality data complete within domain to other domains.

Master Data Management (MDM)

The mechanism centrally managing core data company-wide. With master data like “customer ID,” “product code,” and “partner code” differing per department, company-wide analysis becomes impossible. MDM creates the single source of truth.

Realistically, Coexistence is more often chosen - the realistic method of phased consistency without breaking existing systems.

The reason Coexistence is chosen over others is clear. Centralized is ideal but the migration cost of stopping existing core / CRM / ERP and consolidating into a single master is huge - few companies can complete this without stopping running businesses. Consolidation is read-only so updates remain in each system, ending up with continued dual management. Registry is the light method just connecting IDs, but can’t resolve attribute-value inconsistencies (same customer, different addresses, etc.). Coexistence keeps existing system updates alive while organizing master via bidirectional sync, with the trio of not breaking existing assets, suppressing initial cost, avoiding full-integration failure risk - fitting most realistic enterprises premising phased introduction.

Data flow, catalogue and the governance regime

Visualize inter-system data movement at company-wide unit. Drawing “which system receives data from where, sends where” reveals data dependencies.

[Core system] --orders--> [Inventory mgmt]
   |                          |
   |                          v
   +--customer info--> [CRM] --analysis--> [DWH]
                         |                    |
                         v                    v
                   [Email delivery]        [BI]

With diagrams at this level, “what’s the impact range when a system stops” is visible at a glance. Directly connects to incident response too.

The enterprise data catalogue is the index on top of that flow.

The data catalog handled in the data-architecture chapter, deployed company-wide at EA level. Centrally manages data metadata, owners, and usage, realizing Google Search for data.

Integration of departmental catalogs is the EA-level challenge, requiring devices to integrate disparate catalogs.

A governance regime is what keeps the catalogue alive.

The org regime managing company-wide data. Beyond technology, role and authority design matters - establishing a data governance committee is general.

Establishing CDO is a trend since 2015, a required position at companies treating data as management asset.

Where the data physically sits is the next question.

Modern EA’s DA is designed premising cloud DWH, data lake, and lakehouse. The design paradigm has shifted from “aggregating internal DBs” to “integrated data foundation in cloud.”

Redrawing EA’s DA premising cloud is becoming the work of 2020s enterprise architects.

Security and privacy constrain all of it.

EA’s DA also includes data-confidentiality classification. Govern who handles which data how via labeling of “public / internal / confidential / top secret.”

A personal-info location map (PII Inventory, the catalog of Personally Identifiable Information) is a required output for GDPR compliance, uncreatable without EA’s DA in place.

The level of investment shifts with scale and strategy

The more companies utilize data as management asset, the more important EA’s DA. For companies seeing data only as operational logs, detailed DA is excessive.

The second axis is organisational scale and complexity.

The more complex the org, the higher DA-setup cost - but investment-effect ratio also larger. The needed DA depth differs between single-product small enterprises and diversified large enterprises.

By case, the emphasis lands like this.

A startup with a single line of business. Conceptual model + BigQuery / Snowflake + dbt. Dedicated CDO unneeded, engineering manager concurrent. Data catalog enough with dbt docs, master integration starts when needed.

A mid-size enterprise running management on BI. Domain split + DataHub / Alation + data-steward placement. Split into 3-5 domains, place concurrent stewards on each. MDM with Coexistence for phased integration, deliver to decision-makers via BI tools (Tableau / Looker).

A large enterprise with diversified businesses. Establish CDO + Collibra / Informatica + dedicated MDM team. Place data-governance committee directly under management, standing M&A-response master-integration projects. Manage region-based / regulation-based DA in ArchiMate, auto-generate PII Inventory for GDPR / Personal Information Protection Act.

A company where the data is the product — advertising, finance, SaaS. Data Mesh + semantic layer (dbt semantic layer / Cube.js) + AI Ready design. Domains productize data and provide to other departments / customers, with AI agents autonomously querying via semantic layer. Attach freshness / quality SLAs to all data.

A phased practical matrix for MDM integration

MDM breaks down aiming for “perfect centralization,” so phased integration not breaking existing systems is the realistic answer.

Practical lower bound for MDM investment is mid-size enterprise and up. At startup / small SaaS, MDM is excessive - PostgreSQL master tables + common ID-naming conventions is enough. Uber’s 2014 “dashboard wars” (the same “weekly rides” coexisting in 3-5 versions, CEO and field numbers diverging) is the typical case showing the necessity of central MDM.

MDM goes phased integration via Coexistence. Aiming for perfect centralization always fails.

AI decision axes — Design data in vocabulary the AI can understand

Semantic layers make AI’s data understanding accurate

When business-term calculation definitions are codified in a dbt semantic layer or Cube.js — like “revenue = sum of amount in orders table (excluding returns)” — AI generates accurate SQL when asked “what’s this month’s revenue.” Without a semantic layer, AI guesses the “revenue” definition and can pick the wrong table.

Data mesh and AI compatibility

Data mesh (where domain teams own data quality and publication) pairs well with AI agents that autonomously discover and fetch needed data. When each domain publishes data products via API, AI can find data via catalog and fetch via API — building autonomous workflows.

Pitfalls and forbidden moves

Here are the six most dangerous of the typical ways DA goes wrong at EA level. Every one of them causes “the same customer registered under three IDs” and “the numbers not matching in the management meeting”.

The idea that “we have database designs, so we do not need DA at EA level” is wrong as well. Individual database design and the company-wide view are different things; domain division and master consistency are work that sits outside database design.

Author’s note - “numbers don’t match” that stopped a new project

The real fear of company-wide data definitions being disparate surfaces not at incidents but at decision-making time.

A DX project of “creating a company-wide revenue dashboard” started at a mid-size retailer, and aggregating revenue data from finance / sales / e-commerce DBs revealed that the 3 numbers diverged 3-8% monthly. The cause was differences per system in “is revenue counted at order or shipping?” / “with or without consumption tax?” / “when are returns reflected?” - spending over half a year on investigation and definition agreement, the management-meeting dashboard came online 1.5 years late from start - repeatedly told as standard talking point.

Another, Uber’s 2014 “dashboard wars” is also a famous case. Uber, in rapid growth, made independent data pipelines per team, resulting in the same metric “weekly rides” coexisting in 3-5 versions on internal dashboards, with CEO numbers diverging from field numbers. Eventually Uber developed in-house Michelangelo (ML platform) and Querybuilder (semantic layer), switching to mechanisms of defining metrics company-wide once and reusing. Thereafter, the culture of “metric definitions agreed via GitHub PRs” took root inside Uber, with metric debates converted to engineering work.

Both slap home the decisive value of “aligning word definitions company-wide before technology.” At companies without EA’s DA, the moment AI agents are asked “what’s this month’s revenue?” AI returns 3 different answers.

What to decide - what is your project’s answer?

For each of the following, try to articulate your project’s answer in 1-2 sentences. Starting work with these vague always invites later questions like “why did we decide this again?”

• Conceptual data model (major 10-30 entities)
• Data-domain split (who owns what)
• Master-data strategy (integration method)
• Data catalog (tool, operation)
• Governance regime (CDO, committee)
• Data-classification policy (public / internal / confidential / top secret)
• Cloud DWH strategy (Snowflake / BigQuery etc.)

Related Articles

Summary

This article covered EA-perspective Data Architecture, including conceptual models, domains, MDM, catalog, PII Inventory, semantic layer, and AI Ready design.

Clarify ownership via domain split and data owners, MDM phased via Coexistence, data classification for privacy, hand AI vocabulary via semantic layer. That is the practical answer for EA-perspective DA in 2026.

Next time we’ll cover Application Architecture (AA) (system portfolio, integration patterns).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.