What Is Data Architecture? Clarifying Databases, Data Warehouses, Lakes, and Middle Platforms

When a company continuously builds new ERP, CRM, MES, WMS, and other systems, the amount of data grows rapidly, yet cross‑department analysis becomes increasingly difficult because systems cannot be linked, metric definitions diverge, and historical data is hard to locate.

1. What Is Data Architecture?

Data architecture describes the complete path of enterprise data from creation, flow, processing, storage, to final usage. It must answer five questions:

Where does the data originate?

How does the data enter the data platform?

Where is the data stored and processed?

How are data from different systems unified into a single metric definition?

How is the data finally delivered to reports, analytics, algorithms, and business systems?

For example, a sales order recorded in ERP must be linked with customer information from CRM, cost and payment data from finance, and possibly user‑behavior logs for churn prediction.

The typical data flow is:

Business Systems → Data Collection → Data Storage → Data Processing → Data Model → Data Service → Data Application

2. Database – Recording Business Transactions

A database’s core task is to ensure stable, accurate transaction processing (e.g., e‑commerce orders, bank transfers, inventory deductions). It focuses on write/read efficiency, transaction consistency, high concurrency, system stability, and data security. Tables such as order, product, payment, customer, and work‑order primarily capture the business operation itself, not the whole enterprise’s analytical needs.

3. Data Warehouse – Organizing Data for Analysis

A data warehouse is designed around analytical subjects rather than business processes. Its layered architecture typically follows:

ODS → Detail Layer → Public Summary Layer → Application Layer

ODS aggregates raw source data (ERP, CRM, MES) with minimal transformation to ensure stable data ingestion.

Detail Layer resolves inconsistent codes, formats, duplicates, and invalid records, creating a unified view of business facts.

Public Summary Layer builds reusable models for core entities such as customers, products, orders, and suppliers, allowing multiple analysis scenarios to share the same results.

Application Layer tailors the public models to specific business scenarios like financial analysis, sales analysis, or supply‑chain dashboards.

4. Data Lake – Storing Massive, Diverse Raw Data

Data lakes retain large‑scale, semi‑structured or unstructured data (app logs, sensor streams, JSON, media, documents, training data) before the exact usage is known. They prioritize raw data preservation and later processing based on future needs.

Key lake capabilities include metadata management, data catalog, quality control, access permissions, lifecycle management, and data lineage. Without proper governance, a lake can become a “data swamp” where data is abundant but unusable.

5. Data Middle Platform – Reusing Mature Data Capabilities

The middle platform focuses on data capability reuse rather than storage. It consolidates standard data, common models, metrics, tags, data assets, and services so that multiple business units (marketing, analytics, recommendation engines) can consume the same unified customer, product, and order data without redundant development.

Challenges include deciding which data to retain, ensuring consistent standards across departments, and integrating the reusable capabilities into downstream systems.

Conclusion

Data architecture is not about the number of tables or platforms but about enabling data to flow smoothly, be clearly understood, and be readily usable. A mature architecture makes data trustworthy, usable, and reusable – achieving the three goals of “flowable, understandable, and actionable.”