What are the components of an enterprise identity strategy? What do I mean when I talk about ‘direction setting’ for identity management systems in corporate IT? Here are some of those components:

Current state assessment: where are we today? What are the IT systems that will impact the identity infrastructure? What are the requirements for the proposed system? I’m a big fan of simply writing these things down so that people can see them in black and white, because too often there is a shared fuzzy sense of what the proposed system will be doing. Lack of clarity around that shared fuzzy sense is a major risk factor for the success of any technology deployment, especially something as intricate as systems integration, which is what enterprise identity systems are. A good current state assessment looks at technology and business issues together and requires some kind of checkpoint to agree or disagree with the finding before proceeding.

Business process analysis will vary by the type of identity management system you’re implementing and the goals you’re trying to achieve. If you’re simply deploying a core infrastructure capability it might not be as important to do detailed process analysis. Putting in a employee provisioning system that handles not only full-time employees, but also contractors, part-timers, and so forth is going to require more business process documentation. And you have to look at whether you’re paving cow paths or trying to redesign workflows. If you’re not doing at least some process work you’re making a mistake.

Financial analysis: what are the quantifiable benefits of doing the work, what are the costs, and where is the payback? If strategy is a set of allocation decisions, then financial analysis is one of the key tools to making good decisions. But it’s not always done; sometimes, companies are compelled by Sarbanes-Oxley audit findings to build out an identity infrastructure for authentication and authorization to key systems, for example, or they might want to simplify log-in for their employees (the holy grail of Single Sign On). In these cases, they might not bother doing financial analysis.

In general, the bigger the company, the easier it is to justify infrastructure elements such as identity management. But the thing to look out for in any technology business case is the underlying analysis; can you compare this case to another case outside of the IT department? Can a financial analyst without any knowledge of the technology compare the identity management business case to, say, a business case for investment in new machinery or an investment in a growth area of their business? Project finance is a known good, although too rarely known in IT.

Prioritization: For me, this is the core of doing IT strategy and it lends itself especially well to identity strategy which requires Big Design Up Front. Prioritization is simply the process of creating criteria and evaluating options (you can call them initiatives or opportunities or recommendations or whatever) based on those criteria. In its most rigorous form, the criteria are largely financial with technical constraints but in practice they are always a blend of complexity vs. payback vs. political realities. Well-run prioritization sessions, with the proper assessment and buy-in from the people making the decisions, are a lot of fun. It’s where the rubber hits the road.

Technical architecture: typically, we design an identity vault as the centerpiece of an enterprise identity system. This vault draws on authoratitive source systems (e.g., HR, PBX, physical badging, email, file & print, etc.) for user attributes and then delivers these via service directories to consuming applications. But building out this system, and all the interconnections, is complex and requires involvement from both technical and business perspectives — especially the HR department.

Governance: I hope to write more about this in another post but suffice to say that you need to figure out the policies and procedures for managing your identity infrastructure, including the organization that’s going to do the work. This is far too often overlooked.

Roadmap: I think it’s absolutely required to have a plan of where you’re planning to go in phases or milestones or tracks or whatever. At a high level, the plan needs to communicate to the business and technical leadership what the timings and outcomes are going to be. At a more detailed level, you also need to have, consistent with the high level view, some kind of detailed work plan with resources and specific activities and milestones. The point is not to have an inviolable document that everyone slavishly follows; rather, you need to have a central point of coordination so that work proceeds in the right direction. The plan is going to change over time. To be fancy, it’s an emergent strategy. Or, as Eisenhower supposedly said, “Planning is everything. Plans are worthless.”

It’s important to recognize the level at which identity strategy ought to take place. It’s not at the level of designing requirements for a directory. That is too detailed, although that will certainly be one of the elements on the roadmap. And it’s not at the level of designing architectural first principles (security is valued more highly than cost, but cost more highly than agility, say); that is too abstract.

Instead, identity strategy ought to evaluate options at the project level. Recommendations should describe a series of activities each at the level of a discrete project, each with goals and milestones and project owners. The roadmap sequences these into a precedence of execution based on the requirements and the technical architecture and the business case and all the rest.