This example is about a database that allows users to enter a course title, referred to as Catalog Names into a Louts Notes database (Learning). However, as real life experiences show, having many users causes duplication of course titles.

To counter this action, we decide to implement a review cycle that will ensure that there are not duplicate titles for the same course entered by different individuals at various business locations (units). So, we setup an agent that first forwards the request to a  corporate contact for review. After the review, the Catalog Name will appear in the database and is ready for review.

This is the intent of the change. this short story is the tale of the Replication Gremlin.

The timeliness of the process is not based on the human element, but the configuration and location of the participants. Namely the initiator, approver and Notes database location(s).

The initial assumption is that the initiator and the approver are accessing the same database on the same server. This assumption would look like this:

With this configuration, as soon as the initiator created the entry, a notification message is generated and the approver can approve the request and make the entry available within Ugenie PCS  Learning for immediate use (scheduling of classes).

This assumption will normally (but not always) work within a single campus environment. But, a single campus, such as the VTC in Falls Church, can be divided into several organizational Notes Servers. This would produce the configuration below which introduces the first complication to the system.

In this instance, the initiator and the approver are accessing Ugenie PCS   Learning on separate Notes servers but within the same campus. The Notes replication cycle now determines how fast the request can be approved.

If a normal replication cycle is used on both servers, then each phase will take a minimum of 2 hours.

Now, we have taken an almost instantaneous process and turned it into a 4-hour task because of the Notes replication cycle.

As we look deeper into our Notes network, we will see that servers in different business units do not communicate (replicate) directly with each other. The smallest configuration will look like this:

The previous configuration, while the simplest, is not the norm because our Notes network configuration dictates that there exists a Business Unit Hub server in the mix as follows:

The pictures above are the general considerations to account for with the proposed change. The pictures also assume that all things replicate equally and have full time connections to the Ugenie PCS Notes Intranet.

If we limit our scope to the continental U.S., we will find that some server only have dial-in access to the network, while others only replicate on a daily basis either dues to network connectivity issues, little need for immediate replication to other servers, or cost.

With Ugenie PCS  Learning databases, there are some business unit servers which replicate the database on a weekly or monthly cycle. This request cycle requirement could change the outlook of the activity on their local network and my require them to upgrade their server if they chose to continue using the database for class schedules.

The final factor to consider are the locations external to the continental U.S.

Now, lets move to a more global picture. With active users in Australia and the United Kingdom the Catalog Names entries created by these organizations will be out of the EST timezone. A method for approving their requests in a timely fashion is also needed if there is not 24x7 support available to accomplish this task.

Before the cycle even begins, we will find ourselves 1-day behind. And, the number of hub servers required for the replication chain can be long indeed.