Identity Governance Reference Architecture

The problem

Enterprise applications accumulate access administration independently — each with its own request process, its own notion of roles, and its own (often manual) review cadence. Nobody has a consistent, current answer to “who has access to what, and why is that still appropriate.” That gap is what IGA platforms exist to close, but the platform is only one layer of the answer. This is the reference architecture I use to think about IGA as a system, and it’s informed as much by leading an enterprise IGA platform RFP — evaluating SailPoint IdentityIQ, Saviynt, and Oracle IDM against a real requirements set — as by building on Oracle Identity Manager directly.

Architecture overview

flowchart TB
subgraph Sources["Identity Sources"]
  HR[HR System]
  Directory[Directory Services]
end
subgraph Core["IGA Core"]
  Warehouse[Identity Warehouse]
  Catalog[Entitlement Catalog & Role Model]
  Policy[Policy / SoD Rule Engine]
end
subgraph Connectivity["Connectivity Layer"]
  Direct[Direct Connectors — AD, JDBC]
  WebSvc[Web Service Connectors]
  Manual[Disconnected Apps — Manual Fulfillment]
end
subgraph Governance["Governance Processes"]
  Certify[Access Certification Campaigns]
  Requests[Access Request & Approval]
  SoD[SoD Conflict Analysis]
end
Sources --> Core
Core --> Connectivity
Core --> Governance
Connectivity --> Targets[Target Applications]
Governance --> Audit[Audit & Compliance Reporting]

Identity sources feed a central warehouse. The entitlement catalog and role model give that raw access data business meaning — mapping technical permissions to roles a business owner can actually reason about. A policy engine evaluates SoD rules against assigned access. The connectivity layer executes provisioning against target systems, using direct connectors where possible and a manual, SLA-tracked process where not. Governance processes — certification campaigns, access requests, SoD analysis — run against the warehouse and catalog, not against each application individually, which is what makes them consistent and auditable.

Major components

• Identity warehouse — the aggregated, current view of every identity and its access, built from authoritative sources and connector reconciliation.
• Entitlement catalog & role model — technical entitlements grouped and named in business terms; role granularity is a deliberate design choice (see below).
• Policy / SoD rule engine — evaluates toxic-combination rules (e.g., “cannot both create and approve a payment”) against current access.
• Connector framework — direct integrations (AD, JDBC) plus a defined path for applications that can’t be integrated directly.
• Certification & access request engines — the governance processes that actually run on top of the warehouse and catalog.
• Audit & compliance reporting — evidence generation for SOX, GDPR, and internal audit, sourced from the warehouse rather than assembled manually per review cycle.

Design decisions

• Centralize the entitlement catalog rather than leaving it per-application. A shared catalog is what makes cross-application SoD analysis and consistent certifications possible; without it, governance stays fragmented no matter what platform sits on top.
• Coarse birthright roles, governed exceptions. A small set of department/title-based roles covers the common case; anything beyond that goes through a request and approval, which keeps the role model maintainable as the organization changes.
• Risk-tiered certification cadence over a single blanket schedule. Privileged and high-risk access gets reviewed more frequently than standard access — a design decision that affects reviewer engagement more than any platform feature does.
• Platform evaluation criteria weighted toward integration coverage and data model fit, not feature checklists. In the RFP process, the differentiator between SailPoint IdentityIQ, Saviynt, and Oracle IDM was less about any single capability and more about how well each platform’s data model and connector framework matched the existing application landscape and identity data quality.

Implementation considerations

• Application onboarding sequencing. Applications should be classified by integration complexity, business criticality, and risk before sequencing them onto the platform — high-risk, low-complexity applications first, to build confidence before tackling harder integrations.
• Data quality precedes governance value. Certifications and SoD analysis are only as trustworthy as the underlying identity and entitlement data; platform rollout plans need a data quality workstream, not just a technical integration workstream.
• Change management for reviewers and app owners. A more capable governance process changes what’s asked of business reviewers (more frequent, more contextualized reviews); adoption planning matters as much as the technical build.

Lessons learned

Running the platform evaluation taught me that architecture decisions — how the catalog is structured, how roles are modeled, how certification cadence is tiered — determine whether governance actually works, more than which vendor’s platform sits underneath. A well-modeled IGA program on a modest platform outperforms a poorly-modeled one on a more capable platform.