IT Project Co-Sponsor: John Scoville Project Dependencies:

Transcription

1 March 1, 2005 Student System Consolidation - Phase I Executive Sponsor: Chancellor Davis Project Manager: Jeff Noyes Project Coordinator: Margaret Dillard Project Sponsor: Vice Chancellor Tom Maier, AVC Tonya Lam IT Project Co-Sponsor: John Graham IT Project Co-Sponsor: John Scoville Project Dependencies: < Include any dependencies surrounding this project including other projects or implementations. > PeachNet GaBEST Model Banner V6 and V7 TouchNet PeopleSoft Financials Interfaces HRMS and Academic Datamarts (USG123) WebCT/VISTA Deployment USOA Legacy Reporting Requirements GALILEO Interface with approved 3 rd party Campus Systems (e.g. parking, bookstore, one card, etc.) Luminis Academic Policy GAcollege411 XML Transferable Transcript Prerequisite for Multi-Institutional Functionality (MIF) Implementation Linkages to the IIT Strategic Plan: < Include the linkages to the IIT Strategic Plan Learning Without Limits > Goal 5.2 in the USG IIT Strategic Plan specifically states Develop objective criteria for decision-making and for determining the most advantageous methods for supplying services and support for the USG.

2 Goals & Objectives: < Include no more than three succinct goals for the project. These statements should be worded so they are easy to remember and adequately reflect the desired outcomes for the project. The objective statement should include possible phases of the project (if applicable), the expected timeframe, and budget information. > Recognizing the need to provide reliable and efficient student services across the University System of Georgia (USG), the Student System Consolidation (SSC) project seeks to consolidate the technical environment for the USG Banner Student Information System into one central location that will serve the six institutions participating in the project: Bainbridge College, Waycross College, South Georgia College, Atlanta Metropolitan College, Fort Valley State University, and Georgia Gwinnett College. Through consolidation, we will improve services across USG with a model implementation of the Banner Student Information System software that will include only the software as released by the vendor and approved GaBEST modifications. The model system will be a supportable, sustainable solution that will result in long-range cost avoidance. With this in mind, the SSC project has identified two major objectives: 1. Establish a consolidated technical environment for the USG Banner Student Information System that integrates well with other enterprise applications. 2. Provide an enhanced level of consistent student services throughout the USG. Background/Narrative: < Provide any pertinent background information and/or drivers of the project. Answer questions such as: Why is this project needed? What has brought about the need for this project? What are the surrounding issues? What functions will be affected? What has been the impact of not having this project implemented? > Although thirty-two USG institutions are operating the same basic Banner Student Information System software, each is providing its own computer equipment, technical staff, and facilities at each local campus. These institutions include large research and regional universities as well as smaller four-year and two-year colleges which have limited resources to support this type of effort. These multiple installations are largely duplicative in computer equipment and senior technical staff. In addition, the separate installations, each with their own support staff, invite separate approaches to service delivery, reporting, data collection, and even data definitions. This highly decentralized operation of the Banner Student Information System is inherently inefficient and costly and often results in inconsistent levels of services to USG students at different institutions as well as difficulties in consistent reporting. The purpose of the SSC project is to establish a single, central computer equipment operation that will provide a common software system to be used by all the participating institutions, resulting in a more efficient, consistent, and feature-rich student information system for USG.

3 Boundaries: < Empowerment limits and project constraints. Answer the questions what is in scope and what is out of scope of the project. > Overall Boundaries The initial planning process for this project is based on the following overall boundaries: 1. In order to improve supportability and ensure a consistent level of student services, the same production version and patch level of Banner and Georgia Enhancements are required of participating institutions. 2. In a consolidated environment, as in the existing campus Banner environments, reliability and consistency can best be ensured when the Banner Baseline product and/or existing Georgia Best model software enhancements are used for common academic business practices. 3. In a consolidated environment, as in the existing campus Banner environments, when legacy business procedures limit the appropriate use of the Banner Baseline product or existing Georgia Best model software enhancements, institutions should always explore the common academic business practices that allow implementation through the Banner Baseline product and/or existing Georgia Best model software enhancements. 4. There may be cases in which accepted academic business practices can not be implemented through the Banner Baseline product and/or existing Georgia Best model software enhancements. A model change review process, governed by the Associate Vice Chancellor for Student Affairs, in conjunction with user groups that are representative of the USG campus community, will be available. This change review process group will be responsible for the acceptance, review, and approval of changes to the model software. 5. When the process in Overall Boundary #4 is used to determine that modifications are appropriate to best benefit all USG institutions, these modification will be incorporated into the consolidated model. Specific Boundaries The SSC project sponsorship has established the following specific boundaries based on knowledge gained from the PeopleSoft environments, an awareness of the different needs of the Banner environment, and the future direction of the development of the SunGardHE Banner application. 1. The following SunGardHE products are not planned or budgeted for in the initial implementation phases of this project: o IVR Voice Response o Luminis Platform Suite (including Portal, content management, calendaring, and SSO) o SUNGARDHE Imaging, Workflow, and other document management applications Note: While the SSC project sponsorship recognizes the importance of these products and services, extensive additional analysis is necessary to determine the best way for the SSC environment to accommodate them. 2. The Multi-Institutional Functionality (MIF) project capabilities are being integrated into baseline Banner. SSC institutions will have this capability with the implementation of the appropriate Banner version upgrade 3. Experienced campus personnel are, and will remain, the best avenue to provide primary functional user support. The OIIT Customer Service HelpDesk may be contacted for secondary support as necessary. Escalation of issues with SunGardHE through OIIT has been extended to include 24x7 support. 4. The SSC project will establish uptime availability for the hosted environment as follows: o OIIT will perform regular backups and other scheduled maintenance that will require SSC service downtime according to the OIIT Service Level Guidelines, a published maintenance schedule and process.

4 o If the repetitive testing of any upgrade process proves the tasks associated with an upgrade cannot be completed during the regular maintenance window or over a weekend, extended downtime will be scheduled with prior notice. o A comprehensive backup plan for maximum recoverability will be developed and tested and will use enterprise-class storage solutions and a combination of backup solutions. o A retention cycle for backup sets of at least a 7 day, 4 week, and 4 month cycle will be maintained. Additional backup retention periods may be necessary to address needs during agreed upon academic processing cycles that coincide with the published System Office academic processing cycles. 5. In order to create an efficient and reliable environment, the SSC project will establish the characteristics of the hosted environment as follows: o The Banner database and application servers for the SSC environment will be housed in a hardened facility in Athens. o In order to establish a common quality assurance process, the SSC environment will provide each participating campus with one pre-production environment that may be used for campus testing purposes. Read-only access outside of the Banner application will be provided in this pre-production environment to facilitate reporting. No development or update access outside of the Banner application will be provided to end users of the pre-production environment. User privileges and accesses will be established in this environment as a mimic of production privileges and accesses to ensure the integrity of testing of upgrades, patches, and releases prior to application to production. o The SSC environment will provide each participating campus with one production environment. Read-only access outside of the Banner application will be provided in the production environment to facilitate reporting and execution of read-only interfaces. To protect campus data, no development or update access outside of the Banner application will be provided to end users of the production environment. o The SSC project sponsorship will establish a common process for data updates outside the Banner application with data recovery points. o Campuses will retain the ability and responsibility to customize their Banner Self Service pages through the use of Web Tailor. o The SSC environment will use firewall protection and encryption where appropriate. o The SSC environment for production will be implemented at the most recently released version of the Banner and the Georgia Enhancements. o SunGardHE will discontinue the support of the Banner client/server during the implementation phase(s) of the SSC project. Therefore, in order to provide for the smoothest transition for administrative users, Internet Native Banner (INB) will be used in the SSC environment to provide administrative access to Banner. Traditional Banner GUI (client/server) access will not be provided to administrative users in the SSC environment. o In order to provide the most secure and accountable environment, UNIX shell accounts or telnet/ssh will not be supported in the SSC environment. Mechanisms will be provided to enable users to securely upload tape load files for batch processing and to review the status of jobs that have been submitted through Banner job submission. o A job scheduler will be provided to allow campus-designated technical personnel to schedule and maintain end user jobs for their campus without having an adverse impact on the shared resource. UNIX scheduling through cron or at jobs will not be supported. o The SSC environment will establish a database naming convention that is similar to the PeopleSoft naming

5 convention so as to easily identify the institution and to distinguish between production and non-production environments. o The SSC environment will use default Banner seed numbers. This will eliminate the need to reset seed numbers in multiple areas within the SSC environment for each upgrade. o With the exception of Banner Self Service, the SSC environment will allow access to Banner for administrative users only from the IP address space of PeachNet. Banner Self Service will be accessible in SSL-enabled mode from a supported browser on the WAN. o The SSC environment will provide browser-based delivery for Banner output. o Reporting and read-only database access in the SSC environment will require the ability to initiate an encrypted client session. 6. To ensure the security of the environment, the SSC project will establish user access to the hosted environment as follows: o Because the current architecture of the Banner environment allows creation of DBA level accounts from the Banner Security objects, the central support group will initially create the new Banner user accounts in the proposed SSC environment databases. This will only involve the creation of the initial accounts to establish the account using rules suggested by the State Department of Audits and the Administrative Committee for Information Technology (ACIT). Campus personnel will retain the ability and responsibility to define user classes and access levels and enter the information into administrative Banner. o Database password strength for new accounts will be set and enforced using password strength algorithms. o The SSC environment will not include the ability for campus personnel to create direct database access accounts. o The SSC environment will not provide Oracle login access to Banner schema owner accounts (i.e. general, arsys, faismgr, taismgr, baninst1, WebTailor, etc.) to campus personnel. o The SSC environment will not enable campus personnel to create customized database objects (tables, PL/SQL objects, etc.). o The SSC environment will not enable campus personnel to modify existing Banner Baseline or Georgia Best model enhanced database objects except as participants of a governed change management and joint development process as defined in Overall Boundary # The SSC project will establish supported solutions for data updates outside of the Banner Baseline application forms and/or processes as follows: o The SSC environment will not provide the campus community at large with direct access to update Banner data outside of the administrative Banner application or Banner Self Service. o The SSC environment will provide the ability to transfer files to the individual participating institution s hosted environment to support tape load processes that are a part of the Banner Baseline product and/or existing Georgia Best model software enhancements. o In the SSC environment, batch updates, including update interfaces, to Banner outside of the administrative Banner application or Banner Self Service, will be treated as data base interventions (DBIs). Campus personnel will develop DBIs that follow a change migration cycle of application to-test-environment by the central support group, testing, approval, and written sign-off by campus authority; and application to a production environment by the central support group following a backup cycle, during which a verified recovery point will be taken. 8. The SSC project will establish supported solutions for end user reporting and outbound interfaces as defined below:

6 o The SSC environment will provide a reporting environment to allow flexibility in reporting options at the institutional level for the participating campuses. o The SSC environment will create at least one reporting role and user account for each campus database to support ad hoc reporting and read-only interfaces from all the Banner schemas outside of the Banner application-provided reports. If a set of job-specific or schema-specific roles for reporting outside of the Banner application need to be defined, the SSC project members will rely upon the governing user group(s) to define and document the access associated with the various reporting roles. o Data extracts from Banner in the SSC environment to 3 rd party systems (such as parking or ID card systems) will be handled as read-only interfaces. The reporting role(s) and account provided by the SSC environment will be used to execute data extracts from Banner. o Read-only database access in the SSC environment will require the ability to initiate an encrypted client session. 9. The SSC project will establish beta testing, user acceptance testing periods, and methods as follows: o The SSC environment will provide a read-only, pre-production environment for each participating institution that will be established with the same privileges and accesses as the production environment. The preproduction environment will be used by participating campuses for testing Banner or Georgia Best model software processes and procedures prior to execution in production. o The SSC project will schedule upgrades during specified upgrade windows for a period of time based on the complexity, timing, and relative content of the specific upgrade. o The SSC project will support and observe one common quality assurance process for testing and certification for Banner and Georgia Best model software enhancements in cooperation with the common development environment as defined in Specific Boundary #8. o The SSC project will establish supported solutions for development of non read-only modification as follows: - The SSC project will provide one common development environment that can be shared by all institutions that participate in joint development of approved modification for the project while not interfering with reporting efforts. - The SSC project sponsorship will provide a process to develop, test, certify, and deploy common services. Therefore, the SSC project will support on change management process that will be governed by the process defined in Overall Boundary #4. - The SSC project will support one common joint development agenda as defined by the governed change review process referred to Overall Boundary #4. - The SSC project will provide all participating campuses with access to the common development environment. The SSC project will not provide individual development environments to campuses.

7 Deliverables: < Tangible and intangible products, processes, results and services > 1. Centrally managed disaster recovery and technical business continuity plan for hosted applications. 2. Technical framework to support standardization of business practices. 3. Central management of certain security tasks for hosted application tests following ACIT and OIIT security guidelines including change control procedures for application source code, security awareness training, application of vendor security patches and conducting periodic security penetration tests x 7 hardware support with 4 hour vendor response time for hardware maintenance. 5. SSL encryption for Banner Self-Service (Banner Web) 6. Uniform backup strategy for hosted application, including an automated tape management and tape retirement strategy. 7. Enterprise job scheduling for administrative users using a job scheduler. 8. Service availability monitoring for the hosted application. 9. A service level guideline. 10. Remotely accessed campus reporting environment. 11. Remotely accessed joint developer environment.