Architecture: AbstractionsYou can classify the set descriptive representations of anything (buildings, airplanes, locomotives, battleships, computers, etc.) in a two dimensional classification structure, a "schema". 

One dimension of the classification I call "Abstractions" ... I chose to call this dimension of the classification "Abstractions" because you can abstract out, or separate out, or factor out a set of six single, independent variables or focal points of descriptions that are common to every architected object.

The architectural descriptions of anything will include:

1) Bills of Material 2) Functional Specs 3) Drawings (or, Geometry) 4) Operating Instructions 5) Timing Diagrams and 6) Design Objectives

It is not mysterious why the people who build buildings, airplanes, battleships, locomotives, computers, all the Industrial Age products that are sufficiently complex to warrant Architecture came up with that set of description representations. They are answering the six primitive interrogatives that constitute the total set of questions that have to be answered to have a complete description of anything: What, How, Where, Who, When and Why.

• What is it made of?
• How does it work?
• Where are the components relative to one another?
• Who is responsible for what?
• When do things happen?
• Why do they happen?

This goes back about 7,000 years to the origins of language ... and by the way, I did not invent this classification. It has been well-exercised by humanity for thousands of years. If you don't answer all six primitive interrogatives it means that your description is incomplete.

We see this in Journalism ... the six primitive interrogatives will be answered in the first paragraph or two of the article in the newspaper or you will tend to ignore the article. You intuitively sense the article is incomplete.

Any of the six primitive interrogatives that is not explicitly answered relative to the descriptions of any subject or object (or, if any one is not completely answered - Enterprise-wide at excruciating level of detail) simply means that the answers, the descriptive representations, are incomplete. The unanswered interrogative or portion of interrogative was never made explicit ... therefore, it is implicit ... which means that assumptions are being made. Those assumptions might be right ... and they might be wrong. Erroneous assumptions in tangible, Industrial Age products are the sources of defects. Erroneous assumptions in intangible subjects like Enterprises are the source of miscommunication and misinterpretations.

There is another important observation to be made about this classification of descriptive representations of Industrial Age products:

Bills of Material are descriptive of Parts and Part Structures. There is no expression of Functionality in a bill of materials. There is no expression of Geometry in a bill of materials. There is no expression of operating Responsibilities in a bill of materials. There is no expression of Time in a bill of materials and there is no expression of Design Objectives in a bill of materials. There is ONLY the description of Parts and Part Structures.

Functional Specifications are descriptive of the Functionality of the product. There is no expression of Parts and Part Structures in the functional specs. There is no expression of Geometry in the functional specs. There is no expression of operating Responsibility in the functional specs. There is no expression of Time in the functional specs. There is no expression of Design Objectives in the functional specs. There is ONLY the description of the Functional Specs.

The Geometry (or, Drawings) are descriptive of the Part Shapes and Locations. There is no expression of Parts and Part Structures in the geometry. There is no expression of Functionality in the geometry. There is no expression of operating Responsibilities in the geometry. There is no expression of Time in the geometry and there is no expression of Design Objectives in the geometry. There is ONLY the description of Part Shapes and Locations.

Et cetera, et cetera, et cetera.

Do you see the pattern? I did not complete the pattern by repeating the same observation for Operating Instructions, Timing Diagrams and Design Objectives. But, clearly, there is one and only thing expressed in each of the "Abstractions."

This is really important for engineering work. You are trying to "normalize" each characteristic. There is an engineering cliche, something like "an elegance in simplicity." You want to minimize redundancy except where explicitly controlled because redundancy increases complexity which affects manufacturing, operations, maintenance, performance, costs ... the entire spectrum of the existence of the product. The only way to "normalize" the contents of any one Cell of the Framework is to see the total set of occurrences for any one "abstraction" in the context of the entire object.

That is, for engineering purposes, you only want to see one type of thing in any one descriptive representation and you want to see the total set of occurrences of that type of thing for the entire object.

In contrast, for manufacturing, you need an entirely different kind of description. For any one part, you need to know its structural relationship with any other parts, the functionality of the part, the geometry of the part, the operational responsibilities for the part, the cyclical (timing) characteristics of the part and the part's design objectives. In short, for manufacturing, it would be optimal to make explicit every one of the Abstraction characteristics deriving from the six primitive interrogatives for any one individual part. Any characteristic that is not explicit is implicit and therefore assumptions have to be made ... subject to error.

Furthermore, for manufacturing, it is useful to decompose the end product into smaller parts. The smaller the part, the faster and more cheaply it can be made. A one-dimensional classification, a hierarchy or taxonomy is very useful for manufacturing. However, in a one-dimensional classification, the same content can be classified in more than one category as evidenced in the biological taxonomy. There is a multiple inheritance problem. The categories are "de-normalized".

Hierarchy and distributed Systems Illustrations (Sidebar):

I worked for IBM for many years and we produced and marketed the first commercially successful data base management product, IMS. Many people still use IMS. It was (is) a good database product. It was good for building systems ... it was not good for managing data. It was a hierarchical system ... one-dimensional decomposition. The same data could show up in many "segments". It was not "normalized."

About that time, Ted Codd was floating around with his "relational model", a TWO dimensional schema ... normalization! AHA!! IBM established a research project code- named "System R" at the Santa Teresa Lab in the San Jose area which was the automation of the Codd relational model. It later became what we know now as DB2. The product almost never saw the light of day! The performance was dismal and therefore, management thought no customer would ever buy it. But, they imported the three Chris' from the Hursley Lab in London.

Chris Date ... he was the one who interpreted Ted for the rest of humanity. Ted was a mathematician and he spoke in tuples, normalization and stuff ... and people would say, "Wha'd 'e say??" Chris Date would say, "Well, this is kind-of what he said." "Ohhhh," they respond. "That's really good."

Chris Gane ... was the process modeling guy. "Gane and Sarson" was the predominant European process modeling methodology much like Yourdon and De Marco were predominant in the U.S. I haven't seen Chris Gane in a lot of years. He worked for Charlie Bachman after IBM.

And ... Chris Loosley. Chris Loosley was the performance guy. He wrote a book, "High-Performance Client/Server'. Chris didn't like the title of the book. It was chosen by the publisher for marketing reasons. It was written during the period when the "mainframe" was being blamed for all the ills of Data Processing and everybody was getting rid of their mainframes in favor of "Client/Server". Mainframes were vindicated years later but the utility of putting different things in different places was argued by Chris in the Client/Server book.

Different things in different places ... for example, you can put the screen formatting outboard and keep the data and processing inboard. Or, you can put the processing outboard and keep the data and screen formatting inboard. Or, you can put the data and screen formatting outboard and keep the processing inboard. You can put various things in various places and where you put things determines your "performance" because wherever you put whatever it is, you have to go there, find it, move it somewhere else and do something with it, all of which takes time.

If you want to serve the customer, you put the finished goods inventories near the customer. If you want production efficiencies, you put the in-process inventory and finished goods near the factory. Etc., etc.

Chris used my Framework in the book to argue the point, if you want to build a system with acceptable performance (Column 5), you have to understand the locations of the Enterprise at Rows 1/2 before you decide where to put the data (Column 1), the processing (Column 2), the screen formatting (Column 4). The performance (Column 5) is determined be the integration of Column 1 (data), Column 2 (processing), Column 4 (Screen, i.e. "Work Product" formatting) with Column 3 (location). If you wait until you are writing the code at Row 5 to decide these Location characteristics, you will produce a system implementation that is a "dog", a performance nightmare ... nobody will use it.

I above elaborated Chris' point after 20 or 25 more years of experience using the Framework Ontology ... and I have not yet completed the definition of the Framework structure for yo nor have I discussed the subject of Ontologies. (I will discuss those in the future here.) But ... the basic point Chris Loosely was making was well-defined very early on. Location is the determining factor for "performance"as manifest in response times. The same concept is applicable internal to a machine (computer) as it is external to the computer in the Enterprise. Chris wrote the performance algorithms that made System R into what we know as DB2 today.