The IMA isn't something you build once and then simply use; it's a constantly evolving collection of information, policies, and processes. Consequently, you may find it helpful to think of creating a roadmap or timeline for the process. The roadmap looks like Figure 20-2, but turned into a project plan that repeats steps as necessary to include more and more of the of the enterprise. The roadmap will specify what the scope of the process is now and in the future. A roadmap keeps the process from trying to boil the ocean while at the same time, assuring the enterprise that important issues will eventually be dealt with. The roadmap is the high-level plan for applying the IMA process to the enterprise.
You will be tempted to split the task along organizational boundaries. This is a mistake if your organization is split into functional units such as sales and marketing, engineering, and human resources. Each of these functional departments depends on other departments and interacts with them to a large degree. Consequently, a large amount of identity information is likely being transferred in and out of these departments. Furthermore, any one department is unlikely to have a complete picture of the needed identity information and infrastructure. Thus, an IMA process for the identity functions in the human resources department, for example, will be incomplete and in danger of making assumptions that have to be radically altered in future phases on the roadmap.
A better choice is to pick a division or subsidiary that includes most of its own business functions. Such a unit will have control over its systems and the services it offers to customers as well as the bottom line from those services. Consequently, there is strong motivation to complete the IMA process and reap the benefits as well as sufficient control to ensure success.
Of course, life is never as simple as the theory espoused in a book. For example, the State of Utah had over 25 individual departments, which could have been seen as relatively self-contained business units. Any one of them would be a good environment in which to create an IMA process. The exception was that centralized HR and finance functions served every department. In this kind of hybrid organization, an IMA roadmap would have to address issues in the HR and finance departments at the same time that the IMA process was being applied in one or more business units. Every situation is different, and some creativity will need to be employed to slice the problem up into tractable chunks and lay them out on a roadmap.
An important dimension in the roadmap will be to cover what I call products and projects. I use the term product to denote all of the customer-facing services that the enterprise offers, even if they may not be for sale in the traditional sense. The enterprise portal is a good example of a product that almost every organization has. Ensure that the IMA roadmap includes not just IT projects for internal systems, but also includes products, online or offline, that have an identity component. This may be as simple as considering the customer relationship management (CRM) system in the roadmap at appropriate times. On the other hand, there may be numerous online projects that gather and use identity information independent of the CRM system. Be sure they're included in the process.
As you build the roadmap, it is important to consider the favorable and unfavorable characteristics of the organizations. Some parts of the organization may not be amenable to IMA at the present time because of one or more problems. After considering the characteristics of the business units, there should be some clear candidates for building an IMA. Pick the easy wins and get some early successes for the process. At the same time, the roadmap should include steps for dealing with unfavorable characteristics in the enterprise and mitigate them in parallel with the ongoing IMA process.
The creation of a roadmap will help alleviate fears in the organization that some parts are being left behind. Recognize that the roadmap is not a static document, but part of the overall IMA lifecycle shown in Figure 14-1 and, as such, is subject to constant review and update as the IMA process proceeds.