Purpose of an Applications Directory
Author: Jens Moller

Many Corporate Directories have some application support in them. At some point in time, the Corporate Directory becomes over-burdened by one or more applications that access it frequently and require hefty resources to allow it to perform reliably. When this occurs, the Corporate Directory and Applications Directory diverge.

The problem is that each shares a subset of data that comes from common sources, however, the applications Directory will own a large portion of its data as it relates to the Application.

Its possible that the Application Directory may never have been a part of the original Corporate Directory, and as such the common data will need to be synched from some source, and represented in a common way. There is also the likelyhood that the Directories are largely structured an incompatable way that makes intersynching somewhat of a challenge.

Source of Record - Personnel Data

Since the Corporate Directory is designed to support management of personnel information, including the status (active, terminated, on leave, etc.), it should be the record of source for all other Directories that utilize this same set of data for application purposes.

Depending on the Applications needs, its also quite possible that more than one Corporate Directory might be supplying data to the Application Directory Servers. An example of this mighyt be where the Application Server is associated with a service that numerous organizations subscribe to. Each of organizations manage their own Corporate Directory Data, and supply it based the business rules of that organization.

Source of Record - Applications Data

Applications access is normally associated with the people or applications that utilize any given application. While it is possible to have a 'personal' set of data that is mostly the same as the organizations Corporate Directory, it is highly insecure to have multiply managed data sources for personnel data.

Many companies have at least a few instances of this data floating around its network, but once the business grows it may end up with hundreds of out of sync copies of personnel data, wasting resources, and also requiring agreements with various data sources that may not be any more reliable than just keeping the track of the data yourself.

Therein lies one large problem - the application databases really want to focus on the applications that they are designed for, but they need data from the Corporate Directory. The solution is potentially quite simple - work out an agreement with the Corporate Directory group and share data that each needs.

Once an agreement exists (this will usually require that upper management buys into the applications needs and that security is the prime reason to share this information). This is often the most complicated part to get agreement on.

Usually, there will not be that much data to return to the Corporate Directory, however it will often want an application status value returned to store so that it does not need to refer the applications directory any more often than it has to.

The remaining data will originate as part of the default data sets of the application as well as run time data that the application manages.

Application Directories Operations

These are typically optimised for a given set of functions. Unlike a Corporate Directory Server, where the tree structure changes in a random fashion over time, the Application Directory tends to have a very structured Directory Information Tree (DIT). Directory access tends to be entirely by the application and it can leverage the structure to find and utilize the directory data more effectively. It may also see substantially more updates than a Corporate Directory.

Application Directories should still be mostly read-only, as Directory Servers are designed to operate in that mode.

Application Directories are often created independant of other data sources, as a result, they often provide utilities and functions that allow them to edit and manage personell type of data. This is fine until they are synched with Corporate Directories. Once the record of source is deligated to another service, Application Directories need to honor the source of data, otherwise uncontrolled updates will damage the consistancy between them.

The data found in an Application Directory Server entry will likely be formatted in a a way that benifits the applications needs, and often is not in any kind of format that is remarkably easy to look at and guess what it means. Many instances utilize XML where possible as data elements, allowing the information to be transformed as needed.

Comments? Questions? Contact Engineering