The Framework is the Ontology
I have no idea where people get the idea that the Zachman Framework requires any documentation at all. The Zachman Framework is an ontology – the theory of the existence of essential components of an enterprise (actually, of anything) that warrant description in order to successfully create it, operate it or change it. Whether any or all of those components are described (documented, made explicit) is a function of a methodology and the choice of the Enterprise… not a requirement of the Framework.
Models give you Power
Somehow or other, people hear me say, “Stop the music for 15 or 20 years until you get all of these models built and then you can start writing code again.” I have NEVER said anything even close to that.
What I have said is, “Some day… SOMEDAY, you are going to wish… forget you… SOMEDAY the ENTERPRISE is going to WISH they had all of these models made explicit, all of them Enterprise-wide, all of them horizontally integrated, all of them vertically integrated, all of them at excruciating level of detail.” Why? Because, if they had all of those models made explicit, they would have a VERY powerful capability to accommodate extreme complexity and extreme rates of change. I have NEVER said when I thought that would be. I have ALWAYS said that might even be utopia… you might NEVER formalize all of the models. I have said, the 80/20 rule probably is in effect. If you have 80%, you might not need the other 20%. In fact, if you had 20% of the models, you might not need the other 80%. I also have said that in order to achieve the utopian condition of all the models formalized, it likely would require a lot of work and therefore, methodologically, you will probably have to figure out how to achieve that iteratively and incrementally over some longer period of time.
By the way, I ALSO always say, you can deliver substantial, immediate Enterprise value from a relatively small sub-set of Primitive Models. A little order goes a long way!
By the way again, there ARE implications to not producing any one of the Primitive Models identified by the Framework. Any model that you do not make explicit is implicit. By definition, you are making assumptions about any Framework Primitive Model that you have not made explicit and those assumptions may be right… or they may be wrong. Erroneous assumptions in manufacturing are called “defects.” Removing defects from anything is expensive and the closer you get to providing the implementation of the end result into the hands of your customers (“users”) before you discover the defect, the more costly it will be to remove it. (This is statistically provable… see Capers Jones work on “Software Quality”). Therefore, SOMEDAY, it would be in your best interests to have made all of the Framework Primitive Models explicit… however, you may be willing to assume the risk of some defects (the fewer, the better) at any given point in time.
The Framework gives you Power
The Framework is the ontology… NOT a methodology. The Framework implies nothing about which models you might want to produce (make explicit) or whether you want to produce any models at all. It implies nothing about how you might want to produce the models: top-down, bottom-up, left-to-right, right-to-left, where to start, etc. Although these are significant methodology choices, they are not prescriptions of the Framework. The Framework simply identifies the total set of architecture possibilities and therefore, the nature of the risks that may be or may have been assumed.