The Devilish Details

Mark Dixon is asking what some common success/failure factors might be for Identity Management projects.

To me, talking about success/failure of an IdM project is like talking about success/failure of a home plumbing renovation. Technically the project is a success once the water starts flowing — but the real story is in how long you went before you could take that first shower, how much $$ you had to lavish on the project, and whether you had to rip the drywall out again a week later.

I think the essential problem lies in the fact that IdM tools are built and sold on the strength of their ability to handle common, well-understood business scenarios, but the companies that try to implement such tools are messy conglomerations of systems and process with almost as many exceptions as there are rules.

My experience has been that the companies most likely to get into trouble are:

  • Companies with long & varied histories of mergers & acquisitions.
  • Companies with fractured lines of communication between different provisioning entities.
  • Companies with executives who *think* the business processes are straightforward but don’t take the time to dig any deeper.
  • Companies who are afraid or unable to take action when business process problems become evident during attempts to automate.

My strongest advice for companies starting IdM projects is: know your business processes and survey your repository content & structure to determine conformance to those processes before you try to assign a cost or a length to your project. Otherwise, what’s really happening is that you are giving your IdM project a bad rap – because they are having to perform both a business process audit and a technical implementation of the results all in one go, and when that happens, timelines slip.

Look at the small things – that is what will drag you down. Look at things like identifier life cycles across different systems, like identifier length limitations, especially on legacy systems, look at case sensitivity and encodings (ie Latin-1, UTF-8) of both names and identifiers across systems (especially mail systems, and even if you don’t believe that anyone in your company has a name that uses fancy characters), look at how geographically diverse your AD forest is and understand what the processes for choosing the fileshare that home directories & mailboxes get allocated onto, as well as whether those allocations or other business process decisions depend on departmental or locational data. If they do depend on departmental or locational data, is that data actually present in reliable format and in a consistent way from a data repository? This last question is CRITICAL – because if the only way a user gets placed on the right fileshare, or into the right groups is due to the fact that the person who enters the data into the system “just knows” where the right place is… well that’s tough to emulate in a system, and you had better anticipate a little consternation from the deployment team.

The bottom line is, garbage in, garbage out:

  • the complexity of your IdM project is directly related to the complexity of your business processes, especially those that are non-standard, or that have multiple originations.
  • the initial length & cost of your project will be related to how much/badly your company diverges from the common scenarios covered by IdM tools.
  • the likelihood that you will stay on-time and on-budget within that project depends on how close your initial understanding of the gotchas and exceptions are to the reality of your specific situation, and how good you are at forecasting what time will be needed to deal with all the things out there that you haven’t found yet.

Not that I have strong opinions on this subject or anything :-D

5 thoughts on “The Devilish Details

  1. I’ll try to add a corollary.

    After you know your business practices, get software that can be adjusted and configured to align with them. Do not buy software that requires you to make significant changes in your business practices, no matter how wonderful that software is.

  2. Eric, I have to disagree with your corollary. It happens quite often that software integration projects illuminate business processes that *should* change — not because the software dictates it, but because the business process is poor in the first place.

    Also, very few businesses are going to find software that 100% aligns with their business processes. Companies need to understand that there is always integration work, the question is just how much and is it worth it.

  3. I know what you mean, Pam. And I can’t argue with you. I can give you an example of what I’m trying to talk about, though.

    Consider PKI software. The vendor tells you that you need a Registration Authority (RA). What gets lost in many enterprises is that the enterprise already has one, and has had one for years. In universities, there has always been a business process called enrollement and matriculation for students. But what always seems to happen is that a new business function and office is created that’s called an “RA”. The result is that students have yet another place to report to become part of the university. Often, this is encouraged (a softer word than dictated) by the software and the vendor.

    I think we are in cozy agreement on the main, and by far the most important, point. Understand your business processes!

  4. I too think we are in cozy agreement on the main point – and it’s really interesting to hear about the cases where the edges get frayed, too – thanks for the example.

Comments are closed.