How much customization will your IAM (IGA) withstand without failing?

IGA (Identity Governance & Administration) is the discipline within IAM (Identity & Access Management) where most customization of COTS (Commercial of the Shelf) solutions and even IDaaS (Identity-as-a-Service) solutions tends to happen. Surely, this is changing with the shift to IDaaS, but we still see a tendency to not only customize, but frequently "over-customize".

Following a recent discussion on another LinkedIn post (https://www.dhirubhai.net/posts/martinkuppinger_sap-identitymanagement-activity-7173996363460837378-pQya) that touched the pros and cons of customization and some of the challenges that arise, here are some thoughts about when and how to customize.

First let's clarify terms. I use "customization" when it is about building new code, be it by "traditional" coding or using low-code or no-code approaches. I use "configuration" when settings of the system are changed, best via the UI, alternatively via configuration files. Notably, low-code/no-code won't help us much with keeping control about customizations, even more with most of these approaches still lacking proper documentation, version control, staging, and all the other features needed.

Why to customize IAM solutions?

The first questions to raise are:

• Do we need customization in standard IGA solutions (and to which extent)?
• Why are solutions being customized?

These seem to be two almost similar questions, but they aren't. My experience from more than two decades in IAM is that they aren't similar at all. Customers commonly need much less customization and "bells and whistles" as they think they need.

IAM processes (and notably, that goes way beyond JML - Joiner, Mover, Leaver) can be described in a rather standardized manner. Yes, there are variants and specifics in organizations, but they are commonly at the detail level: How many approvers? Who approves? Do I work with sequential or parallel approvals? However, the answers on such questions should be based on best practices. Which again means that it is about details. There are comprehensive process frameworks available. Some are provided by vendors. Or you just ask my colleague Matthias Reinwarth for the process frameworks we at KuppingerCole Analysts AG have developed in our advisory practice.

At the end, employees are onboarded, granted access, change jobs, leave temporarily or permanently, authenticate, and so on. Roles and other entitlements must be managed. But that happens in every organization and there are best practices. Again: There are certain specifics, there are custom integrations to backend services (which should use standard connector frameworks) and so on. But the required level of specifics does not explain the amount of customization we observe in many IGA implementations.

To the question of "why are solutions being customized": There are various reasons. It starts with "we've always done this that way", where an existing process then is mapped to the new IGA tool. Even worse, when there exist many different ways of "we've always done this that way" - I remember an organization where I talked to the IAM teams at seven different sites, all having their own IAM "processes" (quotas for a reason...) and insisted on these.

Another is that still not enough vendors deliver comprehensive process frameworks out-of-the-box and that there are no established standard frameworks around.

Cynics also tend to say that IAM system integrators benefit from a large amount of customization. However, this ignores the downside: Customer satisfaction suffers from spending a lot of money for customization and from long-running processes, and overall process risk increases.

Does another tool help?

Over the years, I had many conversations with IAM leads and CISOs about "our IAM (IGA) is not running well, we need a different tool." Maybe. But the answer is that it also needs a different approach on customization (less) vs. configuration (more), on adaptation to organizational specifics (less) vs. using best practices (more).

Just changing the tool will not help. You may argue that IDaaS, with an on-average lower degree of customization, will improve the situation. But only to a certain extent. It does not fix the underlying challenge.

Good IAM (IGA) does not start with the tool, but with policies, processes, organization, people, and a thorough requirements analysis. A good process framework where processes are well-described "on paper" (commonly a tool, for sure) withstands the exchange of the tool. In most projects that suffer from over-customization, there is a lack of well-described processes.

The groundwork must be done. This will take only a fraction of the time and cost of the overall project. License / subscription fees, implementation, configuration and the remaining level of customization will cost much more. On the other hand, by doing the groundwork well, the project risk and project cost will go down.

How to customize if customization is needed

I don't say that there is no need for customization. There are specifics that will require adaptation. My point:

1. We commonly need much less customization in IGA projects than we observe.
2. Customization must be done in a way that it doesn't break the IGA implementation sooner or later.

The first aspect is about stepping back, rethinking and optimizing (and defining) processes, putting the ask for "bells and whistles" into question, and relying on proven best practices.

The second is about doing it right. I've seen IGA projects coming into trouble with a major software update because the system integrator had been coding against the database in the backend. When the database structure changed, the code failed. Working against APIs or defining an abstraction layer would have been the better choice.

I've seen many IGA implementations based on an outdated version of the IGA tool. Sometimes, updates just needed a lot of planning and fixes to the customizations. Sometimes, the customer just failed in updating to a new release of the IGA tool because the customizations would break.

When we created the concept of the Identity Fabric a couple of years ago, we added the concept of an "Identity API layer" as a consistent layer of APIs to consume the services of the various IAM tools in place. Such API layer also is the foundation of successful customization, aside of the common good practices in coding such as documentation, versioning, etc.

Today, most IGA solutions provide all or most of their capabilities via APIs. They support container-based deployments (if running on-premises). They support the idea of microservices architectures.

Customization (as coding) must build on APIs and shift the custom code into separate microservices. These microservices can even expose their own APIs, for instance for providing widgets to the builders of business applications for identity-related tasks such as user registration.

The advantage of this approach is that customizations remain segregated and reside in (per definition small) microservices. As long as the APIs are stable, updating the underlying tool will not break the microservices. Even if APIs change, this can be handled better than in traditional customization. Impact is limited to the microservice(s) consuming that particular API.

Three steps for not failing in customizing your IAM (IGA) to your needs

To summarize:

1. Define your policies and processes first, thoroughly.
2. Build on best practices and minimize "bells and whistles" - most of these don't provide a real benefit.
3. Follow good coding practices for customization, build on the Identity API layer of your Identity Fabric, and isolate customizations in well-defined microservices.

Doing so will help you in delivering a solution that serves the business demand while mitigating the risk of failing by "over-customization".