Enterprise Architecture

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

201
3
About the University of California

Enterprise Architecture
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 staf
1.5 Million alumni
Research class

201
3
Problem Statement

Enterprise Architecture
Each campus and medical center has unique and
diverse administrative business processes and
technologies
Business efectiveness, 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

201
Common, integrated e-procurement
Common, integrated energy and climate solutions

3
Common, integrated indirect cost recovery
Common, integrated library efficiency strategies
Common, integrated risk management
Problem Statement - continued

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

201
direction of UC Common Administrative

3
Systems initiative and the beginning of a lot
Goals

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

201
in support of future common and integrated

3
administrative systems.
Requirements

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

201
3
Roadmap

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

201
3
8
Approach

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

201
Lifecycle

3
Create a structure for enterprise
Enterprise Architecture: Key Roles

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

201
overall UC service portfolio

3
UC Central Enterprise Architecture Group: 9
Enterprise Architecture: Key

Enterprise Architecture
Components

201
3
1
0
Enterprise Architecture: Assets

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

201
Example capabilities: keyword search, result filtering,

3
taxonomy navigation, workflow, subscription, etc. 1
1
What Are Our Enterprise Assets?

Enterprise Architecture
201
3
1
2
EA Asset Lifecycle

Enterprise Architecture
Submission & Review
Location specific Adoption & Communication
System-wide Communication

201
3
1
3
 201
Enterprise Architecture
1
4

3
Submission and Review
Location Specific Adoption

Enterprise Architecture
201
3
1
5
 201
Enterprise Architecture
1
6

3
Communication
Outcomes

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

201
3
Outcomes - continued

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

201
UC Enterprise Architecture Book of Knowledge

3
(EABok) and an Artifact Framework (EAAF)
 201
Enterprise Architecture
3
Critical Success Factors

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

201
Facilitate adoption of standards and multi-location initiatives by

3
working with local implementation teams
Lessons Learned

Enterprise Architecture
Executive level sponsorship of Enterprise
Architecture required. Need CIOs who
champion the efort
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

201
program

3
Deal with the Whats In It For Me?
Appendix A

Enterprise Architecture
UC Irvines 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.

201
3
UC Irvines Case Study: Problem

Enterprise Architecture
Statement

201
3
 UC Irvines ESB Case Study:

Enterprise Architecture
Objectives
POC for ESB features beyond WebServices
container
Leverage ESB to mediate data between publisher
and subscribers
Exercise diferent types of data containers (file,
record, table)
Exercise diferent 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

201
architecture.

3
 201
Enterprise Architecture
3
Architecture
UC Irvines Case Study:

Enterprise Architecture
Outcome
Current Status: Apache Fuse ESB in production
and being used as Data Hub in Student
Enrollment Trend Analysis Decision Support

201
3
UC Irvines Case Study: Lessons

Enterprise Architecture
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 of 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.

201
User access to logging info: in the absent of BPM, a commonly

3
defined log and API to access the log would enable the
publishers/subscribers to self-monitor.