Page tree
Skip to end of metadata
Go to start of metadata

Introduction

Description: The Core Diagram is a hybrid tool that brings together value chains, capabilities and conceptual data objects in one single perspective.

It represents the information technology constructs that enable interaction between a service provider and a service consumer.  The consumers functional tasks are chained together on a timeline across the top horizontal, the providers functional tasks are chained together on a timeline across the bottom horizontal, and the technology constructs (entity?) are organized in the center by logical groupings.

Goals: The diagram’s purpose is to identify and highlight the technology constructs that are critical to the participants of a business operating model.  Once identified, projects that impact any of the core components need to be scrutinized for effect on the business operating model.

It also serves as an artifact that can facilitate a common understanding between the provider and the consumer about the scope of the business process.

Context: Each Core Diagram addresses a specific Operating Model.  A library of Core Diagrams can reveal insights into cross-cutting, or foundational services that have broad impact.

Scope: The scope can vary enormously: ranging from a complete operating model of an airline (the Delta core model) to a specific set of business processes as in the Wisconsin advisor core model.

Source: The concept was developed in an influential book on architecture: Enterprise Architecture as Strategy: Creating a Foundation for Business ... By Jeanne W. Ross, Peter Weill, David Robertson

Scenarios

Use of a core diagram is often triggered by a specific problem, or initiative, which needs a broader context to be addressed well. Core diagrams are a way to provide context showing the core activities, services, information, capabilities, etc. related to a problem.

Strategic Planning

  • Audience: Executive leadership, IT directors, etc.

  • Scope: An entire institution or organization; for example, at a university level, including the academic, research, and possibly health care enterprises

  • Goals and outcomes: Shared understanding of “verbs”: the core things the institution does. Shared understanding of “nouns”: core services, information, and capabilities that cut across all business domains

Business Domain

  • Audience: Domain leaders

  • Scope: A selected business domain the institution operates in; for example, all of Student, Finance, etc.

  • Goals and outcomes: Shared understanding of “verbs”: the core things the domain does. Shared understanding of “nouns”: core services, information, and capabilities that cut across the domain.

Project Impact Analysis

  • Audience:

  • Scope:

  • Goals and outcomes:

Role at Institution

  • Trigger: A problem or opportunity related to better serving a role (usually involving multiple functions or offices that have to work together to serve the role)

  • Audience: Teams or offices that work together to serve the selected role

  • Scope: Determined by the role selected for analysis (such as all Students, or Students within a School, etc.), and the breadth of functions included

  • Goals and outcomes: Shared understanding of how functions, services, etc., support a role

Process Improvement Exercise

  • Audience:

  • Scope:

  • Goals and outcomes:

Method

Roles: 

  • Business Analysis

  • Business Process Modeling

  • Business Systems Analysis

  • Subject Matter Expertise

  • Facilitation

Steps:

  1. Review the matrix of operating models (for example, see this article)

    1. Gain consensus on what type of operating model is being worked on

    2. The outcome may vary based on the scope of the business area being analyzed (the whole institution, a business domain, a sub-domain, etc.)

  2. Define the scope of operating model

  3. Identify consumer activities (workshop 1)

  4. Identify provider activities (workshop 2)

  5. If possible, lay out activities in a value chain sequence

  6. SME collates core technical constructs (services, data, business objects) that serve the activities

For another list of method steps, see this article by Nick Malik.

Communication

You can use the core diagram to identify focus areas by:

  • Identifying projects that impact the diagram in some way. Those project's representatives should present the effort’s alignment with the overall vision for the core services.

  • Doing a gap/overlap analysis between the functional tasks along the top and bottom and the services listed in the Core Services area of the diagram.  Those activities, represented in the tasks and capabilities that have no supporting services represent a gap.  Those with multiple services represent a possible overlap.

  • Looking across the suite of core diagrams (Student Lifecycle, Researcher, Advisor, Instructor, Employee) for core services that appear on all or most of the diagrams - these are services that should be optimized since they have the highest impact.

  • Mapping the flow and connections between the services to see where there are issues of business process flow or AuthNZ issues.

  • Getting agreement on the operational model (Unification, Coordination, etc) then seeing which efforts are misaligned with desired operational model.

A core diagram is not a graphic that’s designed to be “shared out” with the organization. It is a framework for organizing the technologies within the organization and then used for reference for many different reasons (see “scenarios” above).

Examples

Delta Airlines core diagram: https://glennas.wordpress.com/2009/08/23/enterprise-architecture-as-strategy-my-favorite-business-architecture-book/ 

University of Wisconsin Advisor Core Diagram: https://wiki.doit.wisc.edu/confluence/display/ARCH/Advisor+Lifecycle

ITANA Learner Lifecycle core diagram: https://spaces.at.internet2.edu/display/itana/Learning+and+teaching+core+diagram

Related Methods

Before this method, are there other methods that it would be helpful to have completed?

Capability maps that are laid out as value chains provide the top and bottom of the diagram.  The concepts from the semantic data model supply the objects in the middle in the diagram.

 

Architecture Methods > Core Diagrams

Links
Contributors

Want to help with this page? Please see the Method Contributor Guide.

 Stewards of this page:

  • Rupert Berk, University of Washington
  • José Cedeño, Oregon State University

Other contributors:

  • Leo Fernig, UBC

  • Robert Dein, Miami University of Ohio

  • Luke Tracy, University of Michigan

  • Paul Schurr, University of Washington