Pollicove's Law of Provisioning

I find it interesting when I see a book listed on a website on the topic of Identity Management is invariably about access management or some other aspect of identity and information security. Now, I completely admit to being biased, but why is there not more thought put out there about the management of identity, a la provisioning, directory/metadirectory design, etc? I know it is possible to find some decent books on LDAP (LDAP Directories Explained is one very good one)but these mostly talk about the LDAP protocol and structural considerations.

Could it be that Identity Management is a much simpler task than we think it is? If this is the case why is the configuration of provisioning systems not a turnkey operation? Particularly since some of the biggest Provisioning vendors support application specific connectors (A topic that I thought I had covered, but I'll definitely cover in an future entry.) one would think that this should be the case.

The problem, as I have often said is this:

Show me any three companies of similar size and vertical, using basically the same set of applications and they will do it in at least three different ways.

Which is what I believe is the basis for what I will now call “Pollicove’s law of Provisioning”

Given x number of companies of the same size and vertical, provisioning (and de-provisioning) activities will occur in at least x+1 number of different ways.

Let's go into this in some detail:

The fact is Identity Management will always be more art than science, even though all companies utilize the same universal basics of Provisioning (Reconciliation, Self Service and Delegated Administration) Every company has its own unique set of processes that have been with them since well before the Information Technology revolution. This happens regardless of Compliance / Regulatory legislation, which further contributes to the uniqueness, with the uniqueness causing factors including, different auditors/methodologies, back end technologies and corporate cultures.

The last part of Pollicove’s law states “in at least x different ways” This is because many large enterprises have multiple provisioning methodologies due to M&A, independent subsidiaries, international presences and other independently evolved divisions of the company. I’m sure we can find more reasons without thinking too terribly hard.

This being said, there has to be some commonality, given some of the universal basics mentioned above. I believe the greatest “economies of scale” covering Provisioning will revolve around these topics. Furthermore specialized features such as account claiming, password management (self service and delegated), and other extensions of the universal basics are where this will come in to play. So in essence, I believe that successful provisioning implementations will come more out of established “playbooks” of how these and other activities are to be conducted. Given time and experience, the successful provisioning architect will come right to the customer with a set of basic use cases, business analysis templates and design outlines which will be quickly turned into complete design docs and implementations.