Most IAM problems are architecture problems, not platform problems

The shape doesn't change, whatever you buy

Strip the vendor branding away and every enterprise IAM estate is answering the same handful of architectural questions: who or what needs access, where the authoritative record of who exists actually lives, how they authenticate and get through the front door, who governs what they're allowed to hold onto once they're in, how the highest-risk accounts get handled differently, how all of that actually reaches the applications and data it's meant to protect — and how you'd actually know if any of it went wrong.

Every major platform — the product changes which boxes get which logo on them. The relationships between the boxes don't. That's the part worth designing deliberately, because it's also the part that survives a platform migration and the part that gets much more expensive to fix once applications are already wired into it.

Where platform-first thinking breaks

A vendor's default reference architecture is built to be true for the average customer, not for your organisation's actual identity landscape — how many HR sources feed it, whether third-party and contractor access needs to be a first-class citizen or an afterthought, what already exists in the directory that has to be worked with rather than replaced. Adopt it wholesale before that mapping happens, and the gaps only surface once real applications, real role models, and real certification campaigns are built on top of it — at which point they're a rebuild, not a design decision.

It's the same reasoning behind running a structured Request for Proposal (RFP) and proof-of-concept rather than a vendor beauty contest: the shortlist should come out of the requirements workshop, not the other way round. Architecture is the same discipline one layer earlier — before there's even a shortlist to evaluate against.

Animated diagram walking through an enterprise IAM ecosystem, step by step: Identity Governance treats Authoritative Sources as ground truth and reconciles back to it; a user authenticates through Access Management; Identity Governance enforces what Access Management applies and revises it; Identity Governance grants access to Applications and Data and governs Privileged Access at the same time; Access Management, Identity Governance, and Privileged Access all feed events into SIEM/SOAR simultaneously. — Illustrative — a reference shape, not any specific client's system. Animates through each relationship in turn; the sequence carries the argument: Identity Governance supervises Access Management rather than just receiving from it, and Access Management, Identity Governance, and Privileged Access all feed the same monitoring layer.

What each layer actually has to answer

People. Not just employees — contractors, third parties, and increasingly service accounts and AI agents all need to be modelled as identities with a lifecycle, not exceptions bolted on later.
Authoritative Sources. The system of record — usually HR, sometimes more than one where a group has grown by acquisition — that Identity Governance treats as ground truth for who exists and what their status is. Get this wrong and every layer above it inherits the error.
Access Management. The front door: how someone proves who they are and what conditions govern letting them through. Gets the most vendor attention and is usually the least architecturally interesting layer — it's largely solved, off the shelf.
Identity Governance. Not a downstream consumer of Access Management — a supervisory layer that reviews and modifies what Access Management enforces, and reconciles back to the authoritative source when its record goes stale. This is where role models, certification campaigns, and segregation-of-duties controls live, and where clean directory data stops being optional.
Privileged Access. Fed by governance, but held to a different standard — the accounts here are the highest-value targets in the estate, so vaulting, rotation, and session monitoring exist as a distinct discipline rather than a variant of ordinary access.
Applications & Data. The point of the whole exercise. Every layer above exists to answer one question correctly: does this specific person or service have exactly the access this specific system requires, no more.
SIEM / SOC. Not a source of access decisions — the layer that watches everything the others do. Access Management, Identity Governance, and Privileged Access all feed it independently, so a compromised credential, a suspicious certification pattern, and a privileged session anomaly show up in the same place, correlated, rather than in three teams' separate blind spots.

Worth asking before a platform decision, not after: if you mapped your own estate onto this shape today, which connection would you struggle to draw with confidence? That's usually where the real work is, regardless of which product ends up on the licence.

Where this shows up in practice

Architecture-first thinking is what let us design a group-wide identity governance platform to replace fragmented regional systems for one retail client, rather than migrating the existing sprawl one region at a time — see the case study. It's also the reasoning behind treating directory data quality as its own discipline: a Privileged Access Management rollout that depends on a manager attribute for approval routing is really an Identity Governance problem wearing a PAM costume, and no amount of PAM configuration fixes it — see Directory Hygiene.

Key takeaways

The relationships between identity, access management, governance, privileged access, applications, and monitoring don't change with the vendor — only what's inside each box does.
A platform's default reference architecture is built for an average customer. Adopting it before mapping your own estate against it defers the real design decisions to the most expensive possible moment.
The shortlist should come out of the requirements workshop — architecture first, platform second, in that order every time.