11 ITLC – Middleware Report May 27, 2010 The work of a subgroup of ITAG

22 Middleware Overview “Without delving into the details of the technology and approach, a common UC middleware may provide an architecture/approach that enables UC to more optimally leverage system wide information technology resources while still addressing campus specific operational differences and cultures” (from Common UC Middleware 1/28/10 R2V5)  Why a common middleware?  Opportunities for campuses to act as ASPs  Sharing applications and services  Common tool set to facilitate sharing  Promote interoperability  Create opportunities for re-use  Proof of concept with a practical pilot

3 Potential Pilots Explored  Pilot Project Parameters  Must involve interoperation between at least two or more IT organizations within UC  Should not be just a technology trial  Should involve the use of middleware, not just shared services  Pilot Project Possibilities  Something related to PPS  UC Trust  Data Warehouse  User Provisioning 3

Proposed Pilot/Proof of Concept User Provisioning for Multi-campus Applications  Why this project?  Part of the ITLC work plan – initial project proposal ready to go  Foundational piece for potentially many more applications  Would have been helpful if in place for previous efforts like:  UCReady  Connexxus  ERS  LMS 4

Project Goal “The goal of the proposed project is to leverage the policies and agreements already established for UCTrust to develop a second software infrastructure that supports the exchange of identity information before, and independently of, the establishment of a user session. “ (Source: ITLC Project Proposal – Initial Overview – User Provisioning for Multi-Campus Applications) 5

Potential Features and Benefits  Common framework for more agile deployment of multi-campus applications  Common definitions (what’s a student, faculty member, etc.)  Lower costs in time, effort, and resources – both centrally and locally  Bus-routed workflow that can build information from a variety of sources  Standard interface specification  Common mechanism for acquiring data  Addresses initial need for provisioning privacy constraints  Automates acquisition of necessary information and approvals 6

Proposed Timeline  Target completion date – January 2012  First milestone is ITLC checkpoint for a go/no-go decision – target date – January 2011 on completion of:  Technical and business architecture  Approach and plan with subsequent milestones to implement the architecture throughout UC  Estimate of resources required for subsequent milestones, both UC- wide and at each campus 7

Next Steps  Obtain approval from ITLC to move forward on Phase I activities  Establish a technical work group to advance the work of the first milestone  Some ITLC membership  UCOP project manager  Technical experts from UC locations 8