What Is Architecture? An Explanation for IT Professionals
Wm. Andrew Wynn. Associate Director, Strategy, Architecture, and Standards
Global Data Warehousing, Bristol-Myers Squibb, Member of the IEEE and ACM
e-mail: andrew.wynn@bms.com
Abstract
This paper addresses the observation that in IT, theterm “Architecture” is used widely yet it's meaning ismost often vauge and inconsistent. The paper begins
with a literature survey of many sources that use the term
Architecture. The sources represents the various uses of
the term “Architecture”. It begins by reviewing
Organizational Archtecture and sequentially progress
through Enterprise Architecture Planning, Information
Systems Architecture and Software Architecture. The
second section presents a more specific definition of
Systems Architecture then is represented in prior literature
survery and highlights how the work Kilov and the RMODP complement and extend the methods presented in
the more common Architecture definitions.

1. Introduction
The following is a quote from Peter Drucker, which
he published in 1945. It is about the value of andnecessity of specification and design as part of the systemdevelopment process. "Automation is a concept of theorganization of work…. Automation is not "technical" incharacter. Like every technology it is primarily a systemof concepts, and its technical aspects are results rather
than causes. The first concept is a metaphysical one: that
there is a basic pattern of stability and predictability
behind the seeming flux of phenomena…. Only after
these concepts have been thought through can machines
and gadgets be fruitfully applied [8].”2. Literature Survey
2.1

Macro-Level Architecture: Organizational
Architecture

In the text Organizational Architecture: Designs for
Changing Organizations [22], David Nadler and his
associates describe an approach to designing High-

Performance Work Systems. The approach is based on
the Systems Theory of Organizational Behavior.
Thereby, it views any purposeful organization of humanbeings as a system. In doing so, Organizational
Architecture seeks to achieve good “fit” (or congruance),
between the various dimensions of an organization. The
theory draws on the socio-technical model of work design.
In the text, the authors trace the basis for their approachback to the research done in the United Kingdom in thelate 1940’s. “Researchers from the Tavistock Institute,
studying the introduction of new technology in British
coal mines (and later in the weaving industry in India),
discovered that technological innovations alone could not
explain the differences in performance. In fact, the certain
technological changes that were intended to increase
performance resulted, instead, in performance declines.
Research revealed that high performance resulted when
the design of the technical system and the design of thesocial system of work were congruent. Building on groupdynamics and general systems theory, the Tavistock
researchers demonstrated that high performance requiredthat the needs of the organization’s social system and theneeds of the technical system be considered equally andsimultaneously in the design process [22]."
The quality of this research and the credibility of David
Nadler as a first class academic and management
consultant [14] lend signficant weight to the contributionsof Kilov [15] and Morabito, Sack and Bhate [20] in theirefforts to define an approach to “system” modeling that is
coniziant of more than only what is required to move andstructure data (which of course is about where mostInformation Systems Architecture definition efforts stop).
For example, consider that IT organizations sometimes
fail when attempting process improvement initiatives,
such as the SEI/CMM [26, 31, 32]. As Michael Westemphasizes, if more consideration were given to theorganization as a socio-technical system, before andduring such efforts, perhaps they would not fail quite as
often [31, 32].

2.2

Mid-Level Architecture: Information
Systems Architecture

The Zachman Framework is the most widely known
method of defining Information Systems Architecture[33]. Its simplicity makes it a useful communication tool
and affords it a good deal of popular appeal. A succinct
summation of its strengths and weaknesses is provided by
Richard Balicki:“The framework’s strengths include (1) a simple
method for classifying design roles and productabstractions; (2) a neutrality with respect tomethodologies, tools, and techniques; and (3) a facility forvarying levels of abstraction (design roles or “rows”)
while limiting scope (product abstractions or “columns”).”
The framework’s weaknesses include (1) its“descriptive” oriented - it serves “to document, rather thanenable precise and explicit specifications of, information
systems constructs.” (2) “the framework does not integratea product abstraction’s design roles. Another way to lookat this is the lack of linkage between rows within acolumn…. (and) there’s a lack of linkage between
columns within a design role”…. (3) the framework’s
representations are implementation oriented even at thehigher level design roles – it represents “business aspects
with implementation oriented constructs (e.g., E-R
diagrams, hierarchical diagrams, data-flow diagrams,
organizational charts, etc.)" [1].
Enterprise Architecture Planning (EAP), as defined by
Steven Spewak [28], is an approach to IT application
portfolio planning that is purposefully based on the
Zachman Framework for Information Systems
Architecture.
The approach is a synthesis of theInformation Strategy Planning (ISP) stage of theInformation Engineering (IE) methodology as defined byJames Martin [17] and the Zachman Framework.
Spewak’s synthesis makes the Zachman Framework
useful in way it would not otherwise be. For example,
the IE-ISP and EAP methods relate the “What”(Information Needs) with the “How” (Business
Functions) from the Zachman Framework as part ofdefining the “Application Architecture” (in EAPterminology).
Additionally, EAP and IE-ISP both do a great deal toclarify how to organize Zachman’s concepts into valuable
projects and IT management and administrative
procedures.
One publically available set of Enterprise Architecture
Planning work products was developed by the UnitedStates Department of Defense and is viewable at the
C4ISR Architecture Working Group website.

(http://www.defenselink.mil/nii/org/cio/i3/AWG_Digital_
Library/index.htm).
The Architecture Framework report available at thissite is includes a list of deliverables that provide
immediate insight into the nature of the approach [5]. A
facsimile is provide below:
C4ISR Essential Deliverables by View
All Views
1. Overview and Summary Information: Scope, purpose,
intended users, environment depicted
2. Integrated Dictionary: Definitions of all terms used in
all products
Operational View
1. High-Level Operational Concept Graphic
2. Operational Node Connectivity Description
3. Operational Information Exchange Matrix
4. Activity Model(s) (supporting deliverable)
5. Logical Data Model (supporting deliverable)
System View
1. System Interface Description
2. Technical View
3. Technical Architecture Profile
Another interesting source of insight about how to
gainfully employ the Zachman Framework and EAP isrepresented in the article "Architecture for a Large
Healthcare Information System" [21].
This article
describes how the C4ISR Architecture Framework to wasused to create an organized operational architecture for the
60+ information subsystems that support the US Military
Health System.

2.3

Micro-Level Architecture: Software
Architecture

According to Steve McConnell, author of The
Software Project Survival Guide [18] and former Editor of
the IEEE, Software Journal, a good Software Architecture
document describes the following:
1. Overall program organization
2. Ways in which the architecture supports likely
changes
3. Components that can be reused from other systems orpurchased commercially
4. Design approaches to standard functional areas
5. How the architecture addresses each system
requirement
He also provides a Software Architecture Checklist(which is included as an addendum to this paper).
McConnell’s concerns are very similar in focus to thoseexpressed in the Software Engineering Institute’s“Architecture” related publications that I have reviewed

[6, 25, 27]. The concerns are clearly not about
Organizational Architecture nor are they about
Information Systems Architecture for application portfolio
planning purposes as in EAP. Rather, I refer toarchitecture from this perspective as Micro-Level because
it is clearly concerned with “IT System Specification” and“IT System Implementation” (to use Kilov’s terms). The
term “Micro-Level” is not meant to demean thisperspective but rather to simply distinguish it from theother, more abstract viewpoints. Also, I refer to this level
as Software Architecture but it is also concerned with
System Architecture (or more commonly System
Engineering) in that the efficacy of hardware and network
components of a computer system application are also
considered.
Effective execution of Micro-Level Architecture is
critical to the success of higher-level architecture
definition efforts. To aid this type of follow-through,
McConnell asserts that Architecture is a separable stageof the System Development Life Cycle and it should
begin when Requirements are approximately 80%
complete.
I can certainly see the value of thisrecommendation, because as an Architect on a large team(of very productive programmers) which does not use
such an SDLC, I am too often surprised that development
efforts have already committed serious architectural“short-cuts” that can not be corrected without missing
deadlines. It would be nice to consistently have theopportunity to provide input before its too late.
Lastly, a few of the guiding principles offered by
McConnell and others concerned with Software
Architecture are priceless. I have included some of themore practical suggestions here (and other moreentertaining observations as an addendum).
1. Architectures should be built with a purpose in mind
(This is not as self-evident as it sounds. A lot of
people seem to be of the impression that Architecture
efforts are not real projects and do not needobjectives and a scope. The RM-ODP EnterpriseViewpoint goes a long way toward establishing a
structured framework for assuring that objectives,
constraints and policies will be explicitly considered.)
2. Implementation of any architecture vision must be
staged (This should be self-evident, but it neverceases to amaze me, how many of my managers andcollueges seem to think that an “Architecture” issomething that we can define once for everything –like a type of magic that will simply make everything
better.)3. “The Best” is the enemy of “The Good” (I just likethis expression. It is best to plan on making
compromises rather than being disappointed that you

could not reach nirvana via the perfection of yourarchitecture.)
4. Don’t “throw in the kitchen sink” - (The bestarchitectures are simple and do not look as nasty as
the problems they were designed to solve.)
5. A good architecture limits the number ways in whichsoftware components may interface with each otherbecause software components alone, do not prevent
their own inappropriate use !
Finally, a few misconceptions that McConnell’s
definition of Architecture clearly debunks include: (1) the
idea that Architecture is just about data modeling, (2) the
idea that Data and Application Architecture can beseparated effectively (more about this later). See the first
addendum for a more comprehensive list of softwarearchitecture concerns.

3. Toward a More Specific Definition ofArchitecture
According to Haim Kilov, the definition of systemarchitecture is significantly different from the definition ofarchicture in general. In an Information Systems context,“we deal with systems that more often than not alreadyexist.” Whereas “with the definition from the Oxford
English Dictionary (OED), the term “architecture” applies
only to something created rather than to something that
already exists” [15]. I think this very aptly clarifies oneof the most often confused aspects of the role ofInformation Systems Architecture. It is not simply aboutdevelopment of new systems. It is also about interfacing
properly with existing systems and about enhancing andevolving existing systems in an orderly fashion.
According to the International Standards Organization(ISO) Reference Model for Open Distributed Processing(RM-ODP), a system architecture is “a set of rules todefine the structure of a system and the interrelationships
between its parts [12].” The RM-ODP definition iscorroborated by Mario Bunge: "Every system can beanalyzed into its composition (or set of parts),
environment (or set of objects other than the components
and related to these), structure (or set of relations, inparticular connections and actions, among the components
and these and environmental items) and mechanism (orset of processes peculiar to it, or that make it tick.)" [4].
One the most challenging aspects of Information
System Architecture and in fact of Information
Management in general, is that things change meaning
depending on their context. The challenge is concisely
illustrated by Kilov: “The characterization of a particularcomponent as “business,” “system,” or “technological” iscontext-dependent, so that, for example, a component
considered “technological” in a business context may beconsidered “business” in a technological context.” This
basically says that without careful attention to Viewpoints
or Contexts, and definition of synonyms and homonyms,
what would be an elegant Information Systems
Architecture can readily degenerate in to a “House of
Mirrors”.
The RM-ODP Defines Five View Points:
1. Enterprise
2. Information
3. Computational
4. Engineering
5. Technology
The RM-ODP Viewpoints provide a thorough array ofperspectives for facilitating abstraction and conceptual
layering.
This “House of Mirrors” effect combined with the factthat system architecture is not simply about new systems
are the two issues that get right to the heart of what is mostcommonly misunderstood (and consequently mismanaged) about Information Systems Architecture.
To further illustrate the challenge of architecting
systems that are equally useful in multiple contexts
consider the following two comments: (1) "The real
challenge is to design an architecture for a family of(software) products, covering not one but a range ofmarkets, with not just one product in each market but aseries of complementary, supplementary, enhanced andeventually replacement products, stretching into theforeseeable future [11].” (2) "…There is no such thing as
information in itself: every information flow rides onsome concrete (physical, chemical, biological or social)process. Consequently, the definition of the concept of an
information system presupposes, at the very least, theconcepts of system and process [3]."Bunge’s comment explains what make’s Hoare’s
challenge so challenging. In a word, information iscontext dependent and therein lies the challenge [2, 13, 15,30]. Just as Database Management Technology wascreated to battle the flood of Program Described Files thatplauged the infancy of the information age, so too abusiness domain must be defined precisely to genuinely
support the creation of information systems which enablebusiness process integration.
While the logic of this argument is sound, practicalchallenges face those who attempt it. Consider thefollowing story:“In 1984, (Ed Yourdon) consulted, during a two andone-half year period, on the practical application of RealTime Structured Analysis at a major aerospace company.

His observations were interesting and yet disturbing. One
team of analysts he studied (the “DFD Team”) started
their projects using data flow diagrams to develop an
overall functional decomposition as a framework forfurther specification.
Meanwhile, a second team ofanalysts (the “Data Base Team”) started by focusing on
the information the system needed to do its job and thenbuilding an information model (also known as an EntityRelationship Diagram or a Semantic Data Model). Overtime, the DFD Team continued to struggle with the basic
problem of space understanding (e.g., the details of what
happens when one controller hands off responsibility foran aircraft to another controller). In contrast, the Data
Base Team gained a strong, in-depth understanding of the
air traffic control. Yet the results did not mesh together;worse, they contradicted each other. In principle, these
two models should somehow come together. Yet under
the pressure of schedule and budget, both products moved
unresolved into preliminary design, with the hope ofresolving the discrepancies at that time. Sadly, the Data
Base Team was perceived as irksome, even somewhat astroublemakers; people (and their careers) paid the price forthis major rift and its untidy resolution.
In 1987 and 1988, (Ed Yourdon) saw this same patterndevelop on projects at a federal government agency and astate government agency. The DFD Team marched onahead in time and political power. The Data Base Teamgained tremendous insight, vital to analysis but all toooften ignored. And again, the Data Base Teams and theirleaders were perceived as troublemakers. Repeatedly, inpractice, separate notations and strategies for different
process and data models have kept the two forever apart.”[7].
In my own, professional experience I have seen thisnightmare played out again and again.
Coad andYourdon felt the answer was an Object-Oriented Analysis
methodology that integrated process and data model
notations. Kilov has defined a modeling and notation
methodology that achieves a greater degree of notation
uniformity (and conceptual integrity) than anything else I
have studied [15]. If the problem Coad and Yourdon soclearly illustrated can be solved with a notation method,
than our profession is certainly on the verge of resolving
this issue. However, by my estimate, I do not believe our
profession will heal the schism between the “DFD” crowd
and the “Data Base” crowd until we collectively learn tovastly improve our management practices and ourcollective level of professional knowledge. I can not help
but think that best practices frameworks such as the
SEI/CMMI and Luftman’s Strategic Alignment Model(SAM) [16] must be an integral part of the solution.
Another part of the solution must improved and morethorough undergraduate education for Information

Systems Professionals. I think a 5 year program as is parfor the course in Engineering and Architectural studies islong overdue. I also think a 3 year professional degree inInformation System similar to a Law degree or an MBA iswarranted. Furthermore, I am very much in favor of
informational systems professional licensure rather than
volutary certification. If this sounds harsh consider that
the Standish Group statistics also sound harsh. Maybe notquite as harsh as they did twenty years ago, but does
anyone think higher professional standards would worsen
those statistics?
Also, I cannot help but think that simply measuring ourown productivity and quality should come before, during
and after attempting to effectively change anything
significant about our culture and work processes [10, 23].
All of the architecture methods referenced in section
one of this paper have relatively loose definitions of theircomponents and component relationships. Kilov’s
semantic modeling techniques have great potential for
specifying and implementing the concepts of every typeof architecture presented in this paper.
Kilov’sphilosophy is strong in exactly those places where otherapproaches to architecture tend to be weak. The following
diagram is from the “Traceability” section of Kilov’s
Business Models text [15].

2.
3.
4.

Designer
Builder
Sub-Contractor

As such, these areas of concern are somewhat
analigous to view points as defined in the RM-ODP.
They are also somewhat analigous to the systemdevelopment life-cycle stages and the workflow streamsof the Rational Unified Process.
As the reader will recall the Zachman Framework is
particularly weak with respect to the relationships between
view points (rows) and domains (columns).
In hisdiscussion of Traceablity Kilov addresses this problem
with the following specification of the <<realization>>
relationships between each of his view points in the
diagram above.
Kilov's "Realization" Relationship Specification

Kilov's Information Management Project Structure

Figure 1: IM Project Structure
Richard Balicki aptly likens Kilov’s Information
System Components (or “areas of concern”) to
Zachman’s Design Roles.
Kilov’s Four Areas of Concern
1. Business Specification
2. Business Design
3. IT System Specification
4. IT System Implementation
5.
Zachman’s Design Roles
1. Planner and Owner

Figure 2: <<realization>> specification
I will resist the temptation to insert a full quotation of
Kilov’s explanation of the above two diagrams (andencourage the reader to read the book instead). Rather I
will simply point out what I find most significant about
these diagrams in light of the focus of this paper.
1. According to Kilov’s analysis of the structure of an
Information Systems Project, the activities that areoften vaugely referred to "architecture" of on kind or
another, Kilov more precisely refers to as Businessand System Specification and Design activities. This
directly addresses my primary concerns of (1) theneed to be clear about what we mean when we use
the term architecture and (2) the need to be clear

2.

3.

about deliverables of architecture activities. In
Kilov's analysis, the deliverables are I think very
appropriately described as specifications and designs.
According to Kilov’s analysis, the structure of theRealization relationship is that in each instance it iscomposed of a strategy, constraints and opportunities
and some appropriate combination of business,
technological and / or IT System components. The
significanct aspect of this from the perspective of ourcurrent Architecture discussion is that Kilov’s
definition is thorough and flexible enough to specify
the work-products and the relationships between thework-products of architecture at any level ofabstraction.
Kilov's Realization relationship isexactly what is missing from the Zachman
Framework and is therefore an invaluable
complement to it.
Kilov includes feedback and refinement in his
Realization specification because information systemarchitecture and specification is not strictly a “topdown” affair. Which speaks directly to one of theimportant and unique characteristics of systemarchitecture we discussed earlier – it is not only

concerned with creating new systems but is almost
always also concerned with integration with existing
systems [15].
One final thought about something interesting I recently
came across in my reading. In a real project organization
documented in the Project Management Journal [19],there are many teams that are “architecture” teams,
including the Data Architecture Team, the System
Architectre Team and the Software Architecture Team all on one project team. This is reflective of a thought I
have often had about what is required to consistently
attain high standards in all aspects of softwaredevelopment – good architecture is everyone’s job !

References
1.

Balicki, R., ”Synergizing Zachman’s Architecture Framework with Kilov’s Information Modeling”, Proceeding from the Ninth OOPSLA
Workshop on Behavioral Semantics, OPSLA 2000, Northeastern University, College of Computer Science, (October 15, 2000).

2.

Berners-Lee, T., Hendler, J., and Lassila, O., “The Semantic Web”, Scientific American Special Online Issue, Scientific American, (April,
2002).

3.

Bunge, M., (Reply to Mattessich on the Foundations of the Management and Information Sciences. In: Studies on Mario Bunge's Treatise.
(Ed. by Paul Wiengartner and Georg J. W. Dorn). Amsterdam-Atlanta, 1990, pp. 641-642.)4.

Bunge, M., Philosophy in Crisis, Prometheus Books, (January 2001).

5.

C4ISR, Architectures Working Group, C4ISR Architecture Framework, Version 2.0, United States of America, Department of Defense,(December 18, 1997).

6.

Clements, P. and Northrop, L., “Software Architecture: An Executive Overview”, Technical Report, CMU/SEI-96-TR-003, ESC-TR-96003, SEI Website, (February, 1996).

7.

Coad, P. and Yourdon, E., Object-Oriented Analysis, Yourdon Press Computing Series, Prentice-Hall, (1990).

8.

Drucker, P., The Practice of Management, Chapter 3: The Challenge to Management, Section: What is Automation?, Harper & Row,
(1954).

9.

GAO, United States General Accounting Office, “Information Technology Enterprise Architecture Use across the Federal Government Can
Be Improved”, A Report to Congressional Committes, US GAO, (February, 2002).

10. Goldenson, D., et. al., “Measurement and Analysis in Software Process Improvement”, Chapter 37 in IT Measurement, International
Function Point Users Group, Addison-Wesley, (2003).
11. Hoare, C. A. R., "Software: Barrier or Frontier", Oxford University Computing Laboratory (November 23, 1999).
12. International Standards Organization (ISO), Reference Model – Open Distributed Processing 2, Architecture, (1998).
13. Kent, W., Data and Reality, Elsevier Science Ltd; 5th repr. 1990 edition (January 1, 1984).
14. Kerns, D. and Nadler, D., Prophets in the Dark: How Xerox Reinvented Itself and Beat Back the Japanese, Harper Collins, (1992).
15. Kilov, H., Business Models: A Guide for Business and IT, Prentice-Hall, (2002).
16. Luftman, J., Managing the Information Technology Resource: Leadership in the Information Age, Prentice Hall; 1st edition (April 28,2003).
17. Martin, J., Information Engineering, Book II, Planning and Analysis, Prentice-Hall, (1990).
18. McConnell, S., The Software Project Survival Guide, Microsoft Press, (1998).
19. Metzger, J., “JWARS: A Case Study”, The Project Management Journal, Project Management Institute, Volume 34, Number 4, (December
2003).
, Prentice-Hall, (1999).
20. Morabito, J., Sack, I., and Bhate, A., Organizational Modeling: Innovative Architectures for the 21st Century
21. Mukherji, R., et. al., “Architecture for a Large Healthcare Information System”, IT Pro, IEEE Publications, November | December, (2002).
22. Nadler, D., et al, Organizational Architecture: Designs for Changing Organizations, Jossey Bass, (1992).
23. Putnam, L. and Myers, W., Five Core Metrics: The Intelligence Behind Successful Software Management, Dorset House, 2003.
24. Rood, M., “Enterprise Architecture: Definition, Content and Utlity”, document 0-8186-5705-7/94, IEEE (1994).
25. Shaw, M., and Clements, P., “A Field Guide to Boxology: Preliminary Classification of Architectural Styles for Software Systems”,
Software Engineering Institute, (April, 1996).
26. Software Engineering Institute (SEI), Process Maturity Profile, SW-CMM, (September, 2003).
27. Software Engineering Institute (SEI), ”Essays on Software Architecture”, SEI Website (www.sei.cmu.edu/architecture/essays.html), (2004).
28. Spewak, S., Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology, John Wiley & Sons,(September 1993).
29. Sprung, C., “Lesson Learned About Architecture:(www.sei.cmu.edu/architecture/essays.html), (2004).

Unstructured

andEclectic”,

retieved

from

the

SEI

website,30. Strong, D., Lee, Y., and Wang, R., “Data Quality in Context”, Communications of the ACM, vol. 40, no. 5, Association of Computing
Machinery, (May, 1997).
31. West, M., “Applying Systems Thinking to Process Improvement”, CrossTalk: Journal of Defense Software Engineering, United States ofAmerica, Department of Defense, March, 2004.
32. West, M., Real Process Improvement Using the CMMI, Auerbach Publishing, 2004.
33. Zachman, J., “A Framework for Information System Architecture”, IBM Systems Journal, vol. 26, no. 3, (1987). IBM Publication G3215298.