Enterprise Architecture Defined: Primitives and Composites

To return to the basic point ... the kind of descriptive representations (models) you need for engineering are different from the descriptive representations (models) you need for manufacturing.

For engineering purposes, you want to see one and only one thing in any one descriptive representation and you want to see the total set of occurrences of that one thing in the context of the entire object being described. You are trying to "normalize" the set of occurrences, get rid of any redundancies (except for "controlled redundancies"), make it as simple as possible ... LEAN.

In contrast, for manufacturing purposes, you want to see only one part (one implementation, one "piece") of the object being described and you want to see (optimally) all of the "Abstraction" characteristics for that one part. You are trying to deliver a single implementation (part) defect-free as quickly and cheaply as possible.

The objectives of engineering and manufacturing are in conflict ... a paradigm problem. The dialectic resolution is the function of Architecture ... but until one can perceive the paradigmatic dichotomy of engineering and manufacturing, there is NO POSSIBLE RESOLUTION.

The above graphic is my attempt to depict this engineering/manufacturing dichotomy.

In the context of my Framework, for engineering you want a single Cell model, one type of component and all the components of that type for the entire Enterprise. Being pragmatic, you don't have to do this all at one time. You could add Enterprise "slivers" and detail "slices" little by little over long periods of time. I call this engineering type of model a "Primitive Model". I got the word "primitive" from "Primitive Interrogatives".

In contrast, the kind of model you need for Manufacturing is a multi-variable model for a single implementation, a "part" of the overall object, in the Enterprise Architecture vernacular, it would be a multi-variable, "Composite Model" for a single implementation, that is, for a "system". In fact, I call the manufacturing model a "Composite Model" because it would be made up of (composed of) components from more than one Framework Cell.

You notice, I mixed the metaphor ... I had been talking about buildings, airplanes, battleships, locomotives, etc., complex industrial Age products and I switched to talking about Enterprises, an Information Age concept. The architectural structure of descriptive representations is the same for ANY object and the engineering/ manufacturing dichotomy is identical for tangible, Industrial Age products as well as conceptual, Information Age objects (like Enterprises).

The Zachman Framework is a two-dimensional classification, a "schema", NOT a hierarchy, or taxonomy (one-dimensional decomposition) and NOT a methodology. The Zachman Framework does not imply anything about how to do Enterprise Architecture, that is, how to produce the Primitive Models that constitute Architecture ... top-down, bottom-up, left-to-right, right-to-left, or where to start. The Framework is inert. It simply classifies all the facts that are relevant to the existence of an object, any object.

The descriptive representation for any one Cell would depict the structural relationship of all the Enterprise components of the same type internal to the Cell as classified in the Framework. Any one engineering component within any one Cell can be related to components in other Cells in the same Row and to the Cell above and the Cell below to constitute a "Composite", manufacturing model. The Zachman Framework therefore depicts both the engineering and manufacturing representations. The engineering Primitive, any one single Cell model and the manufacturing Composites, the components of Cells related between Cells across a Row as well as related to a Cell above and to a Cell below.

I did not invent the horizontal classification, the "Abstractions". They are simply the formal expression of the six primitive interrogatives that constitute a complete description of any subject or object. That classification was derived from the origins of language and has been tested by humanity for literally, thousands of years. Every relevant fact has to be classifiable in those six categories. There are no more categories. That is the total set as evidenced by the thousands of years of usage proof.

Historical Digression for Context (Sidebar)

The other dimension of classification, I called "Perspectives". I have to tell you a little bit of history so that you would understand why I thought the other dimension of the classification was different "Perspectives."

I was the IBM Account Executive for the Atlantic Richfield (ARCO) Company. ARCO was the result of the merger of three independent oil companies. Atlantic out of Philadelphia bought Richfield out of Long Beach, CA and Atlantic Richfield bought Sinclair out of New York City. In 1969, it was the biggest corporate merger in history. They had three of everything and were trying to create one, integrated oil company. Jack Murray was the Vice President of Administration and Jack said, "Well, Zachman ... what do you think we ought to do?" I said something like, "Jeeeeze Jack I dunno! Let me see if I can find somebody who might have some ideas."

Around 1971, I stumbled across some guy ... Dewey Walker, who had recently been assigned to the Large Account Marketing Staff where he was documenting his methodology for "Designing the General Manager's Information System". Dewey had been the Manager of Information Systems Architecture for the Data Processing Group Staff. In 1969, he and Sal Catalano, the Director of Information Systems Control and Planning wrote the seminal article that was subsequently published in two Computer Decisions Magazine articles, "Where Do We Go from Here with MIS?", and "Next in MIS: 'Data Managed' System Design".

A further digression that has some historical significance. Sal Catalano worked for "Dawk" Dawkins, the Vice President of Data processing (who I did not know). Dawkins retired in about 1969 and IBM decentralized Data Processing into, as I remember it, 203 data centers around the world. They no longer needed the Information Systems Control and Planning (ISC&P) Group Staff and started placing them in other responsibilities. Dewey went to Large Account Marketing ... I think the logic was something like, "Well, Dewey already did the IBM Architecture so we don't need him anymore ... maybe some of the larger accounts might find his experience useful".

It is interesting to note that the ISC&P Staff was comprised of a Manager of Planning, a Manager of Architecture, a Manager of Data, a Manager of Communications, and a Manager of Controls. The way they controlled Data Processing was through the equipment Inventories. (When could you add something into inventory and when could you take something out of inventory ... asset management.) I don't remember where the all the people were assigned, I only remember Dewey. It is interesting, in 1969, they had Plans and Controls (the management system, deriving from Column 6), Data (Column 1), Communications (Column 3) and Dewey was defining the Systems "Architecture" (Column 2). Columns 4, 5 and 6 were not recognized explicitly in 1969 ... and still are not recognized extensively in 2014. In any case, the ISC&P staff was pretty innovative for 1965 or so.

Once Dewey came to Large Account Marketing, he began to document his methodology which was intuitive, based on his actual experience (which is not dissimilar to most methodologies even to this day).

Dewey didn't think that Enterprises less than $500,000 million (1970 dollars) were complex enough to warrant expending the energy and resource to do Architecture so he eliminated them. Then he divided his methodology into two phases, Customization and Definition. Customization was a two week, quick look to see if Architecture was warranted. Dewey was looking for Asset Management problems because if an Enterprise was leaking assets, it indicated that management did not have access to Enterprise-wide, semantically coherent data that supported Enterprise decisioning.

They needed Architecture. This is the same problem that Bill Inmon documented in his 1989 book, "Data Architecture the Information Paradigm."

I was bringing Dewey out to Los Angeles to meet with ARCO Management to help define the new, integrated oil company. I remember driving him out to LAX (the Los Angeles airport) one afternoon to catch his plane back to New York and Dewey said, "the secret to this whole thing lies in the coding and classification of the data." My reaction was ... "The DATA! What is THAT!! What does the tape library have to do with anything?!" Data to me was hundreds of reels of tape hanging in racks in the tape library. Remember there were no words to discuss data, no data vocabulary. No entities, attributes, relationships, data models, cardinality, optionality, normalization, no subject databases, no direct access, relational structures, no schemas no anything! ... in fact, database was a pretty new subject that was not all that well-understood. Chen didn't publish until 1977. IBM probably announced IMS about 1970 ... right when ARCO was moving their corporate headquarters to Los Angeles. ARCO was building their own telecommunications access method! There was no IMS DC or CICS DC. Dewey only had the words "Data Classes" to try to describe, non-redundant, normalized, classification of data.

Dewey got frustrated and resigned from IBM to go to Humana as the Vice President of Management Systems. In the meantime, IBM reorganized in 1974, eliminating an entire layer of management. I lost my ARCO account to one of the executives in the (old, BIG) Western Region. IBM moved me up to the (new, small) Western Region as the Manager of Planning Programs on the logic that maybe some other large accounts might be interested in my experience with Dewey's methodology at ARCO. Dewey named his methodology "Business Systems Planning" (BSP) because he knew it was NOT Information Systems Planning (ISP). When Dewey left IBM, I became the de facto owner of Dewey's methodology by default because I was the only one who had any idea what Dewey was trying to do.

Before Dewey left, he never got around to formalizing his Definition Phase which was the creation of the Enterprise's Architecture. All we had to work with was Dewey's two week, Customization Methodology which we fleshed out into a stand-alone planning methodology retaining Dewey's name, "Business Systems Planning." It became officially a 4 to 6 month effort and was a good methodology ... it retained much of Dewey's conceptual innovation and transcribed the Enterprise Strategy that today, I would call a Zachman, Row 1 methodology. It is logically the same or at least very similar to any or all current methodologies that do "Information Strategy" kinds of analysis in support of a business.