The Architecture of Architecture, Part II

“You Say Po-tay-to, I say Po-tah-to.”

In my last article, I argued that because we really don’t have a much needed, shared vocabulary for “our kind” of architecture, there is justified skepticism about the legitimacy and value of the discipline.

In this article, I’ll try to support that assertion by surveying the diversity of opinion on what “our kind” of architecture is about. I’ll start with a review of the conventional wisdom on the subject, and then contrast that with the earliest use of the term “architecture” in the IT space that I’ve been able to find.

Most definitions of “our kind” of architecture define it in terms of components and relationships. Recently, the inclusion of the idea of principles has become more common. For example, one of the most commonly cited definitions of enterprise architecture is provided by IEEE Standard 1471, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems . It reads:

“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.”

But if you compare this to IEEE’s definition of design, from IEEE Standard 610, Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, which reads:

”Design: ‘(1) The process of defining the architecture, components, interfaces and other characteristics of a system or component. (2) The result of the process in (1).’”

you’ll see why such definitions are not helpful in distinguishing architecture from design. Just what makes it architecture rather than design? Indeed, 610, admittedly older than 1471, defines architecture as:

“The organizational structure of a system or component.”

So, design is the architecture, and architecture is the design … hmmm.

The Open Group defines architecture thus:

“Architecture has two meanings depending upon its contextual usage:

  • (1) A formal description of a system, or a detailed plan of the system at component level to guide its implementation.
  • (2) The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time.”

    Because we borrowed the idea of architecture from the discipline of civil architecture these definitions are based on analogy with the definition of civil architecture. Analogies with civil architecture are intuitively appealing, but they must be made carefully, because the medium of “our kind” of architecture is quite different from that of civil architecture.

    From the definition of architecture in the Oxford English Dictionary:

  • “The art or science of building or constructing edifices of any kind for human use …”

  • “The special method or ‘style’ in accordance with which the details of the structure and ornamentation of a building are arranged.”

    Other dictionary definitions of this original meaning of civil architecture ring changes on these basic themes of structure and style. They refer in common to the art and science of design for construction, and to stylistic patterns within that art and science. These aspects have been carried over into most modern definitions of “our kind” of architecture by analogy. But these definitions don’t even bother to distinguish between design and architecture; architecture is design for construction as opposed to design for something else.

    This doesn’t work well with our kind of architecture, because we regularly use the word design to denote a specific activity in virtually all system development lifecycle models (regardless of the granularity of the cycle, or whether the activity is explicit or implicit). More importantly, all of our kind of design is design for construction, so by analogy with civil architecture, any and all of “our kind” of design is architecture. Again this is not helpful in understanding what makes our kind of architecture worthy of the name.