One of the issues in handling Enterprise level implementations, such as Identity Management is what to do when the project is completed? The answer to that is to make sure it’s monitored and that there is a methodology to manage the implementation.
First of all we need to make sure that all connected sources and targets are up. Normally this is not a problem for most enterprise systems since they are monitored from Enterprise Management systems such as HP Openview, CA Unicenter or Microsoft MOM. It’s essential that in addition to making sure the systems are working, we also need to make sure that the systems are all talking to each other. This specific type of monitoring cannot always be done using these standard tools.
In addition to monitoring it is also important that we can manage the implementation for troubleshooting, maintenance and enhancement. When these concepts are combined, we have a recipe for the concept of Managed Services. When I consider the way that managed services work I see two basic models, which I like to call the Slomin Shield and Roto-rooter, two companies you may or may not have heard of.
- Slomin’s is an Alarm Company that offers central service monitoring. If they detect a problem, they call, assess the situation and take appropriate action.
- Roto-rooter is a plumbing company known for their quick response to service calls.
Both organizations represent effective, but different models for providing essential services, but which one is correct for Identity Management? They both have their pluses and minuses depending on the organization’s business drivers, staffing needs and high availability requirements. Based on some of my thinking this is how these models would work for Identity Management.
- The Roto-rooter model is a reactive model. When an organization sees that something needs to be done, a call is made for support services. More often than not, there is an arrangement for providing these support services. Engagement is made on an as needed basis for dealing with enhancement and upgrade processes.
- I would characterize the Slomin’s model as a more proactive model. In this model, there would be ongoing monitoring to make sure essential servers are responsive. As soon as incidents are uncovered contact is made with corporate IT to provide information on system status and likely causes of the problem. Resolved incident details would be entered into a knowledge base to provide historical data not only on what failed, but why it failed. Furthermore there is an ongoing review of needed enhancements and comprehensive review of patchers to determine applicability.
Like I said before, I don’t know that one model is inherently better than the other. The decision to embrace a particular model depends more on the organizations’ business needs and requirements. I hope to examine the pros and cons of each model in future entries.
