Information Management

Information Management is the discipline of treating information as a shared enterprise asset—defining what it means, who owns it, and how it flows—so that data can be trusted and reused across the business rather than trapped in individual systems or departments.

Definition

Information Management, in a business architecture context, is the practice of identifying, classifying, and governing the information that an enterprise needs to operate—independent of the applications, databases, or teams that happen to produce or consume it. It answers questions like: What are the core information concepts our business runs on (Customer, Product, Contract, Claim, Order)? Who is accountable for defining and maintaining each one? And where does authoritative information live versus where it is merely copied or referenced? Architects typically express this through an information map or conceptual data model that sits alongside the capability map and value stream map, forming one leg of the standard business architecture triad. Information Management is distinct from data management and IT data governance, though the three overlap heavily. Data management is largely technical—schemas, storage, integration pipelines, data quality tooling. Information Management is business-facing: it defines the meaning, ownership, and lifecycle of information from the perspective of the business itself, before a single database table is designed. A well-formed information architecture is technology-agnostic; it should remain valid whether the underlying systems are on-premises legacy platforms or modern cloud SaaS. Critically, Information Management also draws the boundary between information as a concept and the processes that act on it. A 'Customer' information concept doesn't change because five different value streams touch it; what changes is which capability or process is accountable for creating, updating, or retiring specific attributes of that concept at a given point in its lifecycle—something architects capture through information-to-capability or information-to-process cross-mapping (often called a CRUD matrix: Create, Read, Update, Delete).

Origin & Context

The formal treatment of Information Management as a business architecture domain traces to enterprise architecture frameworks such as Zachman (which separates the 'What'/data column from process and technology columns) and TOGAF's Architecture Development Method, where a dedicated Data Architecture phase exists alongside Business Architecture. The Business Architecture Guild's BIZBOK further codified information mapping as one of the core business architecture views, positioning it as a peer to capability and value stream mapping rather than a subset of IT data modeling.

Why It Matters

CIOs and CDOs care because fragmented, inconsistently defined information is the root cause behind failed data integration efforts, unreliable analytics, and compliance exposure under regulations like GDPR or CCPA. Business architects care because information concepts are the connective tissue between capabilities and value streams—without a shared information model, capability maps become disconnected islands that can't be cross-mapped meaningfully. M&A integration teams depend on it directly: reconciling two companies' definitions of 'Customer' or 'Product' is frequently the single largest source of delay and cost overrun in post-merger system consolidation. Getting Information Management right materially reduces redundant data stores, speeds regulatory reporting, and gives leadership confidence that a metric means the same thing in every dashboard.

Common Misconceptions

Myth: Information Management is just another name for the data model the IT team already maintains.: Reality: A logical or physical data model describes how data is structured and stored inside specific systems. Information Management operates one level above that—defining business-meaningful concepts and their relationships independent of any system, which then gets translated into multiple, sometimes divergent, physical data models across the technology estate.
Myth: If every application has good data quality, Information Management is unnecessary.: Reality: Data quality within a single system doesn't guarantee consistency across systems. An organization can have pristine data quality in its CRM and its billing system while still having two incompatible definitions of 'active customer'—a problem only an enterprise-level information architecture surfaces and resolves.
Myth: Information Management is a one-time documentation exercise for a data catalog project.: Reality: Information concepts and their ownership evolve as the business introduces new products, enters new markets, or divests business units. Mature organizations treat the information map as a living artifact, revisited whenever capabilities or value streams change materially.

Practical Example

A regional insurer's business architecture team was asked to support a new usage-based auto insurance product. The lead business architect first checked the enterprise information map and found that 'Policy' and 'Vehicle' were well-defined concepts, but no authoritative definition existed for 'Driving Behavior Event'—the telematics data the new product depended on. Working with the actuarial and claims teams, the architect defined the concept, assigned data stewardship to the Underwriting capability, and cross-mapped it to the value streams that would create, consume, and archive it: Quote-to-Bind, Policy Servicing, and Claims Adjudication. This clarified which system would be the system of record versus a downstream consumer, preventing the claims and pricing teams from building parallel, conflicting stores of the same telematics data—a costly rework the architecture team had seen occur on a prior product launch.

Industry Applications

Financial Services: Defining a single authoritative concept for 'Customer' and 'Account' across retail banking, wealth management, and lending lines to support regulatory reporting (e.g., BCBS 239) and reduce KYC/AML duplication.
Healthcare: Establishing shared definitions for 'Patient,' 'Encounter,' and 'Provider' across clinical, billing, and payer-facing systems to support interoperability standards and reduce reconciliation errors in claims processing.
Manufacturing: Harmonizing 'Product,' 'Bill of Materials,' and 'Supplier' concepts across ERP instances inherited through acquisitions, enabling consolidated supply chain visibility and procurement leverage.

Related Terms

Value Stream Map: Shows how information flows and transforms as it moves through stages delivering value to a stakeholder