Big Sky Thinking

Identity Management solutions are very complex and require collaboration across organizational boundaries, IT systems, and networks. Often times, identity data is assumed to be of sufficient quality (see our Blog entry “The Five Elements of Data Quality”) to provision users automatically, define roles, and develop workflows. Unfortunately, this assumption is often false and has severe consequences on any value that you hoped to get from your IdM solution.

One recommendation that we typically make to organizations that are just starting to build their IdM infrastructure is to release a white pages application as their first step. While the value to the organization is often low, so too is the risk if the application fails. This “low value, low risk” approach does offer significant insight, and value, to a small group of concerned individuals: the project team.

One of the nice things about the white pages application is that you can open it up to your end user community for self-service updates. User attributes like Hiring Manager, Department, phone number(s), and job title can all be opened up for editing. End users can update their own information using self-service tools and publish that information to the directory.

From this simple application we get the following benefits:

1. Visibility into all data stored in the directory
   
2. Ability to troubleshoot the Identity Management infrastructure (connectors, schema, namespace, self-service tools) in a production environment and develop a data remediation plan
   
3. Centralized tool to collect updates for user data
   
4. Validation of user data against standards and business rules before publication to the directory and synchronization with other systems
   
5. Improved data quality across all connected systems

Labels: data quality, directory, edirectory, Identity Management, white pages

In one of our earlier entries, "Identity Management: Observations from the Trenches", we discussed some of the pitfalls of rushing to implement an Identity Management solution without looking at data quality, data requirements, and starting with a point solution instead of an enterprise approach. I wanted to add to that discussion and emphasize the importance of knowing your processes before you implement identity management projects.

Many times a project can seem straightforward both technically and organizationally, but often there is something you don’t know that will send it to the scrap heap. Let’s look at the following example: a company wants to improve the time to provision new hires into their non-connected systems by sending an automated email as soon as the user’s identity is created in the directory. Based on the way the process runs today, the client believes they can save two weeks in new hire provisioning, and they are eager to cash in on this golden opportunity. Fair enough.

At this point, the development team is ready to start building something immediately. The core infrastructure is already in place, we just need to slap in some workflow with emails and we are golden, right? Not so fast. It turns out upon further evaluation, that the organization did not clearly understand their onboarding processes. The assumed bottleneck, that staff were not receiving notifications of a new hire promptly, was not really the problem. Instead, the delay in the process was caused by the manual assignment of the user’s id by another department. This id was required for all provisioning activities, including creation of the user’s identity in the IdM system, which means that system-generated emails buy us nothing; they simply automate a part of the process that is already working fine.

So what are our lessons learned?

a)Bring key stakeholders (business owners, corporate staff, etc.) into the early planning meetings and touch base with them regularly

b) Start by mapping out your processes from recruiting through creation of the user identity in the directory (work with your stakeholders to complete this analysis)

c) Identify key data that are needed (user id, etc.) to support the project, where the data reside, and when they become available along the process

d) Validate your process maps with your stakeholders. Step everyone through the process and discuss:

a. the process steps (Are they correct? In the right sequence?)

b. process timing (How long does each step take?)

c. data flow (What data are available when?)

d. process bottlenecks (What are the slow points in the process? Rank them in terms of time consumed.)

e. process dependencies, and identify any process changes that will be required (Can we get people into the ERP system sooner? Can key data fields be entered earlier? Do we need to change the way approvals occur in the process?)

Labels: business process, directory, edirectory, governance, Identity Management, provisioning