Why Use Cases Should Matter in Identity Deployments

In a comment to a previous blog entry, where I attempt to make the case for Use Cases in Identity Management integration efforts, James McGovern comments:

"First, many folks in the IDM space don't really understand how to create use-cases because it is not a traditional business-oriented scenario.

Second, the importance of getting a PM has to be not on internal nor external but someone who has walked the path before. This is pretty difficult to find even amongst the vendors themselves."

Focusing on his first point, I'd have to agree: use cases really come from the software engineering world (I believe originated from one of the three amigos - Jacobson). Wikipedia has a terse description of what a Use Case is:

In software engineering, a use case is a technique for capturing the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by software developers and end users.

In my opinion, the software engineering world has a lot to offer the identity integration world. Software engineers (and I use that term broadly) typically have a lot more interaction with business users than back-end integration folks. Figuring out how to efficiently produce software that the client wants/needs has been at the center of decades of discussions surrounding dev processes and methodologies. The integration community on the other hand are usually less focused on customer satisfaction, and more about making processes work efficiently and reliably. With the advent of identity integrations, the level of interaction with business development users has increased significantly. Many steps within the process of integrating an identity platform necessitates interaction with business users, such as mapping business processes and ultimately optimizing them (and the various touch points end users will have with it - for example in provisioning workflow), as well as user interaction with password management systems, esso, etc. I do agree that some components of an Identity platform may be invisible to the user, but typically the user will have at least indirect contact with it. (For example, in a metadirectory solution, a self-help name change in an HR data repository might result in a displayname change in their e-mail address or the name that appears on a phone handset.)

Identity integrators usually come over from sysadmin-type backgrounds, and (even those who have done an identity implementation or two) might not have the disciplines a software engineer would have in delivering a solution that the client is pleased with. (Even worse, many PMs for Identity projects that I've met don't seem to have much PM experience to begin with, or might be a sysadmin who successfully ran an exchange upgrade.) The result is what Mark Dixon described as the seven deadly risks, outlined below:

* Poor Pre-Project Preparation
* Poor Requirements Definition
* Large Initial Scope
* Inexperienced Resources
* Poor Project Methodology
* Scope Creep
* Not Using Available Support


The solution might lie in borrowing software engineering processes that would be helpful in initial preparation and scoping of an identity project, as well as ensuring that an iterative process results in happy business users.

To be continued...