Novell Home

Directory Design - Thinking "Directorially"

Novell Cool Solutions: Feature

Digg This - Slashdot This

Posted: 1 Dec 2004
 

Here is some practical advice on directory design, or how to think "directorially" as you map the strategy for building an effective directory. For the full BrainShare presentation (TUT386), see http://www.novell.com/brainshare/catalog/controller/catalog.

Starting the Design

First, you should build a directory "constitution," or document that will guide you as you gather the requirements for the directory design. To do this,

  1. Meet with all stakeholders, subject matter experts and everyone else you can find who should have input.
  2. Those with interest in the project will almost always have conflicting views of what the data actually means. This is a good thing - viewpoints that differ can still all be correct.
  3. Establish a ?rules? document early on, and do it all in English Don't worry about directory mechanics ... yet. There will be ample time later to hammer out the design details and workings.

Interviewing Goals

When you conduct interviews, identify all the entities that relate to identity. This will establish all the required entry types. To facilitate this process, there are three key objectives: 1) finding the nouns, 2) finding the adjectives, and 3) finding the truth.

Find the Nouns

For example, the nouns to define in a banking environment might include:

  • Users - define them with a one-to-one, user-to-human relationship
  • Companies - define the companies who do business with the bank
  • Branch - define the physical/legal locales of the bank
  • Applications -- define the back-end deposit/loan systems
  • Accounts -- define the debit accounts scattered in various apps
  • Groups -- define the logical groupings of users

Find the Adjectives (or Supporting Nouns)

When interviewing, establish all the key words used to describe the "nouns" you identified. This will identify attributes required.

For companies, the descriptions could include the following:

  • Customer unique identifier
  • Legal Name
  • Customer contact e-mail
  • Maximum money transfer limit
  • Company is "open" or "closed"
  • Branch ID

For accounts, the descriptions could be:

  • Customer unique identifier
  • Account identifier
  • Application identifier
  • Account Type
  • Account Status

Find the Truths

Document each statement you can guarantee to be true about each entity (noun) you have defined. This is the most important step in the design. Examining all the nouns and adjectives in detail may lead you to a large number of assumptions or statements that you need to verify. If you verify the truth statements up front, it can avoid a lot of problems later.

As you interview all the stakeholders, you need to ask the important true/false questions. (For example, "Are account ID's unique to a branch?")

Questions and Truths for Directory Design

"Can users ever be renamed?" - True
"Can users ever be deleted?" - True
"Can userIDs be reused?" - False

Analyzing the Data

Find the Relationships

Relationships will show up in the truth statements. Diagram the relationships Directory hierarchy will start to become visable If a leaf needs to be multiple places, then that part of the structure should be flat Try to be as generic as possible

Applying the Filter

Deciding whether something really "belongs" in the directory can be difficult. If an entity is used to establish any kind of relationship, then it belongs. Foreign keys and IDs should always be included.

The directory is the card catalog of all other data repositories. Establish clearly what the ?Book of Record? is for every data element (authoritative source). If you need an entity to answer any of the following questions, that entity should be in the directory:

  • How is this related to that?
  • How do I find it?
  • What is this user authorized to do?

Designing the Schema

The directory schema helps identify unique attributes and reuse them across classes. All class attributes added to auxillary classes.

Remember the following guidelines as you are designing the schema:

  • Never modify base classes.
  • Never re-use base classes for different object types - instead, create new base classes.
  • Avoid length restrictions and proprietary syntax types.
  • Try to use existing/RFC attributes wherever possible.

Validating and Completing the Design

Here are some steps to follow to make sure you validate and complete your directory design:

  1. Make sure each truth statement is actually true in the design. Correct any discrepancies that exist.
  2. Make sure generic LDAP clients will understand as much as possible at the tree.
  3. Evaluate the design from each application function. Make sure it's possible to find out how X is related to Y, quickly and easily.
  4. Publish the design in English - most stakeholders won't understand LDAP/X.500/etc. This will mostly be a list of entities and true/false statements describing their attributes and relationships.
  5. Because LDAP isn't perfect, the English design represents the ideal and original goals. This will help when it's time to enhance or modify the design.
  6. Provide detailed schema documentation for the implementers of the design.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell