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?
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.