ITPG Meeting Minutes February 17, 2004

Present: Arlene Allen, Eric Brody, Ken Dean, Chris Dempsey, Saturnino Doctor, Bill Doering, Matthew Dunham, Bill Koseluk, Elise Meyer, George Michaels, Alan Moses, Joan Murdoch, Larry Murdock, Fuzzy Rogers, Glenn Schiferl, Deborah Scott, Chris Sneathen, Jamie Sonsini, Paul Weakliem, Craig Welsh

ITPG PROJECT PROPOSALS

Copies of summaries of the proposed projects were distributed, and discussion continued from last meeting. Prior to discussion of specific projects it was mentioned that projects should involve more co-operation and coordination and critical thought, especially in the light of the current budget situation. Proposals should have a business plan orientation, and methodology proposals (or non-tangible) proposals can be considered as well. Proposals should try to get as detailed as possible. Proposals should be prioritized by mid March, written up by the end of March, and forwarded to the ITB in April for 04-05 funding. Meeting schedule will be increased to twice a month to discuss the proposals. "Ghost writers" should work closely with the principals of the proposals and not write in a vacuum.

Comments on previous meeting's proposals:

Data Modeling: Information Sharing, Training, Ongoing Education – Chris Dempsey

Information sharing, training, ongoing education for application developers on campus: A great deal of time is spent on getting access to data and developing toolkits and APIs to access data. High turnover of developer staff requires enormous resources to train staff on where services are, who is responsible for maintaining them, and how to access them. Some projects may be "impossible" only because we do not know how to get data or how to manipulate it if we can get access. Organizations may be able to share knowledge internally, but often fail to share knowledge with other campus groups. Much of that knowledge is exceedingly arcane – such as writing JCL and SAS to extract mainframe data – and prevents rapid development. Toolkits and APIs must be developed and published for software developers. The DECAF group seems to have some of these tasks assigned, but is now inactive.

Some sort of structure with an Authdir-like architecture is needed to access multiple data repositories; Arlene has assembled a small group to create a model of what we have available and how to gain access that includes input from those who would be actually using the system. Control and security exposures need to be considered. DECAF needs to reform and provide the needed vision in approaching problems and solutions.

Getting Student Data into the Datawarehouse – Chris Dempsey and Deborah Scott

In conjunction with the above, many existing or potential services require access to some type of student data, such as class lists, demographic data, financial data, employment, etc. The data warehouse provides limited data such as the General Ledger for MSOs and business officers, but similar service providing student data yet exists. There has been development of broker calls to supplement the dozens of daily extracts used by campus organizations, but broker calls still require a large amount of time and money to develop and use, and rely on platform dependent client applications. Ideally, one could use authenticated web services to provide near-time or real-time data to campus service providers.

The Student Admissions, Registration and Curriculum Systems are designed for powerful and efficient transaction processing to move students from admission to graduation, but it is not optimized for data access, reporting, and ease of use by all departments, faculty and staff that rely on this information. The proprietary mainframe database, while relatively safe from intrusion requires labor intensive special purpose programming to generate reports and queries.

Administrators and academic departments would benefit greatly from access to this data through a Registration and Curriculum Data Warehouse designed for efficient data retrieval and integration with modern report-writing and data-analysis software. Attempts to achieve this in the past have been hampered by the need for complex security schemes and the lack of widely accepted report-writing software. The IS&C Data Warehouse development team has successfully implemented tools and security for the UCSB financial, purchasing and payroll data for reporting and analysis, and has shown that the earlier obstacles can now be overcome and it is time to move the student and curriculum data into a D/W too.

This effort will greatly expand the capabilities of departments by allowing flexible analysis of data as new questions and requirements arise, without funding a programmer to write a custom report. Examples of organizations and individuals who have requested accessibility of this data are: Institutional Research for UCOP reporting; College of Letters and Science, Dean for curriculum planning, and monitoring of student course load minimums; Institutional Advancement, access to data about student degrees awarded to support Development efforts; Graduate Division, graduate student employment data merged with graduate student course-load information; Student affairs, VCSA, reverse search on student data elements to determine student identity and or emergency contact information.

Many existing or potential services require access to some type of student data. Student data needs to be coordinated with payroll and other existing databases. Chris has been working with Mary Wenzel and the Data Warehouse on this issue. A process needs to be established through a working group that would define user requirement and most critical needs; this possibly could be a component to DECAF, although funding would be needed. There has been development of broker calls to supplement the dozens of daily extracts used by campus organizations, but broker calls still require a large amount of time and money to develop and use, and rely on platform dependent client applications. There are workload concerns, and this project would require funding (yet to be determined) that would identify responsibility for providing the tools to allow broad campus use of local data in a secure environment, but the economy of scale in a campus-wide centralized way of looking at the use, tools, and security should be worth the investment. It is important that the use of the Data Warehouse does not become more difficult. The Accounting office proposed expanding the scope of the Data Warehouse to include student data.

Portal: Project Summary from Integrated Web Services Proposal from 2001) – Deborah Scott

The UCSB Campus community is investing significantly in the development and implementation of complex Information Technology (IT) systems, with self-service, web browser based interfaces to perform increasingly complex transactions with UCSB. Examples of these are: On-line course registration (SA), on-line Quizzing tool (L&S), On-line Housing availability search tool, Graduate Division Portal, Financial Aid on the Web, and many others. Future examples of these are Electronic Grades submission, Degree Audit, New BA/RC application, Course Management applications.

The importance of these systems, and the criticality for data privacy and integrity drive the need for a solid and secure IT platform for the campus that will be available for all system developers to utilize when releasing secure web interfaces to campus computing resources. With limited IT staff on campus, and the importance of correctly leveraging new technologies in this area, it is expeditious to centralize some of the functions, which will allow for common authentication, organization and personalization.

This proposal identifies the overarching project structure needed to implement Campus integrated web services that can be used by all, and maintained consistently and effectively as a Campus Utility. This structure will provide a secure, personalizable and adaptable interface to campus web applications, to increase both ease of use, and ease of administration. It will consist of three sub-projects that are building blocks to the overall goal of integrated web resources that can be phased over time:

1. LDAP/Campus Directory Services
2. Security Services
3. Middleware Services (Data Interfaces/Portal Engines/Application Server)

These projects need to be coordinated with participation from a wide range of College and Division Faculty, staff, Students, Graduate Students, campus IT service providers, and the UCOP New Business Architecture 2010 Initiative.

Another element, which needs to be coordinated within this overall effort, is the Portal User Interfaces for specific user groups on campus. The scope and breadth of this effort is not specifically addressed in this proposal. The people assigned to this project should become essential participants in the discussions concerning portal content based on user roles, and have responsibility for translating these into specifications for enhancement to the integrated web services.

This proposal is a continuation of components previously submitted. OBLIX has arrived and is in the implementation stage. A working group is needed to discuss and understand our needs, and then obtain software and develop tools for campus access. A portal and course management tool should encompass a discipline-based calendar that lists appropriate seminars across departments/disciplines that would merge academic calendars from departments for divergent groups of users. UPortal may be the best solution, but a policy group is needed; the timing is good for an autonomous group to address the student-related issues. SAKAI includes Uportal, so if SAKAI is selected as the course management solution, what is the impact on this project proposal?

Next meeting: Friday, March 12, 2004, 9:00am in the Mary Cheadle Room, Davidson Library.