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.
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 |
- 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.
Data Source | Software/Contact | Class of Information | Data Elements |
---|---|---|---|
Human resources management system | PeopleSoft (jeffw@hr.example.com) | People | Name, address, phone, employee number, and so on |
E-mail system | Microsoft Exchange (leif@is.example.com) | People | Name, user ID, e-mail address, preferences |
Groups | Group name, list of members | ||
Product development phone list | Excel spreadsheet (johnb@pd.example.com) | People | Name, e-mail address, phone extension, home phone |