Introduction to IT as the Acquisition and Automation of Knowledge


Compositional Architecture is knowledge oriented.  Compositional Architecture views software as a media for the acquisition, storage, modification, and active use of knowledge.  This view aligns with the pioneering articles of Phillip Armour.


By “knowledge” we mean awareness of the universe, how to manipulate things in the universe, or the same for abstract systems.  We will not quibble with epistemological niceties which draw distinctions between “knowledge being only in the mind of an intelligent entity” versus mere “knowledge representation”.


Phillip Armour identifies software as the fifth great knowledge media (literally) since the beginning of time:




Persistent knowledge store, updates slowly, little ability to intentionally design (by itself), effects outside world by building organisms


Volatile knowledge store, changes quickly, highly intentional, effects outside world through our bodies and by extension our tools

Hardware/Physical Artifact

Persistent knowledge store, not usually easy  to update, intentionally designed, effects outside world


Persistent knowledge store that transfers well over space and time, slow to update, intentionally created, no capacity to (directly) change to the world


Persistent knowledge store, quick to update, intentionally created, can effect outside world, but most all it is active



The basic four entities of Compositional Architecture, namely the units of computation, distribution, persistence, and transduction, are seen as knowledge containers, knowledge actors, and knowledge composers.  The appropriate means of expressing this knowledge is relative to the problem domain at hand – ideally, the established concepts and notations of a given problem domain can be used directly, such as typically found for various science and engineering disciplines.  The uniqueness of each domain’s knowledge is why there never will be a one and only universal representation, nor a single all encompassing methodology for that matter. 


Compositional Architecture also stresses avoidance of domain knowledge contamination brought on by the inappropriate embedding and submerging of domain knowledge in the noisy details of implementation and thus losing that core knowledge for any further use.  For example, it is highly desirable to avoid embedding business rules into general purpose 3GL (C/C++/Java/C#) procedures and objects.


Within the software engineering domain per se the usual suspects apply such as Requirements, Objects, Java, Class Diagrams, etc.  N.B. nearly all software engineering artifacts are overhead to structuring the mechanics (software) of the final system and have little or nothing to do with its actual knowledge content.  This is similar to blueprints and piles of building materials which say little about the intended function (knowledge content) of a hospital.


The principles of Compositional Architecture are compatible with Armour’s Levels of Ignorance, in particular the notion that the most important steps in system development are the identification of relevant questions rather the directly finding answers, and the grave dangers inherent in not knowing what we don’t know.  It is important to note that the process of reducing the levels of ignorance, and removing noisy “unknowledge”, applies across all meta-levels.


Armour identifies five “Levels of Ignorance”:



Oth Order of Ignorance (0OI)

Know something (relevant) and can use it effectively

1st Order of Ignorance (1OI)

Know that that you don’t know something

2nd Order of Ignorance (2OI)

Don’t know that you don’t know something

3rd Order of Ignorance (3OI)

Don’t have a process to find what you were unaware that you didn’t know

4th Order of Ignorance (4OI)

Not even aware of the Orders of Ignorance and their implications



The goal is to reduce 4OI to 3OI to 2OI to 1OI to 0OI, i.e. understanding the need to manage for the unknown (4OI to 3OI) put a methodology in place to detect (relevant) things of which there was no prior awareness (2OI to 1O1) and then learn about them until a solution is found (1OI to 0OI).


For example, Professor Bill Miller’s notion [personal communication] regarding “First, a new software engineering capability and architecture is required.  We now call that capability -immune system engineering. It goes beyond the OO paradigm, which I call DNA design to include an immune system for the DNA requirements, design and implementation” appears to be a methodology for relating knowledge gained at various meta-levels, including the use of  “anomaly detection” as one means of learning “what we didn’t know that we didn’t know”.


The focus seems to be on Armour’s reduction of levels of ignorance.  Albeit largely applied to the automotive engineering domain.  DNA incorporates 3OI processes to flush out 2OI issues of which we were previously unaware (“model errors” and the like including “requirement errors”) thereby reducing these newly found challenges to 1OI where we now know that we don’t know something, and ultimately on to 0OI where we at last we know something and can successfully use it, redesign it, or fix it.


These steps apply within each of the three application meta-levels spanning automotive design, production, and maintenance.  These steps apply as well as between three meta-levels in an ‘end-to-end engineering life cycle” consisting of a feedback loop style of architectural pattern between these three highest meta-levels of automotive engineering, production, and maintenance.