Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

July, 2011

  • Inside Architecture

    Enterprise Business Motivation Model version 3.5


    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

    To visit a web site produced by the Sparx modeling tool, allowing direct navigation of the model itself, visit

    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.

  • Inside Architecture

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


    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.

  • Inside Architecture

    The Rule of EA Governance


    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.

  • Inside Architecture

    What EA Means to One Agency of the Federal Government


    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?

  • Inside Architecture

    Putting the brakes on “capability obesity”


    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.

  • Inside Architecture

    Business Strategy and Kindergarten Soccer


    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. 

Page 1 of 2 (7 items) 12