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