Blog

Identropy Adds New Advisory Offering: the Identropy IAM Primer Series

Identropy adds a new offering as part of its well-known Advisory Services: the Identropy IAM Primer Series.  This offering not only provides access to Identropy's IAM best practices library, but also provides direct access to an Identropy IAM professional.

Our seasoned Identity and Access Management (IAM) professionals, each with over 10 years of experience in IAM, have created IAM best practices reference documents that capture practical and empirical knowledge in various aspects of the identity and access management landscape, spanning business processes and technologies. They are intended to educate IAM initiative stakeholders of industry best practices and facilitate their adoption in a cost-effective, self-paced manner, thus helping organizations improve their business processes by making optimal use of IAM.

In addition to the best practice documents, the offering includes five hours of direct access to an Identropy IAM professional.  Rather than read a static document, customers can also engage in a live conversation regarding the practical aspects of an IAM initiative. This approach will help organizations get started with a specific IAM topic with the practical hands-on guidance that is often missing in IAM initiatives, thereby leading to a more effective approach to adopting and implementing the solution specific to the customer's environment.For more information on this Identropy's IAM Primer Series, click here: http://www.identropy.com/iam-primer-series/

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.

Identity Management Project Scoping, Part II

In my last entry on Identity Management Project Scoping, I wrote about putting together a "PUT" chart, and creating Business Process Correlation sets. If you have been following along, at this point you should have a pretty telling matrix of processes, user populations and target systems, along with correlations and priorities.

Here is the next step...

Step 3: Provide a Non-Technical Description of Each Process

This one could be a bit time-consuming, but well worth it. For each Business Process Correlation Set, provide a short non-technical description of the process flow from beginning to end. For a more detailed method of describing the workflow, create a table that follows the template below (a sanitized example from one of our clients):

...

 At the end of this excercise, you should have a pretty good handle of what business processes you are looking to automate, the target systems, the user popuations, the priorities, and a good grasp of the process as it stands today.

Typically, the total set of data that you have completed will need to be broken down into a phased implementation.  An Identity Management Consulting firm should be able to guide you in the process of translating the results of the scoping excercise above into an Identity Management architecture, help you find a solution that works for your specific requirements, as well as help you put together your very own Identity Management Roadmap (yipee!).  All fun stuff, and good practice when engaging in an Identity Management project.

 

 

 

Identropy's Identity Management Solutions 101 Series

Our goal is to keep you informed and highly educated on identity management solutions, trends and business.

 

Identity Management Solutions 101: User Provisioning 

 

Identity Management Solutions 101: Password Management 

 

Identity Management Solutions 101: Enterprise Single Sign-On 

 

Identity Management Solutions 101: IaaS (Integration as a Service)  

 

Stay tuned for more sessions about topics such as Deprovisioning, Cloud Computing, SOA and others.

Identity Management Workshop: Critical Ingredients

An Identity Management Workshop can be a fantastic way to start an IdM Project - if it has all the right ingredients.  Unfortunately, with the wrong ingredients an Identity Management Workshop could erode the valuable goodwill of the participants, making the critical starting phase of your Identity Management project all the more difficult.

We've compiled a checklist of some of the right ingredients for a successful Identity Management Workshop. Enjoy!

Give Yourself Some Prep Time 

Prep time means gathering some information about your Identity Management initiative such as business drivers, technical drivers, high level business processes, budget parameters, current technology infrastructure, resource limitations, etc. If you get your hands on a Pre-Workshop Questionnaire, spending time with your team filling it out should help unearth some valuable information and help you set your parameters.  

Heaps of Stakeholder Participation 

A workshop should not be an IT-only initiative (since IT-only Identity Management initiatives tend to fail). The appropriate representation from various departments and business segments of your organization will ensure that the discussions will be balanced and couched in terms of real-life business processes.  Do your level best identifying the stakeholders that should be present, and who in your organization best fits those roles. 

A Pinch of Skepticism and a Bunch of Conversation

Too much skepticism can be a barrier to communication, but just a pinch might enhance the conversations during the Workshop.  A few things to be skeptical about:

• A one-size-fits-all solution
• A 6 month roadmap
• A lecture (the value of the workshop is the conversation it initiates)
• Someone trying to sell you something. (This should be about your organization, not an "offering"!)

Mix in Some Business Processes Analysis

At the heart of an Identity Management project is enhancing identity-related business processes. The absolute wrong way to begin analysis of your environment is to start talking about data synchronization and go up. Start by analyzing the relevant business processes, then analyze how they impact the systems/applications in your environment, and finally analyze how those interactions impact the underlying data.

But Hold the Software Vendors

A workshop led by an Identity Management software vendor will most likely lead to skewing your requirements to match the vendor's capabilities.  It would be more appropriate to use a neutral third party Identity Management Consulting firm that can help you unearth and refine your requirements first, and then provide you the relevant information regarding vendor capabilities to help you make an informed decision.

So there you have it. I'm sure we missed something, so feel free to add in the comments section!