Workflow is a core capability in any Identity Governance and Administration (IGA) deployment; IGA is all about automating the business processes around managing and governing users and their access.
IGA deployments often take much longer than anticipated and don’t achieve all of what the project set out to do. Why? There are many factors, but the automation of workflow processes consistently come up as one of them.
We often hear concerns that the workflow engine of the chosen IGA product can’t meet the businesses workflow requirements. Perhaps the issue isn’t the flexibility of the tool but rather the business requirements around workflow. In this article we will explore IGA workflow and why it’s important to understand your workflow needs before choosing an IGA product.
Workflow in IGA
Workflow can be used for many functions in an IGA solution, but we tend to focus on two types – let’s call them external (or approval) and internal (or operational).
The external workflows present the forms for data entry/review and drive the user interactive processes. These may be approval for access requests, role changes, access certification and other processes. All major IGA products support some level of external workflow. They may provide for simple linear steps for different groups of approvers (like user manager, application owner) perhaps with escalations and risk checking (like Separation of Duties checks). The other end of the scale is for very flexible workflows with branching, looping, returning a request to the initiator for additional information, sub-processes, and custom activities supporting scripts or programs. Most IGA products will sit somewhere on this simple-complex workflow spectrum.
A trend over recent years has been to leverage external ticketing or service desk systems to provide the forms and workflow capability and pass the approved request to the IGA system. This has the benefit of providing the same interface and usability as other provisioning requests in an organization.
There are often also internal flows that drive the operation of the IGA product; e.g. what steps does the product take when the requested access is approved, what does the product do when bulk-loading new users needing access, what does the product do when reconciling accounts and access against policy.
Some IGA products will allow modification of some operational processes through workflow customization, or the provision of exit points in the process to plug in some custom logic to alter the data or the flow. Other IGA products do not provide a means to alter the internal processes.
What Workflow Should You Strive For?
When planning an IGA deployment, there is a tendency to focus on the external workflows, specifically approval workflows. This is the area of greatest impact to the end users and something the business wants to get right. If user interaction with a tool is too hard, people will find ways around it or take shortcuts. If a tool is more consumable it will be used not bypassed.
As an industry we strive for simplification of workflows. Gartner in their “Critical Capabilities for Identity Governance and Administration” (June 2018) report stresses that IGA projects should focus on business process re-engineering and try to adopt a standard (linear) approval workflow across all requests, rather than adopting unique ones for each application. They even recommend a simple four-stage pattern; Policy Analysis, Manager Approval, Resource Approval, Control Approval.
Adopting a standard and simple approach to approval workflows has a number of benefits:
- It gives a greater range of IGA products to select from – almost every IGA product supports this standard four-stage approach. If all vendors support a simple workflow approach, it’s one less differentiator to worry about and you can focus on the other business requirements and which vendor best supports them.
- Deployment will be simpler and faster – given the design and implementation of workflows is one of the challenges in existing deployments, simplifying and standardizing your workflow processes will reduce the risk and complexity of a deployment.
- End-user enablement is a lot easier – if you only have one standard process, education is simpler.
- Operation and maintenance are easier – a single simple approval process is less likely to cause help-desk calls, and there is little maintenance required.
The goal should be to strive to adopt a single, simple workflow process for all access requests.
But, There’s Always That Unique Requirement
Whilst that is a noble goal, and would certainly help with deployment simplicity, almost every major IGA deployment seems to have unique workflow requirements.
Often there is complexity required by the business for external (approval) workflows, such as branching, looping, and customizable nodes. For example; after manager approval, the flow routes the request off to a department secretary who dynamically decides which senior manager to route the request to. Another common requirement is to be able to route the request back to the originator to supply additional data for the request or have one of the approvers supplement the request data. Sometimes there’s a special condition that needs to be programmatically added to the flow.
We have also seen deployments that have unique requirements requiring alteration of the internal operations. Perhaps there is a need for internal data massaging after the request has been approved. Perhaps an update, like changing the email account for a user, requires calling out to and updating an external HR system. Perhaps reconciling accounts and access may need to trigger some corrective actions. These are all use cases that come up and whilst some IGA products support them through configuration, often you need to rely on modifying workflows or some programmatic approach.
Whilst these business requirements may be seen as historical, political or driven by other needs, they are usually valid for the business, or a specific part of the business. There is only so long one can have a design conversation around what “should” be done vs. what “must” be done.
How to Approach Workflow for an IGA Project?
As outlined above, there is a spectrum of workflow complexity, from the simple linear approach as recommended by Gartner, right up to the very flexible complex workflows.
Almost every IGA product will support the simple approval workflows. So, if you have chosen to adopt simple linear workflows, then you can safely choose any IGA product.
However, you do not want the situation where you have decided to adopt simple workflows and have chosen a product that supports only simple workflows, then get partway through a deployment to find that you have more complex workflow needs that the product chosen will not support.
Therefore it is important to understand what your current workflow processes are and how you plan to implement them into the IGA product before you go to market to select an IGA product. You may need to apply some project discipline on the business stakeholders to decide on the workflow approach and stick to it – if you’ve decided you will only support simple workflows, then get the stakeholders to agree on this and kill any project changes that introduce workflow complexity. If you cannot guarantee that, then your selection of IGA product may need to support very flexible complex workflows.
Finally, what about cloud and IGA? Surely this should simplify this problem. Cloud provides many operational benefits; but unfortunately it does not help with IGA workflows. Some cloud IGA products support flexible and complex workflows, but many only support the simple workflows. Often cloud-based solutions don’t give you the ability to get under the covers to extend applications. Most of the on-prem (legacy) IGA products support flexible complex workflows and as they are on your servers you have more flexibility to get into the application.
In closing, any IGA project will need workflow – we are automating business processes. The challenge is understanding what workflow you really need versus what you think you need. Ideally you would choose the simple approach recommended by Gartner. But if not, you should identify the level of complexity you need, agree on it, then choose the IGA product. This will save the pain of getting midway through a deployment and discovering your IGA product doesn’t do what your business needs it to do.
This article originally appeared on 19 Jul 2019 on LinkedIn; https://www.linkedin.com/pulse/how-much-workflow-do-you-need-your-iga-project-edwards-iamdavid-/
