We frequently hear the comment that an organization’s data is one of its most valuable assets. I think that’s probably true, but the fact is that data projects never go anywhere. There’s never money for a project to clean up the data and create enterprise data repositories. What do businesses care about? Processes, because processes achieve business results. Let me relate a story that illustrates this.

Utah, a relatively small state, manages over $1 billion per year in federal government welfare benefits. Each state is responsible for ensuring that welfare recipients are eligible for the benefits that that state distributes. The majority of these benefits are distributed in four major programs that have different eligibility requirements. The job is made more interesting by eligibility interactions—your eligibility for one program could be affected by benefits from another.

Utah, like most other states, had four different computer systems that automated at least part of the eligibility determination process. The lack of a common identity across these four systems was costing the state real money every year in lost time and improperly paid benefits. Utah had tried years before to create a master identifier and then use that identifier in the four separate data repositories so that records could be linked. That had limited success, largely because it relied on the ability of benefits coordinators to link the individuals across four separate systems as they submitted applications.

The IT departments in the three agencies that administer these four programs could never make the case to business leaders to invest in a common identifier, even though there was real need. What ultimately solved the problem was a proposal to revamp the processes that these agencies used to determine eligibility. The new processes provided more decision support to eligibility agents, making their jobs easier and less subjective. That’s something the business could understand. Utah decided to build a new eligibility system at the cost of tens of millions of dollars that served all four programs. Of course, the new system uses a single repository for client data, solving the problems with multiple identities.

When we build data architectures, we’re doing so in support of business processes. Business leaders in Utah’s health and human service agencies could relate to the process problems that their employees faced and saw real advantage (millions of dollars worth) in updating systems that served those processes, so they jumped on board. Process improvement drove the data architecture improvement.

The last chapter talked about using an identity management maturity model to improve processes. Our approach to data architectures is to drive identity data integrity by incrementally making the use of identities more consistent in business process. We’ll use the process inventory as a starting point and process improvement as a driver for changes in the data architecture.

Suppose you’ve identified “employee provisioning " as one of the processes important to your organization. That process starts when the decision is made to hire an applicant and includes steps such as the following:

When you look at the steps in this process, the employee is right up front. Consequently, it’s easy to identify the employee record in the HR database as one of the identity records in this process, but there are others. Here are some of them:

As we consider a single business process, it’s amazing to see how it can translate into multiple identity records. Process links these records even if the infrastructure does not.

Going through the process inventory to find identity records creates an initial identity data inventory . The data inventory is a listing of each identity data source and its contents and other important meta-information. The following attributes should be recorded as part of creating the inventory.

One approach to creating the data inventory is to have business units create inventories for identity data they own and then to aggregate the results. Be careful, however, to train the people performing the inventory so that you get consistent results. You will also have to take care to ensure you don’t miss data sources that are jointly owned or owned at the enterprise level. As we’ve seen, business function and, hence, process do not always fall within neat organizational boundaries. You may find that it’s more convenient to create the baseline data inventory in conjunction with the process evaluation that we discussed in the last chapter, instead of doing it as a separate step.

The purpose of the identity data audit is to answer additional questions about the baseline identity inventory. Identity data audits should be done periodically, say, once a year, as part of maintaining the IMA. During these audits, the inventory is updated and additional data is gathered that is useful in managing the identity data, doing risk assessments for security and privacy purposes, and protecting against loss.

Someone other than the owner or custodian of the identity data should do the audit, although it might be done on the owner’s behalf. In a large organization, the CIO’s office would be responsible for performing the audit. The audit consists of gathering information through a series of questions and then evaluating the information gathered. The questions we ask are very similar to the kinds of questions we discussed for privacy audits in Chapter 4. A privacy audit can easily be folded into the identity data audit, but be sure to include a specific evaluation of privacy in the results.

Here are some of the questions you might want to ask:

These are only example questions. You may think of others that need to be asked that are specific to your organization or the data in the inventory. Using the results of the audit, you should evaluate the maturity level of this identity data. Don’t hesitate to assign different maturity levels to different aspects of the identity data. The results of the audit should be shared with the owner and custodian of the identity data so that they can offer feedback and correct misperceptions or mistakes.

As you conduct the audits, you should be on the lookout for the following kinds of issues:

Audit data should be stored in a data repository to which multiple people can be given access. For example, some of the information in the audit will be useful for capacity planning, while other information will be useful for security audits. Sharing the data as widely as possible will build support for the process.

In Chapter 5, we discussed the lifecycle for digital identities. The purpose of creating an identity map is to instantiate that general model for each identity record. This should result in a flowchart that shows how and where the identity record is created, how it is used, and where it ends up. Figure 16-2 shows an example identity map for an employee record.

The map in Figure 16-2 is greatly simplified from what would really happen to an employee record in even a small organization. However, it illustrates the point that the identity map is an instance of the general lifecycle. The important parts of the diagram show:

All of the dependencies between this record and other systems are recorded in the map, as well as the critical systems that can modify the record. Note that in this simple diagram, the HR system is the only system shown that updates the record, but that’s not likely to be the typical case. For example, the payroll system may have access to and update portions of the employee record.

Figure 16-2. Example identity map for an employee record

Identity maps are especially useful when you are trying to find the interactions between identity systems and rearchitecting them as part of system or infrastructure upgrades. You may not complete identity maps for every identity record in your organization all at one time, but rather build them as process improvement plans dictate.

The purpose of the process-to-identity matrix is to relate identities to the processes that they support in a visual way. Using the matrix, we can easily identify records that are used by multiple processes as well as identifying areas where different records are serving the same purpose in different processes and might be combined.

Table 16-1 shows an example process-to-identity matrix drawn from the employee provisioning process that we discussed earlier in this chapter. In this matrix, we can see the identity records used by the employee provisioning process as well as how some of those same records are used by the asset management process, the financial audit process, and the enterprise sales process.

Notice that the enterprise sales process doesn’t use the employee record or phone record. At the same time, if we were to dig into the inventory and audit data for the salesman performance record, we might find that it contains employee and phone information for the sales team. This illustrates how we can use the matrix to improve processes by normalizing data so that the enterprise sales process derives important employee data from canonical sources.