The Architecture of Architecture, Part II

By Len Fehskens

(Back to article)

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

  • Curiously, these definitions of our kind of architecture bear no resemblance to the definition proposed by the earliest use I have been able to find of the word in an IT context, the landmark paper Architecture of the IBM System/360 (Amdahl, Blaauw and Brooks, IBM Journal of Research and Development, April 1964). This paper defined architecture thus:

    “The term architecture is used here to describe the attributes of a system as seen by the programmer, i.e., the conceptual structure and functional behavior, as distinct from the organization of the data flow and controls, the logical design, and the physical implementation.”

    This isn’t about structural relationships between components, it’s about hiding that structure and focusing instead on behavior. Nowadays, we’d say it defines architecture as the properties of a class of objects. How did we get from “external” properties to “internal” structure? That’s largely the doing of Edsgar Dijkstra, when in 1968 he laid the foundations for the idea of software architecture. There’s a good discussion of this at the Software Engineering Institute (SEI) website—http://www.sei.cmu.edu.

    We take for granted now that the internal structure of software matters, in that this structure significantly affects many important properties of software systems. Dijkstra’s ideas, further developed by Parnas, Perry and Wolf, Garlan and Shaw, Bass, Clements and Kazman, and others, provide the foundation for software architecture as understood today. But for solution and enterprise architects, for whom software systems are often components whose internal structure is a given, they have limited relevance.

    When you consider enterprise architecture, things get even more curious. Neither IEEE nor The Open Group define enterprise architecture explicitly. The most commonly cited first use of enterprise architecture doesn’t actually call it enterprise architecture, and thus doesn’t define it.

    John Zachman first applied the idea of architecture to an enterprise-wide (though IT-focused) scope in his paper A framework for information systems architecture (IBM Systems Journal, Vol. 26, No. 3, 1987). Note that Zachman did not call it “enterprise architecture,” rather he called it “information systems architecture.” Five years later he was still not calling it enterprise architecture, but somebody else was.

    The first actual use of “enterprise architecture” I have found is by Steven Spewak in his book Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology (Wiley, 1992). Note that the subtitle limits the scope to “data, applications and technology.”

    Spewak loosely defines architecture as being “like blueprints, drawings or models.” He defines “enterprise” by writing “the term enterprise should include all areas that need to share substantial amounts of data.”

    More recent definitions of enterprise architecture tend to put less emphasis on architecture and more on the delivery of business value, in response to the pursuit of the perennially elusive “business/IT alignment.”

    For example, researchers at the MIT Sloan Center for Information Systems Research (CISR) published Enterprise Architecture as Strategy: Creating a Foundation for Business Execution (Ross, Weill and Robertson; Harvard Business School Press; 2006), where they define enterprise architecture as:

    “The organizing logic for core business processes and IT infrastructure reflecting the standardization and integration of a company’s business model.”

    And the Wikipedia entry for enterprise architecture defines it thus:

    “Enterprise Architecture is the description of current and/or future structure and behavior of organization’s processes, information systems, personnel and organizational sub-units, aligned with the organization’s core goals and strategic direction. Although often associated strictly with information technology, it relates more broadly to the practice of business optimization in that it addresses business architecture, performance management, organizational structure and process architecture as well.”

    As I said earlier, I am reminded of the blind men and the elephant. Is it possible to see the whole elephant for what it really is? Is there a single useful definition of “our kind” of architecture that encompasses all of these different perspectives and their implied needs? I believe there is. In my next article, I’ll describe my quest for it.

    Len Fehskens is The Open Group’s vice president and global professional lead for enterprise architecture. He has extensive experience in the IT industry, within both product engineering and professional services business units. Len most recently led the Worldwide Architecture Profession Office at Hewlett-Packard’s Services business unit, and has previously worked for Compaq, Digital Equipment Corporation (DEC), Prime Computer and Data General Corporation.