Data Architecture

Data architecture describes the structure behind an organization's information. It defines which data the organization needs, how it is modeled, where it is created and stored, how it moves between systems and which platforms support reporting, analytics and operational use. It also sets the standards that keep data consistent, such as naming conventions, formats and the choice of system of record for each type of data.

Good data architecture makes it possible to answer business questions quickly and reliably, connect new applications without building fragile workarounds and comply with regulations about how data is handled. Poor data architecture shows up as conflicting reports, duplicated data stores and expensive integration projects. For enterprise architecture and IT finance, data architecture determines how much organizations spend on storing and moving data, and how much value they get from it.

Definition of Data Architecture

Data architecture is one of the four layers of enterprise architecture, alongside business, application and technology architecture. It describes the data assets of an organization and the structures, flows and platforms used to manage them.

It works closely with data governance, which sets ownership and policies for data, and is carried out by data architects, who design models, platforms and integration patterns.

Core Components

Data models describe data at different levels of detail. A conceptual data model shows the main business entities and their relationships, while logical and physical models add attributes, rules and storage details.

Data stores include operational databases, data warehouses, data lakes and newer combined platforms. Each serves different purposes and has different costs.

Data flows describe how data moves between systems, through batch transfers, APIs, event streams or integration platforms. Data lineage records these flows so that the origin of any figure can be traced.

Standards and metadata describe definitions, formats, quality rules and ownership, usually recorded in a data catalog.

Common Architecture Patterns

Centralized patterns, such as an enterprise data warehouse, bring data into one platform managed by a central team. They offer consistency but can become bottlenecks as demand grows.

Data lake and lakehouse patterns store large volumes of raw and structured data at lower cost, supporting analytics and machine learning.

Decentralized patterns, such as data mesh, give business domains responsibility for their own data products, while data fabric uses metadata and automation to connect data across many locations. Most organizations combine several patterns.

Importance of Data Architecture in Enterprise Architecture

Data architecture makes data usable across the organization. When data is well modeled and consistently defined, teams can combine it for reporting and analytics without lengthy reconciliation.

It reduces integration costs. Clear systems of record and standard integration patterns mean new applications can connect to existing data without custom work each time. This is especially valuable during mergers and system replacements, when large volumes of data must be moved and reconciled.

It also supports compliance, since regulations require organizations to know where sensitive data is held, how it moves and who can access it.

Cost Implications

Data storage, processing and movement are significant and growing parts of technology budgets, particularly in cloud environments where they are billed by use.

Duplicated data stores, unnecessary copies and inefficient pipelines raise costs without adding value. Data architecture decisions, such as where to store data and how often to move it, have a direct effect on spending. Data transfer between cloud regions or providers can add egress fees that are easy to overlook at design time.

Linking data platforms to their costs and to the business uses they support helps architects identify savings and justify investment in better platforms.

Common Challenges

Many organizations have data spread across hundreds of systems with inconsistent definitions, built up over years without a common design.

Analytics demand often grows faster than central data teams can serve it, leading business units to create their own data stores and copies. These copies then drift out of step with the source, creating the conflicting figures that data architecture is meant to prevent.

Changing data architecture is slow and costly, because so many applications and reports depend on existing structures. Incremental change, guided by a clear target, is usually more practical than wholesale redesign.