The Connector Treadmill: Why Integration Never Ends

Your integrator will not tell you this, so I will. The connector they are about to build for you is not an asset. It is a liability with a maintenance schedule, and you are about to start paying for it for as long as the application lives.

Every identity governance program rests on the promise that connecting an application is a one-time job. You buy the platform, the applications get wired up, and the system runs. Integration shows up in the implementation plan as a line item with an end date.

That promise is the connector fallacy. It is one of the most expensive mistakes in identity governance, and almost everyone makes it.

Connecting an application is not an event

Connecting an application starts a maintenance relationship that lasts as long as the application does.

The target never stops moving. A vendor turns on SSO enforcement and the service account is locked out overnight. An MFA prompt appears where there was none, and a connector that signs in like a user has no way to answer it. An endpoint gets deprecated, a schema changes, a permissions model gets restructured, and the connector that worked last quarter fails this one.

The failures that hurt most are the silent ones. A schema change stops entitlements from syncing, but the connector still reports healthy. Access looks governed on the dashboard while the data behind it drifts out of date, and nobody finds out until an auditor pulls the thread.

Someone has to notice each of these, diagnose it, and rebuild. Multiply that across a portfolio and the work never arrives at done. There is no version of a real application estate where the integration project ends and the running begins. They are the same job.

The standard that was supposed to save you did not show up

Most of this work is custom because the standard meant to prevent it never fully arrived.

SCIM was supposed to make provisioning universal more than a decade ago. The reason it stalled is economics, not engineering. Provisioning is one of the features vendors reserve for their most expensive tier, because deep integration is what locks an enterprise buyer in. The standard exists. The incentive to implement it fully and hand it over at the base price does not.

So a decade on, SCIM is still absent or paywalled across most of the application landscape, governing a fraction of the apps a real enterprise runs.

Everything outside that thin band needs a custom connector: legacy systems, internal tools, partner portals, vendor-locked SaaS. Each custom connector is a small piece of software you now own and have to keep alive. You did not set out to become a software vendor, but alas, the fallacy has now made you one.

The treadmill nobody budgeted for

The result is a pattern that we at Opnova like to call the connector treadmill.

New applications enter the onboarding queue faster than old ones get integrated. The connectors that exist break and have to be rebuilt. The budget meant to expand the program next year ends up maintaining the work you did last year. Sound familiar?

Put rough numbers on it. A custom connector typically takes weeks to months of specification, implementation, testing and integration, and once it exists, it needs attention every time the target shifts, often enough that maintenance runs a meaningful share of the original build every year. One connector is a manageable line in a plan. Two hundred of them is a full-time team that never gets to move forward.

At large organizations, the queue can stretch into years. Some applications get deprecated before anyone reaches them. You are paying to integrate software that will be dead by the time its turn comes up.

If we're talking about low-volume applications, those will never get integrated, there is just no possible ROI. They will always be disconnected.

The cost is real even though the contract hides it

It is easy to overlook, because none of this appears as a line item on the contract. The license is spelled out. The cost of running the treadmill for the life of the program is rarely discussed and almost never included.

It lives in engineering time, in connectors that eat a maintenance budget nobody sized, in the applications that never get governed because the team is busy keeping the connected ones alive. Gartner has found that more than half of identity governance deployments are distressed, missing their functional, budget, or timing commitments.

The connector treadmill is a large part of why. A program can be fully funded and still fall behind, because its cost structure assumes a finish line that was never real.

Connectors are not the problem. Finished connectors are the myth.

Building connectors is real work, and someone has to do it. The mistake is believing they stay built.

An honest plan treats integration as a permanent operating cost that recurs every year. That is the floor. The more interesting move is to stop depending on brittle connectors in the first place.

A connector breaks because it is rigid. It was written for one version of one interface, and it snaps the moment that interface moves. An approach built on intent behaves differently. Something that operates an application the way a person does, reading the screen and working toward a goal, can absorb a layout change or a new prompt that would stop a script cold. It was never bolted to a single version, so it does not fail on the same schedule.

It still needs oversight, and it still needs a human in the loop where the stakes are high. What it removes is the standing cost of keeping a thousand brittle connectors alive. The difference is between maintaining a thousand connectors and governing a thousand applications.

This is the approach we built Opnova around. Its agents operate applications directly, so governance stops depending on whether a connector is still current.

An LLM does not get you off the treadmill either

Which raises the obvious objection. LLMs write code and operate software now, so why has this not already solved itself?

Have one write the connector and you get a first draft faster. That is all you get. Generation was never the bottleneck - the cost is every quarter after the build, and generated code breaks exactly the way handwritten code breaks, except now nobody on your team has read it. Faster on-ramp, same treadmill.

Point an LLM at the application instead and you are heading the right way, but on its own it is a demo, not a control. Governance ends in evidence: who had what, when, on whose approval. A plausible answer is not something you hand an auditor. The work is everything built around it - verification that reads the state back rather than assuming the change landed, an action-level audit trail, credentials the LLM never sees, an approval gate where the stakes justify one, and someone continuously testing those workflows against the applications you actually run. Skip that last part and you have not escaped drift, you have only moved it from your application vendor's release notes to your model provider's.

GenAI is the engine here, not the car. If someone tells you an LLM makes integration a solved problem out of the box, you are hearing the connector fallacy again, in a newer accent.

The question to ask before you renew

Ask one thing before your next renewal: how much of last year's identity budget built new integrations, and how much kept old ones alive?

If the second number is winning, you are not running a program. You are running on a treadmill. The first step off it is admitting the connector was never a one-time cost.