Data Model

Definition

A data model is a formal representation of the information assets an organization needs to run its business, independent of any specific application, database, or technology. It defines the key entities (such as Customer, Product, Order, or Policy), the attributes that describe each entity, the relationships between entities, and the business rules and constraints that apply to them. In architecture practice, data models exist at different levels of abstraction: conceptual (business-facing, technology-agnostic, focused on shared meaning), logical (more detailed, defining attributes, keys, and relationships without regard to a specific database platform), and physical (the actual implementation in a specific database management system, with tables, columns, indexes, and storage-specific optimizations). Within business architecture, the conceptual and logical layers matter most, because they establish a shared, unambiguous vocabulary for what a "Customer" or a "Claim" actually means across the enterprise — before a single line of code or schema is written. A data model is distinct from a data dictionary (which simply lists and defines terms) and from a database schema (which is a technical implementation artifact). It is also distinct from an information architecture, which is broader and includes how information flows, is governed, and is consumed across the organization. Critically, a data model is not the same as a capability map or a process model, though the three are meant to work together. Capabilities describe what the business does, processes describe how work flows, and data models describe what information those capabilities and processes require and produce. When these three views are cross-mapped, architects can trace exactly which data entities support which capabilities — a linkage that becomes essential during systems consolidation, regulatory reporting, and M&A integration.

Origin & Context

Data modeling emerged from database theory in the 1970s, most notably through Peter Chen's entity-relationship (ER) modeling approach, which gave architects a graphical way to represent entities, attributes, and relationships. As enterprise architecture matured, frameworks such as Zachman formally separated data from function, network, and other architectural dimensions, while TOGAF's Architecture Development Method incorporates data architecture as a distinct phase. The Business Architecture Guild's BIZBOK further reinforced the practice of maintaining business-oriented (conceptual) data models separate from IT-owned logical and physical models, ensuring the business retains ownership of what its core information means.

Why It Matters

CIOs and CDOs care about data models because inconsistent definitions of core entities — what counts as an "active customer," a "closed account," or a "in-force policy" — are a leading cause of reporting errors, failed system integrations, and compliance exposure. Business architects use data models to reconcile these definitions across business units before they get baked into new systems, which materially reduces rework during ERP implementations, M&A integrations, and data migration projects. Regulatory and risk leaders rely on well-governed data models to demonstrate lineage and consistency in reporting to auditors and regulators. Ultimately, a shared data model is what allows a capability map, a value stream, and a technology landscape to actually talk to each other with precision rather than assumption.

Common Misconceptions

Myth: A data model is an IT deliverable that business architects don't need to be involved in.

Reality: The conceptual data model — the definitions of core business entities and their relationships — is a business artifact that should be owned and validated by the business, not handed down by IT. When business architects skip this step, IT teams end up encoding their own assumptions about what a "customer" or "product" means, which surfaces later as reconciliation problems and reporting inconsistencies.

Myth: A data model is the same thing as a database schema or an ER diagram in a design tool.

Reality: A database schema is a physical implementation artifact tied to a specific platform. A conceptual or logical data model is technology-agnostic and describes business meaning and relationships; it should remain stable even as the underlying databases and applications change.

Myth: Once a data model is documented, the work is done.

Reality: Data models require ongoing governance. As the business introduces new products, channels, or regulatory categories, entities and relationships evolve, and the model must be maintained and cross-mapped to capabilities and systems, or it quickly becomes stale and untrustworthy.

Practical Example

A regional insurer was consolidating three legacy policy administration systems after a series of acquisitions. Each legacy system defined "Policyholder" and "Coverage" slightly differently, which was causing discrepancies in regulatory filings. The enterprise architecture team, working alongside underwriting and claims business leads, built a conceptual data model that defined a single, agreed-upon meaning for core entities like Policy, Policyholder, Coverage, and Claim, along with their relationships and key business rules. This model was then cross-mapped to the company's capability map, clarifying which capabilities created, updated, or consumed each entity. The resulting artifact became the reference point for the data migration team building the target-state logical model, avoiding the ambiguity that had previously caused reconciliation issues between actuarial and finance reporting, and giving leadership confidence in the consolidated policy data going forward.

Industry Applications

Financial Services

Conceptual data models define consistent entities like Account, Customer, and Transaction across retail, wealth, and commercial lines, supporting regulatory reporting and reducing reconciliation effort during core banking system consolidations.

Healthcare

Data models establish shared definitions for Patient, Encounter, and Claim across clinical and payer systems, which is essential for interoperability initiatives and compliance with healthcare data exchange standards.

Manufacturing

Data models align entities such as Product, Bill of Materials, and Supplier across PLM, ERP, and supply chain systems, reducing duplication and errors during product lifecycle and supply chain digitization efforts.

Related Terms

• Value Stream Map: shows how data entities are created and transformed as value is delivered to stakeholders