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.