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).
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.
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.
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.
Thanks for the response, Nick.
Organisational structures are kludged into ‘Who’ in Zachman because his model is missing an entire dimension (or more than one, in fact). We need to resolve this absence before we can make sense of org-structures in a Zachman-like taxonomy.
The main ‘extra dimension’ that I use relates to asset-categories:
– physical (‘things’)
– virtual (e.g. information)
– relational (e.g. links between people)
– aspirational (e.g. brand, morale, purpose)
– abstract (‘none of the above’, such as finance)
In essence, org-structures are maps of relationships (i.e. ‘where : relational’ links). A business-unit, for example, is typically a composite of ‘where : relational’ and ‘capability + function’ (i.e. ‘service’); any change to any of the underlying primitives will change the composite, and hence the role, purpose and placement of the business-unit.
A capability on its own is almost meaningless: until it’s combined with a function (Zachman ‘How’) into a service, it literally has no function. But by modelling capabilities separately, as distinct primitives, we enable alternate combinations of capability and function to give different effective services (and hence support different processes). This also gives us a better understanding of what’s needed when we substitute one capability for another whilst maintaining the same nominal function, such as in process-reengineering or disaster-recovery.
To me, capability is a nominal primitive, though it has some characteristics of a compound. On one side is the asset-type(s) to which it applies: physical, virtual, relational, aspirational, abstract, or any combination of these. (For example, a sales-capability applies primarily to relational assets, but is usually linked to other asset-categories as well – information, brand, product and so on.) On the other side is what we might call the ‘skill-level’: rule-based, analytic, heuristic and principle-based. Crucially, machines are only well-suited to the first skill-level, and IT to the first and second; IT can be used for decision-support (but _not_ decision-making) in the third, and is all but unusable in the fourth. Capability-modelling allows us to determine the extent to which IT should and should not be used in a given context, and what human skills will be needed to fill in the gaps.
I would agree that any move up and down the Zachman rows is a transformation rather than a construct. As described in the framework summary – http://tetradianbooks.com/2008/12/silos-frame-ref/ – each row upward is another level of abstraction, and each row downward adds another component to the modelling-requirements. The vertical dimension is also in effect a spectrum of time, from nominally infinite (row-0) to unchangeable past (row-6). So the same nominal ‘capability’ can be viewed in multiple ways, sometimes as "one owner’s viewpoint", sometimes "ANY owner’s viewpoint", depending on the chosen level of abstraction – much as the multiple perspectives in data-modelling, from business to logical to physical and so on.
I take your point that we could view a (business) capability as "a transformation above a composition of people and process". But if we do so, we’re actually using the same word – capability – to mean two very different things: a primitive of "ability to act on something" (hence ‘cap_ability_’) and the complex composite of people, business structure, business-relation, function, process, service and capability that we would describe as "the capabilities and role of a business unit". We can get away with such blurrings in everyday business conversations, perhaps, but we can’t do so in a taxonomy for enterprise-architecture: we _need_ the precision of proper usage of terms, or we’ll end up in an unworkable tangle.
I don’t agree that we have to presume a cube (or equivalent ‘pure’ n-dimensional structure) for an architecture taxonomy. For example, the modified Zachman I use is more like a wedge: the ‘asset-categories’ dimension is crucially important at the real-world levels (rows 5-6), but we deliberately focus and de-focus on those categories in reviewing the logical-to-physical trade-offs (rows 3-4), whilst the categories are often almost irrelevant in the true abstract layers (rows 0-2).
Some of these points might sound pernickety – as indeed they probably are for basic-level IT-architecture in information-centric industries, for which Zachman’s simple two-dimensional overview is probably adequate enough. But once we extend the architecture to other industries or contexts that deal more with other types of assets – such as manufacturing, logistics, sales, defence – we _must_ cover the full range, or we end up with an artificially restricted scope that is riddled with gaps labelled ‘Magic Happens Here’, because we have no means to describe what needs to occur there.
This also applies to any business-oriented view of IT-architecture, such as SOA, security-architecture or Enterprise 2.0, or enterprise-scale uptake of cloud-computing capabilities. A true enterprise architecture is the architecture of the enterprise as a whole – _not_ solely the architecture of the enterprise IT.
Again, hope this clarifies your queries above?
ZF is notional, its a way to organize thoughts and the resulting things. It s a poorly formed ontology for today’s complexities. Especially when we have begun to deal with architectures in a pluralistic way requiring more abstractions.
First of all Periodic Table deals elements at microscopic level, it is not dealing with Macro so it is inaccurate comparison. However, its is worth understanding the Pauli’s Exclusion Principle and how that explains why different elements occupy different cells in the periodic table.
Pluralism begins to defy Cartesian System. ZF is basically a Cartesian System owing to its classification scheme.
To understand complex EA behavior, I have begun to explore "Implicate Order" as ontology that overcomes Cartesian Dilemma.
If the Cartesian system is to be excluded to understand the Implicate Order because of its reductionism, then how can the rich distinguishable chemistry in the nature be explained. It is Pauli’s Exclusion Principle which fulfills this. It proposes a descriptive mechanism that distinguishes property of each element from the other, else the nature would seem featureless.
Example cited for "water as molecule" and "lead generation" is inaccurate. Another way to understand, periodic table and if that relates to ZF, is to consider Gene Ontology. In this structure "lead generation" is a process achieved by various functional organs.
Water is a molecule – that is a structure – its features and characteristics will be more important to be studied to generate hydro-electricity
In Periodic Table, it was Pauli’s exclusion principle that clarifies why no two electrons can occupy the same space.
From studying above mentioned subjects it will be clear that "Capabilities" are not mere primitives. They are characteristics achieved out of a composite – meaning – organ or set of organs, that they themselves have evolved from tissues and tissues have evolved from cells. So on and so forth.
When we begin to employ a Holographic framework better perspectives will emerge that ZF proves inadequate to capture and discuss. This is what is proposed by David Bohm in his work on "Implicate Order"
Thanks
More on Gene Ontology at following site:
http://www.geneontology.org/GO.doc.shtml
The three organizing principles of GO are
cellular component,
biological process and
molecular function.
A gene product might be associated with or located in one or more cellular components; it is active in one or more biological processes, during which it performs one or more molecular functions. For example, the gene product cytochrome c can be described by the molecular function term oxidoreductase activity, the biological process terms oxidative phosphorylation and induction of cell death, and the cellular component terms mitochondrial matrix and mitochondrial inner membrane.