Designing an Identity and Access Management Transformation

Identity everywhere and nowhere

The organisation, a mid-sized bank, did not lack identity management. It had, by our count when the mapping settled, more than a dozen distinct mechanisms for deciding who someone was and what they could do: a corporate directory that most office applications trusted, an in-house provisioning tool written fifteen years earlier that only two people still understood, a separate directory for the branch network, local account stores inside the core banking platform and the trading system, and a long tail of applications that each kept their own user table and their own idea of a joiner process. Access requests moved by email and ticket. Leavers were removed from the directory promptly and from everything else eventually.

Everyone inside the bank knew this picture in fragments; nobody had ever seen it whole. The security team knew the mechanisms, the application teams knew their own corners, HR knew the process as it was supposed to work, and the audit function knew the exceptions. When the bank decided to invest in a proper identity and access management programme — a central identity provider, an identity governance platform, a standard joiner-mover-leaver process — the first obstacle was not choosing a product. It was that no shared description of the current situation existed on which a target and a migration path could be argued. That is the gap we were brought in to close, working in the bank's existing Sparx EA repository, alongside the security architect who would carry the model after we left.

What the regulator's findings changed

The programme had a deadline with teeth. A supervisory review had produced findings on access management — recertification of access rights was happening on paper and incompletely, privileged accounts were not systematically inventoried, and the bank could not demonstrate, for several material applications, that leavers lost access within the required window. The findings came with dates, and the dates turned an improvement initiative into an obligation.

This changed the modelling brief in a way worth spelling out. A model built to support an internal programme can afford to be approximately right and improve over time. A model that will be shown to a supervisor as evidence of a controlled transformation has a different standard: every claim in it must have a named source, and the distinction between verified and assumed must be visible in the model itself, not in the modeller's memory. We ran the whole engagement on that footing. Every application's authentication mechanism was recorded together with how we knew it — configuration inspected, owner interviewed, or inferred and awaiting confirmation — and the migration plan the board eventually saw carried that provenance with it. It cost noticeably more effort than a normal current-state exercise. It was also, in front of the audit function, the difference between a diagram and a document of record.

Mapping the identity services that already existed

We resisted starting from the product. IAM programmes have a way of becoming implementations of a vendor's reference architecture, with the bank's actual estate treated as an inconvenience. Instead, the first modelling pass described identity as the bank already did it, in ArchiMate, as a set of services that existed whether or not anyone had ever named them: authentication, account provisioning, access request and approval, recertification, privileged access, and directory synchronisation. Each service was linked to the mechanisms that provided it today — the corporate directory realising authentication for office applications, the in-house tool realising provisioning for the core platform, email and goodwill realising access approval nearly everywhere.

Framing the current state as services provided badly, rather than as an absence of IAM, did two useful things. It gave the security team a vocabulary for the target that was already grounded in the estate — the target would provide the same services, centrally and verifiably, rather than introducing an alien structure. And it made the scale of the tail visible: for each of the roughly two hundred applications in scope, the model recorded which identity services touched it and by which mechanism, which is exactly the inventory a migration plan needs and exactly what the bank had never assembled. The application-by-application facts came from a structured pass through the application owners, seeded from the CMDB export and corrected in interviews, and each fact carried its provenance tag from day one.

How the application facts were gathered

Two hundred applications is too many to interview one by one, and a single blanket method would have given the core platform and a car-park booking tool the same attention, so the collection ran in three tiers. The twenty or so tier-one applications — the core platform, trading, payments, the channels — got proper working sessions: the application owner and a technical lead, ninety minutes, with the configuration on screen where access allowed. We asked to be shown, not told, how authentication was wired, because told and true diverge; in several sessions the mechanism on screen was not the mechanism anyone had described, including once a federation that had been configured years earlier and never switched on.

The middle tier ran on a short structured questionnaire — a dozen closed questions an owner could answer in fifteen minutes — returned through the bank's normal task tooling so completion could be chased by someone other than us. Answers landed in the repository through a script that matched on the CMDB identifier, created nothing new, and flagged every mismatch for a person to resolve rather than guessing. The long tail was triaged from the CMDB and the directory's own data: an application whose only integration is a browser and a local user table can be classified from evidence already held centrally, and confirmed opportunistically when its owner next appeared in any other context.

The tiering was itself an architectural statement: effort followed materiality, and the provenance tags recorded which tier each fact came through. When the programme later found errors — it did, a handful — every one was in the tier whose method predicted it, which did more for the model's credibility than perfection would have, because it meant the confidence levels written into the model were honest.

Responsibilities: assignment, not assumption

The second modelling pass added something IAM designs habitually leave implicit: who does what. Recertification campaigns fail, in our experience, not in the tool but in the org chart — the moment it is unclear whether the application owner, the line manager or the security team confirms an access right, the campaign produces signatures rather than decisions. We modelled the responsibilities explicitly, as ArchiMate business roles assigned to the identity processes: who approves a request for each application tier, who reviews privileged access and how often, who owns each directory, who is accountable when an automated de-provisioning fails and a manual fallback has to run.

Doing this in the model rather than in a policy document had a concrete advantage: the assignments could be queried and cross-checked. A model search listed every identity process with no assigned role, and — by checking the named holders recorded on each role against the HR extract — every role whose holder had left the function; both lists were longer than anyone expected. The responsibility map went through two rounds of workshops with the security team, HR and the largest application owners before it stabilised, and several of the arguments those workshops surfaced were the real design decisions of the programme, settled a year before the governance platform would have forced them at configuration time, when they would have been settled badly and by default.

A target the security team could defend

The target architecture itself is deliberately unexciting, which we consider a virtue in a bank. A central identity provider fronting authentication for everything that can federate; the identity governance platform owning the joiner-mover-leaver lifecycle and recertification; the corporate directory retained as the workforce source of truth, fed by HR; privileged access moved behind a dedicated vault with session recording; and the branch directory absorbed rather than federated, ending a decade of double administration. Each target service was modelled alongside its current counterparts, with stereotyped associations recording which mechanisms the target would replace and which — importantly — it would not; ArchiMate has no replacement relationship, so the convention is documented in the model itself.

The honest part of the target was the exception register. Around thirty applications could not federate: too old, vendor-locked, or scheduled for decommissioning within the programme's horizon. Rather than let each become a corridor negotiation later, the model carries them as explicit exceptions with an agreed mechanism — local accounts under compensating controls, reviewed on a shorter cycle — and an expiry tied to the application's lifecycle. The security team could then defend the target in front of the board and the supervisor precisely because it did not claim universal coverage; it claimed a defined boundary with named, dated exceptions. In our experience that is what a defensible architecture looks like: not a clean diagram, but a diagram whose exceptions are as governed as its rules — a point we find ourselves making in most enterprise architecture engagements, whatever the domain.

Staging the migration as plateaus

With current and target described, the migration path was modelled as ArchiMate plateaus — stable intermediate states the bank would actually inhabit, not phases in a project plan. Four plateaus took the estate from the fragmented baseline to the governed target, each one chosen so that if the programme paused there — budgets pause, priorities shift, banks reorganise — the bank would be standing somewhere coherent and demonstrably better than the plateau before.

Between plateaus, work packages carried the actual migration work — application onboarding waves, directory consolidation, the branch cutover — each linked to the plateau it delivers and to the applications it touches. Mapping each plateau to the supervisory finding it works toward — and being open that the first is pure foundation, retiring none by itself — gave the programme a reporting language the board understood immediately: progress was no longer a percentage on a slide but a statement of which findings were closed and which plateau closes the next one.

The ordering of the plateaus was itself argued out of the model rather than asserted. Privileged access could plausibly have come first — it addressed the sharpest finding — but the dependency analysis showed the vault rollout leaning on the central IdP for administrator authentication, the recertification plateau leaning on the governed lifecycle for its data quality — a campaign over accounts that provisioning does not yet control certifies noise — and the same platform team carrying both the lifecycle and the vault delivery, which ruled out landing them together. Laying those dependencies out as relationships between the work packages, and letting the security team walk them on a single diagram, settled in one session an ordering debate that had been circulating in slide decks for months before we arrived. The sequence that emerged is less dramatic than the one first proposed, and it is the one still holding three years of programme turbulence later.

Driving wave scope from tagged values

The unglamorous asset that made the plan operational was a small set of tagged values on every application element: authentication mechanism today, federation capability, provisioning route, data sensitivity tier, and target migration wave. None of this is exotic — it is a spreadsheet's worth of attributes — but holding it in the repository rather than in a spreadsheet meant it stayed attached to the architecture. The wave plans were generated from model searches over those tags: every application in wave two, with its owner, its mechanism, its exceptions and its dependencies, exported into the onboarding team's working pack at the start of each wave. When reality moved — an application retired early, a federation claim turned out to be optimistic — the tag changed in one place, every view generated afterwards followed, and packs already issued were regenerated at the next wave boundary.

We also wired the tags into simple integrity checks, run by a command-line EA instance under the bank's job scheduler: no application may be marked federating without a named IdP integration pattern; no wave assignment without an owner; no exception without an expiry date. These are the identity-programme equivalent of the model validation discipline we apply to any repository we work in, and they caught real drift monthly. The alternative — programme data scattered across trackers that disagree with the architecture — is the normal condition of large IAM programmes, and avoiding it was probably the model's single largest contribution to delivery.

Working inside a bank's constraints

A word on the repository itself, because modelling an access-management transformation generates content that is itself sensitive. The model names every application that cannot federate, every compensating control, and every privileged access route in the bank — a useful document for us, and for anyone hostile. The repository ran on the bank's SQL Server estate inside the normal database controls, and access to that repository's database was limited to the programme's architects — package-level security governs editing, not reading, so the read boundary had to be drawn at the connection itself — and everyone else received generated documents rather than a connection to the live model. Consultant access ran under the bank's own accounts on the bank's own machines, and ended when the engagement did.

These constraints extended to working style. Nothing left the building; the workshop packs were generated inside the network and stayed there. Where this case study speaks of mechanisms and findings, it does so at the level of pattern, for the obvious reason. We mention the constraint because modelling engagements in regulated environments are shaped by it, and consultancies that treat the model as their own working material, portable between laptops and clouds, create a finding of their very own.

What stayed out of the model

The most important scoping decision was what the architecture model would not hold. An IAM estate has entitlement-level detail below every application — thousands of groups, roles and permissions inside the core platform alone. The governance platform exists precisely to manage that layer, and an architecture repository that tries to mirror it becomes a stale copy of a system that has a live one. We drew the line at the service and application level: the model knows that the trading platform has local entitlements, knows who owns their review, and knows which wave moves them; it does not know what the entitlements are. The one place we bent the line — modelling the privileged account categories explicitly, with each category linked to the system whose reports produce its account-level inventory, because the supervisory finding demanded that the inventory be demonstrable — was documented as a bend, with the vault and the governance platform named as the systems of record for the accounts themselves.

We are equally plain about what the model did not do: it did not shorten the vendor selection, which ran its procurement course; it did not configure the platform; and it could not, by itself, close a single finding. What it did was let a large programme argue about one shared, queryable description of reality instead of a dozen partial ones — which, on a programme where the arguments were the expensive part, was worth the modelling many times over.

What we would do differently

Two corrections from this engagement now travel with us. The first concerns the plateau granularity. Our original design had six plateaus; the bank's delivery reality supported four, and the two we merged away were the ones defined by technical milestones — a directory upgrade, a network change — rather than by a state the business could recognise. A plateau earns its place when a non-architect can say in one sentence what is true once it is reached. States that need a technical diagram to explain are stages of a project, and they belong in the work packages, not the plateau chain. We now test every proposed plateau against that sentence rule before it enters a model.

The second concerns timing of the responsibility work. We ran the service mapping first and the responsibility workshops second, on the logic that you cannot assign what you have not named. In hindsight the order cost us a month: the responsibility arguments were the slow, political part, and starting them earlier — even against a rough service list — would have let the two streams converge instead of queue. The service names changed a little as the model matured; the arguments would have survived the renaming. Sequencing the contentious human work first and the clean modelling second is the general lesson, and it is one consultancies relearn periodically because the clean work is so much more pleasant to start with.

Where the programme stands

At the time of writing, the first two plateaus are behind the bank and the third is in delivery. The leaver-window finding mapped to the second plateau is formally closed — the onboarding waves that followed tier-one took the governance platform across the rest of the in-scope estate, with the evidence packs drawing directly on views generated from the repository — current state, target, the wave that moved each application, and the exception register with its expiry dates. The security architect who worked alongside us owns the model outright, runs the integrity scripts, and has extended the tagged-value scheme once already, cleanly, for a requirement we had not anticipated.

The exception register has done quiet, steady work since. Two exceptions expired on schedule and were closed by decommissioning, exactly as their expiry dates promised; one application appealed for an extension and got it — through a documented decision recorded against the element, which is the point. Nothing about a governed exception is embarrassing in front of a supervisor. An undocumented one is a finding.

The pattern in this engagement travels well beyond banking: describe identity as services the organisation already provides, make responsibilities explicit before any product is configured, stage the migration as states you could stop at, and keep the programme's working data in the model where the architecture can check it. If your organisation is facing an access-management transformation — with or without a supervisor's dates attached — we can help you build the description first. You can reach us through our contact page.

This case study describes a representative engagement pattern. Organisational details are illustrative and do not identify a specific client.