enterprise architecture 2013 university of california enterprise architecture: a case study itana...

Enterprise Architecture 2013

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


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


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

http://www.ucop.edu/information-technology-services/_files/its_strategy-statement%2012-12-12.pdf

http://www.ucop.edu/impac/_files/working-smarter.pdf


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!


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.


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


Current state

• Start from scratch

• Redundancy o Data o Infrastructureo Applicationso 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 andUCOP EA Team

CommonAdministrative

Systems

Align Campus andSystem-wide

Strategy and Plans

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


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: Key Components

10


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


What Are Our Enterprise Assets?

12


EA Asset Lifecycle

•Submission & Review•Location specific Adoption & Communication

•System-wide Communication

13


Submission and Review

14


Location Specific Adoption

15


Communication

16


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.


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)


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


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!


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


UC Irvine’s Case Study: Problem Statement


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.


Architecture


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


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.

enterprise architecture 2013 university of california enterprise architecture: a case study itana...

Documents

uc system

integrated system

integrated energy

payroll systems common

uc business needs

climate solutions common

support of future common

success uc cio