Inside Architecture


July, 2011

  • Inside Architecture

    Enterprise Business Motivation Model version 3.5



    To visit a Wordpress site set up to explain the model, visit



    Special Thanks



    Changes to look for


    • A page was created on the Wordpress site to discuss the difference between a Process and a Capability.  (link)



    1. Add the ability to attach a Value Chain Analysis
    3. <<your suggestion here>>




  • Inside Architecture











    I ask for patience. 




  • 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:


    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