Enterprise Architecture 2013 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

Enterprise Architecture 2013 About the University of California System Formed 1869, starting with Berkeley 10 campuses at Berkeley, Davis, Irvine, Los Angeles, Merced, Riverside, San Diego, San Francisco, Santa Cruz and Santa Barbara 5 Medical Centers – Davis, Los Angeles, Irvine, San Diego, San Francisco 3 U.S. Department of Energy national laboratories - Lawrence Berkeley, Livermore and Los Alamos 220,000 students 170,000 faculty and staff 1.5 Million alumni Research class

Enterprise Architecture 2013 Problem Statement Each campus and medical center has unique and diverse administrative business processes and technologies – Business effectiveness, fiscal efficiency and agility to respond to changing UC business needs needed improvement UC Strategy Statements (December 2012) – – UC Executive Leadership envision Working Smarter Initiative for ten distinct campuses to use one efficient administrative framework: –  Common, integrated financial and payroll systems  Common, integrated time & attendance systems  Common, integrated extramural fund accounting  Common, integrated data warehousing  Common, integrated asset management  Common, integrated e-procurement  Common, integrated energy and climate solutions  Common, integrated indirect cost recovery  Common, integrated library efficiency strategies  Common, integrated risk management

Enterprise Architecture 2013 Problem Statement - continued 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!

Enterprise Architecture 2013 Goals Define and deploy an initial catalog of shared technology services to support common administrative systems, beginning with the new payroll/HR system (UCPath). Build a shared services architecture Increase the consistency, interoperability, and reuse of technology, data and processes across the UC. Create an enterprise architecture for UC along with an initial enabling infrastructure in support of future common and integrated administrative systems.

Enterprise Architecture 2013 Requirements IT and interoperability standards to promote reuse of solutions Clear EA processes and framework(s) Partnership between the UC Enterprise Architecture (EA) Team and ITAG Make sure campus requirements are appropriately integrated A full-spectrum system-wide and location specific communication plan

Enterprise Architecture 2013 Current state Start from scratch Redundancy o Data o Infrastructure o Applications o Cost Variances without common standards One-of-a-kind implementations Desired state Reuse of proven approaches & assets Increased interoperability Informed and deliberate variances Easier to collaborate on UC initiatives Roadmap UC CIOs ITAG and UCOP EA Team Common Administrative Systems Align Campus and System-wide Strategy and Plans 8

Enterprise Architecture 2013 Approach Define Key Roles – UC EA and ITAG working together as a team, and at each location to foster architecture Define Key Components Create an EA Assets & EA Body of Knowledge that is discoverable and reusable – Identify common infrastructure models for reuse and repurpose (thinking EA in a box, Shib in a box, and patterns of deployment) Create and Communicate an EA Asset Lifecycle – Create a structure for enterprise architecture artifact submission, review and approval – Location specific Adoption & Communication – System-wide Communication

Enterprise Architecture 2013 Enterprise Architecture: Key Roles Campus and Medical Center ITAG members: Support the development of Enterprise Assets that are architecturally significant – Examples: Standards, reference architectures, common solutions/services, etc. Evangelize awareness, adoption and use of Enterprise Architecture at their campus Respond to ITLC requests for input on key subjects with recommendation artifacts UC Campus and Medical Center CIOs: Establish ITAG priorities Make decisions regarding investments and campus technology portfolio Determine applicability of Enterprise Assets for their campus, and steps required for implementation UC Shared Technology Services: Make decisions regarding investments in Shared Technology Services and overall UC service portfolio UC Central Enterprise Architecture Group : Curator for Enterprise Architecture Assets Evangelize awareness, adoption and use of Enterprise Architecture across UC 9

Enterprise Architecture 2013 Enterprise Architecture: Key Components 10

Enterprise Architecture 2013 Enterprise Architecture: Assets An Enterprise Architecture Assets Framework (EAAF) is required for lifecycle management of any asset that advances consistency, reuse or interoperability – Examples: standards, specifications, principles, references architectures, etc. A collection of Enterprise Architecture Assets establishes an EA Body of Knowledge An EA Body of Knowledge must facilitate discovery of the Enterprise Architecture Assets – Example capabilities: keyword search, result filtering, taxonomy navigation, workflow, subscription, etc. 11

Enterprise Architecture 2013 What Are Our Enterprise Assets? 12

Enterprise Architecture 2013 EA Asset Lifecycle Submission & Review Location specific Adoption & Communication System-wide Communication 13

Enterprise Architecture 2013 Submission and Review 14

Enterprise Architecture 2013 Location Specific Adoption 15

Enterprise Architecture 2013 Communication 16

Enterprise Architecture 2013 Outcomes More consistency and interoperability, improved quality, reduced redundancy and increased reuse across the UC. Campuses have adopted SOA and Enterprise Service Bus technology for enabling interoperability and real-time interfaces and integration. – Real time message-based IdM integration Secure file transfer mechanisms between all campuses and Payroll/HRIS IdP Proxy One-off data interfaces to and from central Payroll/HRIS system have been decreased, bringing 1200 interfaces down to 300 by identifying commonality of data needs and creating superset interface files. Data Warehousing: Data Dissemination Operational Data Store (DDODS) to reduce data complexity and create consistent meaning and data structure across locations.

Enterprise Architecture 2013 Outcomes - continued 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)

Enterprise Architecture 2013

Enterprise Architecture 2013 Critical Success Factors CIO Responsibilities: Support, leverage, and promote adoption of EA standards at their location Choose to provide (or not) an appropriate ITAG resource at 10-25% FTE level of effort Selection and prioritization of ITAG workplan ITAG resource responsibilities include: Consistent engagement with campus CIO and leadership to assist with planning, outreach and communication Serve as a two-way conduit between campus and system-wide architecture planning Contribute and develop the system wide architectures and standards with the UC Shared Services EA Team Facilitate adoption of standards and multi-location initiatives by working with local implementation teams

Enterprise Architecture 2013 Lessons Learned Executive level sponsorship of Enterprise Architecture required. Need CIOs who “champion” the effort Must have a dedicated team who has overall “ownership” of EA progress and has the time dedicated to promote it. Need to “market” EA as a pre-requisite for common ERP systems or large initiatives. Need to leverage ERP systems or large projects to demonstrate the value of Enterprise Architecture and short term or even immediate results to stakeholders Need to leverage ERP systems for funding and create a sense of “urgency” for an EA program Deal with the “What’s In It For Me?” questions! Challenging charge!

Enterprise Architecture 2013 Appendix A UC Irvine’s Case Study: Enterprise Service Bus Data Hub Architecture – Prepared by: Larry Coon, Durendal Huynh, Tony Toyofuku, and Jason Lin from University of California, Irvine Other….

Enterprise Architecture 2013 UC Irvine’s Case Study: Problem Statement

Enterprise Architecture 2013 UC Irvine’s ESB Case Study: Objectives 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.

Enterprise Architecture 2013 Architecture

Enterprise Architecture 2013 UC Irvine’s Case Study: Outcome Current Status: Apache Fuse ESB in production and being used as Data Hub in Student Enrollment Trend Analysis Decision Support

Enterprise Architecture 2013 UC Irvine’s Case Study: Lessons Learned Development – Configuration: Endpoint configuration templates will help speed up project initiation – Development: Integrated development platform and available design patterns will accelerate adoption. – Data Integration: ESB is a Service Container and Service Mediator. Data transformation while possible to deployed, is better off as a separate integrated layer. – Standard test bed to encourage publishers/subscribers to validate robustness of services Operation – Deployment: centralized deployment is best achieved with reusable service repository. – Administration & monitoring: Beside security configuration and integration, usage statics, error recovery, monitoring and user/application notification are important operation aspects to gain user acceptance. – User access to logging info: in the absent of BPM, a commonly defined log and API to access the log would enable the publishers/subscribers to self-monitor.