Digital Identity

Chapter 16. Identity Data Architectures

As part of the State of Utah's enterprise architecture efforts, we completed an inventory of data repositories in the state in early 2002. There were over 250 databases that contained information about individuals and over 175 that contained records about businesses, and this didn't include spreadsheets, Access databases, and other minor repositories. The problem is that we couldn't really tell which records in one database were related to the records in another.

Many people are happy to hear that their government can't link database records, but it hampers many of the electronic government services that citizens would like to see. For example, there are over 20 different databases that keep track of information about health information for children in Utah. The end result is that when a mother brings her newborn in for immunization, the receptionist can't say, "I see that Johnny hasn't had his hearing and vision checked. Would you like me to schedule an appointment?" That sort of simple customer relationship management can't happen when you keep information about your customers in 250 different places.

As you think about the data in your organization, you'll probably find this story resonating with your experiences. Most organizations have volumes of data that has simply grown and expanded over time in a largely unguided fashion. While we like to think of databases as large repositories of multi-purposed information, most databases are simply ...