Identity Management

Definition

In business architecture, Identity Management is a core capability found in nearly every capability map, regardless of industry. It answers a deceptively simple question — "who is this, really?" — and governs the full lifecycle of that answer: creation of an identity record, verification and proofing, ongoing maintenance as attributes change, linking of related identities (a customer who is also an employee, a device tied to a user), and eventual deprovisioning or archival. As a capability, it is defined independently of any specific system or technology; it describes what the business must be able to do, not how a particular directory service or customer master does it. This distinguishes Identity Management from Identity and Access Management (IAM) as commonly used in IT and security circles. IAM is typically the technical implementation — directories, single sign-on, provisioning tools, credential stores — that enables the business capability. Business architects care about Identity Management because it sits upstream of dozens of value streams: onboarding a customer, hiring an employee, registering a device, verifying a counterparty for a transaction. Get the capability definition wrong — too narrow, too tool-specific, duplicated across business units — and every downstream process inherits the fragmentation. Identity Management also has firm boundaries. It is not the same as Access Management, which governs entitlements and permissions once identity is established, and it is not the same as Customer Relationship Management, which uses identity but focuses on engagement and relationship history. Business architects typically decompose Identity Management into sub-capabilities such as identity verification, identity lifecycle management, identity federation, and identity data governance — each of which can be cross-mapped to value streams, org units, and supporting applications.

Origin & Context

The concept traces to the discipline's broader treatment of "party" and "who" concerns, echoed in the Zachman Framework's dedicated "Who" column and formalized in the Business Architecture Guild's BIZBOK as a recurring capability across industry reference maps. It gained heightened prominence as regulatory regimes like KYC/AML in banking and HIPAA in healthcare forced organizations to treat identity verification as a governed business capability rather than a purely technical concern. TOGAF's security architecture domain reinforced the need to separate business-level identity intent from technical IAM implementation.

Why It Matters

CIOs and CISOs care because fragmented identity capabilities are a leading source of security exposure, duplicate customer records, and failed regulatory audits. Business architects care because Identity Management typically appears in dozens of value streams — onboarding, underwriting, care delivery, procurement — so a poorly defined capability creates redundant investment across business units solving the same problem differently. Getting it right materially shortens M&A integration timelines, since consolidating identity is almost always a prerequisite for merging any other system or process. Regulators and auditors also care directly, since verifiable identity lineage is foundational to compliance in financial services, healthcare, and government.

Common Misconceptions

Myth: Identity Management is just another name for IAM software (directories, SSO, provisioning tools).

Reality: IAM tools are the technical implementation of the capability, not the capability itself. A business architecture view defines the policies, data ownership, and lifecycle rules that any IAM tool must support — which is why the capability should be modeled and governed independently of vendor selection.

Myth: Identity Management only concerns employee accounts and system logins.

Reality: The capability spans every party type the business must uniquely recognize — customers, prospects, partners, legal entities, devices, and increasingly non-human actors like bots and APIs. Scoping it as an HR or IT-only concern is a common source of duplicated capability investment.

Myth: Identity Management is a one-time onboarding event.

Reality: It is a continuous lifecycle capability covering verification, change management (name, role, ownership changes), federation across systems, and deprovisioning. Organizations that treat it as a point-in-time task typically accumulate stale, duplicate, or orphaned identity records that undermine data quality and compliance.

Practical Example

During a bank merger, the lead business architect was tasked with rationalizing overlapping capability maps from both entities. Cross-mapping revealed that each bank had its own Identity Management capability, each supported by a different customer master and separate KYC verification workflow, with inconsistent data ownership between compliance and retail banking. The business architect worked with the security architect and compliance lead to define a single, shared Identity Management capability definition — covering verification, lifecycle, and federation — before any system consolidation decisions were made. This capability-first approach let the integration team make an informed build-versus-consolidate decision on the underlying identity systems, avoided replicating both legacy platforms indefinitely, and gave compliance a single defensible source of truth for regulatory reporting during the transition period.

Industry Applications

Financial Services

Underpins KYC/AML capabilities, requiring verified, auditable identity records for customers and counterparties before onboarding or transacting.

Healthcare

Supports patient identity matching across care settings and provider credentialing, where duplicate or mismatched records directly affect patient safety and reimbursement accuracy.

Government / Public Sector

Forms the foundation of digital citizen services, enabling secure, unique recognition of residents across benefits, licensing, and tax agencies.