Why Your IGA Implementation Architecture Matters More Than Your Vendor Choice

The views expressed in this article are my own and do not necessarily represent those of my employer.

The biggest mistake organizations make with Identity Governance and Administration isn't choosing the wrong vendor—it's letting that vendor control the abstraction layer (if you even have one...). After managing both identity and integration platforms at my previous company, I've seen firsthand how this architectural decision determines whether you get a flexible identity fabric or an expensive, rigid silo.

Most IGA vendors claim to offer APIs and modern architectures, but dig deeper and you'll discover they want to sit at the top of your technology stack, controlling how other systems interact with identity data. This creates a fundamental problem: you're building on their foundation instead of yours.

You need to own Your Integration Layer

Here's what typically happens during IGA implementations. Your project team, under pressure to deliver, connects applications directly to the vendor's APIs Tight Coupling... but works and is fast. The vendor encourages this—they provide detailed integration guides, professional services, and promise that their platform can handle everything you need. Note that I am not indicating that all direct connections are bad, but there are trade off. If you have not found them.... search again as Mark Richard and Neal Form indicate with their First Law of Software Architecture: "Everything in software architecture is a trade-off".

But this approach creates several critical problems that only become apparent later, problems that echo what Brandon Byers articulates in his seminal article "You Can't Buy Integration" on Martin Fowler's site: "Integration is a business concern and you cannot buy it. You can buy programming languages...but you can't buy integration."

Similarly, as Mauricio Salatino emphasizes in "Platform Engineering on Kubernetes," you cannot buy a platform—internal teams will need to figure out which services and how they must be combined to solve specific problems. This principle applies directly to IGA implementations:

Your developer teams get locked into vendor-specific patterns. Each IGA vendor has their own API design and data models and possibly DSL. Your developers spend time learning proprietary approaches instead of industry standards, and that knowledge becomes worthless when you need to switch vendors or integrate with other systems.

You can't compose identity services with other enterprise capabilities. Modern enterprises need to combine identity decisions with threat intelligence, observability data, business context from data lakes, and signals from other security tools and non Security domains. When your IGA vendor controls the integration layer, these compositions become vendor-mediated rather than enterprise-controlled.

Event-driven architectures become impossible. Most IGA platforms don't expose their internal events to external message brokers. You can't easily trigger workflows in other systems when identity events occur, forcing you to build expensive polling mechanisms or accept delayed responses to critical identity changes.

The UI Trap: Why Vendors Can't Solve Your Interface Problems

IGA vendors try their best with their user interfaces, but this reveals another architectural flaw. It never makes sense for vendors to be in the UI business for the same reason it doesn't make sense for database vendors to build your application interfaces. Note that it is possible that the Vendors UI covered 80% of your needs. Go for it, but do not lock yourself in as this being the only way to have access to waht should also function as a headless platform. If it really is a platfom...

Every organization has different user workflows, branding requirements, and integration needs. Vendors must design for the lowest common denominator, creating interfaces that are either too simplistic for power users or too complex for casual users. More importantly, when vendors do expose UI components, they typically require learning a completely new domain-specific language rather than using standard web technologies your developers already know.

The result? Your users get frustrated with interfaces that don't match their mental models, and your developers can't easily embed identity functions into the applications where users actually work. Beleive me you can never please everyone on this front!

The Power of Composite Identity Architecture

At my previous company, I was fortunate to manage both the identity and integration platforms. This cross-pollination was paramount for surfacing one composite API to our customers for all identity concerns—IGA, secrets management, segregation of duties, and real-time identity data.

Instead of letting our IGA vendor control integration, we built a robust abstraction layer using API gateways and event brokers via our integration platform. This architecture enabled us to:

• Combine identity data with business context from our data lakes without moving sensitive information into the IGA vendor's system
• Posibility of Triggering automated security responses by publishing identity events to our enterprise message broker
• Provide consistent developer experiences across all identity services, regardless of which vendor powered each capability
• Let federated teams build their own interfaces using our standardized APIs—as my friend Peter Hofer would say, "you do not want to be in the UI building business"
• Adapt quickly to new requirements without renegotiating vendor contracts or waiting for product roadmap updates

The traditional vendors constantly suggested we "bring it all into their platform" and let them handle integration. But identity has strong cybersecurity concerns while also serving numerous other business domains. You need a forward-looking, decoupled layer that you control to plug in future needs that your IGA vendor will never anticipate.

AI Context Problem: Why You Must Own Your Corporate Hive Mind

Every IGA vendor now claims AI capabilities, but this highlights another reason why vendor-controlled architectures fail. Context is king in AI applications, and you cannot flow all necessary context into one uber-system without creating massive data transfer requirements and dangerous single points of failure.

Effective identity AI requires combining identity patterns, threat intelligence, business context, behavioral patterns, and compliance requirements into what is essentially your corporate hive mind—the collective intelligence that enables smart decisions about access, risk, and governance.

This hive mind must be owned and controlled by your company, not your vendors. When you let an IGA vendor centralize this intelligence, you're essentially outsourcing your organization's decision-making capability to a third party that doesn't understand your business context, risk tolerance, or strategic objectives.

A vendor-controlled architecture forces you to either accept limited AI capabilities based on incomplete context, or create expensive data duplication where sensitive corporate intelligence gets scattered across multiple vendor systems—neither of which serves your long-term interests.

Again I have no problem with Vendor Having AI capabilites. They Should. But they need to expose this information to the greater context of the corporation.

Ian Glazer's Identity Fabric: The Right Architectural Vision

Ian Glazer articulates this perfectly in his identity fabric concept. Modern identity needs open standards that permit orchestration between IGA and non-IGA elements to achieve increasingly complex, federated outcomes.

This isn't about avoiding vendors—it's about maintaining architectural control so you can:

• Compose identity services with other enterprise capabilities
• Orchestrate complex workflows that span multiple domains
• Adapt to future requirements without architectural rewrites
• Maintain vendor independence while leveraging best-of-breed solutions

The Integration Component Solution

The answer isn't avoiding IGA vendors; it's implementing robust integration components—API gateways, event brokers, and service mesh technologies—that create your abstraction layer above vendor services with the appropriate level of decoupling.

This architecture provides several critical benefits:

Developer teams use consistent interfaces regardless of which vendor powers each capability. Your integration layer translates between vendor-specific APIs and enterprise-standard interfaces.

Event-driven workflows become possible because your message broker receives events from all identity systems and can trigger responses across your entire technology ecosystem.

AI and analytics initiatives get clean, consistent data from your integration layer rather than requiring point-to-point connections with multiple vendor systems.

Future-proofing becomes automatic because new requirements get implemented in your integration layer rather than requiring vendor product changes.

Practical Implementation Guidance

Start by establishing these architectural principles:

Never allow direct vendor API integration for business-critical applications. All integration should flow through your enterprise API gateway or integration platform. Even if they are transparent proxies. This leaves it open for future needs!

Require vendors to support standard protocols like SCIM for provisioning, OAuth/OIDC for authentication, and webhook/event streaming for notifications. Anyone with their salt does this today.

Design your integration layer first based on your business requirements, then evaluate how well vendors support those patterns.

Plan for vendor independence by ensuring your integration components can support multiple backends for each identity capability. If the vendor is good and keeps up to date with changing needs, they will have a long and prosperous relationship with your company—but that choice should be yours based on performance and value, not architectural lock-in.

We all need to know our place in the stack. Don't take it personally, vendors!

The Bottom Line

The most successful IGA implementations I've seen treat vendors as service providers within an enterprise-controlled architecture rather than platform foundations that control integration patterns.

Your project manager will resist this approach because it adds initial complexity, but the long-term benefits—vendor independence, architectural flexibility, developer productivity, and AI readiness—far outweigh the upfront investment.

Remember: you're not just implementing an IGA system, you're building an identity fabric that will serve your organization for the next decade. Make sure you are in control of the fabric's architecture.