/Tag: Core Diagram

Steps To Create a Core Diagram

By |2012-12-19T08:34:41+00:00December 19th, 2012|Enterprise Architecture|

To be fair, these are steps to create a solid understanding of the architecture of a business, but the deliverable is a core diagram, so that’s the title of the post.  I first wrote about a method for creating core diagrams about a year ago, as I was preparing for a talk on the subject at the Open Group conference in San Francisco.  Now that I’m preparing for another Open Group conference, I find myself filling out some of the details from the previous effort.  Most of the text below is copied from an e-mail that I sent to a fellow business architect who was asking about how to create a core diagram.

The text below describes a five step process

  1. Collect a list of your organization’s business models
  2. Create or leverage a taxonomy of capabilities that reflect differentiation in business processes
  3. Differentiate each capability on the basis of Ross’ operating model taxonomy (level of Information Integration and level of Process standardization)
  4. Make an educated guess about the operating model of the company
  5. Draw the core diagram and build understanding around it


Understanding how to create a core diagram starts by collecting a list of the business models that your organization performs. Each business model is unique and different from the other ones. Each will require different capabilities and will often drive variations in those capabilities for the sake of market or product differentiation. You cannot create a core diagram effectively without the list of business models.

So what is in a business model? I’ve blogged about that fairly well. A business model is a composition of elements that describes how and why a value proposition exists, who it is for, and what it drives in terms of internal and external requirements. The diagram is below. (click to enlarge)

Metamodel for a Business Model

Once you have the initial list of business models, you will want to engage with direct business stakeholders. Make sure that they understand the concept of a business model, and what makes a business model unique from other business models (e.g. selling the same product in the same way to the same people in another country is NOT a unique business model, but selling a product in three different ways to three different, potentially overlapping market segments within one country probably represents three business models). Engage. Build relationships. This is your first shot.

Once you have that list fairly well baked, you have step two on your hands: a capability taxonomy that reflects process differentiation. In this case, it is a good idea to start with a high level process taxonomy like the ones made available for free from the APQC. I don’t know if there is one for financial services yet, but there should be. If not, you can start with a general one, but it will take some editing. You want your capability taxonomy to be worded in such a way that it represents “things that could be done” without reflecting the way in which they are done. For example, “customer identity management” is OK, but “customer deduplication” is not, because we want to make sure that customers have an appropriate identity but the organization may not want to remove duplication in order to do that.

This requires some editing of a large list of items in a hierarchy. Excel is OK for this. There may be other tools as well… I haven’t experimented past Excel. This is the second point where it is good to be engaging with business stakeholders. Get their help to describe their business model to you in terms of capabilities, and make sure that all of their capabilities are included in your taxonomy somewhere (usually around the third level down in the tree).

Step three is to differentiate each business capability on the dimensions suggested in the EA As Strategy book. (This can be done at a high level. If your taxonomy has more than 200 business capabilities in it, don’t use the most detailed level(s) of the taxonomy. No one has patience for the details in a core diagram.

Draw out a grid like the one illustrated in the EA As Strategy book, only make it empty.

Diagram illustrating the dimensions of Operating Models with Integration (low and high) on the Y axis, and Standardization (low and high) on the X axis

In each one of the boxes, write in the capabilities that are well understood by a particular business stakeholder, then go to that stakeholder and validate your choices. Make sure that you have placed the correctly for that stakeholder’s particular business models. Note that very few stakeholders will have a valid opinion about capabilities that are NOT part of their particular business model, so don’t show capabilities that they don’t care about.

You will quickly discover that most folks agree on some things and disagree on some things. Where a single capability shows up in multiple businesses, one stakeholder may say that it needs high standardization, while another will say that the capability needs low standardization (== high flexibility). Take note of these disagreements. THEY ARE THE VALUE POINTS FOR BUSINESS ARCHITECTURE.

On everything you can get reasonable agreement on, go ahead and create a master table that has the capabilities differentiated in the manner above. That will probably be about 90-95% of your business capabilities in your taxonomy.

Step four is to make an “educated guess” about the operating model that your organization has. It’s a guess because most organizations are difficult to read and no one person will be able to answer your question about what the company as a whole looks like. Most of the time, you can start with the generalizatio
ns that Jeannie Ross made when describing the four operating models in her book “Enterprise Architecture As Strategy.” If there are a large number of capabilities in the “High Integration, High Standardization” box, you can suggest that your organization is a “Centralization” model. If, on the other hand, there are a large number in the “High Integration, Low Standardization” box, you can suggest that the organization is a Coordination model. This is the educated guess part because there is no good formula for making the guess. By this point, you will know a great deal about the organization so your guess is as good as your stakeholders.

Step five is to take a cut at your core diagram… Draw it out and then work with your stakeholders to get common understanding.

For each of the four styles of models, there are different styles of core diagrams. The centralization model tends to break out capabilities by functional area since there is very little (intentional) duplication. So it will be a diagram with a series of functional areas as boxes with the capabilities for each function listed in the boxes. Good idea to put the name of the person accountable for that business function in the title of the box. Lines between the boxes represent flows of information or value between them.

The Replication model is somewhat similar. There will be some functions that are owned by “corporate” while the rest are replicated into EACH of the operating units, so there will be two large “areas” on your diagram. The corporate area will have some functions with capabilities in them, and a single “replicated” area will have the remaining functions with capabilities in them. This is wildly valuable to business planners because they can get agreement among the leaders of each replicated unit about what each one of the is accountable to do and what they MUST depend on the corporate unit to do.

The collaboration model tends to be “hub and spoke” with the hub being the most integrated capabilities and the spokes being unique to each of the business models (or in some cases, small groups of business models that share a lot of capabilities). The lines tend to be information flow, not value flow. The capabilities in the spokes are usually duplicated between the different business units but they (should be) the capabilities that each business unit needs in order to differentiate itself or its products in the marketplace.

The diversification model is the most complex because the “corporate” unit tends to have a small number of core capabilities (often just financial ones) with each of the subsidiaries having a nearly complete and quite independent set of functions with massive duplication of capabilities across them.

I hope this gives you a good start in creating your core diagram.

MSBI–Part 2—What is a core diagram?

By |2012-02-14T07:40:00+00:00February 14th, 2012|Enterprise Architecture|

In her wildly popular book, Enterprise Architecture As Strategy, Dr. Jeanne Ross describes the use of “core diagrams” in Enterprise Architecture.  Shortly after introducing the notion of “operating models”, she provided four example “core diagrams” from successful companies and noted that each diagram reflected the specific challenges that companies with similar operating models would face.

This section of the book is often overlooked, but personally, I think Ross hit on something very powerful.  I spend a good bit of time speaking with CIOs and CTOs about Enterprise Architecture, and I am frequently asked a seemingly simple question: what does an enterprise architecture look like?  What is the “single picture on top?”  You’d think we could answer this question!  But until this book was published, there was no notion of what the “single model on top” should look like, or why one model would sit atop another.   This series of blog posts attempts to answer that question.

If this is the first post you are reading on this topic, you have started in the middle.  Go back to this article for the overview and table of links to the rest of the posts.

What is a core diagram?

A core diagram is an Enterprise Architecture model that reflects the level of integration and standardization that the company has chosen to embark upon, boiled down to specific, tangible, elements for business and technology professionals to discuss and agree upon. 

These two dimensions: process integration and process standardization, are the two independent variables that drive the selection of an organizations operating model.  This distinction is so important to the Enterprise Architecture itself that Dr. Ross defines the concept of “Enterprise Architecture” in these terms!  According to the book, Enterprise Architecture is: “The organizing logic for business processes, data, and technology reflecting the integration and standardization requirements of the firm’s operating model.”

Going beyond the book, this post will describe the concept and value proposition of a core diagram, while the next post will describe the business scenarios in which a core diagram can be valuable.  Between these two posts, I hope to clarify the reason why your EA program should create a core diagram.

The value of a core diagram

A core diagram is a very useful EA artifact for many scenarios.  A core diagram removes ambiguity that business stakeholders either suffer from, or take advantage of, when dealing driving change in the organization.  You can provide direct EA value by removing that ambiguity, presenting clear ownership, and addressing the occasionally emotional attachment that business and IT stakeholders have to overly complex implementations.

  • The core diagram illustrates processes that must be standardized.  Depending on your operating model, some subset of business processes (from a small subset in diversification companies to a large subset in unification companies) are standardized.  The challenge comes “on the line” where there is a case to be made on both sides of the debate: e.g. “this process can be valuable by being non-standardized.”  Assuming that you have a process owner who can decide one way or the other, a core diagram can help make that decision stick.  By clearly denoting a process as “standard” or “agile” in the core diagram, the decision can be clearly communicated and ownership clearly enforced.
  • The core diagram illustrates which data facets must be managed as “master data.”  Operating models with high levels of integration will have some number of shared data facets that are available across the enterprise (in a secure fashion, of course).  Which data facets depends on your company and your level of integration.  Clarity about which facets are shared, and which facets are NOT shared, is necessary for a simple and clear set of information sharing processes. 
  • The core diagram illustrates which systems will stand as “systems of record” for the management of specific functions.  Operating models with either high levels of integration or high levels of standardization will need to denote specific systems as being the “source of truth” for master data and the “system of record” for support of standardized activities.  Clarity removes the temptation to “build your own shadow application” or to “build for one silo” (two antipatterns in highly integrated environments).


A core diagram specifically supports the mitigation of these anti-patterns:

  • If we build it, they will come. (Anti-pattern)
  • I am different, so I need a different process (Anti-pattern)
  • It is too much of a hassle for me to share my data with you. (Anti-pattern)


It goes without saying that a core diagram is not sufficient, by itself, to eradicate bad behavior.  It is NOT a silver bullet.  In addition, there are examples of companies that have succeeded in creating a mature Enterprise Architecture program without one. 

That said, I asked Jeanne Ross about the value of a core diagram and this is what she told me:

“For most companies, I think some kind of picture is essential for understanding the expectations for a business transformation. It helps management understand to what extent everyone is on the same page—prior to drawing the diagram, they think they all mean the same thing, but they usually don’t.”

Jeanne Ross
Director and Principal Research Scientist
MIT Center for Information Systems Research

Personally, I believe that a core diagram is an essential part of most EA programs.  If you think it would be difficult to create a core diagram, your company is probably one that most needs one.

What are the criteria for a core diagram

A core diagram is not “just any EA model.”  It has a specific purpose and a specific part to play in the development of an EA.  It does not have a specific look and feel, although some suggestions for good visualization can be found the “Enterprise Architecture As Strategy” book.

You will know you have a core diagram when it meets all of these criteria:

  1. It is a single diagram with a clear scope representing either the entire enterprise or a specific independent business segment.
  2. The diagram reflects the difficult choices that were derived (or will be derived) from the selection of the company’s operating model(s). 
  3. A non-architect stakeholder can understand and use the model with less than thirty minutes of discussion.

Note that a core diagram is normally a “future state” model of the enterprise, reflecting the direction that the company should go.  However, this is not a requirement.  A current state core diagram could be created, as long as the compromises reflected within don’t make the diagram too complex for it to be simply understood.

Next up: Scenarios for the use of a core diagram (this link will be updated when the next entry is posted).

Creating a Core Diagram for Agile Business

By |2012-01-31T16:47:00+00:00January 31st, 2012|Enterprise Architecture|

Today, I gave my talk at the Open Group conference that presents a step-by-step method for creating a core diagram that is useful for agile business.  I will blog a series of posts on the topic to share this information to my friends and colleagues on the web.

I will create the following posts.  As I do, I will come back and edit this post to provide a link.  This post will stand as an introduction and table of contents to the topic. 

I will post the following articles:


This will likely take a few days, and I’d like to take a few minutes to describe each of these topics.  The talk lasted 45 minutes (at a wildly accelerated pace).  I plan to provide a better, albeit slower, set of information for the folks who read this blog.


Nick Malik speaking at the Open Group conference, Jan 31, 2012, San Francisco

If you’d like to see the original presentation, see the following slideshare presentation: