Information Model

Definition

An information model defines the essential information concepts (sometimes called information entities or business objects) that matter to an enterprise, along with their key attributes, relationships, and business rules. It answers questions like: What do we mean by 'Customer'? How does a 'Policy' relate to a 'Claim'? Is a 'Prospect' the same concept as a 'Customer,' or something distinct that transitions into it? Critically, an information model in business architecture is conceptual and business-facing — it is not a database schema, a data dictionary, or an entity-relationship diagram built for a specific application. It exists one layer above those technical artifacts, providing the shared business vocabulary that data architects, solution architects, and system designers later translate into logical and physical data models. The information model sits alongside capabilities, value streams, and organization structure as one of the core domains of business architecture, and it cross-maps to all of them. Capabilities consume and produce information (a 'Manage Claims' capability operates on the Claim concept); value streams pass information between stages as they deliver value to a stakeholder; organizational units act as stewards of specific information concepts. Without a well-defined information model, these cross-mappings become guesswork, and different parts of the organization end up defining the same business term in incompatible ways. It's important to distinguish an information model from a data model and from a taxonomy. A data model is implementation-specific — it describes tables, fields, and keys for a particular system or data store. A taxonomy is a classification hierarchy for organizing content or terms. An information model is broader and more conceptual than either: it captures the semantics and relationships of business concepts that may be implemented across dozens of systems, each with its own data model, but all of which should trace back to the same shared definition.

Origin & Context

The information model concept has deep roots in data management disciplines, notably entity-relationship modeling pioneered by Peter Chen in the 1970s, which established the practice of modeling entities, attributes, and relationships independent of physical storage. Business architecture adopted and elevated this thinking, formalizing 'Information' as one of the core domains in the Business Architecture Guild's BIZBOK Guide, alongside Capabilities, Value Streams, and Organization. TOGAF's Data Architecture phase and the broader field of information architecture also use related concepts, though business architecture practitioners deliberately keep the information model business-conceptual rather than technical.

Why It Matters

Enterprise and business architects rely on the information model to give the organization a single, shared definition of its core business concepts — preventing the costly confusion that arises when Sales calls it a 'Customer,' Finance calls it an 'Account,' and Support calls it a 'Contact,' each with slightly different meanings. CIOs and data architects care because a weak or absent information model is a leading cause of data quality problems, duplicated master data efforts, and expensive system integration failures. During M&A integration, a clear information model lets teams quickly identify where two companies' concepts genuinely align versus where they only appear to, materially reducing integration risk. Regulatory and compliance leaders depend on it too, since accurate reporting requires confidence that terms like 'customer' or 'transaction' mean the same thing everywhere they're counted.

Common Misconceptions

Myth: An information model is just a data model with a different name.

Reality: A data model is implementation-specific, describing how a particular system or database physically stores information — tables, columns, keys, indexes. An information model is conceptual and business-facing, defining what concepts mean to the business regardless of how any one system implements them. One information concept, like 'Customer,' typically maps to many different data models across many systems.

Myth: Building an information model is the data team's job, not the business architect's.

Reality: Data architects and data modelers do the technical modeling, but business architects are responsible for establishing the conceptual, business-agreed definitions those technical models must trace back to. Without business architecture involvement, data teams end up making business definition decisions in a technical vacuum, which is exactly how inconsistent definitions proliferate.

Myth: Information models only matter for large data governance programs.

Reality: Even organizations with no formal data governance function benefit from a lightweight information model wherever capabilities and value streams are being defined, because you cannot meaningfully map what a capability produces or a value stream carries without agreed definitions of the underlying information concepts.

Practical Example

A regional insurer's business architecture team was mapping the 'Process Claims' value stream and repeatedly hit friction: the claims system, the policy administration system, and the customer service platform each used a different definition of 'Claimant.' In some systems it meant the policyholder; in others, any party filing on a policy, including third parties. The lead business architect facilitated a working session with claims operations, IT data leads, and legal to converge on a single conceptual definition of Claimant, its relationship to Policyholder and Third-Party Claimant, and the attributes each subtype required. This information model became the reference point for the data governance team's master data management effort and clarified, for the first time, which system should be the authoritative source for claimant data — eliminating a long-standing reconciliation dispute between departments.

Industry Applications

Financial Services

Defining shared concepts like Account, Product, and Party across retail banking, wealth management, and lending lines to support unified customer views and regulatory reporting.

Healthcare

Establishing consistent definitions for Patient, Provider, Encounter, and Claim across clinical, billing, and payer systems to support interoperability and accurate quality reporting.

Insurance

Clarifying core concepts such as Policy, Claim, Claimant, and Coverage so that underwriting, claims, and actuarial teams operate from the same definitions during pricing and risk analysis.

Related Terms

• Data Model: the technical, implementation-specific artifact derived from the conceptual information model