80 likes | 192 Views
ITLC – Middleware Report. May 27, 2010 The work of a subgroup of ITAG. 1. Middleware Overview.
E N D
ITLC – Middleware Report May 27, 2010 The work of a subgroup of ITAG 1
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 2
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
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)
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
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
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