On the definition of architecture

I've recently blogged about my view on (enterprise) architecture (see e.g. here and here). In this article I'll investigate the definition aspect of enterprise architecture in more detail. As a word of warning: I'm not going to propose yet another definition for the concept of enterprise architecture. For those who find such a discussions interesting, have a look at thispost on Erik Proper's blog, and make sure you notice the comment by Hans Bot.

The IEEE 1471-2000 definition of architecture is as follows:

Architecture: the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution.

In this presentation, Richard Hill gives a good definition for the terms used in this definition:

• fundamental organization means essential, unifying concepts and principles
• system includes application, system, platform, system-of-systems, enterprise, product line, ...
• environment is developmental, operational, programmatic, … context of the system

Defining these things so strictly gives us, architects, the feeling that we're doing something rational. That terms mean the same thing to everyone. That Enterprise Architecture is, somehow, objective. To many, architecture is indeed about providing rational arguments about enterprise transformation. It is how I use the concept of architecture in my work as consultant - at BiZZdesign - also. However, theoretically this does not add up. As a scholar, I find that disturbing. The point is that architecture, by definition, is subjective. Here's why.

First of all, when adopting IEEE 1471-2000, we assume that all enterprises to be systems. I've recently had a few interesting debates with systems-thinkers who indeed assume the world to consist of systems, be it closed technical systems or open social systems (as a side note: in western society this seems to be the predominant view of the world indeed. However, why not see enterprises as organisms?). The question, then, is: what is a system?

Following the FRISCO report (highly recommended), a system is defined as follows:

A system is a special model, whereby all the things contained in that model (all the system components) are transitively coherent, i.e. all of them are directly or indirectly related to each other form a coherent whole. A system is conceived as having assigned to it, as a whole, a specific characterisation (the so-called "systemic properties").

In other words, a system is a model. FRISCO defines model as follows:

A model is a purposely abstracted, clear, precise and unambiguous conception.
A model denotation is a precise and unambiguous representation of a model, in some appropriate formal or semi-formal language.

Thus, FRISCO makes a distinction between abstract models, and 'tangible' model representations. A conception, in FRISCO, is:

A conception is a special actand resulting from an action whereby a human actor aims at interpreting a perception in his mind, possibly in a specific action context.

The list of definitions goes on and on, building a solid framework for 'thinking in terms of systems'. Summarizing, FRISCO asserts that people view the world (perception), make sense of it (conception) and through the process of summarizing, focus, et cetera, form (mental) models. Even more, systems are defined as a special case of models.

Coming back to the topic of this blog post: the above implies a second layer of abstraction. First of all, seeing the world in terms of systems is a choice. Secondly, systems are 'in the mind of the observer' and therefore inherently subjective. Surely, by communicating about our mental pictures of the world, we can attempt to 'synchronize' our world views but still.

To complicate matters further, there's a third layer of abstraction involved here. IEEE 1471 asserts that architecture is about the fundamental organization of systems. What is fundamental is, of course, also in the eye of the beholder. This means that, when discussing architectures, we're really working at an abstract³ level.

The practical consequences and relevancy of this blog post may seem low. Admittedly, the post is theoretical indeed. The point, however, is that architects should be very aware of the fact that they're working on an abstraction of an abstraction of an abstraction of something in the real world. Changing a line in an architecture diagram, or inventing a new principle doesn't alter the real world!