The Power of Zachman Framework

More often than not, I like things that are natural and simple. The beauty of Zackman Framework is just that: natural and simple. In these years as an architect, I have referred back to it many many times, especially during early years. Now it has kind of printed into my brain with the vivid picture and molded my thinking processes when conducting architecture and design.

Zackman Framework has two dimensions out of box. The horizontal dimension uses the 5W+H (What, Where, When, Why, Who and How). I still remember at the first composition class in primary school, the teacher told us how to use 5W+H to tell a complete story. It helped. It is surprising that this rudimentary stuff can apply to the IT architecture and can do it so well.

The vertical dimension is harder to understand than horizontal one because it involves the level of details and changes of perspectives from top to bottom. I have seen the struggles even among experienced IT professionals to be able to peel the different layers of details either from inside-out or from outside-in. And yet this is one of the most essential skills especially for IT architects. The vertical dimension is top-down in nature, which means when it flows from Contextual, Conceptual, Logical, to the Functioning Enterprise, the pictures get narrowed and more details revealed. One of most striking powers of this layering is that how clearly and naturally it switches from the business concerns/perspectives to IT perspectives. People like to talk about business and IT alignments, often end up paying lip services due to the lack of grasping how the information/knowledge flows from business to IT. This vertical dimension can definitely help.

The intersections of the rows from horizontal dimensions and columns from vertical dimension form 36 cells, which cover the most complete and inclusive concerns among all the popular enterprise architecture frameworks. People can easily find homes for the concerns from other frameworks.

For instance, for the famous 4+1 View framework, its Logical view can be related to the third row – System Model; and yet the later is richer because it goes further as to 5W+H. Its Process View can be related mainly second and third cells of “How” vertical dimension. Its Physical View can be related to the first three cells of Technology Model. Its Development View can be related to row Detail Representations. Its Use Case/Scenarios View can be related to middle cells of Business Model row. The more powers go to the fact that the neighbor cells of each cell serve as its context, so people will never lose sight of where they are when addressing the specific concerns.

Another well-known framework, The Open Group Architecture Framework (TOGAF), its four architecture categories can also easily be mapped to the Zackman Framework: the Business Architecture can be mapped to the first two rows of Zachman; the Data Architecture can be mapped to cells in the row “What”; the Application Architecture can be mapped to the row of System Model; the Technology Architecture can be mapped to the row of Technology Model.

One of main complaints from IT practitioners is that the Zackman Framework tends to be documentation heavy: it sounds scary that 36 cells will correspond to 36 documents if each cell just generates one document. Making 36 documents consistent and cohesive across time span will be extremely costly in larger enterprise, not even mentioning to absorb them by team members. I have found this complaint almost groundless. First, due to its top-down layering nature, there will be much less documents in first two rows. The content of these documents will get enriched when moving down these rows. Secondly, I have proposed so called “two work streams” approach (will talk more in different blog entry): project stream and support stream. The support stream will largely handle the document repository for many cells. Enterprise social software (aka Enterprise 2.0) can be used to expedite the creations and consumptions of these documents.

The Zackman Framework is more of taxonomy of enterprise IT than of a methodology, which means it does not address how people will arrive at the artifacts that these 36 cells will need to produce.

I have long promoted the so called “big picture guided” software development to supplement and remedy the weakness of Agile methodology (will talk more in different blog entry). Regardless to their roles and positions in IT, every team members should have certain levels of understanding about the big picture. Their angles and depth of this knowledge might vary depending on their interests. This belief is largely motivated by the Zackman Framework. Its first two rows (Contextual and Conceptual) will form the solid big picture for any IT practitioners. My Layered Painting SDLC is a great match to implement the Zachman Framework.

I strongly believe that every IT practitioner should know the Zachman Framework. Each profession has its own way of thinking and behaviors, which is molded by training and long time practices. The Zachman Framework is a very powerful mean to mold an IT practitioner into a true professional.