Customizing Identity Governance & Administration (IGA) within Identity & Access Management (IAM) is a common practice, but how much is too much? This question becomes more pertinent as organizations increasingly seek to adapt COTS (Commercial Off-The-Shelf) and IDaaS (Identity-as-a-Service) solutions to their specific needs. The tendency to “over-customize” remains prevalent, even as IDaaS solutions evolve. Iso, let us explore when customization makes sense and, more importantly, how to avoid the pitfalls that come with excessive modification.
Customization vs. Configuration: Let’s Clarify
First, let’s clarify what we mean by “customization.” Customization involves writing new code—whether through traditional coding, low-code, or no-code platforms. Configuration, on the other hand, refers to adjusting settings within the system, ideally through the user interface or, if necessary, via configuration files. While low-code/no-code approaches have gained popularity, they don’t entirely mitigate the risks associated with customization, especially without proper documentation, version control, and staging environments in place.
Why Customize IGA Solutions at All?
The first and most important questions to ask are: Do we need customization in IGA solutions, and to what extent? These are two separate questions. Based on my experience, the amount of customization typically required is far less than many organizations assume.
Most IAM processes, including the management of Joiner, Mover, Leaver (JML) activities, can be standardized. Yes, there are variations and organization-specific requirements, but these are often at the detail level: How many approvers are required? Should approvals be sequential or parallel? Even these specifics can often be addressed using best practices. Several vendors provide process frameworks, or you can consult experts for tailored frameworks that align with your organization’s needs.
At the core, every organization needs to onboard employees, manage their access, handle job transitions, and de-provision access when necessary. These are universal requirements, and best practices can address them efficiently. Yet, many organizations still customize excessively, resulting in unnecessary complexity and cost.
The Real Reasons for Customization
There are several reasons organizations end up with highly customized IGA solutions:
- Legacy Processes: Many organizations are reluctant to let go of legacy processes, opting to map outdated workflows onto new systems. Worse, when organizations have multiple sites with their own “ways of doing things,” customization often spirals out of control.
- Lack of Standard Frameworks: While process frameworks exist, not enough vendors offer them out-of-the-box, forcing organizations to build their own—often from scratch.
- System Integrators: Cynics might argue that system integrators benefit from customization projects. However, this overlooks the downsides: dissatisfied customers, extended project timelines, and increased risk.
Does Switching Tools Solve the Problem?
Many organizations, when faced with a failing IAM (IGA) system, rush to replace the tool. While a tool change might seem like the solution, it rarely is. The problem usually lies in the approach to customization rather than in the tool itself. Even IDaaS, which inherently supports less customization, only mitigates the issue to a certain extent.
A well-functioning IGA system doesn’t begin with the tool. It begins with clearly defined policies, processes, and organizational requirements. In projects that suffer from over-customization, the underlying issue is often the absence of well-documented processes. Without this groundwork, simply switching tools won’t help.
Customization: When and How
I’m not suggesting that customization is entirely unnecessary. There will always be specific needs that require customization. The key is to minimize unnecessary modifications and do it the right way when needed.
- Rethink Processes: Before diving into customization, take a step back and critically evaluate your processes. Do you really need that custom approval workflow, or is there a best practice you can adopt?
- Avoid Backend Coding: A frequent source of trouble in IGA projects arises from coding directly against the backend, such as databases. If the database structure changes in a software update, the custom code breaks. Instead, work through APIs or create an abstraction layer to keep customizations stable.
- Segregate Custom Code: Modern IGA solutions provide extensive API support and container-based deployments. Custom code should reside in microservices, consuming the APIs of your IGA system. This ensures that updates to the core system don’t break your custom code. Even if the API changes, the impact is isolated to the specific microservice, minimizing disruptions.
Three Steps to Successful IAM (IGA) Customization
To ensure your IGA solution withstands necessary customization without failing, follow these steps:
- Define Policies and Processes First: Ensure your processes are thoroughly documented and follow best practices before even considering customization.
- Minimize Unnecessary Customization: Many customizations provide little real benefit. Focus on what truly adds value to your organization.
- Follow Best Practices in Coding: Build customizations on the Identity API layer of your Identity Fabric, isolate them in microservices, and ensure proper documentation and versioning.
By following these guidelines, you can deliver an IGA solution that meets your organization’s needs while avoiding the risks and costs of over-customization.