Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Provide a brief description of this method.

In general, what are the goals or outcomes of this method? What is it supposed to communicate, analyze, or achieve?

In general, what contexts is this method used in? What is it meant to help us understand? (For example, IT services or solutions, business capabilities, processes, information)

In general, what is the scope of this method? How broadly or narrowly is it used? (For example, in strategy, planning, portfolio management, service management, within a business domain, within a project)

Where did this method originate?


Provide one or more different scenarios in which this method could be used.

In each case, who are the participants or the audience being communicated with? What is the scope? What are the goals or outcomes?


What skills are needed to apply this method? What roles should lead this method? (For example, enterprise architect, business architect, solution architect, project manager)

What are the general steps in applying this method?

Does this method involve learning some new terms? Define them.

Does this method involve creating particular artifacts? Are there templates? For details, feel free to link to external resources.

Are particular tools useful or recommended for creating these artifacts?


How can the outcomes of this method be communicated or promoted/marketed to others?


Provide one or more examples where this method has been applied.

If possible, link to example artifacts, and discuss how the example illustrates the goals of this method. What effect or value did using the method have?

Are there examples of when not to use the method? (Lessons learned, antipatterns)

Related Methods

After using this method, what methods would it make sense to use next? Link to each method, and discuss how it follows from this method.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


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:



  • Business Analysis

  • Business Process Modeling

  • Business Systems Analysis

  • Subject Matter Expertise

  • Facilitation


  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.


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


Delta Airlines core diagram: 

University of Wisconsin Advisor Core Diagram:

ITANA Learner Lifecycle 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

Image Added

  • Link to articles, presentations, etc., describing the method
  • Link to examples where the method has been applied


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