Loading in 2 Seconds...
Loading in 2 Seconds...
University of California Enterprise Architecture: A Case Study ITANA Face2Face - October, 2013. Mojgan Amini, UC San Diego Marina Arseniev, UC Irvine Lisa Gardner, UC Santa Cruz Jerome McEvoy, UC Office of President . About the University of California System.
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Mojgan Amini, UC San Diego
Marina Arseniev, UC Irvine
Lisa Gardner, UC Santa Cruz
Jerome McEvoy, UC Office of President
First “Common and Integrated System” is Payroll and HR IS System (UCPath) based on a single instance of Peoplesoft HCM running across all UC System.
Due to system-wide complexity, Enterprise Architecture seen as a pre-requisite for success
UC CIO creates a dedicated UC Enterprise Architecture Team.
Each campus CIO invigorates “Information Technology Architecture Group” (ITAG) with dedicated campus membership.
First tactical step in realizing the strategic direction of UC Common Administrative Systems initiative and the beginning of a lot of work!
UCOP EA Team
Align Campus and
Strategy and Plans
Campus and Medical Center ITAG members:
UC Campus and Medical Center CIOs:
UC Shared Technology Services:
UC Central Enterprise Architecture Group:
Improved collaboration and communication across the UC system
Request Intake process; review and approval workflow process
Workflow for submission of asset with potential for reuse; review by ITAG; ITAG -> location SME for review/feedback; refinements -> curators UC EA; final reusable asset is published and distributed for adoption at locations (adopt where appropriate, adopt mandatory, or specific to location); confirm CIO adoption response; prepare implementation to location
UC Enterprise Architecture Book of Knowledge (EABok) and an Artifact Framework (EAAF)
POC for ESB features beyond WebServices container
Leverage ESB to mediate data between publisher and subscribers
Exercise different types of data containers (file, record, table)
Exercise different mediation mechanism (sFTP, database)
Explore data transformation integration with ESB (in ESB, at subscriber)
Exercise ESB development, deployment, administration, monitoring and notification capability.
Evolve from point-to-point data distribution to single publisher/multiple-subscribers architecture.