What if we stopped manufacturing roles?
On most of the IGA programmes we have led since the post-Covid period, the question is no longer how many roles to build. It is what the organisation is already producing on its own, and where human attention actually deserves to be spent.
A programme that begins with a catalogue to write
A client calls one morning to launch an IGA programme. The request is almost programmatic. "We need to define all our business roles." The environment is large: tens of thousands of identities, hundreds of applications, several Active Directory forests, an Entra ID tenant in consolidation, several populations, thousands of entitlements spread across the estate. The sponsor is convinced that the first step is to write the exhaustive catalogue of roles that will describe every possible situation.
We start the workshops with the business units. The conversation opens on a handful of simple roles. Then each discussion produces its own edge cases. One role becomes two. Two become five. Five become twenty. Each exception, brought up by someone who lives it from the inside, gives birth to a new role. The catalogue grows faster than the decisions it should support.
After a few weeks, a familiar phenomenon shows up. The model under construction becomes more complex than the organisation it is meant to represent. Business managers no longer find their way through it. IAM architects begin to doubt. Nobody dares remove a role, because each role matches a real case told by a real person. Nobody dares add one either, because the catalogue is already unmanageable.
This is the point where we change the question. We stop asking "which roles should we create". We start asking "which people are already working in comparable ways". The nature of the workshops changes almost immediately. The business stops projecting an ideal model and starts looking at what is actually there.
A role is a consequence, not a starting point
A role is not an entity that pre-exists the organisation. It is one possible representation of an observed behaviour. It becomes useful when it faithfully condenses what dozens or hundreds of people already do together. It becomes a burden when it tries to codify every exception that daily practice naturally produces.
An organisation continuously produces peer groups. They emerge from reporting lines, from departments, from functions, from sites, from legal entities, from populations, from assigned responsibilities, from contractual lifecycles, and — at the end of the chain — from the entitlements actually granted. These are regularities. They exist before the IAM programme names them, and they will continue after it.
Our job is no longer to decree those regularities from a whiteboard. It is to bring them to the surface in the data, to name them with the business people who live them, and to decide — case by case — which deserves to be formalised as a role and which can simply be observed. The role becomes a consequence of the analysis. It is no longer the starting point.
Four scenes telling the same story
We picked four recent situations from programmes in different sectors. Each looks like a local case. Taken together, they describe the same mechanism.
- 01
An industrial group, hundreds of field technicians
In a large industrial group, hundreds of field technicians are spread across several production sites. No business role has ever been formally defined for them. Yet when we reconcile the data, their entitlements are remarkably consistent. The same maintenance applications, the same access to supervision systems, the same printing rights on shop-floor workstations. The organisation already produces a de facto role. It only needs to be seen.
- 02
In a bank, one analyst almost like the others
On a banking perimeter, several analysts share exactly the same characteristics: same manager, same department, same legal entity, same function, same seniority, same applications. One person in the group has a few additional accesses. The conversation with the owner is not about the hundreds of shared entitlements. It is only about that difference. A short, precise discussion that leads to a clear decision — where an exhaustive review would have produced mechanical approval.
- 03
In public administration, two agents in the same role
In a public administration, two agents officially hold the same position. Their entitlements, however, differ significantly. As we analyse their context, we find that they operate on behalf of two different authorities, each with its own regulatory scope. The difference becomes immediately understandable. It does not challenge the position title; it enriches how it is described.
- 04
A recertification campaign that regains its purpose
During a recertification campaign, a manager receives several hundred entitlements to validate. By grouping identities into comparable profiles, only a handful of situations truly stand out. The campaign stops being an administrative exercise of clicking "approve" until exhaustion. It becomes a genuine decision-support tool, focused on the few cases where the manager's judgment actually changes something.
None of these situations was resolved by creating a new role. Each was resolved by changing the question asked of the organisation.
How Netwrix Identity Manager supports this approach
We regularly use Netwrix Identity Manager, formerly Usercube, on this kind of environment. What we value in the platform is not primarily its provisioning engine. It is its ability to surface the regularities the organisation is already producing, and to focus human attention on what deviates from them.
- Correlation engine
- The correlation engine reconciles identities that share the same structural characteristics — manager, department, function, site, legal entity, lifecycle. It surfaces peer groups without requiring an architect to decree them. That foundation is what makes it possible to reason in terms of deviation rather than in terms of lists.
- Business rules
- Business rules explain why some differences between peers are legitimate. A contractor may not need access to an application their employed colleagues use daily. An agent assigned to a specific authority may hold an additional right. These rules are not exceptions; they describe the real mechanics of the organisation.
- Business Roles
- Business Roles are not a systematic requirement. We create them when a peer group deserves to be named, governed and audited as an object in its own right. We do not create them to complete a theoretical catalogue. Ten well-formed roles are worth more than a catalogue of five hundred that nobody dares to change.
- Technical Roles
- Technical Roles translate Business Roles into applications. That translation remains a human decision, validated by the application owner. It is never automatically inferred from a technical cluster no one has taken ownership of on the business side.
- Recertification campaigns
- Recertification campaigns build on the regularities already identified. A manager does not receive a flat list of entitlements. They see first what is consistent with each identity's peers, then what deviates from it. Attention naturally moves to the deviations. Decision quality rises; fatigue drops.
- Dashboards
- Dashboards highlight atypical profiles: an identity holding far more accesses than its peers, a role applied to a single individual, an isolated entitlement lingering after a change of assignment. These signals guide the governance committee toward the decisions that matter, rather than toward a pile of volume indicators.
Human attention deserves better than regularities
A mature IGA platform does not ask managers to confirm what is already coherent. It helps them understand what is not. Programme after programme, we see that this shift deeply changes the quality of the decisions the business is asked to make.
The question addressed to a manager stops being "do you approve these three hundred entitlements". It becomes "can you explain why this person stands out from their peers". The first calls for a mechanical answer. The second calls for judgment. That judgment, reserved for the cases that deserve it, is where identity governance actually creates value.
This approach is not revolutionary. It does not claim to replace Business Roles. It simply changes the place we give them in the programme. The role comes to name what emerges. It no longer imposes what should be.
Understand the organisation before modelling it
The most effective IAM programmes we have led are not those that produced the largest number of roles. They are those that allow the business to quickly understand why an identity is consistent with its peers — or why it is an exception that deserves an explicit decision.
At Ariovis, we consider this to be the standard for identity governance programmes launched since the post-Covid period. Organisations move too fast for a hand-maintained exhaustive catalogue to remain realistic. The correlation, business rules, modelling and recertification capabilities of Netwrix Identity Manager then serve us not to impose a theoretical model, but to reveal the regularities the organisation is already producing — and to leave managers the time to deal with the cases that truly deserve their attention.