Last updated on Sat Mar 21 11:44:36 EST 1998
Abstract |
|---|
| We document challenges faced by the University of Michigan's Online Directory Service, enumerate a set of solutions that the Directory Team plans to take to address many of these issues, and explore the risks associated with our suggested solutions. |
|
Special note: This report is designed to be printed, or viewed with a web browser. |
|
The contents of this report are Copyright ©
1998 by The Regents of the University of Michigan.
All rights reserved.
Any trademarks or service marks appearing in this report are the property of their respective owners. |
The current service is a quagmire, admittedly, of unknown dependencies, ancient software that no longer builds, inappropriate operational procedures, and damaged reputation. Our task is to take this chaos and focus it into a relevant, reliable, and scalable service that meets and exceeds the expectations of our customers in steps that clearly demonstrate progress and improvement. Improving the quality of an existing service upon which so many depend requires careful study of the existing implementation, and careful management of changes.
Our eventual goal is to run the directory service on a standards-based, vendor-provided solution that requires much less programming or documentation support from ITD staff. While ITD was the birthplace for much of this technology, it is no longer capable of sustaining a serious LDAP software development effort. Our strategy, therefore, is to choose a product that will scale to support our lifetime customers, that integrates with our chosen security infrastructure, and that requires less support effort from us. We know that our security integration requirements often fly in the face of using unaltered off-the-shelf software. Under this software base, we want to engineer a secure, high-performance, high-reliability hardware foundation and data store. And using this software base, we want to provide accurate and relevant data to enable our customers to build new applications and trust that our service will be there to support them.
In the last four months, the Directory Services team has spent considerable effort attempting to reconstruct a vision of how this service should work. This effort has included:
Introduction
Service Description
The University of Michigan's Online Directory Service provides a
computerized directory of persons associated with the
University of Michigan.
The Directory is a phonebook-like database of faculty, staff,
students, and alumni of the University.
Of course, like all computerizations of paper-based technologies,
the Online Directory Service promises to add value to the
concept of a phone book.
For example, with the Online Directory, you can:
Who are customers of the Online Directory Service?
Most of our customers want one of three services:
first, to search for contact information for people
at the University;
second, to provide a simple e-mail address that others
can use to contact them;
and third, to create mailing lists.
Almost everyone who has used a computer
here at the University has had some need
for one of these three basic services.
There are also departmental customers
who want a feed of HR data
with which to populate their own directories.
Finally, we have identified a class of customers
who use the directory to determine University
affiliation information.
This is interesting for units who, for example,
deliver services based on eligibility criterion
that includes University affiliation.
A brief overview of some common directory terms
Directory data is stored in entries in a fashion similar to
how data is stored in relational databases.
A directory entry is equivalent to a row in a database table.
Each directory entry contains a set of attributes, which
are similar to fields in a database row.
The number, name, and data type of the attributes in an entry
is determined by that entry's object class.
Directories use object class definitions as templates
when creating a new entry.
Every attribute in an entry has a data type,
which determines what kind of data may be stored in the attribute,
and how it is compared to (or matched with) other data.
A single attribute can have one or more values,
values comprising the actual data in the directory.
That's a lot to consider, so let's look at an example: the entry in our directory containing information about me. My entry is in the object class umichPerson. That means, among other things, it has an attribute for my title, for my business phone and address, and so on. It does not have attributes such as the member attribute, since that contains values that are the names of each member in a group, and I'm not a group, I'm a person. The values of the attributes in my entry are string data describing these things about me. The attribute containing my business address, in fact, contains more than one value -- each value is one line of my street address here at Argus.
Overall directory organization appears more like the Unix file system than a relational database. Directory servers maintain entries in more or less a tree organization called the directory information tree, or DIT, for short. Each entry has a distinguished name, or DN, which is a unique path through the DIT to that entry. No two entries share the same DN. A DIT looks more like a computer's file system than it does a database. An example of a DN might look like this:
cn=Charles E Lever, ou=Information Technology Division, ou=Faculty and Staff, ou=People, o=University of Michigan, c=US
As you move to the right in a DN, you move towards the "root" of the tree, and the components become more general: c=US stands for the United States. Moving to the left in a DN means moving towards the leaves of the tree, and the components become more specific: ou=Information Technology Division is one unit out of all the units under ou=Faculty and Staff. The leftmost component of the DN is the actual entry to which the DN refers. cn=Charles E Lever is the entry that contains information about me.
A directory search operation is accomplished when a client specifies a search filter. This is similar to using SQL to search a relational database. A simple search filter names an attribute to search, data values to search for, and what matching process to use. For example, you can search for all entries that have a homePostalAddress attribute that contains the string "Westwood" (substring match), or you could search for anyone whose last name (surName attribute) is "Smith" (exact match). The server can return zero or more results, depending on its data contents, the type of matching requested, the access you have to the directory, and how many search entries it tried to look through to satisfy your request. More complicated filters can be formed by using logical operators to combine simple filters. You can also limit searchs to a particular subtree of the DIT, or even to only one level of the DIT (in other words, all of the entries at a particular level of the DIT, but none of the children of those entries).
On with the show
Delivering accurate directory information to our customers
on a timely basis is the fundamental mission
of a good directory service.
It is useful to separate this mission into two major categories:
delivering directory contents quickly and reliably, and
ensuring the contents of the directory
are accurate and up-to-date.
As it turns out, issues involved with delivering directory information
focus mainly on the technical implementation of the directory server
software, while issues involved with the accuracy of the directory
information are more concerned with how the data itself is managed.
In the next section of our strategy report, we spell out the
technical and business process challenges that face our service.
There are also important questions about a directory service's
funding model, since it is not possible to charge our users directly
for the service.
Data Delivery Issues
Data delivery issues
directly affect how easy it is to get to the
contents of the directory.
User perception of the directory service results from how
quickly information can be obtained from it;
how quickly and easily can one connect (bind) to the directory,
how fast search operations occur,
how often trouble occurs when updating an entry,
and so on.
Also related to delivery issues are factors that determine
how quickly problem recovery can occur
(that is, problem tracking, capacity planning, back-up efficiency
and disaster recovery),
how interconnected the directory service is with other parts
of the University's computing infrastructure,
and how efficiently operational support can be carried out.
Scalability is often affected by more than just how powerful a server engine might be. For example, we might be able to stuff half a million entries into our directory server, but if we can't run our "daily" backup within 24 hours, or can't quickly restore the directory in case of a disaster, then the directory service doesn't scale well. Likewise, even if we can get a large number of users into the directory, can it support an increasing number of search requests and modifications to directory entries?
In particular, the Online Directory Service faces all of these scalability challenges:
A challenge related to scalability is reliability, because often reliability suffers as a service scales up. The Online Directory is not useful if its users cannot quickly find what they are looking for, discover out-dated or inconsistent information, or cannot modify their entry or create mail groups when they need to. And, as the size of any directory grows and its user base becomes more dependent on it, the effect of unreliability is greatly amplified.
Replication is a basic part of any distributed database, and directory service is no exception. Replication of the directory provides solid guarantees against problems that erode service reliability and scalability by keeping several separate copies of the directory on different hardware and in different locations. Disk media failure, power and network outages, and server overload conditions have greatly reduced effects on a properly replicated service. The underlying replication mechanism should be robust, taking advantage, for example, of transaction processing to help the mechanism tolerate faults.
There are at least four different mechanisms for maintaining data in separate databases and directories:
Each may be appropriate depending on the server technology running on each end of the connection.
As it happens, the University of Michigan has one of the largest user
bases in the world for several of its infrastructural
directory-style services
(Kerberos authentication,
online directory services,
and others).
What this means is that this University is constantly pushing
the performance and scalability envelope for these types of
services.
As well, we are early adopters of many technologies because our
technological needs are often ahead of the state-of-the-art
requirements.
Both of these factors work against our efforts to provide
a reliable and scalable directory service.
Compliance with contemporary standards
A decade ago when online directory services were first being
conceptualized, the directory standards evolved in the ISO
networking world.
In America, TCP/IP is favored over European ISO networking,
and ever since the original X.500 standard was released,
TCP/IP directory implementations have developed around LDAP,
the Lightweight Directory Access Protocol.
LDAP is based on DAP, the Directory Access Protocol described in the
X.500 standard, but is designed to run on TCP/IP networks with
lighter weight clients and servers.
LDAP was "invented here." In fact, the University of Michigan still provides public access to a reference implementation that is free, and that many around the Internet still use. However our reference implementation is for version 2 of LDAP; Netscape, many would agree, now provides the reference implementation for version 3. Our reference implementation is incomplete; client referrals, for example, are not supported in the clients or libraries distributed with the reference implementation. As well, patches are made available, but are never integrated into the distribution we provide. The last full version release of our reference implementation was a few years ago. It is likely that this release will be the last.
Since Netscape, Microsoft, and Novell recently adopted LDAP as their system-wide distributed directory access protocol, LDAP has seen significant face-lifts. New protocol versions means older clients don't support many necessary and important features of newer servers, such as:
And as LDAP becomes more wide-spread, our directory servers will be required to support access by new clients. These new clients will appear in the form of embedded applications of LDAP. For example, e-mail clients will want to store their configuration and address book information in directories, and access that information via LDAP.
Unfortunately, the LDAP standards only apply to the protocol by which clients access a directory server; i.e. how to contact a server, how to specify directory searches, what kind of server responses there will be, and so on. The LDAP standards do not specify how the data is organized in a directory. A good way to think of this is that LDAP is, in some ways, equivalent to SQL(tm) -- and it certainly would be silly for an SQL standard to specify the data contents, function, and organization of a database. So eventually we must confront the data compatibility issues that exist between, say, the Microsoft Active Directory and any more-or-less X.500-compliant directory. An Active Directory not only stores the same data in different attributes, it also organizes and controls access to the data very differently. It is clear that some translation or adapter software will have to exist to move data back and forth between Active Directories and our Online Directory, should we choose to maintain compliance with the X.500 standards.
LDAP-compliant clients can also make dangerous assumptions when accessing an X.500-compliant directory. For example, the ISODE X.500 server implementation supports the ability for newly created entries to inherit certain attributes from the parent. This feature does not exist in any LDAP server we know of. This is important for us, however, because our current directory clients rely on newly created entries inheriting the proper object class from their parents. Without this object class, the new entries are all but invisible to searches.
We should also consider how much DAP-compatibility we need
to retain.
Are we interested in continuing to service DAP requests from around the
world, as we do with our current service?
If we throw DAP out the window, are we abandoning potential
customers of the University, and disconnecting ourselves from
the rest of the world, who still use and depend on DAP for
their directory access?
Authentication
Authentication is the process of guaranteeing a person's identity;
that is, proving they are who they say they are.
It is a mandatory part of computer network security
when servers and workstations reside on unsecured
networks and cannot trust one another.
Authentication allows Online Directory users to bind securely
to the directory and modify their own entries or create new
groups.
Certainly the implementation of a directory service is made much simpler when only a limited few can update the contents of the directory. However, as part of the democratized environment at the University, Online Directory users can modify their own directory entries to reflect changes in their personal information. As well, it is easy to implement a flexible e-mail forwarding service by adding a mail forwarding address attribute to each person's entry. A person can advertise a single convenient e-mail address to their friends and colleagues. Moving to a different e-mail server then becomes as easy as updating their mail forwarding address in their Online Directory entry -- their advertised e-mail address doesn't change.
In an effort to pursue the ideal of "single signon" for all infrastructural services on the University of Michigan campus, Kerberos was adopted by most service providers in the University of Michigan computing environment as the network authentication service of choice. This selection of Kerberos requires that it be supported by any online directory service deployed here that allows its users to bind to the directory and make modifications to it.
There are two varieties of Kerberos, past and future, that we need to consider as we evaluate directory server software:
The LDAP standards are still evolving in the area of backup and replication. This continues to be a concern as more vendors, more standards, and more departments enter this part of the equation.
Therefore, any strategy we have for the directory service must address the constraints placed on it by the the client-server architecture. In other words, we must design the service for greater client compatibility, or we must limit the amount of version and protocol deviation that can occur between a client and server implementation.
We get a steady stream of requests for day-old data. One reason for this is that current LDAP client software is clumsy when it comes to maintaining e-mail lists. However, like AFS, we can provide a repository containing yesterday's directory contents that our customers themselves can use to recover from their own mistakes.
As well, we need to gather data about how quickly we need to, and can afford to, recover from a large-scale "act of God" disaster. The directory service itself depends on few other services, namely having connectivity, and access to DNS and Kerberos services. Issues include:
The "people" data in the directory comes mostly from HR databases, although some nontrivial number of entries are set in "non-batch-update" mode, meaning the data is not necessarily a copy of what is in the HR database. The master copy of the "group" data, however, is the copy stored in the Online Directory, so the cost of losing this data is much greater than is the cost of losing the "people" data.
Capacity planning and performance monitoring are key to the success of a large-scale service. We can purchase or easily create automated report generators that can digest log information generated by the server software. Enabling the creation of regular performance and capacity reports is a requirement for the server software.
Data quality professionals often use four orthogonal dimensions by which to measure the quality of data, which is often difficult to quantize.
Since we currently don't have direct control of the data we are fed, we will need to collaborate with our providers to improve the quality of the data. However, directory technology allows new mechanisms for improving data quality. For example, allowing every user to have both read and write access to their directory information means they have the opportunity to keep it up to date themselves. This means that
This information model is known as self-reporting. Of course, self-reporting assumes every user will make an identical and best effort to keep his or her directory entry up to date. And of course, we must understand what data can be self-reported, and what data we must maintain.
This section of our report examines some of the processes that are already in place, and offers some choices about how we can improve them, or change them to more effectively use the new paradigms offered by directory technology.
We have explored ways of making this happen. We could split the directory into several databases per server, keeping one in read-only mode while leaving the others in read-write mode during an update. Access control in modern LDAP implementations makes it possible to effect an "entry lock" which prevents users from changing their own entries while they are being updated by this process, instead of putting an entire directory into read-only mode. As we test and deploy LDAP servers, we will evaluate the potential of using this mechanism to provide a continuous update process.
Of course, shifting away from X.500 server technology means that the current update software will have to be re-implemented, since it depends on the directory existing on disk in EDB format. LDAP servers don't use EDB, but can export their directory data into LDAP Directory Interchange Format [LDIF] files. LDIF is a flat file ASCII representation of a directory, useful for transporting a directory from one hardware architecture to another, or for backing up a directory. The update software can be changed to use LDIF instead of EDB, or it could function entirely on-line by issuing LDAP commands while the directory is left in read-write mode.
We would also like to hone the data extraction process that provides our data feed from the personnel databases. These jobs haven't been changed in several years, although University business processes and policies have changed, and our experience with the data feed has shown that the original jobs aren't quite what we need. We might get better quality data if we used a feed from the appropriate Data Access datasets, for example, instead of the myriad of jobs now in place to provide our feed.
Our current update process is also error-prone. And when an error occurs during this process, it is usually a big error. Parts of the DIT are deleted, or thousands of entries disappear. The reason for this is that the update process is complicated and operates on the directory as a whole using heuristic rules. As the directory has grown, catching errors in the update process becomes very difficult because it has to process more than a hundred thousand entries. This is an important factor in the quality of our service -- preventing and recovering from errors in the monthly update. We must find ways of more thoroughly checking the results before they become a permanent part of the directory data.
Infrastructure services in the University of Michigan information environment have an arguably unique problem: it is very difficult to tell when a person is no longer associated with the University. For instance, if a student graduates, her association may continue if she chooses the University as an employer, or if she wishes to continue her education. Otherwise, she becomes an alumni. New services like U-M Online serve the alumni of the University of Michigan using many pieces of information technology infrastructure that are shared with those currently affiliated with U-M. Also, an individual can be faculty, staff, or a student, or any combination of the three.
The procedures and data sources that determine when a person is no longer affiliated with the University are not timely or complete, and as a result, numbers of users and amounts of data have been building up in the UMCE. As well, service providers do not have a clear method of removing old and expired data and users. Services such as the Online Directory Service and the Institutional File System [IFS] also must handle data for expired accounts. What happens to a user's entry data when a he is removed, and then returns to the University? Or what if he is removed by accident? Expiry policies must be applied by all services consistently; otherwise a user can end up with, for example, an IFS home directory but no Online Directory entry. Further confusing matters, a person may be affiliated with the University, but not eligible to access computing services that are provided here. Is the Online Directory a repository for all who are affiliated with the University, or only those affiliates who are also eligible to access and use computing resources that are provided here?
Finally, purging directory entries often leaves "dangling DNs." In other words, if my entry is purged, there are still references to my entry left in groups of which I may have been a member, or in proxy attributes for entries for which I may have had administrative authority. We'll need to create processes by which these dangling references are discovered and removed from the directory.
Any directory of this type contains not only useful information about each of its users, but also "metainformation" about the population who maintain information in the directory. We should expect that applications for this metainformation will be created and used, especially since U-M is a research university, but also because the population in the Online Directory Service is large, and more-or-less complete. However, making the directory available in bulk can be an invasion of our users' privacy, and should be embarked upon carefully. The presence of Social Security Numbers in Online Directory entries bears some mention at this point, although the use of SSNs as unique identfiers is being phased out by the University. The Social Security information that currently exists in each user's directory entry is an example of data that should not be made available in bulk exports to researchers or departments. Data guidelines in the U-M Standards Practices Guide can help us resolve these issues.
Are we to continue providing bulk feeds for departmental e-mail services that include built-in directories, such as GroupWise or Lotus Notes(tm)? Acquiring the data is expensive for us, and providing it to departments may cause unwanted exposures of some of the data. If we continue to provide this service, we should understand its economic implications, and how to filter sensitive information, if necessary. As well, it may be easy to provide such a feed once a month, or even once a week, but what if the department wants updates more often than that? When is it appropriate to use a flat-file data feed, versus something more complicated, like a metadirectory?
As mentioned before, LDAP access control mechanisms are evolving as the LDAP standards evolve. This evolution may make it easier to store all information about users, and use Access Control Instructions [ACIs] to hide information that they may not want to make publicly available. Users or administrators can carefully tailor the information that anonymous binders can view using ACIs. Currently, "Don't Publish" information in the phone database is not included in the Online Directory. Having more complete information about each user can greatly increase the value of the Online Directory.
For example, an administrator can create a new attribute for Person entries called hiddenHome. Then, she creates an ACI or ACL that operates on a filter such as "hiddenHome=FALSE" that makes the homePhone and homePostalAddress attributes readable by anyone. Otherwise, if hiddenHome in a Person entry contains TRUE, these two attributes in that entry become invisible to everyone. Since users can set the hiddenHome attribute in their own directory entry, they themselves can choose to hide or expose their home information, even though it can still be contained in the Online Directory.
We think that the affiliation information really belongs in an attribute in every person's entry, instead of determining a person's entry's location in the directory tree. That way, a person's entry can reflect every affiliation, not just one. Of course, this will require some reorganization of the directory tree, and it will require that our DN's will have to be rewritten. My DN, for example, might be rewritten cn=Charles E Lever+uid=cel, ou=People, o=University of Michigan, c=US. Remember that DNs are all unique, so I've added on +uid=cel in order to distinguish my entry from other "Charles E Lever" entries in the directory.
The second reason for considering DIT reorganization is that the main campus directory, ours, must be compatible to some extent with PC-based departmental directories. One of the major incompatibilies between an X.500 compliant directory and Microsoft's Active Directory is the DIT organization (and entry contents, which are covered elsewhere). We'll need to explore how our DIT organization must change in order to interoperate with Microsoft's AD.
It is also important to mention again that backups must be subject to the same access control and privacy requirements as the directory data had when it was online.
As well, we can easily see using an LDAP-accessible directory as a scalable distributed authorization server. Such a server might replace or augment AFS pts groups, providing authority checking for network services not related to AFS. Another use might be for maintaining subscription information for UMCE services. We can add a serviceSubscription attribute to each person's entry, and populate it with values reflecting a person's subscription to each UMCE service. Using LDAP access control, we can prevent updates to this attribute by anyone other than the subscription authority.
Currently, such authorities are lumped into one category: cn=Manager. It would make more more sense if we had many administrative entities, and better used X.500 or LDAP access control to allow administrative authorities fine-grained access to parts of entries, or parts of the directory tree.
Year 2000
Everyone understands the Y2K problem,
so there is no need to redescribe it here.
It is important not only that
directory server and clients understand centuries,
but that interchange formats be altered to include century data,
and that administrative tools recognize and correctly convert
between century-less and century-ful data.
We will also have to examine carefully our data feeds to determine where
extraction jobs need change.
Evolving administrative infrastructure
Any plan that discusses HR data at the University of Michigan must,
in due course, acknowledge impact by the deployment of the
PeopleSoft application suite.
The deployment of PeopleSoft promises to bring process streamlining
and Unix-based Oracle, with data being accessible via GUIs on desktop
computers.
It also means that the data we are currently getting from mainframe
data extraction jobs will come instead from Oracle on Unix.
We can expect that the data format (both fields and data types)
will change,
and that our data extraction jobs will have to be reprogrammed
to run against the new databases.
No-one knows exactly when the HR part of the PeopleSoft deployment
effort will be ready, but we will continue to collaborate
with the deployment effort to stay abreast of their progress.
We will also need to explore getting data from new sources. For example, the ID card database may be an appropriate source of information for the directory, in addition to our current feeds, because it may have a more complete listing of employees and students than do the databases from which we are currently fed. The unique identifier assigned to each student and employee is changing from an SSN-based ID number to something called an Entity ID, produced by the ID card database. It may also be the case that many of the populations that are currently missing from our data feeds, such as bargained-for employees, are present in the ID card database or some other database to which we can readily get a data feed. We should establish formal categories for inclusion in the directory; we believe this has never been done.
Eventually it may even be appropriate for the directory database to be the master source for some parts of the University's personnel data. As described earlier, the directory provides an authenticated means for users to update their own personal information on-line. We might be able to take advantage of this in order to feed these changes back to the HR databases, or become the master of this data, feeding our data to HR. This is appealing because it could potentially reduce the complexity of the processes that maintain this data for the University.
Auxilary Services
As part of the effort to improve services provided by the Directory
Services team, we have identified several areas that are not in the
direct purview of the team today, but might be important to our
customers in the future.
There are also some services that ITD already provides that are
related to the Directory that might be better provided in other ways.
In addition to all of that, vendors are charging database level license fees for directory software, since it is an enterprise-wide application built on database technology. And, we're still calculating the monthly cost of our data extraction jobs. There are two separate black-borders, and part of a third, running into the hundreds of dollars a month per job, that specify our extraction requirements.
Finally, we must support specialized authentication (Kerberos), the specialized update processing to convert HR data to directory data, and we must plan for capacity and model our data organization. This requires several full-time development staff, each with unique fields of expertise.
There is no charge-back mechanism in the directory, so we don't recover our costs for providing this service. We feel the directory service is infrastructural, and should be covered without a per-use or per-user fee. This will require a significant commitment from ITD to cover the expenses for this service. I think we'll have to make a better case for this.
Software Integration v. Development
One strategy we can use to help cap costs is to rely more
on software vendors.
In other words, push some of the required expertise to run
this service out to vendors who develop and market directory
software, rather than attempt to develop and run home-grown
software here at U-M.
Vendors can provide the server software, administrative and
operational training, rigorous performance and feature testing,
and documentation, among other things.
They also have a strong incentive to keep up with contemporary
networking standards.
Work we could do on the UM LDAP reference implementation to catch
up with the LDAPv3 standard has already been done by Netscape,
for example.
We can also develop some customized parts of the server software
here at U-M, then transfer the technology to our server software
vendor for them to productize and support.
Let it be noted that this approach has some limitations. First, maintaining a corporate relationship can sometimes be as much work as developing software. As well, vendors have been known to take work done here at U-M and sell it back to us at a high premium. Some would argue that having access to a copy of buildable source for the server software enhances our ability to troubleshoot and resolve problems; most vendors are not interested in providing such a luxury. Finally, reliance on a vendor means we are at the whim of their support service and their development staff.
Thread A:
Reinforce current service
Required resources: We can use 2.5 FTEs with software development skills to handle the server upgrades, software research, and documentation. These tasks will probably take the developers about 8 months (elapsed) to complete. We will need access to test hardware, and monies to upgrade current server hardware and provide additional spare components.
Risk analysis: There may be a limit to how much we can improve the current service. SunOS debugging tools are somewhat limited compared to what is available on Solaris. Also, support for threads on SunOS is an older variety, less standard, no longer supported, and harder to use, than it is on Solaris. Instrumenting the server software may introduce timing or performance problems that break the current service. We may encounter existing service dependencies that prevent some of these changes. Finally, there may be little useful information in the reports we generate.
Required resources: 2 FTEs with data modelling and software development skills can accomplish these tasks in about 10 months (elapsed).
Risk analysis: There may be a limit to the amount of reorganization we can accomplish with the current server software, since it is less flexible and more fragile than more current directory products. We may encounter political complications while attempting to clarify our account lifetime policies. Altering the data extraction programs may prove to be expensive or technically difficult; the HR databases may not contain the data we need, or may not maintain the data at a level of quality that is acceptible to our customers.
Required resources: 2.5 FTEs with project management, software development, and user interface design skills can accomplish this project in about 5 months. We will also need ongoing hardware resources on which to deploy the CGI scripts once the client is done.
Risk analysis: This solution may not be as scalable or secure as we hoped. Differences in browser implementations may make the GUI or even the feature set quite different for different browsers. We may not produce a client that is significantly better than the old clients. We must at least deliver an URL to the "Internet Access Kit" team before they finalize their '98 Kit in May, for delivery to incoming students during Summer Orientation.
Required resources: It will take 3 FTEs with directory administration, performance modelling, and software development skills about 6 months (elapsed) to accomplish this effort. This effort will also require temporary hardware resources while testing and migrating to the new server software.
Risk analysis: It will be impossible to completely reverse engineer the current service -- some pieces will be missing when we eventually cut over. Constructing a test harness can be difficult and expensive, and may not always reveal all the problems. Some vendors are uncooperative. Given the age of our current system, it is likely we will have to use drastic cut-over instead of a gradual migration.
Required resources: This effort will require the allocation or migration of ongoing resources with which to evaluate and provide new services. We will also need to identify hardware and operational resources on which to base new services.
Risk analysis: There may be some limits to what even the new directory server software will allow us to accomplish. We still need to study carefully metadirectory and public key technology to understand how it works and what it will mean to deploy it. Account lifetime issues may be too complex to address.
Evaluation Criteria
| Due date | Deliverables |
|---|---|
| April 1, 1998 |
|
| May 15, 1998 |
|
| July 1, 1998 |
|
| August 15, 1998 |
|
| October 1, 1998 |
|
| November 15, 1998 |
|
| January 1, 1999 |
|