Before we get too far into discussing the IMA governance process, we should spend some time discussing the IMA lifecycle . Figure 14-1 shows that lifecycle, in general terms. The first thing to note is that a lifecycle implies a continuing process, and that’s exactly what we’re hoping for. The IMA should be an ever-evolving architecture that reflects current business needs. The IMA lifecycle is an up front acknowledgment that the IMA will affect the business on which it is built. As the IMA is built and put into practice, the business will change. The lifecycle feeds those changes back into the architecture to create a dynamic process.

Figure 14-1. Identity management architecture lifecycle

The cycle starts with modeling, by which we mean the process of understanding the business, data, application, and technology environments within which the identity infrastructure will exist. We will spend a great deal of time in later chapters discussing the modeling aspects of identity management architectures. Modeling is not just where we start, but where we return, time and again, to gage the vitality of the IMA and monitor the ever-changing environment.

The second phase in the lifecycle consists of planning and documenting. This is an important activity that takes the models built in the first phase into account and creates plans for meeting the identity needs of the organization. This is the phase where standards are defined or set forth, certification requirements are laid out, and policies are created and discussed.

In the third phase of the lifecycle, the plans, policies, standards, and so on that were created in the second phase are reviewed. There might be several iterations back through the modeling or planning activities before they are finally approved. Once they are, the plans and policy are considered in force and, in a healthy organization, should be considered binding.

The next phase of the lifecycle is labeled communicate. You should not interpret this to mean that the other phases are carried out in secret, and this is the first time that others in the organization are informed of what’s happening. To the contrary, we’ll see that the entire process is designed to involve as many people and communicate the happenings as broadly as possible, even gaining consensus around important ideas before they are approved.

However, after the plans of the second phase have been approved in the third phase, they need to be communicated as approved plans and be maintained in a way that they serve as a reference for others in the organization who used them in their work. This implies more than simply sending them out in an email and hoping that everyone keeps the most recent copy. The communication phase requires version control, authoritative storage and presentation, easy reference, and searching.

The IMA is used in the implementation phase by system architects and others in the organization. The IMA should affect what is bought, how systems are built, and how data is stored and used.

The final phase of the IMA lifecycle is one that is often overlooked, but plays a crucial role in turning what would otherwise be a dead-end planning exercise into a living, cyclic process: auditing. Auditing is, perhaps, an unfortunate name, because no one wants to be audited. Even so, the feedback that the organization gets from comparing the plans to the implementation and then suggesting changes is invaluable. Just the number of outflows from the auditing box should be a clue to its importance. The audit might suggest changes to implementations to bring them into compliance with established plans. Alternately, the audit might suggest changes to the plans themselves, because they are unworkable in certain situations or not accomplishing their goals. Lastly, the audit might suggest changes to the models based on an evaluation of existing conditions.

Creating an IMA requires the help and cooperation of multiple people from many different organizations within the enterprise. In order to coordinate their actions and create an atmosphere where the results will be accepted and used, the process for creating the IMA, approving it, and enforcing its provisions, must be clearly delineated.

Figure 14-2 shows a sample governance model for creating an IMA. This figure does not show a new organization, but rather a relationship between roles that will be assumed by people already in the organization. We’ll see how these roles interact in detail in this chapter.

The governance model presented here is certainly not the only one that will work, and it will need to be tailored to your organization. The objectives of the model are the following:

Figure 14-2. Illustrative IMA governance model

As you read the following description of roles and processes, keep these objectives in mind. That will help you determine how best to map this model onto your own organization.

At first, the information that follows may seem like overkill. The temptation will be strong to just get a few trusted people together and tell them to determine a strategy and then sell, or even announce, the new strategy to the rest of the organization. In some organizations, it may even work. Before you do that, carefully read and understand this chapter. I think you’ll find that it’s not as complicated as it appears at first, and the various roles and procedures serve useful purposes that are worthwhile.

You can take specific steps in the initiation phase to help ensure a successful outcome of your IMA process:

The following sections describe these steps in more detail.

The first step in the initiation phase is to create a vision for what the IMA will accomplish within the organization. Creating the vision requires more than simply writing the vision down, although that’s certainly necessary. Creating a vision is a collective effort among the people who will have to buy off on and participate in the IMA activity.

The first step in creating the vision is for the enterprise leader (perhaps the CEO or the CIO) to establish the need for the IMA and to issue a challenge to the organization to create one. The challenge should spell out, in high-level terms, the objectives that the IMA activity is meant to accomplish. For example, the objectives might be:

These objectives should be placed in a charter that is communicated widely within the enterprise, both to business and IT units.

After communicating the charter, the next task is to develop a “straw-man” vision that describes a target digital identity infrastructure fulfilling business goals and objectives in a generic way. The following are specific steps you can take to help create the straw-man vision:

With these steps completed, it is time for a series of meetings among those in the enterprise who are the influencers and leaders. The goal of these meetings is to establish a shared vision, translate the high-level objectives into more specific goals, and assign roles to specific members of the organization. These facilitated meetings should build from the “straw-man” vision developed earlier into a group consensus around the outcomes that will result if the IMA process is successful.

Facilitated meetings are an established way of creating shared vision, and I recommend that you employ a trained facilitator. An experienced facilitator will be able to consult with you on specific techniques for achieving the goals of the initiation phase, and can help adjust the meetings and processes accordingly.

Assigning roles and responsibilities for the IMA effort is an important step and should occur as a result of the meetings that create the vision. Rather than define these roles in terms of positions, we’ll describe them generically with some hints as to how these generic roles map onto some common organizational structures.

The roles that we discuss in this section were influenced by the NASCIO Enterprise Architecture toolkit.^[*] The NASCIO toolkit identifies eight primary and seven supporting roles in the creation of a governance model for an enterprise architecture. I’ve adapted those roles into an IMA process. There are two categories of roles: primary and supporting. The model in Figure 14-2 shows only primary roles for clarity. Table 14-1 shows the primary and supporting roles that support the IMA governance process.

One of the first tasks and a critical success factor is to find and allocate resources. There are two primary resources necessary to get started: people and computer systems.

The roles discussed in the previous section will be assigned to people within the organization. Customize the roles to work within your enterprise and create an organization chart for the IMA process that mirrors the roles found in Figure 14-2.

Next, determine the time commitment for each role. In a large organization, the IMA team, manager, and communicator roles will likely be full-time assignments. Smaller organizations might assign the manager as full-time and assign IMA participation as an additional duty for everyone else. Additionally, the number of IMA team members varies with the size of the organization. I recommend a team of three to seven people, depending on the size of the organization and whether they are full-time or not. Teams larger than seven people can be unwieldy to schedule and manage. At least one person on the IMA team will need to provide clerical and reporting support.

An important part of assigning IMA roles is to contract for time with the participant’s supervisor. For full-time roles, this may be a formal HR process. For part-time roles, the contract should be a written acknowledgment by the supervisor of the person’s roles and responsibilities within the IMA activity and the expected time commitment each week. Executive intervention may be necessary in this stage to get commitments for the key people.

Team members must be able to easily share their data and documents. Email can fill this need, but you may find that a more formal tool for this purpose is helpful. I strongly recommend the use of a content management system for sharing results, managing document versions, distributing reports, and communicating progress. The content management system needn’t be expensive. Plone, an open source product, will work fine for many organizations. Also, free or low-cost weblog software can be used to communicate progress and important information.

You’ll see, as we continue through the book, that there are survey and data collection aspects to the IMA process. Survey products are available online and should be sufficient for much of the required survey work, but the data will need to be pulled from the survey and manipulated. In many instances, spreadsheets will suffice, but there may be some sophisticated data reporting requirements that require database and web skills that go beyond the ability of a small team to self-support. IT resources for managing the database and wrapping it in data entry and query forms should be committed to the IMA team as necessary.

One of the primary arguments of this book is that identity is a central to the business, and business goals and IT activities can only be aligned through a new approach to managing identity. Otherwise, why would someone go to the effort of creating an IMA?

That being the case, building an in-house competency in identity and the processes for managing an IMA is crucial. Only by direct contact with the processes and systems will your organization know enough about how identity is being used in the business to have it make a strategic difference.

Early in the process, you may need to delegate critical aspects of creating the identity management architecture to outside consultants who can guide the process and have specific skills that in-house personnel do not have. Figure 14-3 illustrates the process of moving from external consultants to internal specialists over time.

Figure 14-3. Moving from external consultants to internal specialists over time

The trick to managing this is that if you turn too much over to external consultants early in the process, you may fail to learn the competencies necessary to bring the process entirely in-house. To alleviate this problem, you should avoid putting external consultants in most of the primary roles in the governance process and use them as advisors only. There may be specific tasks that need to be outsourced, such as conducting a particularly specialized set of interviews or a technical survey and analysis. Over time, however, reliance on external consultants will be costly and keep your organization from developing necessary skills. Identity driven businesses should own rather than rent their identity management architecture.

As part of creating the vision, we discussed the importance of gathering information about the business objectives and goals. That’s a crucial first step in creating a business context within which the IMA can be fashioned.

When I was the CTO for http://iMall.com, I knew exactly what we did: we created specialty hosting solutions, including e-commerce tools, for small and medium-sized businesses. What’s more, I knew exactly who was doing what, because I’d hired most of the 125 employees myself. I had, for all intents and purposes, perfect knowledge of iMall’s business model.

Later, when I was CIO for the State of Utah, I had a much tougher time getting my arms around the business. First, governments are large, even the governments of relatively small states. Second, they do a lot of things. At first it seemed impossible, but there are specific things you can do to understand an organization, even one that’s complex and loosely coupled.

Our model of the business will provide us with two important results: a business function matrix and a set of guiding principles for the IMA effort. Both of these are important to creating an IMA that is sensitive to business objectives.

A business function matrix (BFM) is a matrix that documents the business functions that your organization performs and which organizations within the enterprise perform them. The steps to creating a BFM are fairly straightforward:

Creating the BFM might not take very long in a simple business like iMall. In a complex organization, the process might take considerably longer. The U.S. federal government has a BFM called the Business Reference Model that was assembled over the course of several years.

Organizations’ units are arrayed along one axis of the BFM. The chief decision is how fine-grained you want to be. It’s entirely reasonable to start the process with a high-level, abstract view of the organization and then drill down into more specific information as the IMA process evolves.

The goal of building a business model is to determine what functions various parts of the company are performing. If this were a business book, we’d be concerned with finding out if those activities led to competitive advantage, but that question is clearly beyond our scope. We’re merely trying to find out what happens, not decide whether it’s the right thing or the wrong thing. Your organization may have already performed a competitive advantage exercise, and in that case, the information about who’s doing what will be readily available. In most cases, however that will not be the case, and you’ll have to start from the beginning.

In the end, you should have a list of functions that the various organizations in your enterprise perform. This list should give the function a name, organization that performs it, and contain a brief description. In many cases, the description will be a list of subfunctions. Some of the functions may seem very similar to functions performed elsewhere in the organization. We’ll normalize this list later.

Build the function list by talking to members of the various organizational divisions and asking the following kinds of questions:

As you work your way through the organization, divide each function into subfunctions by decomposing it into smaller steps. “How do you...?” is a good question to ask to get the answers that lead to decomposition.

Remember that our goal is to understand the business and how identity is used in support of business goals. As you perform the functional decomposition, make note of any functions where identity information or activities are being used. This information will be helpful in understanding identity processes that business units use to accomplish their function.

There are a few caveats:

If you just turned to this section from the Table of Contents, you might be expecting a list of important principles for creating an IMA. Sorry to disappoint you. Rather, this section is about creating your own set of guiding principles that reflect the culture and objectives of your organization.

As I described earlier in this chapter, we created a process for defining how we’d make e-government the standard way of doing business for Utah government. One of the most important things to come out of that process was a set of principles for e-government in Utah (see "Principles for E-government in Utah“).

We created these principles using a facilitated process where over 100 people broke into smaller groups, brainstormed principles, and then chose the ones they thought were most important. We brought all those groups back together, had them present their results, and then the entire group determined a short list of seven principles that were the most important.

I’m confident that we ended up with a set of principles that represented the feelings of the business and IT leaders in Utah state government. Over the coming months, these principles served as a charter of sorts that we could refer to. These principles grounded the discussion in important objectives and kept it on course.

Building a similar list of principles for your IMA process will bring the people whose support you need together and make them feel like a part of the process and the decision making. You’ll be more sure that the decisions made further down the road will gain widespread support if they are based on principles that everyone helped create.

An important part of this process is the up front work to educate the participants in the crucial ideas and let them form educated opinions. We were lucky in Utah that we’d been discussing e-government for several years, so almost everyone had a core set of beliefs and ideas. In addition, Governor Leavitt had been a strong proponent of e-government, and had made his own views evident in cabinet meetings and other venues. These things made our job easier.

One way to jumpstart the process is to get people thinking about where they stand on some key, strategic choices. Burton Group has published a list of IT architecture principle areas that can be used to start a discussion of principles and guide people to an enterprise-wide set of core principles. I’ve adapted these to issues relevent to an IMA. The revised areas are shown in Table 14-2.

Areas in the Management column raise questions about how management feels. Is your organization risk averse? Does management expect an optimal solution? Is IT (and hence and the identity infrastructure) treated as a cost center or a means of competitive advantage? What degree of autonomy does the IT organization have? Do projects have to be justified in strict ROI terms?

Areas in the Vendor column raise questions about the enterprise’s feelings toward your organization’s relationships with vendors. Do you prefer to work with single vendors or are you comfortable integrating products from multiple vendors? Is it important that you have a second source for mission critical products and services? Do you prefer open solutions? What level of vendor risk is your organization comfortable with? What is your philosophy toward outsourcing?

Areas in the User column raise questions about the enterprise’s feelings toward users. Are users required to use services and infrastructure created by the IMA or is such use optional? Does IT bill for services? Is IT expected to support all users or just some?

Areas in the Identity column raise questions about issues we’ve discussed in the earlier sections of this book. Where can your organization use accountability to augment or replace strict access control? What plans do you have for federating identity information with partners? Does your business see identity in terms of security or as a business enabler? What is the attitude toward privacy? Are you engaged in self-service-style online transactions with your customers?

Don’t try to come up with a principle for each area in Table 14-2. These are just areas to jump-start your discussion. In the end, you should come up with 6 to 12 principles that are the most important to your organization. This list should be communicated widely and used as the basis for the activities that follow.

Creating the governance process, fashioning the business function matrix, and establishing the guiding principles for the IMA are critical steps. They form the backdrop against which we build the IMA. The next chapters will jump right into the specific components of the IMA. The first step is to understand the identity management maturity model and build a process architecture.