Enterprise Directory Project Pre-Feasibility Study Information and Educational Technology

Transcription

1 UC DAVIS: OFFICE OF THE VICE PROVOST INFORMATION & EDUCATIONAL TECHNOLOGY Enterprise Directory Project Pre-Feasibility Study Information and Educational Technology Background Unprecedented growth and an increasingly complex regulatory environment demand a new approach to the University s core business processes and structure. In order to support this significant projected growth, UC must begin to put into place a New Business Architecture that will scale to meet the challenges driven by enrollment growth, technological advances, and the rising expectations of our constituents. As the New Business Architecture evolves to better support basic administrative operations, it will offer similar opportunities in the administration of such mission critical activities as sponsored research and student services. 1 In response to the UC 2010: A New Business Architecture report, UC Davis has established a New Business Architecture (NBA) Initiative, with a local steering committee co-chaired by Vice Chancellor, Janet Hamilton, and Vice Provost, John Bruno. The central component of the NBA Initiative is a Business Portal designed to implement integrated and streamlined user-centric services for students, faculty, and staff. Access to services must be provided through a common, Web enabled, enterprise portal. Legacy system services and new applications, implemented over top of our legacy systems, must be accessible via this common enterprise portal. A comprehensive middleware infrastructure is a centralized way to provide portal authentication, authorization, and personalization. The UC Davis information assets are distributed among a large number of administrative and academic computing systems making it difficult to achieve coordinated access to institutional data. It also complicates the delivery of effective decision support systems, since there is no single centralized representation of this information. As the UC Davis campus makes deeper commitments to the development and implementation a business portal, middleware, and Enterprise Directory Services (EDS) in particular, has emerged as a fundamental technological foundation. Current Situation We have made important strides at UC Davis with the development of MyUCDavis, an enterprise portal. MyUCDavis delivers functionality for students and faculty and is just beginning to provide for new business functionality. The development of new portal 1 UC 2010: A New Business Architecture, UNIVERSITY OF CALIFORNIA (Letterhead for interdepartmental use)

2 functionality will depend heavily on our ability to access and share information from our legacy administrative computing systems. Today at UC Davis, there are islands of information providing overlapping sources of person identity and attributes with varying levels of data currency, validity, integrity, and security. Some of the principle sources of identity and person information come from: The Account Management System, The Payroll Personnel System, The Student Information System, The Library Information System, The Advancement Information System, University Extension, HR systems, The Financial Information System, Campus billing systems, and The Telephone Directory. As a result of the independence of our legacy systems, each one tends to develop its own middleware infrastructure to support authentication, authorization, and workflow. This is insecure since we have to remember multiple account information (login IDs and passwords), various authorization schemes (each one different), and the separate workflow infrastructures. Information in the legacy systems is not shared and therefore suffers from inconsistencies (an address update in one system is not propagated to the others!). Ultimately, this becomes an increasing and unnecessary burden on students, faculty, and staff who must navigate among these legacy systems. Additionally, each of our legacy systems presents a different client-side access method. Some of our more recent systems are Web enabled, but many require downloading fat client-side software that varies from system-to-system and without a consistent user interface. The existence of Citrix servers is witness to the current state of affairs with fat clients and clients that fail to run on common desktop platforms. UC Davis has a directory lookup service for finding people. This directory service is built algorithmically by extracting person information from legacy systems and correlating this information. During this process, inconsistencies are found and business rules are used to resolve conflicts (not always correctly). While this process has been useful for providing a basic directory lookup, it is not used by any of the legacy systems to create unique person identification it is not an integral part of our legacy systems. Proposal Typically, administrative and academic services are organized in a function-centric manner the student information system, the financial information system, etc. As was indicated above, each system tends to have its own independent view of people, 2

3 authentication, authorization, and workflow and this creates barriers for accessing and sharing information. The key to creating a user-centric view of services is to provide an infrastructure that will facilitate the sharing of information among our functionally organized administrative computing systems. Enterprise Directory Services (EDS) are the most fundamental services of the middleware infrastructure and are designed to promote convenient and accurate access to legacy data. We are proposing to design and implement Enterprise Directory Services. Initially, this service will consist of two components: 1) a centralized Person Registry designed to maintain unique identification for all persons associated with UC Davis, and 2) a Directory containing additional person attributes suitable for implementing authentication, authorization, and workflow services. Additionally, an Identity Management Office will have to be established. The purpose of the office is to maintain the uniqueness of the entries in the Person Registry. Statement of Work Enterprise Directory Services are comprised of two components, the Person Registry and the Directory. The Person Registry will be based on a small collection identity attributes to verify identity and resolve any inconsistencies with existing historical Person Registry records. Work associated with the Person Registry includes the following: Work with campus constituencies to define the community to be included in the campus Person Registry. Identify the Registry data elements and business rules associated with these data. Identify sources of Registry information and work with system owners to integrate these data into the Registry. Work with system owners to develop plans for the adoption and integration of the Registry s unique person identifier into each administrative system. Design, implement, and develop processes to ensure that Registry entries are unique and unambiguous, and can be managed to ensure their integrity over time. The Person Registry is the key to creating and maintaining unique identification for all UC Davis constituents. As such, on-going project costs include an Identity Management Office that will be responsible for the campus identity management process. The campus Directory, the second component of our proposed Enterprise Directory Services, will maintain person and other management information on active campus constituents. It will receive cleansed or verified data from the Registry and obtain and provide consistent, centralized directory information to campus administrative systems. 3

4 Work associated with the Directory includes the following: Work with campus constituencies to define the Directory data elements and business rules associated with storing these data, necessary to support campus computing systems. Implement the protocols that will permit campus systems to use the Directory. The Directory must utilize standard protocols that ensure the broadest possible integration of campus business and academic applications. Work with campus system owners to adapt their systems to read and write directory records to the extent permitted by their applications and the campus security architecture. A summary of the project work plan is in Attachment 1. There are significant challenges. A centralized and authoritative Person Registry and Directory requires the commitment and engagement of all current administrative system owners. It also requires the adoption of these standards for future systems. In order to simplify the project we envision it in two phases where the first phase concentrates on integrating the Registry and Directory in one of the legacy administrative systems rather than all of them at once. It is conceivable that we would be able to handle more that one administrative system during the first phase, but this would depend on our ability to leverage the necessary resources. Critical Success Factors The following factors must occur for this project to succeed: 1. Creation and support of a middleware infrastructure that provides a common, highly available, redundant, and trusted Person Registry and Directory. 2. Development of an Identity Management process that assures an unambiguous identity for individuals. 3. Campus agreement on a common method to establish a trusted identity for individuals. 4. Full participation by the current and future major administrative systems in the development and use of the Person Registry and Directory. Project Risks 1. The most significant risk to the success of this project is the inability of the campus to adopt a common approach for identity management. If new and existing system providers are unwilling or unable to use the centralized Person Registry and Directory, the ability of the campus to successfully implement the New Business Architecture will be compromised. 4

5 The proposed project plan includes adequate analysis and design stages to fully explore the best practices associated with integrating existing administrative systems into the Registry and Directory. 2. Another significant risk is the availability of resources to assist with the construction of the Registry and Directory. Resources required for this project include management, technical development, and subject matter experts from many administrative computing systems. 3. A risk is inherent in our project schedule. It is paced to plan for input from each administrative system owner, allowing time to build consensus on the architecture for the exchange of directory data. The project team is aware that at least one system the Library has already purchased a system that expects a centralized directory service. Another system Banner s Student Information System plans to ship a new version in the next year, which also expects a centralized directory service. Other campuses have already encountered this misalignment of schedules for deploying a directory service and have resolved this problem with various temporary solutions. UC Davis may well face a similar situation in which a temporary solution can be employed prior to the full-scale rollout of the Person Registry and Directory. 5

6 Financial Analysis Project Totals One Time Costs Labor $36, $303, $153, $493, Hardware $36, $92, $129, Software $0.00 $125, $125, Training $6, $6, $12, Total per year $78, $527, $153, $759, On-Going Costs beginning in Hardware Replacement $34,000 Software Maintenance $50,000 Labor (3FTE) $241,500 Indirect costs, Identity Management Office $50,000 Total Annual Costs $375,500 Budget Assumptions Labor One-time labor costs are based on 2-fulltime programmer analysts, one project manager and one technical lead. On-going labor costs are based on 3 FTE for the management of an Identity Management Office: 1 manager and 2 fulltime programmers. Hardware One-time hardware costs include one development server and two desktop computers for development. On-going hardware costs assume 1 database and 1 LDAP server and 2 additional servers for redundancy. Software Software costs are based on estimates from the leading LDAP suppliers, namely SUN and Oracle. Training We expect to secure training for members of the core project team. Budget assumptions here are based on comparable training currently offered. 6

7 Attachment 1 PROJECT PLAN, Phase I Summary Project Initiation Stage Begin Date Estimates March 2002 Key Issues Identify the project charge, including The scope of the project, The costs and benefits, The core project team, Identify a cost benefit formula for infrastructure projects. Participants (participants remain constant over the duration of the project) John Bruno and Dave Shelby, project sponsors The NBA Technology Development Team (TDT), considered as part of the extended project team and the traditional Project Customer Advisory Committee. The IET component of the core project team: Randy Moory (technical lead), Sandra Stewart (project manager), 2 programmer analysts, Patrick Kelly (Database administrator and hardware specialist), and Jatinder Singh (technical architect). Deliverables 1. Pre-feasibility document completed. 2. Project Oversight Committee identified. 3. NBA Technology Development Team identified as the Customer Advisory Committee. 4. The Project Team identified, including (a) core EDS technical staff who will build the EDS and (b) technical people who will change their administrative systems to use the EDS. 5. Hardware and software environment identified for prototyping. 7

8 Analysis Stage Begin Date Estimates June, 2002 Key issues Review the Advanced Technology Workgroup report regarding the build of Registries and Directories. Organize and undergo training for the technical team. Review hardware and software solutions identified by the Advanced Technology Workgroup for long term (3 year) production-level support. Deliverables 1. Updated business requirements, including an analysis of feasible technical architectures. 2. Updated budget. 3. Draft schemas for the Registry and Directory. 4. Trial construction and loads of the Registry and the Directory for learning purposes. 8

9 Design Stage Begin Date Estimates November 2002 Key Issues Select the architecture and other configuration designs for long-term (3 years) production-level support. Select the development software for the construction of Enterprise Directory Services. This development software assumes long-term (3 years) production-level support. Select a best-fit integration with existing administrative systems, including the campus portal. Make design decisions for loading the Registry and Directory. Develop plans for one administrative system to integrate with the Registry and Directory. Develop resource plans for a Registry interface that allows administrative offices to access the centrally maintained Registry and Directory. This is particularly crucial for individual updates and data cleansing. Deliverables 1. Feasibility Study Report, including a cost benefit analysis 2. Finalized schemas and namespace for the Registry and Directory 3. Finalized architecture and topology of the Registry and Directory 4. Loaded Registry and Directory per the project team s decisions to date 5. Plans for the conversion of one mission critical system into the Registry and Directory. 6. Plans for the campus-wide coordination of data cleansing associated with multiple feeds into the Registry and the Directory. 9

10 Final Construction Stage Begin Date Estimates May 2003 Key Issues Identify a pilot administrative system to begin exchanging person data with the Directory, replacing its dependence on other disparate systems. Write functional and technical specifications for the load processes. Complete the programming that provides the exchange of person data between the Registry and the targeted administrative system. Complete the programming that provides the exchange of person data between the Registry and the Directory Complete the programming that provides the exchange of person data between the Directory and the targeted administrative system Determine the scope of subsequent administrative systems involvement. Develop a schedule for subsequent administrative systems to begin exchanging person data with the Registry and the Directory. Deliverables 1. Person Registry 2. Directory Service 3. The conversion of one mission critical administrative system, integrating it with the Registry and the Directory. 4. A plan for each additional administrative system to convert to the directory services 10

11 Deployment Stage Begin Date Estimates November 2003 Key Issues Develop a schedule for each system to integrate into the Registry and Directory. Develop a schedule for the de-commissioning of the existing account management system. Develop a Project Plan for Phase II implementation of Enterprise Directory Services as the central person repository for mission critical administrative systems. Develop a plan and budget to establish an Identity Management Office. Deliverables 1. The installation of the Directory as the campus computing accounts management system. 2. Plans and a proposed schedule for the de-commissioning of the legacy computing account management system. 3. Completion of a project plan for the implementation of Phase II for Enterprise Directory Services. 4. Completion of plans to establish the Identity Management Office. 11

12 Project Timeline, Phase I March Project initiation Key Deliverable Pre Feasibility Study Report June 2002 Key Deliverable November 2002 Key Deliverable May 2003 Key Deliverable November 2003 Key Deliverable -- Analysis Stage Draft schemas for the Registry and the Directory -- Design Stage Feasibility Study Report -- Final Construction The conversion of one administrative system to interface with UC Davis Registry and Directory -- Deployment Stage, End of Phase I Schedule for the replacement of additional disparate directory services currently embedded in existing administrative systems. 12

13 Attachment 2 Enterprise Directory Project Return on Investment Analysis Return on investment from implementing Enterprise Directory Services and the management of identities is significant. The EDS project team will adopt a similar approach and will seek assistance from the Graduate School of Management and one administrative unit that represents an average investment of time managing identity and directory information. Factors included in calculating a return on investment for Enterprise Directory Services include the following: o o o o Reduced Administrative Costs: Common attributes stored and resolved in most of our internal applications become available from centralized trusted sources. Attributes such as name, telephone, , address, office, department, etc become current and accurate for all the campus applications are available from one system. Processes to provision or transfer members of the community become simplified. Enhanced Productivity: Enterprise Directory Services and identity management make single sign on possible. Multiple user names and passwords for a single individual can be eliminated. Enterprise Directory Services also provide centralized policy-based controls enabling access to information and services, regardless of location or the device being used. Reduced help desk and technical support costs: User access to information and services is streamlined with Enterprise Directory Services. Dozens of separate access procedures are reduced to single sign-on. Application development for the New Business Architecture can rely on a trusted centralized source of information, rather than maintaining the directory and identity resolution internally. Enhance security: Tighter security for identity management is affordable in one location and minimizes the chance of intrusion by eliminating the multiple application-based registries. Centralized identity management and policy-based controls reduce the number of access points and ensure consistency in grants to this service. Osterman Research surveyed 40 organizations that adopted centralized identity management. With a median user base of 2500, these organizations reported and average cost saving and productivity gains of $2.49 million over 3 years. Gartner Group observed and reported significant savings in other organizations. An insurance company reported 40 percent ROI in a single year. 1