There is an interesting pattern in the Identity Governance and Administration (IGA) industry.

Every so often, we see a case study announcing that an organization successfully brought dozens of applications under identity governance in a relatively short period of time. The numbers are usually presented as evidence of a major technical breakthrough: 50 applications. 80 applications. Maybe 100.

Those are certainly positive outcomes. Organizations moving away from aging identity platforms, reducing technical debt, improving governance coverage, and bringing previously unmanaged applications into an IGA program should be recognized.

But there is another question worth asking.

Why is onboarding dozens of applications still considered extraordinary?

For a mature IGA platform, application onboarding should be expected. More importantly, it should be repeatable.

The real accomplishment isn’t reaching application number 80.

The real accomplishment is ensuring that application 81 isn’t another engineering project.

IAM Has Normalized Complexity for Too Long

Much of the identity industry grew up around platforms that required substantial customization.

Organizations implemented complex Identity and Access Management (IAM) environments using custom connectors, scripts, middleware, application-specific workflows, proprietary integrations, and specialized development resources.

At the time, that was often the only practical way to solve difficult identity problems.

But an unintended consequence followed.

The industry gradually began treating that implementation complexity as a natural characteristic of enterprise IAM.

Organizations came to expect that onboarding another application might require:

• Custom connector development
• Specialized IAM developers
• Professional services engagements
• New scripts or middleware
• Extensive regression testing
• Separate deployment cycles
• Long-term maintenance of customer-specific code

Eventually, complexity stopped being questioned.

It simply became “how enterprise IAM works.”

That assumption deserves to be challenged.

A complicated organization certainly creates complicated identity requirements.

But complex business requirements do not automatically require complicated software implementations.

Those are two very different things.

Complexity Belongs in Configuration, Not Customer-Owned Code

At Fischer Identity, we have operated from a different architectural premise for more than 20 years.

The complexity of an organization’s identity environment should be represented through configuration, policy, workflow, attributes, lifecycle logic, and integration—not through layers of customer-owned custom code.

That distinction matters.

A modern IGA platform should allow an organization to connect an application, determine which identities and accounts exist within it, understand its entitlements, establish governance policies, configure provisioning and deprovisioning behavior, and incorporate that application into the larger identity lifecycle.

That should be a normal extension of the identity program.

It should not require rebuilding part of the identity platform every time another system appears.

Fischer Identity’s configuration-driven architecture has long been designed around this principle. Our platform supports cloud, on-premises, hybrid, legacy, ERP, HCM, SIS, directories, custom applications, APIs, and other enterprise systems while avoiding the customer-owned customization that creates long-term technical debt.

And when an integration does require additional connector capability, Fischer Identity’s engineering organization develops and supports those connectors rather than shifting that development burden to the customer.

That is an important distinction. The customer’s business is not building identity connectors. The customer’s business is governing identities.

Hundreds of Applications Shouldn’t Be Unusual

Large organizations operate hundreds, and sometimes thousands of applications.

Not all of them require the same level of identity governance.

Some applications need basic account creation and termination.

Others require entitlement aggregation. Some require complex provisioning.

Others require access requests, approvals, role assignments, certifications, separation-of-duty controls, temporary access, or detailed lifecycle policies.

That variety is normal.

A mature IGA architecture has to support that variety without treating every application as a custom implementation.

Fischer Identity customers routinely integrate and govern hundreds of applications as part of their implementations and as their IAM programs evolve.

And that second part is important.

IGA implementations do not end at go-live.

Organizations add systems.

They replace systems.

They move applications to SaaS.

They consolidate ERP platforms.

They acquire companies.

They change authentication technologies.

They introduce APIs.

They retire legacy applications.

They adopt entirely new categories of technology.

An identity platform that performs well during implementation but becomes increasingly difficult to modify afterward hasn’t really solved the problem.

It has simply moved the technical debt somewhere else.

The Real Test Comes After Go-Live

One of the best ways to evaluate an IGA platform is not to ask what it can connect to on day one.

Ask what happens three years later.

Suppose an organization replaces its HR platform, adds another authoritative source, expands into a new business unit, or brings an entirely new population of users into the identity program.

What happens?

Does the identity team need to redesign major portions of the system?

Do custom integrations have to be rewritten?

Do developers need to reconstruct workflows?

Does the organization need another consulting engagement?

Or does the platform simply adapt?

The University of Virginia (UVA) provides a useful example of how a flexible IGA architecture can support significant organizational and technology change.

UVA operates an extremely complex environment that includes an R1 research university, academic medical center, regional trauma center, distributed healthcare operations, faculty, staff, students, contractors, affiliates, external identities, and numerous overlapping identity relationships.

Fischer Identity automated provisioning and deprovisioning, supported advanced identity matching, reconciled external accounts, implemented policy-driven access, streamlined identity claim, and ultimately managed more than 180,000 active users and almost two million identity records.

Six months after go-live, UVA consolidated three existing HR systems into Workday HCM.

That could easily have become another major IAM implementation.

Instead, Fischer Identity was adjusted through configuration, disconnecting the legacy sources, aligning workflows to the new Workday data and business processes, and validating the new integration. The transition was completed without redesigning the identity architecture or introducing customer-specific code.

And the story did not end there.

Approximately two years later, UVA implemented Oracle HCM to manage employees associated with its regional medical centers.

Again, this did not require rebuilding the IAM environment.

Oracle HCM was added as another authoritative identity source through configuration. The new source system and its employee population were introduced into the existing Fischer Identity environment without disruption to the production IAM service and without impacting the identity populations already being managed.

That sequence matters.

First, three HR systems were consolidated into Workday.

Then another major HCM platform was introduced to support a different employee population.

Meanwhile, the same identity platform continued operating across the university, academic medical center, regional healthcare operations, students, employees, affiliates, contractors, and external populations.

This is what architectural flexibility actually looks like.

It is not simply the ability to connect to Workday or Oracle.

It is the ability to change the authoritative-source landscape of a large organization while the identity program continues operating around it.

That is a much higher bar.

And it is exactly why configuration-driven architecture matters.

A mature IGA platform should not merely survive organizational change.

It should expect it.

That is what architectural flexibility looks like in production.

Application Onboarding Velocity Is Really an Architecture Question

When application onboarding is slow, the immediate assumption is often that the organization needs more IAM engineers.

Sometimes that may be true.

But organizations should first ask a more fundamental question:

Why does onboarding the application require so much engineering in the first place?

If each application requires custom development, then onboarding capacity will always be constrained by the availability of developers. Five developers can only build so many integrations. Ten developers can build more. But the organization is still scaling identity governance by scaling labor. That isn’t particularly efficient.

Configuration-driven platforms change that equation.

When reusable integration patterns, connectors, policies, workflows, and lifecycle capabilities already exist within the platform, the work shifts away from software development and toward understanding the business requirement.

The questions become:

• Who should receive access?
• When should they receive it?
• What attributes determine eligibility?
• Who approves it?
• How long should access remain?
• What happens when someone’s role changes?
• What should happen when the relationship ends?

Those are identity governance questions.

And that is where IAM professionals should be spending their time.

Not Every Application Is Simple—and That’s the Point

There is also an important nuance here.

No serious identity provider should suggest that every application integration is identical because they aren’t.

A basic SaaS application with a standards-based API is very different from a 20-year-old institutional system with unusual data structures, proprietary interfaces, or complicated provisioning behavior.

Complex applications exist. Legacy applications exist. Strange applications definitely exist. We’ve seen plenty of them.

The point is not that integration requires zero effort. The point is that a mature IGA platform should absorb as much of that complexity as possible without forcing customers to modify the underlying product.

That is the difference between supporting complexity and exporting complexity to the customer.

Fischer Identity was designed to support sophisticated identity lifecycles, multiple authoritative sources, complex multi-role users, external identities, and dynamic access policies without requiring organizations to build auxiliary IAM systems around the platform.

The same philosophy applies to application integration.

Application 81 Is More Important Than Application 1

Most vendors can demonstrate integration with a few major enterprise platforms.

Active Directory. Workday. ServiceNow. Salesforce. Microsoft 365. SAP.

Those integrations matter, but they aren’t necessarily where an IGA program becomes difficult.

The better evaluation question is:

What happens when we reach the systems that aren’t on the demo slide?

Application 81. Application 181. The research application somebody built ten years ago. The departmental system running on-premises. The healthcare platform with unusual provisioning requirements. The ERP module that doesn’t behave exactly like the documentation says it does. The acquired company’s applications. The legacy system nobody plans to replace for another seven years. Those systems are part of the real enterprise.

A successful identity program has to govern them too.

Stop Measuring IGA Success by How Much Engineering It Requires

There has long been a strange assumption in enterprise technology that difficult implementations somehow demonstrate product sophistication.

They don’t. A product requiring a large development team to accomplish ordinary identity governance tasks isn’t necessarily more powerful. Sometimes it is simply harder to operate. The better measure is sustainability:

• Can the organization continue expanding identity governance without continuously expanding technical debt?
• Can administrators adapt policies when the business changes?
• Can new authoritative sources be introduced?
• Can applications be added quickly?
• Can lifecycle policies evolve?
• Can integrations survive product upgrades?
• Can the IAM program continue operating after the original implementation consultants leave?

Those questions tell you much more about the long-term value of an IGA platform than the size of the initial implementation team.

The Fischer Identity Approach

Fischer Identity has spent more than 20 years solving complex identity problems, including some of the most demanding environments in higher education, healthcare, government, and enterprise organizations.

We have deliberately taken a different approach from vendors that depend heavily on customer-specific customization.

Rather than investing in architectures that require customers to continuously develop around the product, Fischer Identity has invested in the product itself.

That means:

• Configuration-driven identity lifecycle management
• No customer-owned custom code required for identity processes
• Extensive connector and integration capabilities
• Support for cloud and on-premises applications
• Dynamic RBAC, ABAC, and PBAC policy models
• Advanced identity matching across multiple authoritative sources
• Lifecycle management for employees, students, contractors, partners, external identities, and other populations
• Continuous provisioning and deprovisioning
• Full administrative control
• An architecture designed to evolve as the customer’s environment evolves

Our customers should not need an army of developers to operate their identity platform.

And adding another application should not feel like starting another implementation.

The Industry Is Moving in the Right Direction

There is a positive side to seeing the industry celebrate faster application onboarding, SaaS delivery, configuration-driven integrations, and reduced dependence on custom development.

Those are good developments. Organizations absolutely should expect those capabilities from modern IGA.

What we would challenge is the idea that they are inherently new.

Fischer Identity has operated around many of these principles for decades.

We may not spend the marketing budgets of the industry’s largest vendors telling the market that every capability is revolutionary. We would rather invest in the platform and in the customer experience.

And perhaps that makes Fischer Identity something of an underdog in a very noisy market. We’re comfortable with that.

Because ultimately, customers don’t need another identity platform that looks impressive in a presentation.

They need one that keeps working when the organization changes.

They need one that can govern application 81. And 181.

And whatever comes next.

Application Count Is Not the Innovation

Organizations evaluating IGA platforms should raise their expectations. Connecting dozens of applications should not be extraordinary. Managing hundreds should not require an army of developers. And expanding identity governance should not continuously create new layers of technical debt.

The innovation isn’t the application count.

The innovation is making application onboarding routine.

That is how identity governance scales.

And that is how Fischer Identity has been building IAM for more than 20 years.