Zachman Framework 3.0 Announced Tues, Aug. 23 … Quick Notes

by Ronald G. Ross on August 25, 2011

in Business Architecture, Requirements, Zachman

Here’s a zipped pdf of the new 3.0 version of the Zachman Framework (with permission): [approx 1.5M]. An official version will be posted on soon. Visit Zachman’s new website for the latest! 

Our Editor for, Keri Anderson Healy, attended the announcement event – she reports an excellent turnout. The following are some quick first-look notes from Keri (my own comments appear in brackets). 

  • The Framework has a new subtitle: The Enterprise Ontology (TM). Zachman considered changing the main title word “Framework” to “Ontology” but decided to stay with the former. 

[Keri and I both think that was a good decision.]

  • Some new terms appear as replacements, aiming to better convey the ‘business’ message. Zachman explains:

“Because I came from an ‘information’ community I had initially used words like ‘data’ in column 1. Big mistake!  People thought the Framework was about IT! The first thing people saw was the word ‘data’.

[The Framework has always been about business engineering – that was clear even from the earliest talks I heard Zachman give in the late 1980s and early 1990s. In truth, I would have never guessed it would still be an issue 20+ years later.]

  • Faint grey lines now appear crossing column boundaries in a row. These new connections better convey that the Framework supports two kinds of models: engineering (the primitives) and manufacturing (the composites).

The Framework is well-known for its depiction of the engineering primitives (the columns, which are normalized – one thing in one place). The engineering models, however, don’t do anything in and of themselves. The enterprise also needs its manufacturing models – the composites. So these new faint gray lines have been added as a reminder that the composite models also exist and they are also important.

Note: These new faint gray lines are meant as ‘for example’ connections. In this sense they are like the examples shown in the Framework for the primitives in the columns.

  • Adjustments have been made to row 6 to better convey what it is about. In early versions of the Framework graphic, row 6 was depicted as just a sliver. It has always been ‘the enterprise’. Row 6 is different in nature from the five rows above it, which are engineering specifications for things in the enterprise, rather than the actual things themselves
  • The rows are now color-coded and each cell icon reflects the color theme of its row. At the request of various Framework users, however, the background coloring has been removed from the cells of rows 1-5 so users can annotate their own specifics over the cell graphics.
  • For rows 1-5, the color progression is red, orange, yellow, green, blue. Rather than the next-in-series indigo, row 6 is color-coded orange emphasizing that it represents the realization of what row 2 specifies.

[The row 2 / row 6 alignment is consistent with the business-engineering theme that Zachman so ably promotes.]

{ 19 comments… read them below or add one }

David Eddy August 25, 2011 at 8:01 pm

Ron -

Interesting that John puts “inventory” on Column 1… in an industry that doesn’t keep a current inventory of its work product.

Personally I’m NOT for “ontology”… it’s become a tremendously over exposed term… sort of like putting the obligatory “Ummm” in a conversation.


Ronald G. Ross August 25, 2011 at 9:07 pm

David, You said:

Interesting that John puts “inventory” on Column 1… in an industry that doesn’t keep a current inventory of its work product.

>>Still a craft, not a profession?

Personally I’m NOT for “ontology”… it’s become a tremendously over exposed term… sort of like putting the obligatory “Ummm” in a conversation.

>>Business people are not too likely to relate to the term. And logicians and others who are into such matters have very stringent tests for such things.

I think John’s point, however, is that once you have a structured vocabulary you can ‘reason’ over it. I think that’s very likely to prove crucial for EA management and design tools of the future. Or maybe they’re already out there and I don’t know??

Concept systems are very fundamental to managing *any* kind of know-how. Businesses need an inventory of their concepts … literally. Sound arcane? Not at all. I’m just talking about structured business vocabularies. We are already in a knowledge economy … we just aren’t acting like it.


Dipu April 22, 2012 at 8:23 pm

How knowledge mngenameat works ?Knowledge mngenameat is not just about technology, but technology can be used to enable knowledge mngenameat processes and practices. (KMS) is an example of using technology to help an organization be more efficient and successful in their knowledge mngenameat efforts. Knowledge Management System in use at a call center like the ITS Help Desk. On a daily basis, the ITS Help Desk interacts with the University community by telephone, e-mail, and in person concerning problems or questions with technology on campus. Using a Knowledge Management System, when a customer calls, e-mails, or visits the Help Desk with a problem or a question, the Help Desk agent searches the knowledge base for previous instances of the same problem or question. At this point, one of two scenarios are possible.1)If the problem has arisen in the past and was documented in the knowledge base, the Help Desk agent can reuse the knowledge and efficiently answer the question or resolve the customer’s problem.2)If the problem or question has not been documented in the knowledge base, the agent can research the problem, answer the customer’s question, and then document the solution in the knowledge base.Later on, if a customer calls with the same or a similar problem or question, the Help Desk agent who answers the call can use the search engine to find the information in the knowledge base and efficiently answer the customers question.Eventually, when a knowledge base has matured, it can be made available to customers directly so that they can find answers to questions on their own in a self-service manner.


Bola July 17, 2012 at 11:36 pm

The Zachman Framework for Enterprise Architecture (Zachman Framework) is a formal way of spyficeing an enterprise architecure using a two-dimensional classification matrix. One dimension of the Zachman classification matrix is based on six interrogatives (What, How, Where, Who, When, and Why); the other dimension is based on six stakeholder groups (Visionary, Owner, Designer, Builder, Implementer and Worker). The classification matrix is intended to provide a holistic view of the enterprise architecture which is being modeled.The Zachman Framework was originally developed by John Zachman at IBM in the 1980s, and is now a de facto industry standard for Information Technology (IT) department to specify enterprise architectures. It is less popular with the software development or user communities.The advantages of the Zachman Framework approach include an intuitive classification matrix which provides comprehensive coverage for all enterprise architecture stakeholders. The weaknesses of the approach include the generation of voluminous specification documentation, which can be of questionable utility.


Christian April 24, 2012 at 2:00 am

Long-Term Effects of KMS: The long-term impact of the use of KMS on lnirnaeg, innovation, and expertise development. The availability of existing solutions may bias employees to adopt existing solutions rather than search for or develop novel solutions that may be more effective. In the long run, reliance on existing solutions may result in competency traps that inhibit organizational lnirnaeg and innovation (Levitt and March 1988). The literature on organizational lnirnaeg suggests that experience plays a vital role in the lnirnaeg process. In the case of knowledge management systems, experience will be tightly tied with the use of the system. Thus, in the long run, knowledge workers may gain extensive experience at assembling knowledge components to solve problems instead of actually creating the knowledge components themselves, an important consideration related to expertise development in knowledge intensive firms that tend to promote heavy use of KMS. Further, the presence of KMS maypredispose users to the use of explicit and easily available information rather than tacit knowledge that may be more effort intensive to access on account of the stickiness of such knowledge (von Hippel 1998).Reference:A framework of knowledge management systems: issues and challenges for theory and practice Jungpil Hahn, Mani R. Subramani .Proceedings of the twenty first international conference on Information systems


Joanne Dong August 29, 2011 at 2:37 pm

The Zachman Framework has been evolving over the last 20 some years. It has been, and will continue to be critical to our thinking in the field of enterprise architecture and business architecture.

The Zachman Framework for Enterprise Architecture is less of a framework because it does not define work products or artifacts as most other architecture frameworks do. Its strength is that it provides a great way of thinking about an enterprise (or a business) from different perspectives or viewpoints.

Since its first publication in the IBM Systems Journal in 1987, the Zachman Framework has become a major influence to many other later architecture frameworks or methodologies including OMG’s Model Driven Architecture, TOGAF, FEAF, The 4+1 View Model of Software Architecture etc.

The Zachman Framework was a pioneer of IT architectural framework. Zachman stressed that an information system does not have a single architecture, instead it has multiple diagrams and blueprints representing different aspects or viewpoints of the system just like a building architecture. This holistic thinking towards IT architecture (and business architecture) is the foundation of filling the long-debated gap between business and IT and making IT a true partner and asset to the business instead of a cost centre.


Ronald G. Ross August 29, 2011 at 4:22 pm

@Joanne – All very well said. The Framework is essentially a thinking tool. One of its great strengths (which a great many people miss) is that it is completely methodology-independent — intentionally. It’s just architecture, pure and simple. That’s why it will endure.


she April 24, 2012 at 2:03 am

Knowledge Management(KM) is the collection of psrecsoes that govern the creation, dissemination, and utilization of knowledge. In one form or another, knowledge management has been around for a very long time. Practitioners have included philosophers, priests, teachers, politicians, scribes, Liberians, etc. So if Knowledge Management is such an ageless and broad topic what role does it serve in today’s Information Age? These psrecsoes exist whether we acknowledge them or not and they have a profound effect on the decisions we make and the actions we take, both of which are enabled by knowledge of some type. If this is the case, and we agree that many of our decisions and actions have profound and long lasting effects, it makes sense to recognize and understand the psrecsoes that effect or actions and decision and, where possible, take steps to improve the quality these psrecsoes and in turn improve the quality of those actions and decisions for which we are responsible?Knowledge management is not a, a technology thing or a, computer thing If we accept the premise that knowledge management is concerned with the entire process of discovery and creation of knowledge, dissemination of knowledge , and the utilization of knowledge then we are strongly driven to accept that knowledge management is much more than a technology thing and that elements of it exist in each of our jobs.


Anghielynperigrino September 23, 2012 at 4:27 am

The Zachman Framework is the basis for Architecture We know what architecture is for insrdtuial products (buildings, airplanes, locomotives, computers, etc .) because in the Industrial Age, it was the insrdtuial products that were increasing in complexity and the insrdtuial products that were If we hadn’t gotten extremely sophisticated relative to architecture for insrdtuial products, we would not likely be able to create and change complex insrdtuial products and we would likely still be in the Industrial Age learning about Product Architecture.Now when we are in the Information Age, it is the Enterprise( organization ) that is increasing in complexity and it is changing. the Enterprise Architecture is the determinant of survival in the Information Age.Therefore, the Framework for Enterprise Architecture, the Zachman Framework , has some profound significance in putting definition around Enterprise Architecture, the survival issue of the Century. so the Zachman Framework would be a good place to start.


JD Beckingham August 30, 2011 at 5:58 am

The changes in ZFv3 seem to be minor but important. Inclusion of lines (horizontal integration) across the columns is a good move.
I look forward to reading the ZFv3 concise definition of ‘inventory’ in the What column; and expect that there will be some debate regarding the apparent ‘absence of data’ as it is no longer specifically mentioned in the column heading.
It’s worth noting that even though the ‘What’ column may have been ‘labeled’ data at various times, it was always intended to be anything and everything of interest to the organization. In an earlier version of the concise definitions for “List of Things Important to the Business” Zachman included Products, Markets, Tornadoes as examples.

Beyond that I think ZF “will always be relevant to our thinking in the field of enterprise architecture and business architecture”.

The challenge enterprise architecture (rows 1-3), business architecture (rows 1-2), and IT architecture (row 3) face is operationalizing the framework in practice and in development of effective EA and BA methodologies.


Ronald G. Ross August 30, 2011 at 9:18 am

@JD B. – You said:

>> “[I] expect that there will be some debate regarding the apparent ‘absence of data’ as it is no longer specifically mentioned in the column heading.”

RGR: It’surprising how subtle, yet crucial little changes like that can really be. I agree with the change entirely. A business is not in business to manange data; it’s in business to manage real-world things. (An insurance policy or financial product is very real to customers.) The business focus should be on what is our inventory of real-world things we need to manage. Data is simply how you represent what you know about real-world things in a system. Most people in our industry don’t get that.

>> “Beyond that I think Joanne was spot on when she said ZF “will always be relevant to our thinking in the field of enterprise architecture and business architecture”.”

RGR: I think it’s likely professionals will still be talking about the Zachman Framework 50 years from now. **I would encourage everyone who thinks the Framework is valuable to urge John to write and publish the definitive book.**


Elham April 24, 2012 at 2:16 am

(KM System) refers to a (generally gerntaeed via or through to an IT based program/department or section) system for managing knowledge in organizations for supporting creation, capture, storage and dissemination of information. It can comprise a part (neither necessary nor sufficient) of a Knowledge Management initiative.The idea of a KM system is to enable employees to have ready access to the organization’s documented base of facts, sources of information, and solutions. For example a typical claim justifying the creation of a KM system might run something like this: an engineer could know the metallurgical composition of an alloy that reduces sound in gear systems. Sharing this information organization wide can lead to more effective engine design and it could also lead to ideas for new or improved equipment.Successful Knowledge Management practice requires effective Knowledge Management strategy, which should be aligned with institutional strategy. Careful reviews should be taken to assure good cooperation among culture, people, processes, and enabling technologies, which are the four pillars of Knowledge Management infrastructure.


Jan Widegren September 16, 2011 at 3:16 am

One type of artifact that I have found difficult to put into the right cell(s) in the ZF is specifications of system requirements, for example use case specifications and non-funtional requirements. To which cells do these artificts belong in ZF 3.0? Thank you for any hint.


Ronald G. Ross September 16, 2011 at 3:48 pm

@Jan – Re uses cases: With respect to Zachman and assuming you mean the traditional definition of use cases (see Wikipedia), I would put them in column 4 (“who”), row 3 (Architect Perspective). Developing uses cases involves designing man-machine interactions … which represent an architected way to support interacton ‘at a distance and over time’ between roles via composed work products.

I would have to defer on non-functional requirements … Haven’t really thought about it.


Jan Widegren September 19, 2011 at 1:53 pm

Thank you for your quick response.

Putting the use case specifications in the Who-column, Architecture Perspective row sounds reasonable if you consider the primary question answered by use cases is “Who (which roles/actors) are using/interacting with the system?”. However, the use cases also, and maybe foremost, answer the question “What kind of functionality is provided/realized by the system?” From that perspective, perhaps an alternative would be to place them in the How-column, Architecture Perspective row. After all, the process/work-flow definitions go into the How-column, row 2 (right?) and each use cases should be connected to the process activities/context where it is used. This way, functionality at both enterprise and system-level go into the same column (How).


Ronald G. Ross September 19, 2011 at 2:28 pm

@Jan — The generic models Zachman gives are:
* Column 4 (who): role-workproduct-role
* Column 2 (how): input-process-output or input-transform-output
To my mind, use cases are about creating some work product that some other role(s) need or can use. The flow or sequence you see is simply one deemed most effective for the ‘build’ of the work product.


Abhishek April 22, 2012 at 11:34 am

Zachman Framework Concept:The basic idea behind the Zachman Framework is that the same cmpolex thing or item can be described for different purposes in different ways using different types of descriptions (e.g., textual, graphical). The Zachman Framework provides the thirty-six necessary categories for completely describing anything; especially cmpolex things like manufactured goods (e.g., appliances), constructed structures (e.g., buildings), and enterprises (e.g., the organization and all of its goals, people, and technologies). The framework provides six different transformations of an abstract idea (not increasing in detail, but transforming) from six different perspectives.[24]It allows different people to look at the same thing from different perspectives. This creates a holistic view of the environment, an important capability illustrated in the figure.Focus of ColumnsIn summary, each perspective focuses attention on the same fundamental questions, then answers those questions from that viewpoint, creating different descriptive representations (i.e., models), which translate from higher to lower perspectives. The basic model for the focus (or product abstraction) remains constant. The basic model of each column is uniquely defined, yet related across and down the matrix.[26] In addition, the six categories of enterprise architecture components, and the underlying interrogatives that they answer, form the columns of the Zachman Framework and these are:[24]The data description — WhatThe function description — HowThe Network description — WhereThe people description — WhoThe time description — WhenThe motivation description — Why


Pardeep July 18, 2012 at 12:35 am

The Zachman Framework is the theory that there extsis a set representations (models) for describing, designing and building complex objects. The framework draws on two distinct classification systems to define the set of representations that are needed to manage the complexity and change of these objects. This set of representations forms the cells of the framework.The first classification system is the six fundamental questions (commonly used in journalism): who, what, when, where, why, and how. This set of questions has been used for millennia to describe situations or objects and forms the basis of human communication. These interrogatives form the columns of the framework.The second classification system is based on the stakeholders from traditional architecture: owner, designer, builder and has been extended to include: planner, and subcontractor. This set of perspectives has been used for centuries in the architecture of buildings independent of geography, culture, language, politics or technology. These perspectives form the rows of the framework.


Walid April 24, 2012 at 2:09 am

The Zachman Framework is a schema for oznagiring architectural artifacts (in other words, design documents, specifications, and models) that takes into account both whom the artifact targets (for example, business owner and builder) and what particular issue (for example, data and functionality) is being addressed.The term Zachman Framework has multiple meanings. It can refer to any of the frameworks proposed by John Zachman:The initial framework, named A Framework for Information Systems Architecture, by John Zachman published in an 1987 article in the IBM Systems journal.The Zachman Framework for Enterprise Architecture, an update of the 1987 original in the 1990s extended and renamed .One of the later versions of the Zachman Framework, offered by Zachman International as industry standard.In other sources the Zachman Framework is introduced as a framework, originated by and named after John Zachman, represented in numerous ways, see image. This framework is explained as, for example:a framework to organize and analyze data.a framework for enterprise architecture.a classification system, or classification scheme.a matrix, often in a 6 6 matrix formata two-dimensional model or an analytic model.a two-dimensional schema, used to organize the detailed representations of the enterprise.


Leave a Comment


{ 2 trackbacks }

Previous post:

Next post: