Memorandum of Understanding Data Management System (DMS)

Transcription

1 UcSB/UCI Academic Senate Data Management System Collaboration This (MOU) Is an agreement between tic Santa Barbara and tic Irvine to coilabotate and deliver a shared Data Management application. j Data Management System (DMS) lune 1,2015 Memorandum of Understand Ing Natalie Schonteld Executive Director, Academic Senate Shobreb Bozorgmehrl Director of Academic and Network Applications tic Irvine Dana F. Roode Chief information Officer and Associate Vice UC Irvine Chancellor, Office of Information Technology Deborah Karoff Executive Director, Academic Senate tic Santa Barbara Approvers Affiliation Campus Please provide signatures on the final page. Versions effective date: July 1, David Marshall Executive Vice Chancetior tic Santa Barbara Andy Satomi Director, Academic Affairs information Technology tic Santa Barbara tic Irvine This MOU Is valid from the Effective Date outlined herein and is valid until the Date of Termination. This Agreement should be reviewed a minimum of once per fiscal year; however, in lieu of a review.-,_... I Next Review Oat: June 1, Z016 Current Review Date: during any period specified, the current Agreement will remain In effect. This agreement can be Periodic Review terminated with 6 months notice by either party. Approval ;. : -.

2 : UCSB/UC1 Academic Senate Data Management System Collaboration )une 1, 2015 I. Executive Summary This document serves as an agreement between UC Santa Barbara s Academic Affairs Information Technology and UC Irvine s Office of Information Technology to provide a collaborative model for delivering the Academic Senate Data Management System by implementing a central web-based document workflow system. This approach will bring forth significant tong-term cost saving benefits by eliminating redundant efforts across multiple campuses. Benefits include opportunities to streamline processes and adopt unified standard practices, as well as provides the means to implement scalable IT solutions; all of which are vital to the university s complex business environment. II. Project Overview The existing Data Management System (DMS) at UCSB will be modified and redeployed to support multiple UC Campuses. The application and data will reside at the UCSB campus where project programming staff will perform necessary and agreed upon development, bug fixes, updates, and enhancements to the system. The data will be hosted and maintained by the hosting campus OBA and security teams and all participating campuses will be able to submit requests for any updates and enhancements. The project will require additional security considerations, database considerations, and user interface updates to reflect a custom look-and-feel for each campus. The project may also add additional workftow or custom functionality required by a single campus that updates the structure of the entire application. Each participating campus wilt be responsible for developing and maintaining data feeds and web services to support the application. Each participating campus will also be responsible for importing the initial data and the rotlout to their own campus including training, documentation, and first-tier customer support. Training of participating campus IT support will be provided by the hosting campus. The development and maintenance overhead necessary to run multiple campuses from a single application and data storage system may be offset by looking at the following benefits: 1. StandardizIng and digitizing Senate business process into one shared application enables faster replication ofprocess innovations across oil participating campuses, 2. Collaboration from multiple campuses for a single application will help us streamline business processes at oil campuses. 3. A unified code base means multiple campuses are employing technical personnelfor a centralized software environment, not disparate systems. This approach reduces the overhead created by Individual campuses each employing technical personnel to duplicate common application functionality. 4. Upon completion of each version of the system, a single technical team can perform maintenance. 5. Most standards and middleware customizations can be reusedfor other applications and will help set standards for the benefit of other UC campuses. DM5 - UCSWs Data Management System Hosting campus The campus where the system and data reside PattcIpating campus The campus who is not hosting, but using the system 2

3 I. Feature sets and application design IlL Collaborating between Campuses 3 needs over and above the hosting campus current processes, additional infrastructure resources will The system itself will need servers and server maintenance, database support, security support, individual campus will be maintained and backed up by that campus. If a participating campus has Infrastructure teams using the procedures of the hosting campus. Any data stored locally at an back-up processes etc. The hosting campus will provide these services with their Internal iv.. Infrastructure Needs information sharing regarding project progress and challenges. Major features created for an participating campus will be required to submit bugs from their campus Into the bug tracking system. hosting campus. Second line support, Including infrastructure-related Issues and emergencies will be provided by the individual campus should be developed in such a fashion to allow each participating campus to First line support Including Uient communications should be done from the originating campus. fixes. A standard schedule will be used to roll out any updates or fixes to the system. Each The project manager and the Governance Group will determine the prioritizatlon of Implementing the Bugs will be logged and maintained In a single bug tracking system located at the hosting campus. III. Bug fixing and maintenance opt-out of the enhancement by hiding or disabling the functionality. A regular meeting will be scheduled among alt participating campuses to facilitate communication and Ii. Software Development When the campuses cannot agree on a feature or require different customizations, both sets of Governance Group. The requirements document will include the necessary features, workfiow, campus customizatlons, and other business rules necessary to develop the next version of the DM5. project team consists of technical staff from the hosting campus who will be working on the testing, and quality assurance testing. This focus on testing and review contributes to a more reliable, more usable software product. Participating campuses are not expected to extensively test or review their respective Academic Senate office as key stakeholders we will refer to them as the DM5 the schedule. These requirements should be delivered to the DM5 project team for review. DM5 requirements should be Included In the document with extra funding or development time added to development of the system. The DM5 project team will return with the project roadmap for review requirements, tlmeilnes, and other deliverable Information for the project. requests are placed in the Enhancement Request List located on the project site for review and comment by all participating campuses. All developed software must follow existing procedures and standards for DM5 development, Including: analysis, design, design review, code review, automated business offices of the participating UC Campuses. Each campus will identify a primary contact from and approval from the DM5 Governance Group. The project roadmap will contain resource Participating campuses are encouraged to submit proposals for enhancing the DM5. Enhancement new product enhancements. A single DM5 requirements document will be created and approved by the joint Academic Senate UcSB/UCI Academic Senate Data Management System Collaboration

4 UCSB/UCI Academic Senate Data Management System Collaboration be required and will need to be discussed with the Governance Group. When needed, a neutral party such as ITLC could get Involved to determine If the current Infrastructure services are adequate or if updates need to be made. It will not be feasible to Implement multiple Infrastructure procedures for each participating campus. IV. Architectural Issues I. Data The participating campuses will provide a nightly data feed to populate and update the database with the campus user information, Data associated with this application will fall into a set of distinct categories: Application-specific data will be stored In a single database location for all participating campuses. a Campus-specific data will be accessible either a the application database, or be accessible via an API (Application Programming Interface). Hooks and automation may be developed to populate between these systems. Approaches to integrate external campus data, including data feeds or SOA for phone book data and access control will be evaluated prior to implementation. This will be an addition to the current architecture of the application. II. Security The security of DM5 is critical because the DM5 application will have access to sensitive documents pertaining to the Senate office. All campuses will need to ensure their security requirements are met through an established standard Infrastructure review, code review, and application vulnerability scanning All participating campuses will need to use tiie Single Sign On system developed at UC Santa Barbara which is based on the Shibboleth technology. This system will allow us to authenticate all users as UC employees and to properly determine their role in the system. There will need to be a separate component to the application to build the security and roles across campus which will add some overhead programming to the application. Campus security teams will need to be consulted to assure all standards are followed property. V. Service Level Agreement A full description of hosting campus and participating campus responsibilities are documented in the Service Level Agreement. These responsibilities Include: performance and reliability gaas & measurement, operational & support communication strategy, and periodic review. The SLA ITLC - University of California s Information Technology Leadership Council API A set of functions or procedures within the system in order to support the building of applications. Single Sign On - A method of access control that enables a user to log In once and gain access to multiple systems without having to log on again. Shibboleth A standards based, open source software package for web single sign-on across or within organizational boundaries. 4

5 System enhancements0 new module development, and timeline specifications will be determined by VI. Project Deliverables document Is posted at: httos:i/aaft.ucsb.edu/orolects/data.manaement.svstem 5 transfer of funds should be initiated by the UC Irvine Academic Senate office. actual costs align with the annual fee. expands, the DM5 project team and Governance Group will make appropriate adjustments to ensure of maintenance and user support needs are determined, and as the user base and functionality VII. Costs the Governance group0 based on the prioritization list located at: UCSB/UCI Academic Senate Data Management System Collaboration UCSB and UCI have collaboratively determined the annual cost to be $51,055. On June 1, 2016, this MOU will be updated and re-approved to reflect the agreed upon costs for fiscal year The annual fee is subject to renegotiation yearly. Over time, as mote accurate assessment of the level The UCSB Academic Affairs Information Technology account Is An Interlocatlon

6 U. UCSB/UCI Academic Senate Data Management System Collaboration VII. Approvals Name Signature for Approval Date David Marshall UC Santa Barbora j4 d%14- Qct /2 f//c Andy Satomi UCSonto Barbara 6/2 /Ja/ Deborah Karoff UCSanta Barbota &i ii/_ t t Dana F. Roode UC Irvine Shohreh Bozorgmehrl UC Irvine 7/z q / Natalie Schonfeld UCIMne % W( /f25( 1ô7.1O1 6