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:
Roles:
Business Analysis
Business Process Modeling
Business Systems Analysis
Subject Matter Expertise
Steps:
Review the matrix of operating models (for example, see this article)
Gain consensus on what type of operating model is being worked on
The outcome may vary based on the scope of the business area being analyzed (the whole institution, a business domain, a sub-domain, etc.)
Define the scope of operating model
Identify consumer activities (workshop 1)
Identify provider activities (workshop 2)
If possible, lay out activities in a value chain sequence
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. posted initially at the Microsoft DevBlogs site, but accessed now through The Internet Archive.
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.
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).
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
Want to help with this page? Please see the Method Contributor Guide.
Stewards of this page:
Other contributors:
Leo Fernig, UBC
Robert Dein, Miami University of Ohio
Luke Tracy, University of Michigan
Powered by a free Atlassian Confluence Community License granted to Internet2. Evaluate Confluence today.