/Tag: Segment Architecture

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:

To create a roadmap, we need to know what it is supposed to accomplish

By |2011-11-04T15:16:22+00:00November 4th, 2011|Enterprise Architecture|

I’ve been involved in a number of meetings recently as our IT teams try to come to consensus on answering this question: What is a Roadmap?  It’s been a fascinating series of discussions.  One thing that strikes me is that most of the internal discussions, and many of the discussions I’ve seen online, are only seeing part of the business process where a roadmap is used. 

If we don’t see all the process interactions, we can’t get the requirements right.  And if we don’t get the requirements right, the solution (the design of the roadmap) will not be as useful as it could be.

[Terminology Note: I don’t have any great love of the word “roadmap” to refer to the EA artifact.  I like “action plan” as a term, but I have no strong preference.  In keeping with prior posts on the subject, I’ll keep using the word “roadmap” unless and until we can get some consensus on an alternative word.]

Picking the correct approach

There are two different business processes where a roadmap is useful: deciding on the order of efforts, and tracking the efforts against that decided order.  IT folks tend to focus on the second.  I will focus on the first.


When we look at the notion of strategic planning from an EA perspective, we are trying to reduce unnecessary effort.  Just as a downhill skier in the Olympic games will surely lose if they are off course by a few degrees, adding a few extra meters to the length of their run, commercial enterprises are not asking for “any path down the hill” to win the race.  They are asking for “the best possible path down the hill.”  (If your company is run by a salesman, they may shout the words “win the race.” 🙂

The business has created their strategy and we have assisted with creating the measurable scorecard to track our progress towards achieving it.  That is step one (most Enterprise Architects have NO idea that this is part of their job).

The first process that uses Roadmaps starts here (colored in brown above).  Enterprise Architecture collect information to produce a series of alternative approaches (“candidate roadmaps” in the diagram above).  The input information includes other roadmaps, as well as business rules, political needs, dependencies, parallel initiatives, resource constraints, technology standards, fiscal constraints, regulatory constraints, and business drivers.  Each approach allows the business to deliver on that strategy in a way that is feasible, fiscal, and forward looking.  We allow ideas that may require us to change big things (merge, split, and repurpose teams, systems, processes, assets, etc.). 

Why have many candidates?  Because there is nearly always more than one path.  Each path will have tradeoffs.  One may be quicker to see results, another less expensive, and another less disruptive to existing product plans.  We need the business to pick the path that they want to follow.  Moreover, we want them to debate the tradeoffs in front of their peers, and come to a resolution about which path they will collectively select.  Because the only thing worse than having no roadmaps is having many competing roadmaps.  It is tempting to come to the business with only one roadmap. “Here’s your solution, sir.” On occasion, that works. Depends on the organizational politics. Personally, I think that is not a good recipe for buy-in. Your mileage may vary.

At the end of this two-step process, we walk out of the room with something powerful: buy-in.  We come away with a clear decision: beyond “get this done,” we now have “go do these projects, in this order, to get it done.” 

The candidate roadmaps fuel the debate.  It is the tinder to which we strike a match.  Each one explains all of the information that a stakeholder needs to debate the pros and cons, and the collection of information is sufficient to allow business leaders to pick one with their eyes open to the tradeoffs. 

Delivering on the approach selected

In the second part of the process (in purple above), we bring up the roadmap on a regular basis as we review, with our business stakeholders, the status of our projects and whether there are dependencies that may be driving our decisions.  In other words, if two projects are on time and a third project is late, but the fourth project cannot kick off….  You get the picture.

This is a kind of decision-rich governance activity.  The “roadmap” in this context is used for expectation management.  While this is a very valuable activity, you do NOT need all the same data for this activity as you do for the previous one.   Whether you need one diagram or two will depend on your business and how it handles project governance.


I went to such trouble to explain the distinction between these two parts of the process because the first part (using a roadmap as a high-level decision making tool) is often misunderstood by EA stakeholders who only view EA from an IT context.  As such, much of the debate on “what belongs in a roadmap” is centered around delivery needs and not enough on the decision needs described above. 

To build a better roadmap, it helps to know where it will be used.

Video Podcast: How Microsoft Does Enterprise Architecture

By |2011-06-23T10:36:23+00:00June 23rd, 2011|Enterprise Architecture|

It is amazing how often I need to share the very basic concept of Enterprise Architecture with my peers, customers, stakeholders, and associates.  Microsoft’s customers often ask about Enterprise Architecture, and when our customers come to visit us in the Microsoft Executive Briefing Center, they are more frequently bringing their Enterprise Architects along for the conversation.  To help clarify our view of EA, I teamed up with the Microsoft Showcase team and Microsoft Studios to produce a podcast describing Enterprise Architecture. 

The podcast is located on the Microsoft IT Showcase site here.

I thought about including a transcript, but I don’t have one.  I mostly spoke from an outline.  If you have questions or comments on the video, please don’t hesitate to contact me and we can collaborate. 

Segment Architecture in a Commercial Setting

By |2011-04-25T01:37:00+00:00April 25th, 2011|Enterprise Architecture|

The notion of an Enterprise Architect in a Segment (aka “Segment Architect”) has been fairly well described in for the Federal Enterprise Architecture Framework.  (FSAM reference).  It is not always well understood, and there are a small number of blog posts that disparage the concept.  That said, in a federal context, the politics of enterprise architecture doesn’t seem to get played out across the blogosphere. 

I am getting moderate traction at implementing the notion of segment architecture in a commercial setting, and I’d like to share my experiences with the community.  This post is one of what will likely become a series of posts on the trials and tribulations of implementing commercial segment architecture.

Preface: FSAM without the bureaucracy

First, a caveat and caution to those folks who are intimately familiar with the implementation of the Federal Government version: while I took a great deal of inspiration from FSAM, I cannot pretend that I have made any real effort to implement the FSAM in my organization.  As an outsider to Federal IT governance, I am looking through a very narrow lens.  The OMB is the overseer of overseers.  They rely on reports submitted by the agencies themselves.  Each agency is a large organization with billions of dollars of funding. In order to support the multiple tiers of oversight demanded by Congress, huge amounts of information must be put into standardized reports and fed upstream for oversight.  This emphasis on standardization and documentation is simply overkill in a commercial setting, where governance is a matter of judgment, and not a campaign pledge or a debate on CSPAN. 

I appreciate the difficulty of the OMB’s job.  I’m glad I don’t have to do it.  In that vein, I started my implementation of segment architecture by tossing out the extraordinary reliance on reports.  I stuck to the goals and concepts of segment architecture.  And that’s where I’d like to start in this post: what problem does segment architecture solve?

The ivory tower problem

The first step in understanding a problem from an architectural standpoint is to explain the problem as a set of interacting responsibilities.  For folks of the BPM bent, this can mean looking at a series of high level business processes.  For folks of a more architectural nature, this is often thought of as a set of interacting capabilities, each of which produces, consumes, or manages information as part of a larger system dedicated to a goal.  These architectural models are extremely useful, because they help to create a mechanism for understanding the problem space and for creating clear solutions.

However, reference models and taxonomies are not solutions.  No one can implement a reference model.  These “thinking tools” are inputs for specially trained individuals, and cannot be used by business people.   Reference models are architecture, but they are architecture for architects.  They are the patterns that architects use, not the blueprints that builders use.


On the other side, there are problem solvers.  Traditionally, in both business and government, an empowered individual will decide that “my organization will go after this goal” and they will direct their team to get to work.  The team may have to modify their existing processes or change their existing systems, and the goal is quickly broken down into a gap analysis, a proposed solution, and an implementation program.  The program will trigger and manage a series of projects and the results will be measured and reported. 

These activities are well understood and problem solvers have been promoted into management on the basis of doing these activities well.  As a result, there is great understanding for them, and support of them.  This culture does not care about reference models, taxonomies, or assessments.  This culture is well populated, and is seen as either the solution or the problem (depending on whether they are successful or not).  This culture of problem solving often outnumbers the architects (100 to 1) and they are slow to change. 

To the problem solvers, enterprise architects live in an ivory tower. They create models that are correct, but useless.  They do work that is visible, yet not necessary.  They spend time and money without solving any real problems.  To the problem solvers, a reference model is pretty useless.  A reference model plus $5 will get you a cup of coffee. 

Building bridges from both directions

In order for the problem solvers to gain any value at all from the reference models and taxonomies, those artifacts need to be correct and relevant.  Without specific information, they can be pretty, but not pretty useful.  From the solution side, enterprise architects need to gain understanding, relevance, and a tie to the work that actually must be done, the dates it must be delivered in, and the costs that play out across the infrastructure.

For the enterprise architects to have an impact on the problem solvers, their models must also be understood, and there has to be a set of key individuals who use those reference models to get the problem solving moving forward.  There has to be an understanding of how to use the information collected, and how to solve specific enterprise problems.  The problems that an EA is trying to solve are different problems than the ones the business is focused on.  The EA problems are around total cost of ownership, not solution development.  They are around consistency, simplicity, and reliability.  They are not normally focused on specific features, specific constraints, or specific interfaces.

A bridge must be built.  The realization that led to segment architecture is that this bridge cannot be done with training or artifacts or databases… the bridge is constructed of people.  Those people are Segment Architects.

Enterprise, Segment, and Solution Architects

In the problem solving space, you need solution architects.  These are the folks who will build the actual solutions that the business needs from the parts available (existing systems, databases, processes, hosting providers, authorization systems, etc.).  In the enterprise space, you need the enterprise architects.  These are the folks who evolve the future state for the enterprise’s processes, information, roles, and tools.  In the middle, you need the segment architects.  These are the folks who work with the business during the goals, gaps, and solution stage to insure that they enterprise needs and solution components come together. 

The segment architect is responsible for the following:

  • Developing a deep relationship with the business and developing a deep understanding of the problems that need to be solved.
  • Understanding the reference models and providing the needed information to build, evolve, improve, and implement them in the segments.
  • Assessing the state of the processes, information, roles, and systems that are involved in a particular business area to inform the solution efforts
  • Developing the initial “conceptual solutions” needed in order for the programs and projects to get under way, and for the solution architects to have a reasonable and achievable scope to operate within.



The distinct role of Segment Architect

For a while, I’ve had a challenge that is not simple to explain: how is a Segment Architect different from the other roles.  Not simple.  Here’s my attempt for tonight.

First off, let me say this: a Segment Architect is an Enterprise Architect.  He or She is assigned to work within a segment, but could be reasonably assigned to another segment (and in fact, should be periodically reassigned in order to retain their independence).  The segment architect is accountable for all of the responsibilities of an enterprise architect.  He or she must “own” enterprise requirements and insure that they are implemented in line-of-business solutions to the best of his or her ability.  As an EA, they care about where information is created, where it is mastered, and where it is manipulated.  They care about which business units perform specific business processes at a high level, and which governance mechanisms will be used to measure results. 

That said, in the early planning stages, the Segment Architect fills in the (not-yet-funded) role of a solution architect.  He or she will consider all of the requirements, well before they are reasonably understood, using the reference models and taxonomies as analysis tools.  They will develop a conceptual solution that allows the organization to understand what teams will be involved, what systems will be targeted, and what information should be mastered.  Without the segment architect assigned, the business units will perform this architectural activity without any architects in the room, and the result is quite dangerous.  That said, the solution concept developed by the segment architect is a pencil sketch compared to the actual solution that will go live.  It is directionally correct, but the real solution may take on a very different character.

The segment architect does not get the privilege or the honor of actually delivering the solution.  That honor, and that responsibility, falls to the solution architect who will be held accountable for meeting enterprise requirements as well as solving specific business problems.  The solution architect is assigned to the actual project, and has to deliver on it.  The EA does not.

Tell me what you think

I hope that this article provides some of the basics of segment architecture for the EA community, and opens up a channel of dialog about this important and emerging role within the Enterprise Architecture profession.  I am open to questions and concerns, which I may answer in subsequent blog posts.  Please feel free to share your ideas.

One bit of credit that I’d like to give.  Finding an image of a chasm that business people can cross is not easy.  The images if a chasm that I used in this blog post originated from an April 2004 article on the IBM web site called “Bridging the Chasm between Strategy and Execution” by Sydney Fuchs.  The article is quite good and I recommend it, but the context is not quite the same as I used in the image here.  I did not ask for permission before absconding the image, modifying it, and repurposing it.  I hope that Mr. Fuchs will forgive the intrusion.

The ivory tower is a distant memory

By |2011-03-20T13:22:28+00:00March 20th, 2011|Enterprise Architecture|

Just reading through a LinkedIn thread on “the biggest problem facing Enterprise Architecture,” and I noticed one response that struck a chord.  Charles Wade stated the biggest problem as: “Practicality! We spend allot[sic] of time in the Ivory Tower of Ego and don’t know how to apply EA.”

Yep.  I was there once.  Rare air up in the ivory tower.  Nice view.  Couldn’t wait to leave.  No one can hear you scream.

I left the ivory tower when I got the opportunity to engage directly with the business as an Enterprise Segment Architect.  (I’ll write about segment architecture in a future post… very similar to the role described at the federal level in FSAM).  In this role, I am very much an Enterprise Architect, but I don’t live in the ivory tower… My feet are firmly on the ground.  I drive the definition of initiatives and work (sometimes very long hours) to create clear and achievable roadmaps.

IT is involved, but my work far exceeds IT.  I’m working with the business directly, focusing on policies and procedures, understanding processes, looking at change management, rationalizing ownership of business capabilities, and yes, examining software system features.  My output is not software.  It is a well crafted initiative that “should” succeed in delivering on a business strategy.  It’s EA… without the ivory tower.

Right now, it is 7pm on a Thursday.  I’ve been at work for ten hours.  I’m finally going home. 

I spent exactly 3 minutes in the ivory tower today… writing this blog post. 

I don’t miss it.