ITANA Face2Face - October, 2013
Enterprise Architecture
University of California Enterprise
Architecture: A Case Study
Mojgan Amini, UC San Diego
Marina Arseniev, UC Irvine
Lisa Gardner, UC Santa Cruz
Jerome McEvoy, UC Office of President
2013
• Formed 1869, starting with Berkeley
• 10 campuses at Berkeley, Davis, Irvine, Los Angeles, Merced,
Riverside, San Diego, San Francisco, Santa Cruz and Santa
Barbara
Enterprise Architecture
About the University of California System
• 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
2013
•
•
•
•
• 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)
Enterprise Architecture
Problem Statement
– 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
2013
• 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.
2013
First tactical step in realizing the strategic direction of
UC Common Administrative Systems initiative and the
beginning of a lot of work!
Enterprise Architecture
Problem Statement - continued
• Define and deploy an initial catalog of shared
technology services to support common administrative
systems, beginning with the new payroll/HR system
(UCPath).
Enterprise Architecture
Goals
• Build a shared services architecture
• Increase the consistency, interoperability, and reuse of
technology, data and processes across the UC.
2013
• Create an enterprise architecture for UC along with an
initial enabling infrastructure in support of future
common and integrated administrative systems.
• IT and interoperability standards to promote reuse of
solutions
• Clear EA processes and framework(s)
• Partnership between the UC Enterprise Architecture
Enterprise Architecture
Requirements
(EA) Team and ITAG
• Make sure campus requirements are appropriately
integrated
• A full-spectrum system-wide and location specific
communication plan
2013
Current state
UC CIOs
•
Start from scratch
•
Redundancy
o
o
o
o
•
•
Desired state
Data
Infrastructure
Applications
Cost
Variances without
common standards
One-of-a-kind
implementations
ITAG and
UCOP EA Team
 Reuse of proven
approaches & assets
Enterprise Architecture
Roadmap
 Increased
interoperability
Align Campus and
System-wide
Strategy and Plans
 Informed and deliberate
variances
Common
Administrative
Systems
 Easier to collaborate on
UC initiatives
2013
8
• 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
Enterprise Architecture
Approach
– 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
2013
– Create a structure for enterprise architecture
artifact submission, review and approval
– Location specific Adoption & Communication
– System-wide Communication
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
Enterprise Architecture
Enterprise Architecture: Key Roles
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
•Curator for Enterprise Architecture Assets
•Evangelize awareness, adoption and use of Enterprise Architecture across UC
2013
UC Central Enterprise Architecture Group:
9
Enterprise Architecture
Enterprise Architecture: Key Components
2013
10
• An Enterprise Architecture Assets Framework (EAAF) is required
for lifecycle management of any asset that advances
consistency, reuse or interoperability
Enterprise Architecture
Enterprise Architecture: Assets
– 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
2013
– Example capabilities: keyword search, result filtering, taxonomy
navigation, workflow, subscription, etc.
11
Enterprise Architecture
What Are Our Enterprise Assets?
2013
12
•Submission & Review
•Location specific Adoption & Communication
Enterprise Architecture
EA Asset Lifecycle
•System-wide Communication
2013
13
Enterprise Architecture
Submission and Review
2013
14
Enterprise Architecture
Location Specific Adoption
2013
15
Enterprise Architecture
Communication
2013
16
• 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
Enterprise Architecture
Outcomes
• 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.
2013
• 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;
Enterprise Architecture
Outcomes - continued
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)
2013
Enterprise Architecture
2013
• 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
Enterprise Architecture
Critical Success Factors
• 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
2013
implementation teams
2013
• 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
Lessons Learned
• 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
Enterprise Architecture
Appendix A
• Other….
2013
Enterprise Architecture
UC Irvine’s Case Study: Problem Statement
2013
• 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
UC Irvine’s ESB Case Study: Objectives
2013
Enterprise Architecture
Architecture
2013
• Current Status: Apache Fuse ESB in production and being
used as Data Hub in Student Enrollment Trend Analysis
Decision Support
Enterprise Architecture
UC Irvine’s Case Study: Outcome
2013
• 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
Enterprise Architecture
UC Irvine’s Case Study: Lessons Learned
• Operation
2013
– 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.