Identity Management Project Continuum

I recently had a discussion with some sales folks who were interested in the Identity Management project lifecycle. The question came from a product sales perspective as in How do we know where a client stands in the big picture of IdM? ...or more pointedly How do we know which product to pitch to a given company based on how far along they are? I laid out what I like to call the Identity Management project continuum.

Implementing IdM is not a single project. Nor is it even a few stand-alone projects. I call it a continuum. The folks at TNT recently posted a blog describing IdM as a lifestyle. I think that's a great way to think about it. I was, though, a little annoyed about their claims regarding software vendors. They suggested that because we sell software we don't understand the customer perspective. I think they're wrong about that -- at least with some of us. In an ideal world, businesses looking to deploy IdM would have someone competent driving the boat -- maybe an employee, maybe a consultant, but probably not a software vendor. We provide tactical tools to get the job done but that doesn't mean we don't get the big picture. We just typically wouldn't want ownership of the big picture. That's not our focus.

To get back to the topic, the continuum is not black and white. It necessarily varies for every business based on their data, infrastructure, processes and business needs. For any given business, the phases will occur in different orders, their prioritations will vary and some phases may not be required at all.

Below is a sample outline of what I described as the continuum. It's meant to be a general guideline and a starting point for discussion. It's certainly not trying to be a one-size-fits-all project plan

Vision and Roadmap - This is important. You should identify and clearly document the goals, business drivers and overall approach. List the general timeframes and expectations.

Data Cleansing and Reconciliation - Most organizations have multiple data sources that are stored in different formats with different technologies. Step one is usually identifying the data sources, cleaning the data as-needed and creating attributes that can be used to join records together.

Basic Account Provisioning - The first step provisioning may be as simple as automated account creation but could also include single-step workflow or automation of group/role memberships.

Basic Password Management - Management of passwords is often a key driver for IdM projects due to the organizational cost savings.

Basic Auditing - This step should involve initiating the collection of audit data and a few basic reports. Advanced reporting based on captured data can be implemented down the road.

Build/Strengthen Centralized App Authentication - This can be implementing SSO, consolidating authentication mechanisms, reducing the number of authentication stores or otherwise improving the application authentication infrastructure.

Advanced Provisioning - Build upon the basic provisioning infrastructure with advanced workflow, additional business rules, improved deprovisioning functionality and inclusion of additional data sources and/or applications.

Internal Federation - With an established infrastructure for authentication and entitlement, federation may be the next step. Here you adopt a standard and think about how you want to pass authentication information across security boundaries.

External Federation - After the basic federation infrastructure is in place, you may be ready to enagage in cross-organizational federation with customers, service providers and partners.

One other thing...

While I'm writing about projects, I'd like to give a nod to a great set of blogs by Mark Dixon about IdM project risks. While I don't think the ideas are completely original (I'm sure Mark would agree), they are indeed brilliant. And Mark organizes and explains the information very well. If you are embarking on an IdM journey, these are a must read:

Seven Identity Mgt Implementation Risks, Mark Dixon (1/25/06)
Identity Risks - Poor Pre-Project Preparation, Mark Dixon (1/31/06)
Identity Risks - Poor Requirements Definition, Mark Dixon (2/04/06)
Identity Risks - Large Initial Scope, Mark Dixon (3/14/06)
Identity Risks - Inexperienced Resources, Mark Dixon (4/14/06)
Identity Risks - Poor Project Methodology, Mark Dixon (4/24/06)
Identity Risks - Scope Creep, Mark Dixon (7/26/06)
Identity Risks - Not Using Available Support, Mark Dixon (7/27/06)

I'm really glad Mark is writing about these. If he hadn't, I might have felt the need to try it myself. I probably wouldn't have done such a nice job and definitely wouldn't have had the audience reach. ...I look forward to reading more from Mark about the four other risks.