Defining Architecture

Architecture is a concept everyone knows, but what is architecture actually?

In Chapter 2.2 of TOGAF 9.1 it says:

TOGAF embraces but does not strictly adhere to ISO/IEC 42010:2007 terminology.

Yet, in its list of definitions, TOGAF attributes ISO/IEC 42010:2007 when it defines architecture:

1. A formal description of a system, or a detailed plan of the system at component level, to guide its implementation (source: ISO/IEC 42010:2007).
2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

The citation of ISO/IEC 42010:2007 is incorrect. The second definition is a paraphrase, not a literal quote of the 42010 definition, but the first definition should not be attributed to 42010 at all. Neither should refer to 42010 as its source, I would say. The actual text of the definition of architecture from ISO/IEC 42010:2007 is:

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.

I asked around about the TOGAF reference. Andrew Josey from the Open Group picked up on my question and has now filed a defect report (“Minor”, “Editorial”) in the TOGAF 9.1 Defect Reporting system (protected link; you need to be a member of the Architecture Forum to access it).

It so happens that ISO/IEC 42010:2007 is today a deprecated standard, since the standards bodies have published a revised version, ISO/IEC/IEEE 42010:2011, which updates this very definition. The text of the definition of architecture from ISO/IEC/IEEE 42010-2011 is:

Fundamental concepts or properties of a system in its environment, embodied in its elements, relationships and in the principles of design and evolution.

The new definition is in my opinion clearer than the 2007 definition, and the one I will use in the future. The 42010 standard has a long history, enough to fill a whole annex (Annex A) of the standard and a classic paper. The 42010 FAQ points out that there are several key ideas in this definition:

• “Architecture” names that which is fundamental or unifying about a system as a whole; the set of essential properties of a system which determine its form, function, value, cost, and risk.
• An architecture is a conception of a system – i.e., it is in the human mind. An architecture may exist without ever being written down. Therefore, the Standard distinguishes architectures and architecture descriptions: just as it is said, “the map is not the territory”, an architecture description is not the architecture. An architecture description is what is written down as a concrete work product. An architecture description represents an attempt to express a conception of a system to share with others. The focus of the Standard is on requirements on architecture descriptions.
• An architecture is understood in context – not in isolation. To understand a system’s fundamental properties (i.e., architecture) is to understand how the system relates to, and is situated in, its environment. Often, the architect cannot know what is fundamental about a system without knowingfundamental to whom? Therefore “fundamental” is to be interpreted in the context of a system’s stakeholders in its environment.
• Finally, there are some things that an architecture definitely is not. An architecture is not merely the overall structure of physical components that make up a system. While physical structure can be fundamental to a system, it need not be.

Strictly speaking, TOGAF “messes up” the 42010 definition by suggesting two meanings “depending on the context” but not then explaining when and where which definition should be used; in TOGAF chapter 35.1, only the second definition is used, even though in a place where the first definition ought to be used (artifacts/documents context), but actually following 42010 and saying that the architecture as one thing, and the architecture description as another thing. 42010 is very clear: An architecture is abstract – not an artifact. The 42010 standard uses another term, architecture description, to refer to artifacts used to express and document architectures.

When we work with architecture, as architects, we are architecting (42010:2011):

Process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle.

In the Common Approach, architecture is defined as:

a systematic approach that organizes and guides design, analysis, planning, and documentation activities.

Finally, a quote from the Danish architect/designer Arne Jacobsen:

I don’t see that any buildings should be excluded from the term architecture, as long as they are done properly.