Identifying Which Data Elements You Need

As we saw in Chapter 6, Defining Your Directory Needs, much of the design of your directory service will be driven by the applications that use it. Now examine each directory application to determine what data it will use. In the first pass, just look at each application and list all the data elements it will use. To obtain this information, you will either need to become an expert on the application itself or enlist the help of others.

For commercial software that supports LDAP, a list of data elements in the form of attribute types should be provided somewhere in the documentation. If not, contact the company that produced the software and request the information. For custom applications created in-house, a design document should be available that includes the information. As the directory expert, you may want to help adjust the design so that the application uses the directory wisely. Table 7.1 shows some examples of applications and the data elements they might require.

Table 7.1. Applications and Their Required Data Elements

Application	Vendor	Class of Information	Required Data Elements
Policy management agent for a Web server	Netegrity	People	User ID, password, department
		Groups	Group name , description, list of members , owner
Electronic mail system	sendmail	People	User ID, password, e-mail address, mail host, vacation message, delivery options, forwarding address
		Groups	Group name, description, list of members, owner
Company phone book	Developed in-house	People	Name, e-mail address, phone numbers , user ID, password, mailing address, department, manager, home page URL, car license plate number
Organizational chart generation utility	Oblix	People	Manager, employee type, job title
Asset management application	Developed in-house	Computers	Owner, make, model, CPU, speed, storage capacity, IP address, host name

After you have compiled a list of the data elements used by each application, locate the data elements that are used by more than one application. It is almost always better to simplify and use as few data elements as possible. Failure to do so can create data redundancy problems within your directory service itself ! For the applications shown in Table 7.1, several data elements can be shared between the applications. For example, the first three applications require access to a person's user ID and password.

Often one or two applications drive the initial directory service deployment, and it is appropriate to focus only on the needs of those applications. Keep in mind that you will probably need to revisit decisions made now when other directory-enabled applications come online, especially if the new applications use some of the same data elements as the first round of applications. Directory services software is generally designed so that it is relatively easy to add new data elements incrementally. However, be careful not to combine data elements that may need to be separated later; it may be difficult to determine how to divide an existing data value (for example, reliably extracting a person's surname from his full name).

Try not to let your thinking become too specialized during the data design phase of directory planning. Always consider what will happen if your directory is asked to support new applications. It makes sense to do a significant amount of up-front data planning if one or more of the following apply:

• You are replacing a directory service that is already deployed and in use.

• You plan to serve a wide variety of applications with your directory service (as opposed to providing a specialized service focused on just one or two applications).

• Your service must interact with many other data sources.

• For political or practical reasons, you need to involve people outside your team in the data design process.

When you need to get a handle on the data elements already in use, it is helpful to create a data sources inventory . Simply put, this is a list of all the data sources (databases and directories) in use within an organization that are relevant to your directory deployment. It should include a fair amount of detail about the database tables in use, including information on each field that appears in each table. Similarly, it should show all the attributes and object classes in use in the directory service. The data sources inventory should also include pointers to supporting documentation, when available, and may include contact information for those responsible for each database.

Creating a data sources inventory can be costly and time-consuming for large organizations, but it should be valuable when the time comes to ponder the relationship between the data elements you plan to store in your directory service and those held in other data sources. Table 7.2 shows a sample data sources inventory.

Table 7.2. A Sample Data Sources Inventory

Data Source	Software/Contact	Class of Information	Data Elements
Human resources management system	PeopleSoft ([e-mail])	People	Name, address, phone, employee number, and so on
E-mail system	Microsoft Exchange ([e-mail])	People	Name, user ID, e-mail address, preferences
		Groups	Group name, list of members
Product development phone list	Excel spreadsheet ([e-mail])	People	Name, e-mail address, phone extension, home phone

In smaller organizations and for simple directory deployments, there is invariably less need to involve people from other groups in your directory design. There may not even be any other groups!

Tip

Be careful to plan for the future, especially if you work in a growing organization. If you hear that the two-person team that currently produces the paychecks by hand is hiring six more people and meeting with PeopleSoft to discuss software and support needs, you should be prepared to adjust your directory plans accordingly .

After you have completed your data sources inventory, you may find that you have a long list of data elements. This is not something to be too concerned about ”directories are designed to handle many data elements without much overhead. The next step is to look at the characteristics of each data element in more detail.