← All insights

Business roles without the baggage

Almost every SAP role model starts clean and ends tangled. The drift isn't bad luck, it's the predictable result of design choices made early. Get those right and the model stays maintainable for years.

Role design is where SAP security is won or lost. Get it right and access stays understandable, segregation of duties holds, and reviews are quick. Get it wrong and every downstream control fights an uphill battle against a model no one fully understands. The frustrating part is that almost every estate begins with a sensible design, and then erodes.

How role models decay

The decay follows a familiar arc. A clean, role-based model is built at go-live. Then reality arrives. A user needs one extra transaction, so a wide role gets assigned rather than the design adjusted. A new requirement appears, so a role is copied and tweaked, then copied and tweaked again. Temporary access is granted and never removed. Within a couple of years there are hundreds of near-duplicate roles, no one is sure which are in use, and "least privilege" has quietly become "whatever was easiest at the time."

A role model doesn't fail in one bad decision. It fails in a thousand small, reasonable ones, each easier than fixing the design.

The principles that hold up

The designs that stay clean for years tend to share the same handful of choices.

Build from what people do, not what they might need

Roles modelled on actual job activities, the real tasks a function performs, stay tight. Roles modelled on "everything this department could conceivably touch" balloon immediately. Designing from genuine usage rather than imagined need is the single biggest lever on whether a model stays least-privilege.

Separate the building blocks from the business view

A maintainable model usually distinguishes between technical roles (coherent bundles of related access) and the business roles users are actually assigned (combinations aligned to a job). Keeping that separation means you can adjust the underlying access in one place without re-engineering every assignment, and you can explain to an auditor what each business role represents in plain language.

Design segregation of duties in, not on

SoD is cheapest to enforce at design time. If conflicting duties are kept out of the same role from the start, you avoid a permanent remediation backlog later. Bolting SoD analysis onto a model that was never built with it in mind is how teams end up with thousands of conflicts and no realistic path to clearing them.

Make the model legible

Every role should have an obvious purpose someone can state in a sentence. If a role's name, contents and reason for existing aren't clear, it will be assigned by guesswork and reviewed by rubber stamp. Legibility isn't cosmetic, it's what makes every later control possible.

The maintenance question

Good design is necessary but not sufficient. The estates that stay clean treat the role model as something that's governed, not just built. New access requests are mapped to existing roles rather than spawning new ones. Unused roles are retired. Changes go through a path that protects the design instead of eroding it. The discipline is modest, but it's the difference between a model that ages well and one that has to be rebuilt every few years.

Why migration is the moment

There's rarely a good time to rebuild a role model on a running system, the risk of breaking live access is too high. That's what makes a major platform move so valuable: it's the one point where roles are being rebuilt anyway. The temptation is to copy the old model across to save time. It's also the costliest mistake available, because it imports years of accumulated baggage into a system that could have started clean. The migration is the chance to design from real usage, build SoD in from the first role, and carry forward the access people actually use, not the debt they happened to accumulate.

Business roles without the baggage aren't a matter of luck or heroic clean-up projects. They come from designing around real work, separating structure from assignment, building in segregation of duties, keeping the model legible, and governing it lightly but consistently. The payoff is an access model that an auditor can understand, a user can be assigned to with confidence, and a team can maintain without dreading the next review.