University of California Enterprise Architecture: A Case Study ITANA Face2Face - October, 2013

1. University of California Enterprise Architecture: A Case StudyITANA Face2Face - October, 2013 Mojgan Amini, UC San Diego Marina Arseniev, UC Irvine Lisa Gardner, UC Santa Cruz Jerome McEvoy, UC Office of President

2. 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

3. 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) • http://www.ucop.edu/information-technology-services/_files/its_strategy-statement%2012-12-12.pdf • UC Executive Leadership envision Working Smarter Initiative for ten distinct campuses to use one efficient administrative framework: http://www.ucop.edu/impac/_files/working-smarter.pdf •  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

4. 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!

5. 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.

6. 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

7. Roadmap • Current state • Start from scratch • Redundancy • Data • Infrastructure • Applications • 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 UC CIOs ITAG and UCOP EA Team Align Campus and System-wide Strategy and Plans Common Administrative Systems 8

8. 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

9. 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

10. Enterprise Architecture: Key Components

11. 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.

12. What Are Our Enterprise Assets?

13. EA Asset Lifecycle • Submission & Review • Location specific Adoption & Communication • System-wide Communication

14. Submission and Review

15. Location Specific Adoption

16. Communication

17. 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.

18. 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)

20. 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

21. 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!

22. 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….

23. UC Irvine’s Case Study: Problem Statement

24. 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.

25. Architecture

26. 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

27. 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.