Topology Design Checklist

Understanding and Deploying LDAP Directory Services > 6. Data Design > Identifying Which Data Elements You Need

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053055078214168035127083181127149

Identifying Which Data Elements You Need

As we saw in Chapter 5, much of the design of your directory service will be driven by the applications that use it. Therefore, the first step in determining which data elements you should include in your directory service is to start with a list of directory-enabled applications that you plan to deploy. We talked about forming just such a list in Chapter 5.

Now you should examine each application to determine what data it needs to access in the directory service. In the first pass through the list, just look at each application and list all the data elements each 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 attributes should be provided somewhere in the documentation. If not, contact the company that produced the software and request the information. For custom applications that are 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 6.1 shows some examples of applications and the data elements they might require.

Table  6.1. Applications and data elements

Application

Vendor

Class of Information

Data Elements

Authenticated Web server

Netscape

People

User ID, password

   

Groups

Group name , description, list of members , owner

Electronic mail system

Netscape

People

User ID, password, email 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, email address, phone numbers , user ID, password, mailing address, department, manager, home page URL, license plate number

Organizational chart generation utility

Oblix

People

Manager, employee type, job title

Asset management application

Developed in-house

Computers

Owner, make, model, processor speed, storage capacity, IP address, host name

After you have compiled a list of the data elements used by each application, locate any identical (or nearly identical) data elements used by more than one application. It is almost always better to simplify and use as few data elements as possible. Failure to do this can create data redundancy problems within your directory service itself! For the applications shown in Table 6.1, you can see that 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.

The compilation of all the data elements used by each application can be a large undertaking, but you may be able to use an incremental approach. Try to divert some of the work from this initial directory design stage to future design iterations that will occur after the initial deployment of the service.

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 they use some of the same data elements as the first round of applications. Unlike traditional database management systems, directory services are designed so that it is relatively easy to incrementally add new data elements. However, be careful not to combine data elements that may need to be separated later; it may be hard to determine how to split up any existing data values (for example, reliably extracting a person's surname from their 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 a specialized service that is focused on just one or two applications).

  • Your organization has a lot of data sources for your service to interact with.

  • You need to involve people outside your team in the data design process for political or practical reasons.

In large organizations, it is likely that you will need to involve people from a variety of groups in any directory service design work concerned with data. This is because some of the data elements you want to include in your directory service may already exist in other data sources (e.g., a human resources database). Eventually, you will need to overcome political hurdles and work with the people who manage the other data sources to ensure that your directory service is not viewed as creating more data- related problems than it solves . On a more practical note, if you are not well-versed in data matters yourself, you can probably learn a lot by talking to the experts.

Tip

If you choose your directory data elements without consulting the experts who already manage similar information, you will probably ruffle some feathers. For example, you should consult your personnel or human resources department when choosing data elements for people-related information. Similarly, it may make sense to consult the networking group within your IS department if you plan to store information on switches and routers.

If you do not consult your colleagues, be aware of the potential consequences. In our experience, such decisions can and do come back to haunt you later. If you are having trouble getting cooperation from other groups, make sure you have buy-in from your management, and let everyone know that your directory project is important. If you have support from the top, political barriers should fall more easily!



When you need to get a handle on the data elements already in use, it helps 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. It should include a fair amount of detail about the actual database tables in use, including information on each of the fields that appear in each table. Similarly, it should show all the attributes and object classes in use in the directory services. The data sources inventory should also include pointers to supporting documentation, when available, and may also include contact information for those responsible for each database.

Performing a data sources inventory can be costly and time-consuming for large organizations, but it can also be valuable when you are pondering the relationship between the data elements you plan to store in your directory service and those held in other data sources. Table 6.2 shows a sample data sources inventory.

Table  6.2. A sample data sources inventory
Data Source Software/Contact Class of Information Data Elements
Human resources database Peoplesoft jeffw@hr.airius.com People Name, address, phone, employee number, and so on
Email system Microsoft Exchange leif@is.airius.com People Name, user ID, email address, email preferences
    Groups Group name, list of members
Product development phone list Excel spreadsheet johnb@pd.airius.com People Name, email address, phone extension, home phone

In smaller organizations 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 within 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 sure to track this progress and be prepared to adjust your directory plans accordingly



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



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing
<  BACK CONTINUE  >

Index terms contained in this section

applications
          data element needs 2nd 3rd 4th 5th 6th 7th
data
         design
                    identifying element needs 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
         elements
                    identifying needs 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
         sources
                    inventory 2nd 3rd 4th
design
         data
                    identifying element needs 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
elements
         data
                    identifying needs 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
identifying
          data element needs 2nd 3rd 4th 5th 6th 7th
                    data sources inventories 2nd 3rd 4th
inventories
          data sources 2nd 3rd 4th
needs
         data elements
                    identifying 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
software
         applications
                    data element needs 2nd 3rd 4th 5th 6th 7th
sources
         data
                    inventory 2nd 3rd 4th

2002, O'Reilly & Associates, Inc.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net