User considerations should be paramount. The database should reflect a natural organizational structure and be partitioned in a logical way. Service contact points could, for example, be held in one database subtree in order to make browsing easier. Entries in the database should be named in a natural and descriptive way, rather than using impenetrable acronyms or identifiers. It may be advantageous to keep public and private views distinct in the database, again by placing the data in separate access areas. This makes sense from the perspectives of security and management as it eliminates inter-dependency. Implementation of the security mechanism in particular will be simplified by ensuring that public data is kept apart from private data.
The main concern behind the infrastructure is how efficiently the service is rendered. If your organization is small then the service will be handled adequately by a single directory server. In certain situations more than one server will be required, an organization with several sites lacking strong network interconnections being the most obvious example. Here low-bandwidth connections would limit the usability of the directory if one machine at a central site was used to service all requests. In this case, the solution is to install servers at each of the sites and implement a data replication scheme so that each server holds a copy of the entire directory database. In this way every local user has fast access to a site-local access point, and with no need to resort to inter-site networking when resolving directory requests.