Share via

Why Business Capabilities are not in the Zachman Framework

  • Article

The Zachman framework for Enterprise Architecture is often compared to the periodic table of elements in Chemistry.  Both contain items that can be used to construct a wide array of useful things.  Both contain elements that can be understood in rows and columns with properties applied to each.  Both allow you to predict the existence of an element before one is discovered. 

Both claim comprehensiveness.  In chemistry, you cannot describe any substance made of matter without referring exclusively to the elements described in the periodic table.  In architecture, according to some enterprise architects, you cannot describe any architecture without referring exclusively to the elements described in the Zachman framework (ZF).

image

Unfortunately, this leads to some confusion when it comes to capability mapping.  Business capabilities are a tool used by enterprise architects and business architects to understand and model businesses. 

But here’s the rub: business capabilities do not appear in the Zachman framework.   This causes confusion among new architects first learning the Zachman framework.  The confusion goes like this: If the ZF is comprehensive, and defines everything that an architect needs, then why does an Enterprise Architect need a capability?  Are capabilities non-architectural?   Should the notion of capability mapping be disregarded by Enterprise Architects because capabilities are not part of the comprehensive Zachman framework?  Should the development of a taxonomy of capabilities be considered a pointless exercise because it isn’t architectural?

Hmm…

Consider this: Water (H2O) is not in the periodic table of elements.  Obvious, right?  After all, why would a molecule, like water, appear in a table of elements?  It wouldn’t, right?

But there are taxonomies, in chemistry, that include water.  There are taxonomies of molecules, taxonomies of liquids, taxonomies of solvents, etc, each of which include the molecule H2O that we know of as water.  A “molecule” is a core concept in Chemistry.

Similarly, a business capability is an architectural concept that does not exist in the Zachman framework.  It could be said to be a compound concept, just as the concept of a molecule is a composition of atoms.  A specific instance of a molecule is Water.  A specific instance of a business capability is “Lead Generation.”  In the same way that a molecule is an abstract composition of atoms, a capability is an abstract composition of roles, processes, technologies, and entities. 

So, are business capabilities part of enterprise architecture, even though they cannot be seen on the Zachman framework?  Yes.  For the same reason that molecules are part of chemistry.  A framework can define and categorize the raw materials, but it doesn’t define all the USEFUL, RELIABLE, and STABLE combinations of elements that we live with, work with, and communicate with every day.  It doesn’t even define the rules necessary to combine the elements.  (in EA, a metamodel does that).

Please don’t misunderstand.  I’m not bashing the Zachman Framework.  A taxonomy of elements is necessary, but it is not sufficient.  You can understand a lot about chemistry by using the periodic table, but you cannot do gene mapping or work in AIDS research if you limit yourself  to that single taxonomy.  You need those long (sometimes very long) taxonomies of useful, reliable, and stable combinations in order to draw conclusions about your work, organize your efforts, and find the answers you need. 

For the same reason, capability hierarchies are necessary, nay, essential to modern Enterprise Architecture.  A capability hierarchy is architectural, because it is useful to architects, used by architects, and fundamental to some architectural methods.  Is any such taxonomy perfect?  Why should it be?  In the real world, a list of things doesn’t have to be completely known, or even completely knowable, in order to be useful.

Comments

  • Anonymous
    August 14, 2009
    You're correct in saying that 'business capability' isn't in Zachman as it stands, and that this suggests that capability needs to be viewed as a composite. But if you try to apply that logic, you'll find it still doesn't work: there are no Zachman primitives that can be merged together to construct a composite that describes capability. The problem lies right at the root of Zachman's framework. Crucially, and despite all the efforts to make it so, Zachman is not a viable taxonomy for enterprise architecture. It will just-about work for enterprise IT-architecture, but it is too incomplete to be usable outside of that scope. There are several key problems with Zachman, of which the most relevant here is the misuse of the 'Who' interrogative as a taxonomic label. As a result, capabilities - the label actually required for that column - are assigned solely to human actors, locking out any means to describe capabilities of IT- or machine-based actors at the implementation levels, or business-capabilities at the higher (more abstract) levels. To resolve that part of the structural problems in Zachman, we need to define the column-header as 'capability', and link it to another dimension which categorises capability-actors (IT, human, machine etc, and their various combinations and abstractions). This then enables modelling of exactly the kind of capability-hierarchies you describe above. Similar column-header clarifications resolve the problems with using standard Zachman to model the relationships between capability, function, service and process. More detail at http://tetradianbooks.com/2008/12/silos-frame-ref/ Hope this helps, anyway.

  • Anonymous
    August 14, 2009
    Extremely Interesting, Tom.  Thank you for sharing. Your model is the first honest attempt I've seen to remove "Actors" from the ZF and replace that column with Capabilities under the notion of "Who." I'd be concerned about your approach, however, because you leave no room for the combination of organizational structures with other architectural elements, because you replaced the organizational structures with capabilities. You have correctly stated that capabilities need to be combined with other things to be interesting, and that "molecules can be based on simpler molecules, in the same way that DNA is based on simple molecules." Just as you can take a molecule and add an atom to produce another molecule, I believe that you can take a capability and add a relationship to an architectural primitive and get another interesting composite. But, can we say that capabilities are, or are not, constructed from existing primitives?  That's an interesting problem, and one that I don't have an easy answer for.  Just as the effort to move up or down a row in the ZF is more of a transformation than a construct, is it possible that the capability is a construction that sits on a fictional row, above row zero, that represents not one owner's viewpoint, but ANY owner's viewpoint?  That, in fact, the capability is a transformation above a composition of people and process? IMHO: The only real limitation of the ZF is the arbitrary notion that any three dimensional representation has to be in the shape of a cube.

  • Anonymous
    August 15, 2009
    The comment has been removed

  • Anonymous
    August 19, 2009
    The comment has been removed