Blog

4 Steps Towards Taming your Identity Management Initiative

A Case Study: Addressing NERC CIP using an IAM Strategy

Given the increased relevance of NERC CIP compliance in the Energy sector over the last 12 months, we have been focusing on this topic from an Identity and Access Management (IAM) perspective since early this year.  Our CTO, Ash Motiwala posted a couple of very good blog articles on this subject: A NERC CIP Quick Win = Recertification + Closed Loop Deprovisioning and An Introduction to NERC CIP Compliance and Identity & Access Management Technologies.

Next week, on Tuesday, May 11^th from 3 to 4 pm EDT, we will be hosting a webinar featuring a case study by one of our clients in the Energy sector: PPL.  Details for the event and the registration page are available here.

PPL, formerly known as PP&L or Pennsylvania Power and Light, is an energy company headquartered in Allentown, Pennsylvania.  It currently controls over 11,000 megawatts (MW) of electrical generating capacity in the United States, primarily in Pennsylvania and Montana, and delivers electricity to 1.4 million customers in Pennsylvania.

I will be presenting, alongside Pete Johnson, Director of Information Assurance at PPL, and will be discussing their approach to streamlining and maintaining compliance with several regulatory requirements, with a specific focus on NERC CIP, using IAM.  I had the opportunity to work directly with Pete and the PPL team in defining and starting the execution on their IAM strategy, and I believe that this case study will be valuable to any organization subject to multiple regulations in any vertical, not just Energy.  Evidently, the stiff fines that are now enforceable by NERC (of up to US$1M per incident per day), are a very strong driver in the Energy vertical.

Consistent with our style, this session will be very "meat-and-potatoes".  We intend to keep this vendor agnostic, without marketing jargon, focusing mainly on the practical knowledge and experience gained by PPL.  Our intended audience is IT Managers, IT Professionals, CIO, CISO, COO, CTO, IT Directors, and Solution Architects.  We are planning to leave time for a Q&A session towards the end, so I hope you can join us.

Top 10 Common Pitfalls of an IAM Initiative

Hard to believe, but I've been in Identity and Access Management for 14 years. Time flies when you're having fun.

Over this time I've grown and my hair has gone gray a bit. I've been reflecting on my journey so far:  If I had a chance to go back to a particular point in time, I often ask myself, what would I have done differently?

The answer? A few things-personal and professional. For one thing, pursuing a career in professional soccer would have been nice (the thought tends to come back every 4 years in time for the FIFA World Cup). Professionally, I would have taken a slightly different approach to IAM projects and initiatives. In pondering this existential question, my colleagues and I have assembled a very valuable asset-a list of top 10 common pitfalls of an IAM initiative. We use it consistently in our advisory services area to help customers define their IAM roadmap and implementation plan as part of our very popular Kickstart Program.

This list helps us achieve some consistency and a pragmatic flavor in our recommendations; we would not recommend something that runs counter to our experience. We include it in our deliverables and always illustrate each pitfall with a few personal stories, which resonates well with our clients.  It sparks discussion.

In a recent session with a client, a senior stakeholder said: "you know, this list could be applied to any IT initiative, not just to IAM". This to me was somewhat of a revelation, and might give the list below a much broader use, even though it originated from our focus only in identity.

So, with that preamble, and in no particular order, I give you our list of the "Top 10 Common Pitfalls of an IAM Initiative":

1. Focusing on technology before business processes - IAM is far more than technology. Many would argue that it is more aligned with business processes than technology. Yet, many times an IAM initiative is so heavily focused on products and automation, that very little focus is given to business processes. In our experience this results in user dissatisfaction and inefficiencies, where tasks are done in a certain way because "that's how the tool does it." In the long term, this often results in the project being deemed a failure, and the only option being a rip and replace (regardless of the product or technology choice).
2. Automating bad processes - Somewhat related to the prior, but slightly different. Defining a business process is one thing; having a good business process is another. We have seen many examples of this, but one I recall was a scenario in which the on-boarding process took too long and impacted business; so in order to expedite it, a provisioning process was defined and automated, triggered from the entry being added in HR. However, the process of creating the individual's record in HR was done manually after an ad hoc workflow between the HR recruiting to payroll groups completed. And in this handshake there were two points of manual data entry for the same information, and an informal notification process. Downstream, this led to very expedient creation of duplicate accounts for the same user, and at best a marginal shortening of the on-boarding time, often overshadowed by a very convoluted clean-up process.
3. Having an unsupportable infrastructure (leads to abandoning the roadmap) - This one reminds me of Pierre (from Chapter 7 of Tom Freese's "It only takes 1%"). You can have the best IAM solution possible today, but if it takes too much effort to maintain, or if it is so customized that it cannot be effectively supported over time, then it ultimately ends up being abandoned. Assuming that your IAM solution leverages vendor-supplied technology, here is where the Pareto principle is best applied: 80% of the functionality in the infrastructure should be standard functionality of the product, 20% should be customized functionality. Beyond this balance, the infrastructure quickly becomes unsupportable (just wait for the first upgrade cycle).
4. Lack of a roadmap (the initiative loses direction) - There could have been a tactical need that triggered the initiative, or perhaps it was originally driven by a department or line of business. However, without a defined evolutionary path, aligned with business objectives, it is all too common to see the initiative dissipate and implode. Here is when we see customers implementing similar solutions in different parts of the organization, rather than leveraging one, as well as ripping and replacing existing IAM infrastructure; devolving into a vicious cycle, ala Bill Murray's Groundhog Day. Becoming reactionary in nature, reacting to immediate needs, such as technology upgrades or incremental functionality needs, sans roadmap. The symptom we tend to find during our assessments is that the organization is constantly reacting to IAM requirements, as opposed to anticipating them.
5. Lack of executive sponsorship - I concede that this one is far from unique to IAM, as it would be common to any IT initiative. But this is one of the most common mistakes made. Whether IT or a line of business leads the effort, unless it has a committed executive sponsor with visibility and decision making power, the initiative is doomed from the onset. My colleague Clint Finch elaborated on this one in a recent blog post. We believe that this is the main reason why IAM initiatives that fail, fail.
6. Treating IAM as a project, not as a program - This is my favorite one, and at the risk of being controversial, I would say that this is the one plaguing the 2010's IAM initiatives. The issue is that even with executive sponsorship and a well-defined roadmap, without ownership, stewardship, continuity and context, the initiative will not achieve its goals. I applaud organizations that not only recognize the importance of this concept (many of which learned by trial-and-error), but embrace this by creating organizational structures that define the role of an IAM Program Manager (titles may vary of course). Having a senior leader, dedicated, empowered and motivated to make the program a success over a multi-year period is instrumental in the success of the IAM initiative. On this one, my argument is that the reverse is most often true: "treating IAM as a program, not as a project", significantly increases the chances of success for the initiative.
7. Too much, too soon - Managing scope is of course essential to any initiative to succeed, and IAM is no exception. What we believe is that an IAM initiative should be split into phases, and that these phases should not exceed 6 calendar months. Beyond that, we have seen organizations lose faith in the initiative, because it takes too long to derive value, which ends up draining the initiative. Each phase should have a meaningful scope with well-defined and measurable milestones that address prioritized business needs. Balancing what goes into each phase, how much is enough is of course critical, and highly dependent on the organization's business drivers. Empirically, there is something about the number "1200 person hours" that is consistent in successful IAM projects, so I tend to look for 1200 multiples to gauge how much goes into each phase. It is also very important here is to also consider the impact that the IAM program will have on end users - minimizing end user change will prove wise. Our CTO, Ash Motiwala, published an excellent 2-part series on scoping an IAM project (here is part I and part II), which are now our most read blog articles.
8. Not managing expectations for the dollars allotted - This one is perhaps a legacy of the 90's, when there was very little experience with IAM, and vendors ruled the world. So when a client had a budget set aside, most of the allocation would go into product procurement, leaving insufficient funds to fuel the end-to-end implementation of the solution. From there emerged "X factors", which became a way for clients to rank vendors - "vendor ABC's typical implementation is 3X the cost of license" or "I would go with vendor XYZ, since their TCO is about 5X the cost of license." We have improved in this area over the years, but the point remains: organizations need to set and manage the right level of expectation with their executive sponsors, and this is not just the cost to procure, architect, host and deploy the solution; but also the cost to operate and maintain it, as well as the impact that it will have on both the organization's applications landscape and end user training.
9. Not having the right team for the job - This pitfall is typical of the 21^st century, and in my view, the second most popular reason why an IAM initiative may fail. With deep specialization and over allocation of resources typical of today's organizations, having the right team is much more than just having the right skill sets and knowledge, and the right organizational structure, but it is also being clear on the resource availability. Even if you have the right people, but they are not available to devote time to the initiative, it will go nowhere. In our roadmap definitions, we spend time discussing our recommendations around the right structure to execute the work, and highlighting that there is a core team and a supporting roster. For example: an on-boarding or termination (provisioning and deprovisioning) project will go nowhere unless the appropriate stakeholders from HR are available to actively work on the project, particularly during the requirement analysis and design phases. Below is an example of an IAM initiative staffing structure we that we have recommended.
10. Poor technical architecture - This one is related to item 3 above, but it has more to do with the conception of the IAM infrastructure. There are choices that become very difficult to change or adapt later on if you have a poor technical architecture. There are no silver bullets here, and it's not like you can just decide to start from scratch and ignore what your IT environment already looks like. However, there are some questions you can ask yourself to validate your architecture:
• Am I leveraging the right tool for what it was intended? Are we using a meta-directory instead of a provisioning engine? Are we using a NOS directory when what we needed is an enterprise LDAP] directory?
• What if our company acquired another company or was acquired by another company? How would my IAM architecture adapt to something like that?
• What if we needed to change our [LDAP] directory schema? How would applications react to that? Would they need to be recoded?
• Are we wiring authentication into the applications, or is it being consumed as a service? What if we decided to move away from user name and passwords for authentication? Would we need to recode all the applications?
• How would this architecture scale over time both in terms of response time performance, administrative staff required to support it, and geographical coverage?

All right, there you have it. No parallels should be drawn between these and the David Letterman's top ten - or the Ten Commandments. Incidentally, I would really welcome somebody breaking down these 10 items ala George Carlin. Seriously though, your comments are always welcome.

Considerations for an Identity Management Initiative in 2010

First off, I would like to express my sympathy to victims of the terrible earthquake that hit Haiti. I can only wish that the rescue and recovery efforts yield positive results.

Thanks to the recession, we have learned a lot (or so we would like to think) on the importance of sound business decisions, have we not?

This blog post is my attempt to bring some of the lessons learned, along with scar tissue, that I have been able to sum up from the last 24 months, as it relates to identity and access management initiatives. Last year, I spent time reading some Harvard Business Review articles, and recall reading a blog post titled: "6 Lessons Learned in the Downturn" by Anthony Tjan, which were very influential in shaping my thoughts for this post.

At the risk of stating the obvious, I would start by saying that the last 24 months have forever changed the way in which Identity initiatives will be carried forward.

It is clear that identity and access management systems are, more than ever, critical parts of any IT infrastructure. Organizations will always need to grant application and system access to those who need it and eventually remove that access once it is no longer needed. This is a recession-proved observation. The circumstances of today's economy highlight the need to tackle these activities in a more efficient, transparent and scalable way, and in most cases, automation is about the only choice you've got. Manual labor is way too expensive today, even when outsourced. This should be an encouraging statement for any identirati.

5 Lessons Learned

Below are five points that best capture the essence of this change.  These are based on experience working with clients across many industry verticals:

1. Your dollar needs to go a much longer way than before - If you even have an approved budget, you really need to maximize the value you will get from your initiative, and be ready to show how. Consider getting a second opinion before you buy new IDM technology. Ask yourself some questions:
• Have you done proper due diligence?
• Do you or your team have the cycles to invest in carrying out the proper due diligence?
• Are you relying only on what the vendor says or what you read on an analyst report?
• Do you have enough insight on how to negotiate with the vendors you have selected, based on what is important for your initiative?

We have seen from experience that even a nominal 2-week investment in an Identity Management Workshop that assesses your current state, identifies business drivers, high-level requirements, and formulates an implementation roadmap can go a long way.

A case in point: One of our clients allocated $750,000 in budget to acquire IDM technology in 2009.  Before moving forward, they invested in a workshop and in the end, identified a set of previously unknown requirements and ultimately saved 40% ($300,000) in their purchase, all within 8 calendar weeks. Considering what they spent on our services, this is an ROI in excess of 450%. Not bad in any type of economy if you ask me.

2. Minimize capital expenditure if you can - Consider lease vs. buy scenarios. The maturity of IDaaS today provides options for customers to avoid procuring software and hardware products that require capital expenditure, and instead consume them on an on-demand basis as an operating cost. This of course will maximize your cash-at-hand. Evidently, not all of your identity and access management needs can be met with an IDaaS approach, at least not today, but I would argue that 24 months ago this was not even an option to consider. There are several approaches to IDaaS, which can be appropriate to your initiative. It may be worth exploring these and engaging with providers that specialize in these kinds of models. Not all organizations are ready or comfortable with an all-in-the-cloud approach, but there are managed services models that work on-premise that should be explored.
3. You have to have metrics - For identity and access management initiatives, there is no longer room for soft ROI; hard dollar is king. As you define your Identity initiative, you need to think about how you can measure value and ROI to the organization. For some organizations, which adopt internal chargeback models for managing budgets, this should be relatively easy. The idea is not to stop at simply measuring costs, but ensure that you are measuring returns. In a way, try to make your metrics meaningful to the lines of business that you support (i.e. your internal clients). A metric that is often overlooked is time to value - everything being equal in cost, you should look to shorten the wait until you can show measurable value to the organization. In practice this will help you decide how you undertake your initiative. Maybe shorter phases are better than longer ones. Perhaps rather than a pure waterfall project management approach, you start to introduce agile methodology concepts. We have seen initiatives whose budget is cut in mid-flight. Even though you cannot fully prepare for this, you want to consider what you will show for if it ever happens, and whether or not delivering value early is the key to preventing your funds from being cut in the first place.
4. Let's demystify identity management - This may get controversial, but after 14 years of experience in IDM, I would like to demystify it. I agree that IDM is complex, requires specialized skill sets, and above all, is unforgiving if you do not have the right experience, but at the same time it is not unattainable, and settling for less is not the right posture. There are many ways to meet compliance requirements, even if you have not automated all of the access granting flows in your environment.

I applaud the advent of identity activity monitoring (the term we like to use to describe this new trend) in 2009, and while the analysts have not yet coined a particular name for it, there is a great report by Gartner's Mark Nicolett and Earl Perkings that focuses on this area, separate from just SIEM or just IDM, more as a separate niche in its own right.

I intend to further discuss identity activity monitoring in a future blog post, but for now, I would describe it as an approach to tracking user activity in various IT systems and applications that is correlated to the definition of a digital identity; thus creating a closed feedback loop that allows you to more confidently determine if your IDM controls are effective, regardless of whether they are automated or manual. In this way, organizations have a way to extract value out of lazy assets (such as application, database or system logs), which otherwise are used only for security event monitoring, and leverage them to increase visibility into what users are doing within the IT infrastructure. This is a very clever and effective way to approach some of the compliance requirements that Identity initiatives often try to address, in a faster and cost effective way. Moreover, it does not conflict with a traditional IDM implementation, but rather complements it.

5. Understand and embrace identity assurance - this is not limited to scenarios in the extranet in which users from one organization interact with systems in another - scenarios that some would deem esoteric and not as business critical. Even within the same organization, you need to pay attention to identity lifecycle as a whole and not just as discrete steps: provisioning, authentication, single sign-on, etc. Consider the intersection of identity assurance with your data and risk classification, and ask yourself: am I spending too much in authentication technology and too little in the process of ensuring I know who the person is? Is it the reverse? Strong authentication alone is useless from an identity assurance perspective (a good friend assures me that a well-trained Labrador could figure out how to use a smart card - although I have not seen the documentary on TV yet). The point here is to ensure that your effort and investment is balanced in light of your requirements. Otherwise, you may be wasting precious dollars.

To illustrate, here is a real life example: a client has a request/approval process in place to manage the issuance of access cards (with no picture ID) to various facilities in their organization. When an employee first comes on board, to issue an access card, they undergo a process of vetting their identity against information in HR, and that the request that has been approved by two management levels. Now, since the process often takes a few days to complete, some managers tend to hold on to the access card from a departed employee, and literally keep them in a drawer. When a new employee comes onboard, the manager recycles the access card and increases the employee's productivity by orders of magnitude, but all access activity and access authorization is based on the departed employee's information. The organization is now incurring significant costs to ensure that access to its facility is tightly managed, but the process for ensuring that a departed employee event triggers the deactivation of the access card is not well enforced.  So in the end, this imbalance in identity assurance costs the organization money and does not really mitigate the risk it was intended to.

I would love to hear comments and feedback on these points, particularly if you disagree.

On Developing an Identity Management Roadmap, Part III

In part 1 and part 2 of the series on roadmap development, we covered scenarios where you should not develop an IAM Roadmap and some of the prep work towards developing one.  In this entry, we'll cover the actual steps of working out a roadmap.  Hat tip to Luca, who left a comment on part 1 of this series which helped provide some direction for this blog post.  Luca asked:

How can a long-term road map help to achieve a good outcome (architecture, software, finance) in highly dynamic environments? In your opinion, is it possible to put down a road map that can be useful even after plenty of mergers and reorganizations? I am wondering if is possible to define a road map that could be, in the same time, enough flexible, to be respected also after some important changes, but well defined, in order to be useful and drive choices in the right direction.

My short answer to the question is, yes, I do believe that it is possible to develop a flexible roadmap that can weather the storm of environmental changes. The core is to approach the development of your roadmap using a proven and agile methodology (we at Identropy have developed our roadmap development methodology). But before we get there, a little background information is in order.

An IAM roadmap should consist of multiple phases or iterations, where discrete use cases are implemented in each phase.  Each phase should have an average duration of 3-4 months --, slightly shorter or longer is acceptable, but we try to never exceed 6 months at a time; and identifying 'Lessons Learned' and a 'Roadmap Review and Adjustments' exercises between phases is critical. You cannot assume that the roadmap is static, it needs to be adjusted and recalibrated.  The total duration of the roadmap should range between 12-36 months. Beyond that timeline, your roadmap starts to lose touch with reality and its value diminishes.

The following is our 5-step process for IAM Roadmap development:

1. Assemble the Building Blocks (Use Cases)

 The building blocks of any roadmap are the identity initiative use cases that you have already identified as important for your organization.  Furthermore, each use case should be related to a set of requirements.  All of which must have been developed prior to roadmap development, as described in part 2 of this blog series.

2. Discover Roadmap Placement Criteria

Roadmap Placement Criteria are meant to serve as a guide towards placing a use case in a specific phase within the overall IAM program.  Our fixed criteria are 3, and are seen in almost every identity management program:

• Value: How valuable is this use case to the organization?  Many times, this is directly related to who the use case is important to within the organization. For example, if the CEO has a directive that the use case addresses, then its value to the organization will be greater than that of a use case that addresses a departmental need, not directly aligned with the critical path of the organization.      
• Complexity:  How complex is it to orchestrate the completion of this use case? Complexity should not be viewed from a purely technical perspective, but as a whole – is there a capital investment required? is the organization ready to undertake the initiative? does it have the right resources and change management approach? is there executive sponsorship and organizational alignment to make it happen?. For example, most Identity Provisioning projects today are not terribly complex from a technical perspective, although they can quickly become complex due to political reasons.
• Dependencies:  Does the use case require that another use case be completed prior to addressing it? Is there a logical progression for tackling the use case that makes sense to sequence?  This could be an architectural dependency (which it often is), although it could take a broader meaning. For instance, you may address a smaller-value, but related use first to build momentum, credibility and build experience and confidence, which will help you undertake the higher-value use case – in a way “walk before you run”. Other factors may be taken into consideration based on the organization's priorities, such as  timeline dependencies (for instance based on compliance-driven deadlines) or specific “quick win” use cases.

 

3. Create a Roadmap Analysis Diagram

Once you have identified the use cases as well as the criteria, you will need to create a roadmap analysis diagram that displays the information in a consumable format.  By placing all relevant information in a single diagram can be instrumental in forging meaningful dialog towards developing a roadmap.

In the diagram above, we've kept it simple by representing the 3 main criteria: complexity, value to the organization and dependencies. Complexity is represented on the x-axis, value on the y-axis, and dependencies as arrows between use cases, which are represented by the green boxes. You could extend this chart as needed to accommodate additional criterion as appropriate (for example, by adding a z-axis, but we tend to get lost after the third dimension).
Placement of use cases (green squares) in the correct place on the chart can be a tricky endeavor, and should generate fruitful debate among stakeholders. The particularly challenging part of this exercise is to have a fair degree of consensus of the relative value and complexity that the organization assigns to each use case. Clearly, this will vary greatly for each organization, and hence why there is no “cookie cutter” approach to an IAM roadmap.

Advice: A good piece of advice that our clients have found useful is to start with extremities (the most and least valuable, mostand least complex), and place all other use cases on the chart relative to those. We typically iterate a few times through this chart before we discuss it with a broader audience. Additionally, we suggest that you start with two dimensions first, say value and complexity, before you factor the third dimension, say dependencies.

 

4. Translate the Roadmap Analysis Diagram into an Implementation Plan

 By taking the information gathered during Roadmap Analysis, use cases can be intelligently placed in different "buckets" that represent a phase. Which once defined and sequenced, will become your Implementation Plan.  Phase 1 should consist of foundational components that can be quickly identified from the Roadmap Analysis Diagram by singling out use cases with multiple arrows pointed towards it, without any arrows emerging from it – this is a good way to identify your “quick wins”.  Phase 1 should be relatively rich in “quick wins”, or use cases that have no dependencies and fall in the top left quadrant of the Roadmap Analysis Diagram: lowest complexity, highest value. Analyzing dependencies should also provide insight into parallel vs. serial execution/implementation of use cases.

 

Advice: Each phase should last an average of 3-5 months.  Since the success of your IAM program is so heavily dependent on incremental wins in order to build momentum, as well as feedback and lessons learned, anything longer than that should be broken down into sub phases.  Two 3-month phases are almost always better than 1 6-month phase. Also, at present times, we believe that any Implementation Plan that extends further beyond 24 months becomes unrealistic, and there is no use in forecasting activities that far out, since the pace of changes will undoubtedly invalidate most of your assumptions, not to mention the pace of technology evolution may provide different options to achieving the objectives.

 

5. Vet Results with Executive Stakeholders, and Get Their Support

Once completed, vetting the roadmap with executive stakeholders is critical. An executive stakeholder can provide valuable insight that will better align the roadmap to the organization's drivers.  During this exercise, demonstrating your thought process is as important as the actual roadmap that you've arrived at.  Expect it to be altered. In fact, be disappointed if it isn’t.  But, if you fail to provide a framework for executives to think within, alterations can break the overall approach you've spent so long thinking through.  Here are a few questions you'll want to have answers to for before this session:

• Can we complete this roadmap in less time? Perhaps by adding more resources?

• Can I implement a specific use cases earlier if necessary?

• Can implementation costs be reduced by executing 2 of the phases in parallel?

• What risks do I face for stopping after a specific phase and taking a break until the following year?

Spending up-front time constructing the right framework for your organization during the roadmap development exercise will prove invaluable to your efforts in the long run.  It will allow your organization to be flexible and make informed decisions (instead of reactionary responses) to the cross paths that lie ahead. At the same time, by having the executives engage in discussions and revisions of the roadmap, your chances of securing their support (and thereby securing funding) drastically increase. In another blog series, we will talk about the most common pitfalls in an IAM initiative, and not having executive sponsorship is perhaps the “kiss of death” for any IAM initiative. Hopefully, this series has provide you with enough tools and confidence to navigate your path, but we do recognize that every organization is different and there are externalities (such as a recessed global economy) that will greatly impact an IAM initiative, regardless of how well your IAM roadmap had been developed, but to quote the great Wayne Gretzky: “you miss 100% of the shots you don't take.”    This concludes our 3-part series on Developing an Identity Management Roadmap.  We hope you've enjoyed it, and look forward to your comments...

On Developing an Identity Management Roadmap, Part II

In Part I of this series, we covered why a corporation may (or may not) need an Identity Management Roadmap. In this post, we'll briefly cover its prerequisites.

Roadmap Development should be viewed as a discrete task that is only one component of an Identity Management Workshop. In fact, Roadmap Development should be the last (or one of the last) tasks in your identity management assessment. Here is a brief description of a few items that you should have explored during your workshop prior to the task of Roadmap Development:

1. Drivers

Your organization's business drivers for the IAM (Identity & Access Management) initiative will set the overall tone of the workshop, and should be the first item you discuss. Based on a detailed discussion of the drivers, an Identity Initiative Definition document should be drawn up, that labels your drivers, and a brief paragraph that explains each one and how it relates to your initiative. For example, a business driver may be "Acheiveing Compliance to XYZ Regulation", where the description describes why its important to your organizatoin.

2. Use Cases

For each driver, a set of use cases should be developed that explains in human readable language, the scenario you are facing, and a description of the expected behavioral response of the identity management system.

3. Business Process Analysis

Business Process Analysis is probably a heavy term for what needs to be accomplished here. Part of the Identity Management Scoping Exercise will identify all processes, user populations and target systems in scope. An analysis of the in-scope processes should occur in order to measure complexity of any process re-engineering and technology mapping efforts.

4. Technical Infrastructure and Competency Analysis

A survey of the current infrastructure will provide insight into the complexity of integrating an IAM solution, as well as the assets currently owned by your organization that may be leveraged as a part of the solution. During our workshops, we often find clients own more than they know - a finding that saves significant software dollars.  Also, an assessment of your organization's technical competencies is important, in order to take training prep into consideration during roadmap development. 

5. A Proposed Logical IAM Architecture

By creating a suggested logical IAM architecture prior to creating a roadmap, your organization will unearth technical dependencies between the various components of your identity management solution - a key finding that will inevitably impact how you lay out your roadmap.

 - - - - - -   

Hopefully the points above have elucidated why an efficiently orchestrated Identity Management workshop will not dive head first into the tricky task of Roadmap Development. A lot of prep work has to be completed in order to lay the right foundations for the task. In the next section of this series, we'll focus on the actual tasks of developing a roadmap.

On Developing an Identity Management Roadmap, Part I

Since we've performed more identity management workshops for our customers than I care to count, I thought a blog series was in order to provide some of our insights into aiding corporations develop an Identity Management Roadmap (which is a step by step guide for your organization to follow when deploying an identity management solution).   I got a chance to sit down and interview some of our 10+ year identity gurus to collect some of their golden nuggets of identity wisdom for this series.  Heck, this may even inspire and enable some of you ambitious folks out there to develop an IDM Roadmap for your organizations yourselves!

But I Don't Think I Need an Identity Management Roadmap

...and you may be right.  Here are a few pointers that might indicate that an Identity Management Roadmap might be overkill for your organization.  If you have a very specific itch that needs to be scratched but nothing more than that, then you probably do not need an IDM Roadmap.  An example of a localized itch is if your organization just got slammed on an audit for "orphan accounts" in AD, but everything else was in perfect order.  Another example is if you work for a healthcare organization that needs SSO to appease the docs who have to remember 25 different usernames and passwords for various applications, but everything else is in good shape (i.e., identity data integrity looks good, user access recertification processes are fine, etc.). In situations like these, find the right technology and apply it. Simple as that.  At most, you'll need an afternoon whiteboard session with an Identity Management specialist to help you compare the pros/cons of the various toys in the identity toolbox that can solve your problem along with a cost analysis of software and services.

Why do I need an Identity Management Roadmap?

If you have more than a few identity related problems that you are trying to solve that may require more than one identity management software component, an Identity Management Roadmap will be critical for successfully putting a solution in place for the following reasons:

Architecture: Too often, we perform an Identity Management Assessment for a customer that already has an Identity Management system in place and find a hodgepodge of technologies poorly assembled together into what they deem their 'Identity & Access Management System'.  In most cases, the various components of the system were deployed in isolation of each other, often times by different teams.  Each team thought they had an isolated itch, purchased software, and deployed it.  The result is a poorly constructed system that is repeatedly taped together with 'customizations'.  The process of developing a roadmap will avoid such an end.  A good workshop will identify stakeholders across your organization, set up interviews, and systematically find itches (use cases) corporate-wide.  The result will be a better architecture that satisfies your organizations requirements as well as stands the test of time.

Pitfalls:  The process of developing a roadmap will help you see the big-picture of your organization's requirements and strategic direction.  This can ensure that your efforts don't get sidetracked by tactical endeavors, something that can easily occur without a roadmap to guide you. Identity Management initiatives are full of technology related time-sinks that give techies a 'really cool problem to solve,' but may not be a part of your corporation's business drivers. From another angle, a roadmap forces you to think strategically, taking timeline into consideration and focus on identifying time-sinks up front.  

Exploit Your Software: The process of developing an IDM Roadmap will require a technology assessment of your infrastructure.  Often times, we perform an Identity Management Assessment for a customer and find plenty of existing software that can be used to satisfy some of the client's requirements.  It wouldn't be an over-exaggeration to state that on average, corporations use less than 20% of the capabilities of the IDM software they purchase, usually due to a lack of understanding the product's capabilities.  The process of developing an IDM Roadmap will help unearth valuable software that you already own and could perhaps leverage in your identity initiative. How great would it be to find out that you could spend less on software because you could leverage what you already own?!

There you go. Three solid reasons why you should develop a roadmap prior to implementation.  As you might have noticed, there are a lot of pre-requisites to the IDM Roadmap. That is the topic of our next post in this series.