Enterprise Business Motivation Model version 3.5

By |2011-07-27T00:26:07+00:00July 27th, 2011|Enterprise Architecture|

For those of you who have been waiting for me to announce the release of the newest version of the Enterprise Business Motivation Model, I’m happy to announce that version 3.5 is available now. 

To visit a WordPress site set up to explain the model, visit http://motivationmodel.com

To visit a web site produced by the Sparx modeling tool, allowing direct navigation of the model itself, visit http://motivationmodel.com/ebmm

To download a PDF document exported by the modeling tool (for those folks who love PDF files), visit this link here

Special Thanks

The Enterprise Business Motivation Model has gone through a long list of changes since the original article was published over two years ago.  I’ve spent considerable time working through the model and getting feedback from colleagues from around the world. 

I’d like to give special thanks to Michael Davison, JD Beckingham, Neil McWhorter, Bruce McNaughton, Henk Harms, Bill Ulrich, Jim Rhyne, Kirk Rheinlander, Leo de Sousa, Yelena Edelstein, Al Newman, Amy Nguyen, David Vugteveen, and many others who have commented, criticized, and asked for clarifications.  Without your concerns and your insight, the EBMM would not move forward.  Thank you!

Changes to look for

There are many changes since the last public version (v1). 

  • The business model description was updated to reflect connections between customer types and partner types, and to more completely cover the model elements of Alexander Osterwalder’s Business Model Generation. (model, description)
  • Porter’s Five Forces was added as a separate area clarifying the linkage between a Five-Forces analysis and business models themselves.
  • The dual notion of Business Capability and Business Unit Capability proved too confusing and arbitrary for a core conceptual model.  The single concept of Business capability remains.
  • The concept of Data object is now elevated to a top-level element in the model with necessary changes to the high level view. 
  • Business role was added with relationships to business processes and data objects.
  • The concepts of Regulations, Legislative Edicts and Charter Legislation were added to clarify the role of these key concepts to Government and Semi-private organizations.
  • The concept of “capability maturity” was expanded to “assessment metric” to allow a broader understanding of how measures can be applied to business capabilities in order to motivate and measure the success of initiatives.
  • Clear distinctions are made between an enterprise, a company, and a business. 
  • An additional relation has been added to business unit: relates to.  This allows models of the enterprise to include interrelationships between business units other than the normal hierarchical relationships that the existing “includes” relation allows.  This should enable a wider array of analysis models to be created for those architects who need to model a subset of the enterprise.
  • A page was created on the WordPress site to discuss the difference between a Process and a Capability.  (link)


Of course, we are not done.  I am publishing version 3.5 in order to insure that my conversations with other Business Architects has a current footing.  The following concerns have been shared and are under consideration for future versions:

  1. Add the ability to attach a Value Chain Analysis
  2. Add the ability to represent the accountabilities of a team in relation to the business processes themselves
  3. <<your suggestion here>>


As always, I welcome feedback and input.  I’m proud of where the EBMM has come so far and look forward to working with exceptional people to discuss and describe future changes to the model. 

Note: I didn’t keep a careful list of the folks who offered valuable feedback on the model.  If you offered feedback, and I didn’t mention you above, please accept my apologies and send me a note.  I’ll update this post.

Finding Common Ground: in response to a BPTrends article on Process and Capability

By |2011-07-26T21:03:13+00:00July 26th, 2011|Enterprise Architecture|

Recently, Paul Harmon published an article in BPTrends that discusses his views on the notion of Business Capability, and whether it is a useful concept.  He was not particularly kind to the field of Business Architecture in his article.  While I encourage my readers to take a few minutes to read the original, I have included a few excerpts to give perspective to those with a little less time on their hands:

    • To date, I have to admit that I have no clear idea of what the term "capability" means.
    • In other words, as far as I can see, according to this definition, a "capability" is just a way of talking about being able to produce what processes produce.
    • I don’t see a real difference between WHAT an organization can do and HOW the organization will do it.
    • I might prefer to call it a Business Process Architecture, but I can certainly live with the term Business Architecture, if that’s what most people come to prefer.
    • the idea of "capabilities" is introducing confusion into the marketplace. It is hard enough to work with an organization to create a business process architecture that can be used to effectively organize the management and measurement of how well the organization is achieving its goals. To introduce the idea that an organization should first or simultaneously create a map or hierarchy of "capabilities" and then create another hierarchy of processes is to add confusion to an already very difficult and complex task.
    • If former IT architects want to become business architects, I’m all for it, but they are going to find that there are BPM practitioners who are already functioning in that role, and I believe they will be well advised to work with us rather than trying to create a new body of knowledge with a new vocabulary.
    • I believe that we ought to resist any urge to quickly redefine terms and practices that we have been using for many years.


My attention was called to this article by a reader of my blog who was interested in my response.  This is particularly apropos because, as a member of the OMG Business Architecture Working Group (or BAWG), I am one of the folks that Mr. Harmon is talking about. 

First let me say that his criticisms are fair.  As any new methodology appears, it runs the risk of creating confusion in the minds of business stakeholders.  We are not immune to that criticism.  In fact, within my own organization, BPM practitioners have been dismayed by the discussion of business capabilities and have asked many of the same questions that Mr. Harmon asks.  In our organization, we have worked to address those concerns and I believe we have been successful.  I will be sharing some of those discussions with readers in upcoming posts.  In addition, I welcome Mr. Harmon’s questions and would love to work with him, and any other member of the BPM community, to amicably answer these concerns as best I can.  I hope that the efforts of the BAWG will produce fruit by providing the consistent basis that Mr. Harmon so clearly calls for.

I don’t agree with Mr. Harmon’s conclusion: business architecture is a ‘redefinition’ of Business Process Management terms and practices.  That said, my belief is based on my own practice.  I recognize that Mr. Harmon may have been speaking with practitioners who have been using Business Architecture concepts in confusing and inconsistent ways. 

Just as business process management did not coalesce as a profession until some key voices published books that entered general business practice, I ask only that Mr. Harmon consider the possibility that Business Architects have not found a small set of clear voices just yet.  Our field is younger.  Just as the folks who believe that “functional groupings” were a reasonable way to organize a company may have found confusion in the introduction of BPM concepts 20 years ago, I believe that business and BPM professionals are finding confusion in the introduction of BA concepts today.  We are not less legitimate as the result of our youth… but we are less coherent.

His confusion is healthy, and through his expression, he provides further demand for the outputs of the BAWG and other BA thinkers who want to resolve his dilemmas and create clarity. 

I ask for patience. 

I will attempt to answer specific questions in later blog posts.  I wanted to start with this message to make it clear that I do not view Mr. Harmon, or any other business professional, as opposed to the ideas that I profess.  Rather I view his views as the necessary result of our own poor consistency, in words and practices.  I am confident that, as our profession matures and we find our voice, we will demonstrate clearly the ways in which BPM professionals and EA professionals can support each other’s efforts and build a shared model of success.

We can, we should, we must, be united in our shared goal: to improve the ability of our organizations to fulfill their missions. 

We want the same things.  We are using different tools, at different points in different processes, to achieve them.  By working together, and not apart, we will both succeed in a better way.  I seek to find that common ground.  I beg all who want the same things to help me to find it.

The Rule of EA Governance

By |2011-07-21T17:52:23+00:00July 21st, 2011|Enterprise Architecture|

There is a clear distinction between Enterprise Architecture, as described by the architect, and Enterprise Architecture as implemented by the enterprise.  I would like to posit the following as a fundamental principle that describes the difference:

All Enterprise Architecture will be implemented according to the structure of ownership and governance that exists in the enterprise. 

This is essentially an update to Conway’s Law, but Conway was focusing mostly on application development.  Conway’s law, dating from 1968, is:

…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. “

Many of the factors that drove Marvin Conway to describe software design are also at play in enterprise architecture.  Organizations want to use the teams that they have, so they will design software in such a way that it can be coded by those teams, regardless of whether that is the best way to design or deliver that system.  For example, if your company has a team of people who manage the CRM system, and a team that manages Web front-ends, then any business scenario that involves web front-ends on a CRM system will have exactly two modules.  One will be written by the Web-front end team and the other by the CRM team.

In Enterprise Architecture, the effect plays out quite differently.  EA often creates recommendations to consolidate systems, reduce overlaps, fill gaps, and optimize spending.  Since EA doesn’t design software, Conway’s law doesn’t apply. 

So how does the Rule of Governance work you ask?  If you have two business customers who both want a CRM solution, and you have one governance body, you will end up with one CRM system.  If you have two governance bodies, you will end up with two CRM systems.  If you have four business units who want CRM, and you have three governance bodies, you will end up with three CRM systems.

This rule plays out repeatedly.  I’ve never seen it fail. 

The failure to recognize “The Rule of EA Governance” is one of the causes for the failure of an EA program. 

Enterprise Architects are an optimistic bunch.  We honestly believe that we can influence the course of our businesses (evidence: we work as Enterprise Architects!).  We use modeling techniques and engineering principles, and produce nice drawings and great designs.  The business doesn’t care about nice drawings and great designs.  They care about “stuff they own” and “stuff they don’t own.” 

If you want to change the way the business works, especially with respect to shared processes, capabilities or technologies, an EA MUST create a mechanism for the shared “thing” to be owned by only one person.  As soon as only one person owns it, and has authority over it, it will exist only once.  If two people own it, it is a matter of time before they go their separate ways.  Of course, making sure that the RIGHT person owns it, that’s an altogether different problem.

So if you want to know if your Enterprise Architecture can be implemented, count the “things” in it.  Then count the number of those things with exactly one owner (and clear governance).  Those are the things that will be implemented just the way you describe it.  Everything else is a free for all.

What EA Means to One Agency of the Federal Government

By |2011-07-21T15:31:23+00:00July 21st, 2011|Enterprise Architecture|

I ran across a document from the Dept. of Commerce that describes Enterprise Architecture as follows:

“An Enterprise Architecture (EA) is a blueprint that explains how the results of Strategic Planning, Performance Planning, Budgeting, Capital Planning and Investment Control, Security and Privacy procedures, Acquisition, and other related information technology (IT) and general management processes work together to meet the enterprise’s mission and objectives.  The EA development process leads to an integrated framework, based on principles and standards, which explain Commerce’s mission and how resources will be deployed to accomplish that mission. The EA documents the future state of the Department’s information technology based on business and technology drivers as well as the transition plan for moving from the current (as-is) state to the future (to-be) state. An EA modeling toolset helps enable the development and implementation of the EA.” (source link).

Fascinating.  Breaking this down a bit, the first sentence of the definition says:

  • A bunch of processes exist, specifically including but not limited to: Strategic Planning, Performance Planning, Budgeting, Capital Planning and Investment Control, Security and Privacy procedures, and Acquisition.
  • Other processes exist that are grouped under “related information technology (IT) and general management processes.”
  • Those process work together to meet the enterprise’s mission and objectives.
  • An EA is an artifact that provides a blueprint to explain how these processes work together to meet the mission and objectives.


The second sentence says:

  • An Enterprise Architecture (the artifact) is developed through a process. 
  • Following the EA development process, an enterprise produces an integrated framework.
  • The integrated framework is based on principles and standards.
  • The integrated framework explains the mission of the agency.
  • The integrated framework explains how resources will be deployed to accomplish that mission.


The third sentence says:

  • An Enterprise Architecture (the artifact) documents the future of agency technology.
  • The future is based on business drivers and technology drivers.
  • An Enterprise Architecture (the artifact) documents the transition plan for achieving the future.


The fourth sentence says:

  • Tools are helpful (but not required) to enable the development of an Enterprise Architecture (the artifact).


There are 13 statements in that definition of EA.  Is it really necessary to make 13 statements in order to create a definition of Enterprise Architecture?  Apparently the US Department of Commerce thought that it was.  There are some interesting statements in there, that represent a particular viewpoint on EA.  There are also some statements that may reflect internal politics or discussions.  

I am interested in solving a specific problem: how should all EA programs describe themselves?  Given that problem, I find the following statements interesting:

  • An Enterprise Architecture is a thing.  It is tangible.  It can be delivered, and the act of delivering it can be measured. 
  • An Enterprise Architecture specifically includes IT resources and excludes everything else.
  • This thing called an EA contains a couple of interesting parts:
    • An explanation of the agency’s mission and objectives.
    • An explanation of how the agencies’ resources should, in the future, work together to meet that mission and those objectives.
    • A transition plan to explain how gaps will be addressed.


I have a couple of big problems with this definition. 

  1. The biggest problem I have is the second statement: that an EA is limited to technology.  That doesn’t make sense to me.  Technology cannot be mapped to the enterprise without a full understanding of the process architecture and shared information requirements of the enterprise.  It is good to create a future state technology roadmap after the enterprise architecture is developed, but not before, and not necessarily as part of the enterprise architecture itself. 
  2. A smaller problem is that the definition goes into detail by saying that a blueprint will be created, but not much detail on why it is created, how it is created, and when it is supposed to be used.  So what is the purpose of defining Enterprise Architecture if you don’t use the opportunity to answer some of these key questions?
  3. Lastly, the definition describes a couple of interesting deliverables, including a blueprint and a transition plan.  Why should a select group of experts create them?  Can anyone create them?  Is there a low bar of quality that we should not fall below?  It justifies the creation of the artifact, and even discusses the tools, but not the people who will create it or the skills that they must possess to do so effectively. 

What are your thoughts?  Is it useful for all organizations to leverage the same definition of Enterprise Architecture?  Do you agree with the statements made in this definition?  Is an EA a thing?  Should the definition of EA mention all of the items mentioned?  Should it be extended to fill in the gaps identified?

Putting the brakes on “capability obesity”

By |2011-07-15T20:58:17+00:00July 15th, 2011|Enterprise Architecture|

Microsoft IT made a bet, a couple of years ago, on using capability modeling in our own internal Business Architecture program.  That required us to have a shared and consistent hierarchy of business capabilities that we would use across all lines of business.

At that time, we adopted principles like MECE (“Mutually exclusive, comprehensive, and exhaustive”) to provide guidance about the contents of the capability hierarchy itself.  We set up a process for the team to manage the hierarchy and insure that the principles were followed. 

The team did NOT create other hierarchies, and simply “de-scoped” any discussion of a business process hierarchy or a platform feature hierarchy (those artifacts would belong to other teams, you see).

What happened? 

The Business Capability Hierarchy (or BCH) grew fat.  If we needed a taxonomy element because we were doing platform rationalization, we’d throw it into the BCH.  If we needed a list of features so that we could compare vendor products (buy vs. build), we’d throw those in to the BCH as well.  The stuff that got thrown in was “worded” as a capability, but it’s hard to know if it wasn’t just a reworded business process or system feature.  It’s easy to make things unique.  Just add words.

The result is not satisfying.  Our current taxonomy is over 2,200 items long.  In many places, it is five levels deep.  That is really big.  Too big.  There are more capabilities than there are business systems.  More capabilities than there are processes.  More capabilities than there are roles.  More capabilities than there are business objects.  If the point was to be a place where we would consolidate information, we’ve blown that out of the water.

Even if I filter the hierarchy to only show me Level 3 elements, it is still over 650 elements long.   Still too big, but if we limit ourselves to level 3, we can put two or three systems under each capability.  That’s something.  But not enough.

My advice to other companies who are adopting capability modeling: adopt a rich set of “management principles” early on:

Principle Implication
The Magic Number Seven (plus or minus two) Level 0 has one item.  At each level below, there are exactly seven elements (plus or minus two).  If not, re-balance. 
Only Level Three Matters Levels 1 and 2 are for navigation and nothing else.  Make associations ONLY to level 3 items.  Level 4 is documentation.  Level five is not allowed.
No system features The capability hierarchy must not be used for feature-by-feature product comparisons.  Leave features out.
No process variations If the only difference between two “capabilities” is the process that a person is following when they perform it, merge them. Let the process hierarchy handle that distinction.
Three mappings per application or process If you map an application or a business process to the capability hierarchy, it will map to three capabilities, at most.  If the app or process maps to more capabilities… you have too many capabilities.  Merge branches to reduce the hierarchy.  (Twist: platform products like SAP should be mapped module-by-module.)
Comprehensive and Exhaustive Leave nothing out.  Don’t just focus on the value chain processes.  That will mean that you use valuable “space” to cover supporting processes.  This is a good thing. 


Net result, your capability hierarchy is unlikely to exceed 300 items.  Best if you can keep it under 200.  Anything more than that, and even your best architects cannot learn it.  It becomes fat.  An obese capability hierarchy is not an effective tool for strategic planning.  Take my word for it.

Business Strategy and Kindergarten Soccer

By |2011-07-13T08:38:19+00:00July 13th, 2011|Enterprise Architecture|

Back when my kids were small, they all played soccer on local youth teams. 

It is interesting to watch very young kids play soccer, because the instructions are so simple: kick the ball into the goal.  With instructions like that, what do you get?  Bumblebees, of course.  While many of the kids will wander around the field, or stand in one spot wondering when something will happen, about half of each team will be in constant motion, within about ten feet of the ball.   They hover and dive and kick wildly, with the ball hopping in one direction and then another.  From the sidelines, all you can see is a cluster of little bodies moving around, and you see the ball kicked first this way, and then that.  It’s like watching a cluster of bees gradually move up and down the soccer field.

The behavior of the players is simple.  Everyone wants to score.  No one wants to pass.  No one plays a position because that is too difficult to explain to a five year old.  Rules like “offsides” are simply ignored.  The kids get dirty and get their exercise.  That’s all the parents really want.  Most everyone is happy. 

So, why bring this up?  Because the same thing happens in some companies.  There are companies that have honed a senior layer of internally competitive business managers.  Each has tremendous ambition to rise to the next level, where prestige is accompanied by a serious bump in pay.  This happens in some law firms, ad agencies, and even some large businesses. 

Take a company with a highly competitive upper middle management layer, and toss in a business strategy.  It’s like tossing a soccer ball into a group of kindergartners.  Everyone goes for the ball.  No one steps back to take the pass, because no one trusts anyone, and no one is going to be held to their position.  There are no real referees.  Add referees and the players have to start to mature!  The parents (investors) can put in referees, but if they don’t, the game looks like Kindergarten Soccer.  Lots of energy.  Everyone gets dirty.  A few times, someone scores a goal.

It is very difficult to be an Enterprise Architect in a culture like that.  No competitive child wants to listen to someone on the sidelines shouting out instructions.  Most commonly, an Enterprise Architect can be an advisor, providing pointers to one of the players so that he or she can beat the other players.  At best, you can be a coach, but only if the team recognizes that they are a team.  Even then there is no “practice time”… only “game time.”  No easy way to get these players to practice new skills, develop trust, and take the the field as a team.

Now, you could say that a business strategy should be so detailed, and so well described, that it identifies roles that each person should play.  But in Kindergarten Soccer, it won’t work.  The kids can’t follow complex plans without their childlike enthusiasm for “kicking the ball” simply taking over. 

In some businesses, Business Strategy is Kindergarten Soccer.  The only difference: if you are advising a losing player, you can be disposed of fairly quickly.  When your kid is out of the game, you go too.  Politics trumps Performance every time. 

EA Schools of Thought

By |2011-07-01T19:05:00+00:00July 1st, 2011|Enterprise Architecture|

As an Enterprise Architect, I’m first and foremost a problem solver.  I don’t like to ignore problems.  Yet, it appears that EA as a field has a problem and I’m finding it tough to ignore it.  What is the problem?  If you judge by the 1500+messages that have flooded the Enterprise Architecture Network on LinkedIn, Enterprise Architects cannot agree. 

How did I come to that impression?  Let’s look at the measures.  Across a handful of questions over the course of the past few months, there have been literally hundreds of responses.  Judging by the responses, we seem to have, as a group. different opinions about every facet of our profession.  We appear to disagree about mission statements, value propositions, metamodels, methodology, inputs, outputs, and the necessary levels of job experience needed to perform.

Certainly the impression is reasonable, but is it a reality. 

Yes and No.

There are a handful of “schools of thought” that emerge if you read and discuss.  The number of people in each school of thought varies, but there are some clear distinctions between them.  The biggest disagreements come from folks who are using the same words, but come from these different schools of thought.  

The following list is in alphabetical order.  Note that ALL of these folks have presented themselves as Enterprise Architects.

  • Alignment Architects – these folks are focused on interpreting strategy, making it actionable, and using it to scope and define business change initiatives.  Also referred to as Business Architects.
  • Application Architects – these folks are focused on implementing successful “enterprise applications” or “enterprise systems.”  Also referred to as Enterprise IT Architects (EITA)
  • Information Architects – these folks are focused on managing information assets at the enterprise level in a consistent way
  • Process Architects – these folks are focused on improving business processes or reorienting business processes to place the customer first.
  • Strategy Architects – these folks are focused on helping business leaders create new strategies, open new markets, develop new products, etc..


Just to make things interesting, the Zachman framework (ZF) is used by a subset of “alignment” architects as well as a subset of “application” architects.  So when you are discussing ZF, you aren’t even sure which perspective they are coming from.  It is just as easy to get two “alignment architects to disagree about the value of ZF as anything else. 

If you sort out the responses into groups on the basis of these different schools of thought, there is remarkable consistency among the answers.  That’s right: consistency.  People are saying similar things… sometimes even the same things… about the value, methods, and concepts of Enterprise Architecture.

Perhaps we need to split up the field into specialties, just as physicians have specialties, with some base training and a focus on a particular branch of medicine.  After all, an oncologist makes a reasonable diagnosis when you have a cold, as would an Emergency Room doctor, but in the event of a car accident, I’d take the ER doc any day, and in the event of cancer, I’m making a beeline to the oncologist. 

If we understand enough about an enterprise, and the problems that they want to solve, we can focus on a single specialty (and/or bring in the right specialist). 

Solve these problems

With these architects

We need new products.  We need to open up to new markets.  New opportunities have arisen.  New threats are recognized.  New competitive pressures are being felt. 

Strategy Architect

We need to be more agile.  We need to organize our business to deliver to our stated mission.  We need to get our strategies to be realized more quickly.  We need to cut waste.  We need to focus on what matters.  We need to implement new regulations.  We need to respond quickly to corporate mandates.

Alignment Architect

We need to implement more scalable technical solutions.  We need to integrate and/or replace complex areas of our line-of-business applications with packaged solutions.  We need to add process flexibility into our systems.  We need to consolidate business rules.

Solution or Application Architect

We need to make our processes more efficient and effective.  We need to reduce friction between business groups.  We need to minimize the cost of a business process, and remove waste. We need to refocus our processes on customer requirements and customer experience. 

Process Architect

We need to create a single version of the truth.  We need to reduce the amount of processing needed at each step of an information-based process.  We need to reduce the difficulty in producing consistent reporting.  We need to manage large amounts of information.  We need to improve the ability of business units to communicate through consistent information.

Information Architect


Perhaps if we begin to see that these folks are EACH needed, at different times, to solve different problems, we can spend much more time agreeing with one another.