Sources of Data

Now you should have a list of all the data elements you want to include in your directory service. It is time now to take a slightly broader view and determine where you will obtain the values for the data elements and how you will manage the relationships with other data sources.

By now you probably have a pretty good idea what data elements exist in electronic form in the other data sources within your organization. Some data elements are unique to a new application you plan to deploy; thus the data values themselves may not exist anywhere yet. The following are common data sources:

• Other directory services

• Network operating systems

• Databases

• Simple files or spreadsheets that hold data in electronic form

• Applications

• Administrators

• End users

You may need to obtain data from any or all of these sources. For each data element you plan to include in your directory, you should decide the following:

• What data source will be consulted to obtain the initial data values?

• Will the data element be updated from other data sources on an ongoing basis?

• Will changes made in the directory be propagated back to any other data sources?

The information you have already gathered about each data element should help with these questions. You may not have all the answers when you initially deploy your directory service, but it is important to give some thought to these issues in advance. You do not want your directory service to hold out-of-date information, nor do you want your directory service to be accused of trying to supplant other important data sources such as the Human Resources department's database (unless that is part of your charter). Common data sources and surrounding issues are discussed in more detail in the following sections.

Tip

When surveying the data sources present in your organization, be sure to ask yourself whether each one will be important a year or two from now. If a system will be decommissioned in the near future, you may not want to invest much effort in studying it (unless of course your directory service is destined to replace it).

Other Directory Services and Network Operating Systems

Your organization may already have a large, central directory service. If not, you probably have departmental local area networks (LANs) that include some kind of network operating system such as Novell NetWare (with data held in Novell eDirectory servers), Microsoft Windows 2000 Server (with data held on Active Directory domain controllers), or Sun's Network Information Service (with data held in NIS servers). You probably also have data in DNS servers.

If the kind of data held by these systems is relevant to your directory project, find out what data these systems contain and how it is being used. Think about whether the LDAP directory service you deploy can take the place of some of these existing directories. Also consider replicating data between the various systems; replication should prevent the problem of having different values for a data element present in several systems.

Databases

Your organization probably has several database systems (relational, hierarchical, or other) that hold interesting data. Examples include customer databases, the human resources or personnel database, student databases, and databases used to manage network resources. Another example is your in-house private branch exchange (PBX) telephone system (if you have one); its database probably contains the most up-to-date telephone number information.

In general, you will view these existing databases as gold mines when populating your directory service with an initial set of data. Do not be surprised if these systems are hard to work with, though. Often they are old, expensive to run, difficult to make changes to, and difficult to tie into other systems. Some databases may impose unreasonable restrictions on certain data fields, making the databases fairly useless as data sources. For example, a PBX database may be able to store only six characters for a login ID, whereas most other systems allow eight. These kinds of restrictions also make it difficult to propagate information from your LDAP directory back to the database if you ever want to do so.

You will need the cooperation of whoever runs these databases to get the data you want. Thus you may need to spend time lobbying to convince them that your new directory service is valuable to them and to the organization as a whole. But persist in your quest; existing databases often hold valuable information.

Files

In smaller organizations or within departments, it is common for an administrative assistant to maintain a complete phone list in a simple file or spreadsheet. If the information is maintained at the department level, it can be a good source for the most up-to-date contact information on people. Of course, the data may not be in a form that is easily pulled into a structured data system such as an LDAP-based directory service.

Applications

Many network-based or collaborative applications have a built-in database or directory that stores information about users of the application and other objects the application needs to know about. These application-specific directories tend to be proprietary, closed systems that may not even provide application programming interfaces (APIs) for accessing the data. Examples include e-mail systems that are not LDAP aware, some Web servers, and most electronic calendar systems.

One of the most important reasons to invest in an enterprise directory service based on LDAP is to replace many of these application-specific directories, or at least to coexist with them. If you are working on such a project, you need to develop a coexistence strategy or actively manage a transition to the replacement service (this may be a lengthy strategy). The existing application data stores are the best source for the application-specific data elements you plan to store in your directory service, so try to work with them and not around them.

Administrators

The administrators charged with caring for the computer systems, networks, and telephone systems in an organization manage a lot of interesting data. If the data these administrators manage is not available in electronic form or another manageable format, you will still want to directly enlist the aid of these administrators in setting up and maintaining the data held in your directory service.

End Users

Last, but certainly not least, end users are often the best source of data about themselves. This is especially true with personal contact information (such as home telephone numbers and addresses) and preferences.

Because you probably do not have time to ask each person for information, you should provide an easy-to-use interface to your directory service so that individuals can update their own information. Some data elements come from other databases or are maintained by administrators or applications, so be prepared to explain to end users why they can't change those data elements themselves. It is a good idea to publish information about the origin and owner of each data element held in your directory service. Such information is usually included in your data policy statement (as discussed earlier in this chapter).