by John A. Zachman

Introduction

The question has been asked, "is the Zachman Framework designed to sell Business Rules?"

In fact, the 'Zachman Framework' is not designed to "sell" anything.  It is simply a classification scheme for descriptive representations of complex objects.  Actually, it is a classification scheme for descriptive representations of anything -- subjects or objects.  In fact, it hypothesizes some descriptive representations of subjects or objects where no empirical precedent exists, much like the periodic table hypothesized chemical elements that had not yet been discovered.  In a similar fashion, the 'Zachman Framework' suggests that there is a set of models (specifically, "Column 6" models) that are relevant for describing the 'motivation' of the enterprise, among which it is reasonable to expect that we would find 'Business Rules' as at least part of the description.

The Framework

The Framework itself is both primitive and comprehensive.

It is 'comprehensive' in the fact that it encompasses the six interrogatives (Who, What, Where, When, Why, and How) that six millennia of linguistic experience suggest are the total relevant set.  Each question is unique, and if one answers all six questions about any subject or object, there are no further questions to be asked -- that is, it is comprehensive.

It is 'primitive' in the fact that these interrogatives cannot be factored any further.  They are not divisible.  They are primitive.

Furthermore, it is primitive and comprehensive in the fact that several millennia of experience in architecture and construction (as well as several hundred years of experience in engineering and manufacturing) would seem to substantiate.  That is, there are three sets of relevant constraints (or 'perspectives') bearing on the structure of the descriptive representations of complex objects, namely:

• constraints relevant to the objects' use,
• constraints relevant to their (logical) definition, and
• constraints relevant to their (physical) design.

These are supplemented by additional 'perspectives'

• placing the objects in context,
• transforming them ('out-of-context') into implementation, and
• (finally) their physical realization.

These six 'perspectives' too are both primitive and comprehensive in the fact that they are not factorable and there are no further perspectives relevant -- once again as suggested empirically in the older disciplines of architecture/construction and engineering/manufacturing.

Another characteristic of the Framework worthy of note is that as a schema (a classification device) it is 'normal,' that is, one fact in one place.  A meta-object only goes in one cell.  This was purely accidental on my part ... I just stumbled across the primitives ... the primitive interrogatives and the primitive constraints.  Their individual uniqueness created a normalized schema by definition.

Also, the Framework is generic. It can be used to classify the descriptive representations of anything.  It can classify representations of things that have a peer relationship (Division A, Division B, Division C, etc.) as well as things that have a kind-of 'meta' relationship (the product, the enterprise that builds the product, the enterprise that builds the enterprise that builds the product, etc.).  Furthermore, it can be used to classify descriptive representations of objects that have 'gozinta' characteristics, that is, that have a 'bill-of-materials' (or granular) relationship (a program, a system, an application, a whole department, the enterprise, the industry, etc.).

All of these characteristics of the Framework make it a good thinking tool ... a thinking tool that will help thinking about a very complex subject like an Enterprise.  Once we establish a domain, we can think about one thing at a time without losing sense of its enterprise context.  We can isolate a single variable ('Cell') and think about that Cell without getting mired down in the myriad of issues going on in the other 35 Cells.  At the same time, we can maintain an awareness of the significant horizontal relationships with 5 other independent variables -- an awareness of the significant vertical relationships with 5 other perspectives (or constraint sets), as well as an awareness of other related, peer, meta, and/or granular frameworks.

Business Rules

In the nature of the periodic table, we already know that there are 'sub-atomic' components for each of the Framework descriptive representations (or 'models').  The sub-atomic components are depicted generically in the 'meta-models' of the various descriptive representations.  Maybe, we may even find a kind of 'quantum-physics' of descriptive representations growing up ... but I suspect that this will take a quite a bit of further research because, up until now, we have discovered very few algorithmic transformations between models, let alone stable, universal components beyond 'thing-relationship-thing.'

In this vein, under the auspices of GUIDE, a prestigious group of Business Rules experts met several times a year for nearly four years and produced a meta-model of 'Business Rules.' From a Framework perspective, this was clearly a meta-model of the Designer's view of the Enterprise motivation ("Column 6, Row 3").  The resultant model is described in a document entitled "GUIDE Business Rules Project, Final Report (November 1995)" and can be downloaded from the GUIDE web site.^[1] 

A new Business Rules project has been formed and (from a Framework perspective) is focused on fleshing-out the meta-model of another one of the Framework cells, namely the "Column 6, Row 2" OWNER'S view of the motivation of the Enterprise.

The Framework and Business Rules

How could we use the Framework to facilitate our discussions in the second GUIDE Business Rules project?[^[2] 

In fact, I suggest that the Framework could be effectively used to 'frame' the discussions, to help think through the complexities of the myriad of enterprise issues and focus at this point simply on what is motivating the enterprise to do whatever it is doing.  This is interesting because somehow or other, the business rules seem to be deriving from WHY the enterprise elects to do whatever it does.

We ought to designate the Framework (domain) under discussion ... I suggest the 'Enterprise' Framework (NOT the 'Product' Framework nor the 'I/S' Framework, nor any other Framework, BUT the 'ENTERPRISE' Framework).

Next (I submit), we should limit our discussions about the Enterprise to the OWNER'S perspective ... Row 2 ... the 'usage' constraints ... how the Owners 'use' the Enterprise, maybe in Enterprise terms, what it is … or maybe what they would like it to be.  What we should NOT attempt to talk about is how to design it, that is, how to logically define the systems that make it work (Row 3).  Neither should we talk about how to build it … how to physically design it for implementation (Row 4).

Either of these perspectives would be OUT OF SCOPE.  HOWEVER, we must remember that, after we figure out how to describe what it is or what the Owners want it to be, someone is going to have to define it logically, design it physically, and actually construct it ... but for the time being, we should concentrate on describing what it is, Row 2, the 'usage' constraints -- the "Owner's view."

Next, I submit that we should limit our discussion to WHY it is what it is, or what the Owners want it to be ... that is, the enterprise motivation ("Column 6").  We would NOT want to talk about how to structure the assets ("Column 1"), or how to perform its transformations ("Column 2"), or how to effect its logistics ("Column 3"), or how to allocate work ("Column 4"), or how to time its events ("Column 5") ... all of these interesting subjects would be OUT OF SCOPE.  It is complicated enough just trying to figure out how to describe WHY it does what it does, let alone how it is structured, transformed, distributed, worked, and cycled.  HOWEVER, after we figure out how to describe WHY it does what it does, we MUST NOT FORGET that that its motivation will affect the structure, transformations, logistics, work flow, cycles, and so on.

In summary, I would suggest that we concentrate on the Owner's view of 'why' the enterprise does what it does (i.e., "Column 6, Row 2") and not get mired down in all the other entertaining Enterprise subjects.  But at the same time, let us not forget that the enterprise is far more complex than simply "Column 6, Row 2" -- and that (very pragmatically) to make the Owner's view of the motivation of the enterprise a reality, sooner or later this "Column 6, Row 2" model will have to be related to the "Row 2" models of all the OTHER Columns and to the "Column 6" models of all the other Rows.

Column 6:  'Motivation'

There has been a suggestion that the columnar model for "Column 6" of the Framework might be 'Justification and Choice' rather than 'Ends and Means' and that this might facilitate the Business Rules discussion.

I would observe that we already have an impressive candidate list of concepts and ideas that likely would comprise the meta-model of an Enterprise "Column 6, Row 2" cell.  They include:  goals and objectives, strategies and tactics, missions and vision, critical success factors and measurements, ends and means, cause and effects, opportunities and threats, strengths and weaknesses, policies and risks ... and so on, and so on.

The first question to ask is … how do 'justification and choice' relate to this pre-existing list?

• Are they two more candidates to add to the list?

• Or are they two categories into which all of the candidates on the list could be sorted?

• Or are they something else?

I DO NOT think that they are a replacement for any of the other candidates on the list -- at least, not at this point in time.

The next question to ask -- assuming that they are either candidates or categories or something else of interest -- is "how do they contribute to the body of knowledge?"  Do we learn anything more about transcribing or understanding enterprise motivation?  Do we learn anything more about deriving business rules?  Do we learn anything more about any of the other candidates on the list?  Do we learn anything more about anything?

I tend to think that, as we get into building a meta-model, if we need to express the concepts of justification and/or choices or if we need to classify the meta-objects by those categories, then we could use them.  If they are redundant, or don't prove useful, or if we don't learn anything more from them, then we wouldn't need to expend the effort to incorporate them into the model.

I clearly do not believe that they are more expressive of the intent of the "Column 6" models than are 'ends and means.'  There is simply too much academic research, authoritative documentation, and general usage that suggest concepts of 'goals and objectives' and 'strategies and tactics' convey the idea of enterprise motivation.  I chose to use the more abstract terms 'ends and means' as the columnar meta-meta-model in that 'ends' clearly expresses the idea of 'goals and objectives,' and 'means' clearly expresses the idea of 'strategy and tactics' without raising any terminology debate.  These words ('ends and means') are just as expressive, generally understood. and a little more abstract.  My opinion is that 'Ends and Means' is still the best available, most expressive alternative.

I suspect that 'Justification and Choice' is more relevant to the decision process than to the planning process.  Although the decision process clearly is embedded in the planning process, it may not have to be included in the model in order to discover Business Rules.  Furthermore, the decision process may be a little beyond our capability to model at present, as it opens up a discussion of psychology and human behavior.

The Framework is Neutral

As a thinking tool, the Framework does not preclude anything.  In fact, by definition, anything in the enterprise must necessarily be classifiable somewhere in the Framework.

Furthermore, the Framework does not argue anything.  It is totally neutral. It does not presuppose anything.  It does not even presuppose what the contents of all of the cells are beyond asserting that the "Column 1" models describe things ('What'), "Column 2" Processes ('How') ... and so on, and so on.  What we (the business rules project) would be trying to figure out is what the contents (the meta-model) of one of the cells is -- specifically (I submit) the "Row 2, Column 6" cell … but that meta-model would be OUR creation, not anything preconceived by the Framework.

Once again, the Framework is simply a comprehensive, primitive, classification scheme for descriptive representations of complex objects, in our case, enterprises.  It is useful for isolating independent variables without losing the holistic perspective.

In response to the question, "is the Framework only understandable by 'data people'?" -- clearly, the Framework is interesting and understandable to the 'data people' ... because it is a classification scheme (structure).  It is consistent with the approach to any infrastructure activity. It is 'normalized' ... it is consistent with what you have to do whenever you want to share, to store, to find, to re-use, to change.

It is totally devoid of process. It presupposes nothing as related to implementation.  It is neither linear nor procedural.  Therefore, even though it is a simple, logical structure, I suppose it might be difficult for programmers (or other purely 'sequential people') to understand.

However, that does not render it any less vital to the Enterprise or to Enterprise thinking, any more than data is less vital to programs or to systems thinking.  In fact, if the programmers and systems thinkers of a few years ago had given data a little more consideration as an Enterprise asset rather than simply a tedious (although necessary) adjunct to programs and had employed some good classification, structural techniques (however unfathomable and uninteresting they might have been), we wouldn't be expending billions of dollars today on data warehouses and the 'year 2000' debacle.  I would argue the same about the structure for architectural representations … the Framework.  Just because programmers and other 'sequential people' have a more difficult time understanding it does not mean that it doesn't exist or that it is not a useful concept, vital to the longer-term well being of the Enterprise.

I simply don't believe the Enterprise of the 21st Century will have the time or the money to rectify catastrophes associated with lack of structural comprehension.  That has everything to do with infrastructure, reusability, managing complexity, managing change, and so on. We HAVE to learn to use these kinds of thinking tools.

In Summary

The Framework for Enterprise Architecture can be a good thinking tool for enterprise issues in general -- and business rules, specifically.  It helps bound complex discussions, focusing on a single variable from a single perspective without losing sight of the total enterprise context.  A fruitful discussion of Business Rules has the potential of ushering the broader topic of Enterprise Architecture into a world of enterprises in dire need of managing increasing complexity and escalating rate of change.

I submit, Architecture and Business Rules are on the critical path for any enterprise serious about existing in the 'Information Age.'

Notes

[1]  editor's note. The current version of this paper, entitled Defining Business Rules ~ What Are They Really? is now available at:  www.BusinessRulesGroup.org.

[2]  editor's note. This second paper has now been published and is available at:  www.BusinessRulesGroup.org.

# # #