university of california enterprise architecture a case study itana face2face october 2013 n.
Skip this Video
Loading SlideShow in 5 Seconds..
University of California Enterprise Architecture: A Case Study ITANA Face2Face - October, 2013 PowerPoint Presentation
Download Presentation
University of California Enterprise Architecture: A Case Study ITANA Face2Face - October, 2013

Loading in 2 Seconds...

play fullscreen
1 / 27

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

  • Uploaded on

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 . About the University of California System.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

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

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
university of california enterprise architecture a case study itana face2face october 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
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
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
problem statement continued
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!

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


ITAG and


Align Campus and


Strategy and Plans





  • 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
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
enterprise architecture assets
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.
ea asset lifecycle
EA Asset Lifecycle
  • Submission & Review
  • Location specific Adoption & Communication
  • System-wide Communication
  • 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
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
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
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
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 esb case study objectives
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.

uc irvine s case study outcome
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
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.