OK I’m only going off the basis of two projects here – one that failed dismally and another that succeeded nicely – so this list is by no means complete … but it does express a few concepts that I had cause to reflect on, while getting that second, successful project up and running.
In summary, my key tips are:
- IdM Systems Need Constant Babysitting
- You have to Win Trust
- Go for the Slow Creep, rather than the Big Bang
- IdM Systems Must Be Visible
IdM Systems Need Constant Babysitting.
I don’t believe there is any such thing, in the Real World, as a “set and forget” IdM system. No amount of careful planning, error resistant coding and forward thinking is ever going to counter the myriad of data inconsistencies, human errors and straight changes of circumstances that will arise. (And seriously – who has the time for all that planning and perfect code when project deadlines are looming – there will always be something you didn’t think of.) So the IdM system is going to generate errors, and someone is going to have to keep an eye out for them. It’s best if this can be made clear from the outset so that the owner of the system can arrange for a suitably trained babysitter to keep the IdM system humming, once the project team has moved on.
You have to Win Trust
One of the things that makes IdM so fascinating for me is the sheer range of applications it can be put to. This is truly the server application with the potential to have a finger in every pie (and hand-in-hand with that, the potential to ruin the day of the maximum number of users at a time). Unlike many other server-based IT projects, which can be conducted nefariously in darkened back rooms, the IdM project must involve people from throughout the IT department, HR, and other areas of the organisation, all with their particular needs, wants, and current ways of doing things.
With all these disparate strands to bring together, it is inevitable that the IdM project will become, for some people, a source of fear and mistrust… and often, while they’re at it, a very useful target for blame. It can seem surprising, to the well-meaning IdM architect, to encounter opposition from the very people who’s jobs are going to be made noticeably easier through the automation of manual tasks. But yet is it really so unusual? Many people fear loss of control, not necessarily because they think you’re trying to automate them out of a job, but because you’re turning something that they currently know how to do into a Big Unknown. When they have an irate user on the phone they won’t be able to just “go and fix it”. Instead they will have to wait for the invisible machinations of some new-fangled system – in front of the user’s demands they will be simply helpless.
The solution is to consult, consult, consult, involve, involve, involve. Knitting together the often-complex strands of existing directories is hard enough – don’t add to the problems by alienating the very people who could help the most. Otherwise you may well find when the blaming starts being flung in your direction, some of it will stick.
Go for the Slow Creep, rather than the Big Bang
Sometimes on an IdM project you may be lucky enough to be offered the management of a brand new system, right from the start. And as IdM systems become more commonplace there will no doubt be projects involving the replacement of one IdM system with another. But many projects involve taking over the management of a mature, in-production directory that has grown up over time, with several different “standards” applied (if you’re lucky), and some patchwork of existing management that may involve several teams, and a lot of tedious manual work.
When a company is paying for an IdM “solution” the expectation will often be that, at the appropriate time, a switch will be flicked and, hey presto! we have full management. I think that is a surefire route to dooming the project. I have yet to see a test system that truly mirrors all the complexities of the live system (maybe I just haven’t worked in the right places, but I have a strong hunch this is generally the case), and the last thing you need is a shamefaced rollback when the system didn’t do 100% of what it was supposed to.
A better way to approach existing and complex systems is the slow creep. This may be as careful as taking over one attribute at a time. Introduce account provisioning a long time before deprovisioning, so that everyone is more comfortable with the IdM system by the time you raise the scary topic of “automatic deletions”. As well as providing staged milestones with which to measure project success, you will also be doing a fantastic job of the all-important Winning Trust.
IdM Systems Must Be Visible
One of my complaints about MIIS 2003 is that it doesn’t have a client application – only a server interface. Remote Desktop access to the server itself is not something you want to hand out to a general audience, but meanwhile there are probably quite a few people (like Helpdesk) who need to see if password syncs have been successful, or if data updates have gone through to the desired place.
What Microsoft have given us is a facility for writing our own workstation tools. The Developers Reference contains some excellent vbscripts that can be used as a starting point. The scripts for checking password change history and for getting all connectors for a specified user are well worth trying out.
I used these scripts as a starting point to developing my own client application MiisApp (more on this in future posts). It combined a toolkit for querying MIIS and SQL, along with the ability to “watch” MIIS in progress, and access to the import and export logs. By making MIIS readily accessible to other IT staff I hoped to avoid the notion of MIIS as a Big Black Spider spinning its webs in a darkened cave, and instead have MIIS as the Helpful Engine, chugging its way through data updates, new user creations, password syncs and whatever else is needs doing.
