The path to more mature identity management processes and infrastructure can be characterized by a series of steps that gives specific milestones. These milestones are called “maturity levels .” Each level is a reflection of certain capabilities in the organization’s processes and infrastructure. Higher maturity levels reflect greater capabilities and have more advanced characteristics. The maturity model defines the key elements at each level and thus represents a path that you can follow to guide your identity management processes to more mature levels. The path we’ve defined includes four levels and is shown in Figure 15-1. These levels are adapted from an identity management maturity model developed by Gary Daemer of Booz Allen Hamilton.

Figure 15-1. Levels of digital identity maturity

In level 1, the organization has very few processes and the infrastructure design is tactical and ad hoc. At the focused level (2), some projects in the organization have good processes and a designed identity infrastructure, but many do not. At the standardized level (3), the organization has created enterprise-wide policies, processes, and infrastructure. With enterprise-wide policies and processes, the organization can learn from various projects and use that knowledge to improve future projects. At the integrated level (4), policies and processes are very mature and processes have been automated. The infrastructure is complete.

The following sections characterize identity management practices at each level in the maturity model. The characteristics are organized into eight areas: business goals, policies, processes, identity management, identity storage, authentication, authorization, and federation. The characteristics given are illustrative; there are more characteristics than can be enumerated here. Nevertheless, these should be sufficient to give you a clear idea of what each level looks like.

As you go through the process of building an IMA in your organization, don’t try to do too much too fast. For example, you might make the mistake of establishing policies that require activities and behaviors that aren’t yet supported by the infrastructure. The way to avoid this is to have a firm grasp of where your organization is in the maturity model that is presented in this chapter, and then set goals to move to the next level in specific areas.

One thing you should remember is that most organizations will be at different levels of the maturity model for any given process or infrastructure component. For example, it’s possible that a company could have a fully functioning self-service password reset functionality but not have enterprise-wide policies. The key is to assess your maturity in different areas and then set goals accordingly.

Evaluating the maturity level of your identity infrastructure involves evaluating business drivers, processes, systems, and user understanding for each component. As it turns out, evaluating the processes will cause you to evaluate the business drivers, systems, and user readiness, so that’s where we concentrate our efforts.

The first step is to perform an identity process inventory . Starting out, you may not have many of your processes documented, so you have to go search for them. This is where the business function matrix that we discussed in Chapter 14 comes into play. One or more processes support each business function. Depending on how fine-grained you got in your decomposition of functions, you may have to dig a little deeper or come up a few levels to get to the right level for finding processes.

Processes can usually be found by looking for tasks and then asking, “How does this task get done?” For example, asking that question about the task of resetting a user’s password will lead to the processes that use and update identities.

If you’re organization is operating at the ad hoc or focused levels in the maturity model, you’ll find the processes completely fractured according to business function, because they will have grown up independently. As your identity infrastructure matures, identity processes will cut across multiple business functions.

This discussion of processes may not seem to concentrate enough on identity. Be careful not to just pick out identity management processes, such as “password reset,” or you’ll miss other processes that also affect identity. For example, consider the “employee provisioning” process. On its face, this is not an identity management process, but as we’ll discover in the next chapter, it’s a process that is all about managing identities of various sorts.

Once you’ve found the processes, the next step is to document and evaluate them. The following questions and ratings can form the basis for a process inventory:

The factors listed above are illustrative. You may find other factors that are important to you and your goals. You should customize this to suit your needs. Using the rankings that you arrived at in the evaluation should allow you to assign an overall maturity level to the process.

A team of people who are not involved in performing the process day to day should carry out the evaluation. The team can gather data through questionnaires, individual and group interviews, and reviewing documents. You will also need to create criteria that allow the team to make consistent judgments. The evaluation must be done in a way that is helpful rather than judgmental. One way to accomplish this is for the evaluation team to be transparent in its dealing with the process team, sharing data and insights freely, and thoughtfully considering feedback from the process team on the inventory.

Like everything else in the IMA, the process inventory is not a static document, but a tool that is used and updated as necessary. The inventory data is best stored in some kind of structured way (XML or a database), rather than as plaintext documents, so that it can be searched and evaluated. As you move through other activities in building your IMA, you’ll find more identity processes. Have a methodology for adding them to the process inventory and incorporating them into the plan.

As you contemplate building an identity process inventory for your organization, you may feel overwhelmed. Most organizations have no idea how many processes they perform and are often surprised at the size of the number. The good news is that you can often make progress on the maturity of your processes in a piecemeal fashion, making the task much easier to accomplish. In the last section, I said that tasks lead to processes. Tasks are also one of the keys to prioritizing your action plan.

As you look at tasks, try to identify those tasks that are causing the organization considerable pain, because they’re not performed well or those that are costing a lot to accomplish. The processes associated with these tasks are where you should start. As an example, consider that task we mentioned in the last section: resetting user passwords. Most organizations spend a lot of money on help desk-supported password resets, and there can be considerable benefit from automating the processes that support this task.

As you dive into the processes surrounding password reset, you’re likely to find that there’s not just one process, but many. Furthermore, they likely overlap and compete with one another. In an organization at the ad hoc or focused levels, there will be multiple password reset processes for each system and application. Furthermore, the administration of these passwords will likely be manual, requiring expensive intervention by multiple administrators.

After you’ve chosen the most critical processes to improve, envision the goal state for each of them. The goal state would likely include standardizing and documenting the process and replacing the manual processes on the various systems with an automated self-service system. Staffing may need to change, skills may need updating, and metrics developed. You may also move to integrate some or all of the many processes into a single process at the same time, or you may take that as a second step after the systems have been standardized.

The goal state can be documented in the same format as the process inventory given previously. Be wary of creating unrealistic goal states. For example, you may upgrade the technology platform significantly and move the automation ranking a great deal, but the stability ranking may not be able to move much until other process have been redone. Keep current skill sets, staffing levels, and budgets in mind when you’re planning. Its OK to move slowly if that’s all you can do. The important thing is having a process for continuous improvement.

Once you have used the maturity model to assess your current state in any given area and selected a goal, the gap between these two is filled with what we can term “best practices .” The term best practice gets thrown around a lot. For our purposes, we use the term to define activities that have four characteristics:

As I stated earlier, there are many things you will change in your organization as part of building a functional digital identity infrastructure, but I believe the best approach is to build the process first. As part of building the process, tools will be bought and systems will be changed, but those technology pieces are done in response to a process need rather than the other way around. Using process creation to drive tool and system changes results in clearer requirements and systems that meet business needs.

This thinking is antithetical to how many IT organizations approach solving technical problems. When faced with a gap, many turn to a vendor and product to solve the problem. Once the product has been purchased, then the organization gets down to developing a process to use the tool.

Creating a process that leads to your goal state requires several steps:

One of the most difficult tasks is to integrate similar processes across different systems. This can require significantly greater resources and much greater political skill, but is the key step in moving from the focused level to the standardized and onto the integrated levels.

Building a digital identity infrastructure that is responsive to business goals requires assessing where your organization is now and where it wants to go. The identity maturity model and the associated process inventories presented here are a tool for doing that. Once you know where you want to go, processes can be designed, implemented, and fine-tuned to put best practices into place.