Designing Data Architecture: A Complete Guide to Core Components and Principles

Many people equate data architecture with database design or data‑warehouse layering, but data architecture is the bridge that translates business language into IT‑understandable structures, answering four key questions: what data exists, what it is called, how the data relate, and where and how it flows.

Data Architecture in Enterprise Architecture

Enterprise Architecture (EA) consists of Business Architecture (BA), Data Architecture (DA), Application Architecture (AA), and Technology Architecture (TA). DA connects BA’s data needs with AA and TA, acting as a bridge rather than a purely technical or purely business concern.

Four Core Components of Data Architecture

The methodology defines four indispensable components:

Data Asset Catalog : a five‑level hierarchy (L1 Business Domain → L2 Topic Domain → L3 Business Object → L4 Logical Data Entity → L5 Attribute) that clarifies what data exist and who owns them.

Data Standards : rules that unify terminology, defined from business, technical, and management perspectives to eliminate language inconsistencies.

Data Model : three layers—Conceptual Data Model (CDM), Logical Data Model (LDM), and Physical Data Model (PDM)—that describe relationships and guide implementation.

Data Distribution : defines where data reside and how they move, covering Data Source, Data Flow, and Information Chain.

Data Asset Catalog Details

The catalog solves the basic problem of identifying "what data" and "who is responsible". L3 business objects are the core unit; a qualified object must be indispensable, uniquely identifiable, relatively independent with attributes, and typically represent master or transactional data.

Data Standards

Data standards address inconsistent naming across departments (e.g., "客户类型" vs. "Customer Type"). They are defined from three angles:

Business: definitions, usage, and rules.

Technical: data type, length, allowed values.

Management: responsibility for definition and maintenance.

Unified standards enable consistent application development and facilitate reuse.

Data Model Layers

Conceptual Data Model (CDM) : business‑level abstraction of entity relationships, used for communication.

Logical Data Model (LDM) : refined CDM with attributes, satisfying normalization and primary‑key identification.

Physical Data Model (PDM) : implementation‑level design for relational databases, detailing tables, fields, keys, and performance considerations.

Data Distribution

Data distribution answers "where the data are" and "how they flow". It comprises:

Data Source : the originating IT system certified as the single source.

Data Flow : CRUD processes that support root‑cause analysis of data quality.

Information Chain : end‑to‑end description of information movement across activities.

Effective distribution often requires integration tools such as FineDataLink, which can synchronize ERP/CRM data and expose standardized APIs.

Design Principles

Manage data by business object, not by field or table, to assign clear ownership.

Adopt an enterprise‑wide perspective; data standards and models must be consistent across departments.

Classify data by type (master, transactional, reporting) to enable cross‑department sharing.

Structure and digitize business objects with explicit attributes and formats.

Implement data service layers and shared APIs to avoid duplicate copies.

Four‑Step Planning Process

Plan Data Asset Catalog (L1‑L3) : define business domains, topic domains (using top‑down or bottom‑up methods), and identify business objects through five dimensions and three rounds of validation.

Define Business Terminology : standardize names for each business object to eliminate ambiguity.

Design Conceptual Data Model : relate objects across topic domains to capture business relationships.

Plan Data Sources : map objects to source systems, verify creation points, and ensure compliance with source‑selection principles.

In a recent project, FineDataLink was used to ingest ERP/CRM master data, configure incremental sync rules, and expose a unified API, dramatically improving data consistency and reducing maintenance cost.

Core Value of a Complete Data Architecture

Clarifies data assets and assigns responsibility.

Unifies data language, removing misunderstandings.

Reveals data relationships, helping identify hidden business needs.

Supports data sharing and quality improvement through standardized sources and services.

Data architecture is not a one‑off project; it must evolve with business changes, continuously iterating the asset catalog, standards, model, and distribution to keep governance, quality, and integration issues under control.