Point of View

There is a pattern I have seen enough times to name it.

An organisation struggles with its identity platform. Releases are slow. Production incidents are frequent. The team is firefighting constantly. The platform feels brittle, opaque, and expensive to change.

So they replace it.

New vendor. New architecture. Significant investment. A programme that runs eighteen months longer than planned.

And then, quietly, the same problems return.

Different platform. Same instability. Same drift. Same gap between what was designed and what is actually running in production.

The platform was not the problem.

—-

What Is Actually Happening

Identity platforms fail in predictable ways, and almost none of them are the vendor's fault.

In many delivery teams, multiple engineers share access to the same hosted or SaaS environment. There is no branching, no locking, no coordination model. One engineer's change overwrites another's. A configuration update made at 2pm conflicts silently with one made at 11am. Nobody knows until something breaks in production — and when it does, there is no reliable way to establish what changed, when, or who made it. The investigation is forensic rather than diagnostic.

This compounds everything else. Configuration accumulates outside version control. Changes are made directly in production because the promotion path is too slow or too unclear. Environments diverge from each other over time until no one is confident what any of them actually contain. Testing is manual, infrequent, and incomplete.

The feedback loop is slow by design. A change is made. It is tested manually, if at all. It is promoted through environments on a schedule measured in weeks, not hours. By the time a problem surfaces, the change that caused it is buried under several others. Root cause analysis becomes guesswork. Confidence in the platform erodes. Teams become conservative, which slows delivery further, which increases the pressure to take shortcuts, which introduces more risk.

This is not an identity problem. It is an engineering problem.

The organisations that struggle most with identity platforms are not struggling because they chose the wrong product. They are struggling because they are operating a software system without the engineering discipline that software systems require.

—-

Why Identity Gets a Pass

Most organisations have learned this lesson elsewhere.

Application delivery teams version their code. They run automated tests. They promote changes through structured pipelines. They instrument their systems and watch them in production. This is not considered advanced practice. It is considered basic hygiene.

Identity platforms get a pass because they are treated as infrastructure rather than software. They were historically managed by security and operations teams whose tooling and operating models were built for a different era. DevOps reached the application layer. It largely did not reach the identity layer.

The result is that the most critical system in the enterprise — the one that controls access to everything else — is often the least engineered.

—-

The Replacement Trap

Replacing the platform is appealing because it feels decisive. There is a programme, a budget, a timeline, a vendor relationship. There are milestones and deliverables and a go-live date.

What there usually is not is a new engineering model.

The new platform arrives and inherits the old operating patterns. Configuration is managed manually. Environments diverge. Testing is sporadic. The platform becomes fragile again, faster than anyone expected, and the cycle begins.

I am not arguing against platform modernisation. Sometimes the platform genuinely needs to change. But platform selection is a second-order decision. The first-order decision is how the platform will be engineered, operated, and evolved. If that question is not answered before the programme starts, the platform choice will not matter much.

—-

What the Fix Actually Looks Like

It is less dramatic than a platform replacement and more durable.

Configuration moves into version control. Every change is reviewable, auditable, and deployable from source. Automated tests cover the behaviours that matter — authentication journeys, token flows, policy decisions, access control outcomes. Environments are built to be reproducible and consistent, not manually curated and quietly divergent. Changes move through a structured pipeline, not through direct production access.

This is platform engineering applied to identity systems. It is not a novel idea. It is the same discipline that modern engineering teams apply to every other critical system. The novelty is applying it here, where it has historically been absent.

The payoff is not just stability. It is speed. Teams that operate identity platforms with proper engineering controls can release faster and with more confidence than teams that do not. The engineering investment pays back in delivery velocity, not just in reduced incidents.

—-

The Question Worth Asking

Before the next platform evaluation, before the next vendor briefing, before the next programme proposal lands on someone's desk — the question worth asking is simpler than any of those conversations.

How is the current platform actually managed?

If the honest answer involves manual configuration, infrequent testing, environment inconsistency, and a promotion process that relies on individual knowledge rather than structured pipelines — the platform is not the problem.

The engineering model is.

Fix that, and almost any platform becomes manageable.

Do not fix it, and almost any platform will eventually fail.

—-

Paul McKeown is the founder of Idem, a senior technology advisory and platform engineering practice based in Wellington, New Zealand. Idem works with engineering leaders and programme sponsors on complex platform and delivery challenges across financial services, SaaS, and enterprise infrastructure.