Directory Design Checklist

Understanding and Deploying LDAP Directory Services > 24. Case Study: A Large University > Deployment

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053054012003009099076073042231086

Deployment

Deployment 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 Choice

Big 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.

20-20 Hindsight: Directory Development

Big State's decision to develop rather than purchase software had mixed results. At the time the service was developed and deployed, the state of the market was very immature, so Big State would have had to make unacceptable compromises in its service by deploying off-the-shelf software. Key technology such as LDAP did not yet exist either, so it had to be invented. Big State's development efforts had a substantial and lasting effect on the industry, and many vendors have based their directory solutions on LDAP software that was developed at Big State during this time.

Unfortunately, substantial development effort was required. A lot of time and several people were committed to the effort, costing Big State real dollars. (Of course, given the payoff in terms of advancing both the directory industry and Big State's directory deployment, this price was deemed well-worth paying.) More seriously, Big State spent valuable time developing a solution from scratch. An even more serious negative consequence of Big State's decision is that Big State must continue to support the software it developed to run its service. Keeping the software bug-free and enhancing it to grow with the service it provides requires a significant ongoing investment.

Big State is contemplating moving from its home-grown environment to a more standard, vendor-based environment. Many obstacles must be overcome to duplicate the functionality of the Big State deployment using vendor-supplied products. Starting with a vendor-based solution and evolving over time with the vendor would have made this transition easier.

Given the plethora of capable directory products on the market now, Big State would have little problem finding products to support its needs if it were starting to design a service today; the idea of developing a directory server from scratch would be certainly out of the question. However, developing specialized directory-enabled applications that are aware of local schema and policies would still be a perfectly reasonable thing to do.

Piloting

The 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 Costs

One 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 Production

Moving 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.



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing
<  BACK CONTINUE  >

Index terms contained in this section

Big State University case study
          deployment 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.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net