When enterprise architects try to explain to people who are not enterprise architects what it is they do for a living, they almost invariably resort to using an analogy with the architecture of buildings, and describe enterprise architecture as a ‘kind of blueprint’. While this analogy may be helpful in conveying a general sense of what the discipline of enterprise architecture is ‘sort of like’, it can be seriously misleading if taken too literally.

Despite this risk, far too much thinking about enterprise architecture has been unduly influenced by this analogy. This is not surprising; after all, it is called ‘architecture’, and it is reasonable to expect that if two disciplines share an important part of their name, they must share a lot of other stuff as well. Unfortunately, they do not. Buildings and enterprises are qualitatively different kinds of artifacts. Probably the biggest difference is the way people relate to them. People do not just use or interact with an enterprise: people are the enterprise.

Minimizing, if not entirely ignoring, this difference, whether deliberately or inadvertently, makes the problem of enterprise design seem tractable, in that it can be thought of as a matter of drafting the right kind of blueprint. Hence, most definitions of architecture as applied to what must be thought of as people-intensive systems, are inherently structural in nature, and architectures are thought of as being derived via and represented by models. The idea that architecture is primarily about structure, and the idea that architecture is best represented by models, mutually reinforce one another. Most architectural models are represented by ‘boxes and lines’, and it is hard not to think of what is depicted as some kind of structure.

This is ironic, because the earliest well documented use of the word ‘architecture’ in an IT context was to describe the programmer visible behavior of the IBM System/360 family of processors, in a manner independent of the internal structure of the implementation.

The emphasis, if not exclusive focus, on structure as the concern of architecture leads to an even more pernicious consequence: divorcing the architecture of a system from its raison d’être. Models are very good at representing the what and how of a system, but they leave the why implicit and external to the model, and thus, too often, external to the architecture. This makes it far too easy to think of the system as an end in itself, rather than as a means to achieving some mission.