The Architecture of Architecture, Part II
In my last article, I argued that because we really dont 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, Ill try to support that assertion by surveying the diversity of opinion on what our kind of architecture is about. Ill 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 Ive 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 IEEEs 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).
youll 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:
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:
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 dont even bother to distinguish between design and architecture; architecture is design for construction as opposed to design for something else.
This doesnt 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.
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 isnt about structural relationships between components, its about hiding that structure and focusing instead on behavior. Nowadays, wed say it defines architecture as the properties of a class of objects. How did we get from external properties to internal structure? Thats largely the doing of Edsgar Dijkstra, when in 1968 he laid the foundations for the idea of software architecture. Theres a good discussion of this at the Software Engineering Institute (SEI) websitehttp://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. Dijkstras 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 doesnt actually call it enterprise architecture, and thus doesnt 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 companys 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 organizations processes, information systems, personnel and organizational sub-units, aligned with the organizations 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, Ill describe my quest for it.
Len Fehskens is The Open Groups 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-Packards Services business unit, and has previously worked for Compaq, Digital Equipment Corporation (DEC), Prime Computer and Data General Corporation.