Enterprise IDM: Part 1: Organizational Structure

13 Oct 2005 Automated User Provisioning using Role-Based Access Control. You know the concept as you sell it to customer: Sooner or later Mr. Customer decides to implement IDM. And now it is your turn to fulfill what you promised. First thing that you realize is that "few key roles" will not be that few. You will need build the "key roles" from sub-roles, many of which are system-dependent. And soon it turns out that the number of roles will exceed the number of employees. Well, you finally find a way how to reduce the number of roles (I will describe this "Role Explosion" problem later), but you have another problem now.

You need to assign the roles to the employees. You think: "Ahhh, now it's going to be easy. I just got the electronic version of that organizational chart, I'll put it somewhere and I'll hack the workflow to look at it while assigning roles." That's exactly how I looked at it. But now the reality:

First fact that you find out is that there is no single organizational structure source. One structure is in the HR system. And that's for accounting and statistics purposes. Then there is an orgstruct in groupware system. That's used by all that little cozy applications like telephone number directory and micro-workflows. And there are another (usually partial or modified) versions of organization structure in different applications, beginning with Active Directory and ending with quite-unimportant-department-application-that-was-not-really-used-in-years.

All of the responsible people would swear to you that all these structures are only replicas of the one primary organizational structure (usually that one in the HR system). "Oh, well, that's fine. I can choose the one that best suits me", you think. And then you choose one and start to use it in your workflows. All works fine on the test data, but it suddenly break up when deployed in the "real" environment. After a while (that looks like weeks to you, with all these managers screaming around) you'll find out that all the organizational structures were not that much same. And according to Murphy's law you've choosen the worst one. But that not really matters, because later you'll find out that there is no consistent source of organizational structure anyway. One version has most of the data that you need but the relations are all broken. The other has the relations fine, but there is no unique key how to merge these two. And after a while you'll find out that the data there are "a bit outdated" anyway ...

The only thing that you can do is to return back to the architecture&design phase and re-desing the modules that deal with organizational structure. Current provisioning systems are great at merging people records, but fail terribly when it comes to merging organizational structure. So we've developed our own tools to do that. We merge the structure to a single "view" in the Directory Server and use that as a database for workflow decisions. And it quite works.

Moral:

1. Never trust anyone telling you that they have single, consistent organizational structure source that you can use.
2. Allways analyse the quality of data, not only their availability.
3. Provisioning system is not the only tool that you'll need. Prepare to develop your own "gadgets". Make a "padding" in the project plan for the unexpected.