An issue that seems to come up with every identity management project, and increasingly with privileged access management projects, is whether approvals workflows should run in a parallel or serial fashion. To clarify, we’re talking about cases where there is a request for something – create a new user, change someone’s entitlements, grant access to a privileged account, whatever – and two or more people have to approve it before it can be fulfilled. When this happens, should we invite those people one at a time, or all at once?
As it happens, I have a pretty strong opinion about that. 😉
From a security perspective, I think it makes no difference. The security policy generally says “so long as persons A and B (.. and C and …) agree that the request is business-appropriate, then go ahead and do it. Conversely, if at least one of the individuals in this set says “no” then block the request.
In other words: security policy has no preference for concurrent vs. serial. It just says “meet the minimum requirements and get no rejections before proceeding.”
What about the responsiveness (SLA) of the system? If you invite authorizers sequentially, then the time elapsed after a request is submitted and before it can be fulfilled (assuming it gets approved) is the sum of the response times of the individual authorizers. i.e., T(A) + T(B) + T(C) + … If any of the authorizers is slow to respond, the request will take a long time to complete. This is bad for business. Alternately, if the approvals process is concurrent — i.e., we invite all the authorizers at the same time, when the request is submitted, and fulfill it once they have provided the minimum required set of approvals, then the SLA is max( T(A), T(B), T(C), … ) — i.e., fulfillment happens after the slowest authorizer gets back to us. Definitely better.
OK, so security doesn’t care and SLA prefers concurrent approvals. What other variables are there?
One argument raised is “we did it this way on paper and we don’t want this project to turn into a business process re-engineering quagmire.” That’s fair – to a point. If the old process identified who should approve something, and all you change in the new process is sequence, but not basic security logic, then I’d argue that you aren’t really doing business process re-engineering. Instead, you are applying a minor optimization (more favourable process timing) to an old process. In other words, unless you have some intense politics to overcome, I’d say rearrange the process timing and don’t turn it into a big discussion.
Another argument I hear in favour of sequential authorization is that in the event that an early approver rejects a request, this saves subsequent approvers from the trouble of being invited to review the request. Approvers get fewer junk e-mails and are happier as a result. Makes sense – but how often does that really happen? In talking to our customers, I’ve learned that well over 90% of all requests are approved. This is for many reasons, including: (a) requests submitted by automation are almost always correct; (b) business users have better things to do than submit dumb requests; (c) everyone knows that there is an audit trail, so they don’t want to be caught requesting things that are not business appropriate; and (d) when requests are rejected, it’s almost always due to errors in input at request time, rather than the *intent* of the request being denied. i.e., if we do better form validation for the requester, we’ll wind up with even less rejected requests.
So the nuisance-to-later-approvers effect is very minor at best. From a business value perspective, what’s more important? Rapid fulfillment and tight SLA for change requests, or 1-in-10 or 1-in-20 request e-mails being pointless because someone else might have been able to reject it before you. I can’t speak for everyone, but it takes me less than a second to delete a SPAM e-mail. Maybe a few seconds to read a workflow request e-mail and decide that it’s nonsense. I just don’t buy the nuisance argument in favour of serialization.
So thus far we have 1 vote and 3 abstentions – SLA is better if we invite authorizers all at once. Security doesn’t care, the business process re-engineering argument is a paper tiger and the nuisance argument doesn’t stand up to data about real-world approval rates.
The final question is configuration complexity. Which is easier to setup in the workflow engine – serial or parallel? While nobody talks about this much, I think this is the main reason for choosing one system over the other. It is *very* difficult to configure a traditional workflo wengine to invite an unknown number of approvers all at once and then to wait for a minimum set of approvals before proceeding. Indeed, with a traditional flow-charting tool, it’s quite a nuisance to configure even basic approval processes with a fixed number of authorizers, once you allow for reminders, escalation, delegation and so forth. Try drawing a flowchart for N approvers (N not defined in advance) who are invited to review something, get e-mail reminders if they don’t respond quickly enough, get replaced with alternates if they continue to remain silent, etc. Very hard to draw.
In my opinion, people impement serial workflows really for just two reasons: (a) they used to do it that way on paper and (b) their workflow system lends it self to serial approvals more than to parallel.
That’s a terrible reason to do anything, by the way. “I’ll do it this way because my tool can’t manage anything better.”
Get a better tool.
Of course, I’m biased, because Hitachi ID Identity Manager is designed for concurrent invitations sent to a variable number of dynamically selected authorizers, by default. Plus early escalation away from authorizers who Exchange says are out of the office. Plus reminders, escalation and delegation. Out of the box.
So next time you think about approvals workflow, please consider a parallel process. It’s just better – better SLA, same security, no downside that I can see.