Understanding and Deploying LDAP Directory Services > 24. Case Study: A Large University > Deployment |
DeploymentDeployment of the Big State directory service was a relatively simple process. Because the directory service and associated directory-enabled applications were all new, there was no existing user base to be migrated and no existing service to worry about interrupting. The deployment steps detailed in the following sections were followed. Product ChoiceBig State had several requirements driving its choice of directory product. At the time of deployment (the early 1990s), Big State was ahead of even the early adopters on the industry directory curve ”meaning that no commercial products existed that served Big State's needs. So Big State embarked on a development project to build the software it needed. This software had three main components : a directory server, LDAP directory clients , and gateways linking existing services. At the time, X.500 was the only standard directory protocol available, so Big State developed an X.500 directory server based on publicly available code. The Big State developers implemented a new, more scalable, high-performance database; a replication service; and a new, more powerful access control scheme that satisfied their needs. Big State, along with members of the Internet Engineering Task Force (IETF), also designed and implemented the LDAP protocol itself. LDAP (or something like it) was necessary to bring directory service to the rest of the Big State campus, which consists primarily of Macintosh and Windows machines. At that stage, LDAP was implemented as a front end to the X.500 directory. (See Chapter 2, "A Brief History of Directories," for more history on the development of LDAP.) Big State developed a number of LDAP directory clients covering all the major platforms to provide users with read-and-write access to the directory. These clients include the flagship maX.500 Macintosh client, the waX.500 Windows client, and the xax500 UNIX X Window client. Also developed was a simple command-line interface client called ud . These clients know about Big State's data management procedures and are able to provide users with intelligent error messages when things go wrong. The clients also know about the special schema designed for groups and other applications, allowing users to query and update schema elements. The mailing list service and the ability to change personal information encouraged users to update the directory frequently. Big State also developed a number of gateways linking existing services (such as finger, Gopher, and the Web) to the directory service. This strategy allowed users to access the directory immediately using their existing tools.
PilotingThe first Big State directory pilot was conducted with only the online phone book application. This allowed the service to be piloted, data-handling techniques to be tried out, and initial user reaction to the service to be tested . The phone book application was considered relatively low-risk, especially in comparison to the email application. The phone book is important, but if it is down or malfunctions, users can always resort to printed or telephone-based directory assistance. If the email application malfunctions, however, mail service can be hindered and university business can be seriously disrupted. As part of the phone book pilot, Web, finger, and Gopher gateways to the directory were deployed to give users a variety of access methods . The pilot was conducted rather informally and without any scientific feedback-gathering techniques. Only online documentation was required for the various white pages gateways, but more elaborate documentation and training courses were developed for the various directory clients such as maX.500. These clients were rolled out in parallel with both the phone book and the email application. They became more important as more users found the need to update the contents of the directory. When the phone book application was shown to be successful, Big State moved forward with plans to pilot the email service, which required more formal piloting procedures. The service was first tested on a very small scale in a laboratory environment using Big State's directory staff as guinea pigs. Success there led to rolling out the service in a real, although unannounced, environment. This involved securing the necessary machines, space, power, and network connectivity; configuring the machines and loading them with the required directory and other software; populating the directory with appropriate data; putting in place pilot monitoring and backup procedures; and other tasks . The service was rolled out to select groups of individuals as well as to others who became aware of the service (there was no easy way to prevent them from using the service). Documentation was developed for both end users and support staff, and support staff were also trained. When the unannounced pilot was deemed successful, various methods were used to publicize the service for its rollout to a wider audience. These included publicizing the service in new student and new hire enrollment packages, placing articles in the campus newspapers, and other methods. The IT division's public relations department was also helpful in this endeavor. Analyzing and Reducing CostsOne lesson the Big State directory team learned early on is that data maintenance and personnel are by far the most expensive costs associated with the service. Almost all data maintenance procedures are automated, but even the tiny fraction that are not cause lots of extra work and headaches for the Big State staff. An ongoing effort for the directory team is to automate more and more of the maintenance processes and reduce the number of exceptional cases that must be dealt with by hand. The periodic bulk data loading procedure proved to be one of the most troublesome aspects of the service. Despite massive effort to automate this service, handle exceptional conditions, and generally make the procedure easy, problems still occurred. The goal was to get this procedure mostly automated, with a system administrator handling any reasonable exceptions. Instead, the procedure continued to cause problems, requiring attention from the service designers. Another high-cost aspect of the service turned out to be help desk and other related support services. Users forgetting their passwords, wanting information added to or removed from their entries, and needing other exceptional conditions handled turned out to be a large burden on the support staff. Big State addressed this problem by developing more and better documentation, automating certain tasks so that users can service many requests themselves , and offering training classes to the user community. Going ProductionMoving from a pilot to a production environment was a relatively painless task. Because the service was new and deployed from scratch, the same infrastructure used for piloting could be used for the production service. By the time the pilots had been operating for a while, going production was a simple matter of making sure the production operations were in place and had sufficient capacity, and then opening the service to a wider audience. Several more robust procedures such as for monitoring were also developed as part of the production process. Other tasks associated with going production, such as developing training classes, creating documentation, and publicizing the service, were completed after the service was up and running smoothly for some time.
|
Index terms contained in this sectionBig State University case studydeployment 2nd 3rd 4th 5th 6th 7th 8th 9th developing software 2nd 3rd linking services piloting 2nd 3rd product choice 2nd production rollouts reducing costs 2nd 3rd case studies Big State University deployment 2nd 3rd 4th 5th 6th 7th 8th 9th 10th costs reducing Big State Universtiy case study 2nd 3rd deployment Big State University case study 2nd 3rd 4th 5th 6th 7th 8th 9th developing software 2nd 3rd linking services piloting 2nd 3rd product choice 2nd production rollouts reducing costs 2nd 3rd directories case studies Big State University 2nd 3rd 4th 5th 6th 7th 8th 9th 10th directory software Big State University case study 2nd linking services Bid State University case study piloting Big State Universtiy case study email services 2nd online phonebook production rollouts Big State Universtiy case study reducing costs Big State University case study 2nd 3rd rollouts Big State University case study software directory Big State University case study 2nd sofware developing Big State University case study 2nd 3rd |
2002, O'Reilly & Associates, Inc. |