The Axioms Of Architecture

Posted by Martin Hunter on 21 December 2012

In my recent blog post I explored why architecture as a process was more important than architecture as a deliverable artefact. I talked a little bit about what the defining characteristics of an architectural process are at a holistic level. In this post, I want to take this discussion further and talk about what I appear to me to be the axioms (or “known truths”) of architecture: The things we always come back to, regardless of methodology, framework, personal style or organisational culture. This means that whether you are a proponent of TOGAF, a hard-core Zachman follower, live by a sector framework (e.g. DODAF), are biased by one technology or another, or just making it up as you go along, then these are the “truths” that you consider at the core of your role as an architect.



The foundation of the architectural optimisation process rests in the questions why? and what? These are the things that the architecture process optimises the state of an architecture towards. In IT (enterprise and/or solutions) architecture, the “why” is often expressed as a set of motivations (reasons for change) and objectives (states that we want to be in), whilst the “what” is expressed as a set of functions (things that the enterprise or system does or needs to do).

The final component of the trilogy of questions in this axiom is “how”. This represents the factors we can change (the “variables” if you like), which invariably comes back to some manifestation of four sub-factors: People, Process, Information and Technology. It doesn’t seem to matter whether you’re talking enterprise strategy or real-time systems, the core “how” concerns for an architect boil down to the information used, the process that handles this information and the balance between human and computer effort in realising this process.

One thing that I have learned in my IT career is that there is (or should be) a reason for everything; a rationale, simple or complex, that explains why we act or do. This is where the “why, what and how” come in. Architecture is an optimisation process based on the application of logical argument, and this means that architects should be constantly seeking logical reasons and rationales for decisions that are made. No rationale = no decision.


To an extent, this second axiom is an extension of the first and something of a no-brainer when you say it as it is written above. Unfortunately it is something which is all too commonly missed in reality. The truth stated here is that application of thought before action will always derive a better path to value than not thinking before acting. If you work in IT, I know you will not be surprised when I state that action is not always taken with due consideration of facts (and will probably be able to sight many instances in which this has occurred). Over the last 20-30 years, the IT industry has built up many methods (sight any one of a number of commonly used (if not properly applied) SDLCs) and roles (e.g. project managers, business analysts, architects) around mitigating the risk of the unknown, of uncertainty. I think however that there is still a natural tendency to over-simplify and under-analyse in IT, often to the point that could be considered “not thinking before acting”. If IT as a sector is to build and maintain a reputation of the delivery of value, then this axiom has to come at the head of everything we do.


If you are an architect (and hopefully if you work in IT, possibly if you don’t) you will be familiar with the concept of “views”. Views are used in IT architecture and construction architecture and are a common construct in many frameworks (TOGAF, Zachman, Rational 4+1 etc.). In its broadest definition, a “view” could be considered something that expresses the structure of a thing (e.g. enterprise, system) from a single dimension or aspect. In IT, we might base our views of an enterprise, for example, around dimensions such as business motivations, people roles, IT applications, data structure, IT deployment infrastructure and so on. The important point here is that views that are cast from a single-dimension are the simplest and therefore the easiest and least error-prone way of communicating complex ideas. In reverse, views that attempt to consider multiple dimensions in one go (e.g. process structure and information structure together) are more complex, difficult to pin in one’s mind and ultimately lead to miscommunication, which is not good. If you want to know more about the arguments for single-dimensional views (and a useful catalogue of views to consider in IT architecture) then you can’t go wrong looking at Rozanski & Woods’ fabulous volume called “Software Systems Architecture – Working with Stakeholders Using Viewpoints and Perspectives” (

In some respects, I think that any process of optimisation (of which the architectural design process is one) comes back to these axioms. This includes the process of analysis (e.g. business analysis and testing in IT). As such, I think you don’t have to be an architect to benefit from thinking about your role in IT in the context of these axioms.