The
Architect & the Architectural Engineer, two
different Roles
Author
: Jaap Schekkerman, B.Sc.
1 Table of Content 2
2 Introduction. 3
3 The Architect 4
3.1 Are
Enterprise Architects Like Building Architects?. 4
3.2 The
History of Architects.
5
3.3 What
is architectural engineering?. 5
3.4 Summary. 6
4.1 References. 8
This paper describes the
role of an architect from an historical perspective,
addressing the change in roles in the building architecture
between architects and architectural engineers.
Today this change in roles between architects and
architectural engineers can also be transposed to
the world of business and IT architecture. Identifying
these two different types of roles can be helpful
in positioning and organizing the architecture activities
and processes.
Michelangelo was an architect. Throughout human
history, architects have ranged from learned men
revered by royalty, to anonymous craftsmen rising
through the ranks of guilds. Both have built castles,
cathedrals, and chateaux. Until the last century,
there were no schools of architecture, no building
codes, etc. There were no ready-made building materials
to purchase structures. Anyone could hang out a
shingle as an architect, and did.
The transformation
of civilization in the industrial revolution expanded
the types of buildings needed: Railroad stations,
offices, and factories, to name a few. Manufactured
building materials allowed more diverse structures
and technological improvements in electrical, heating
and plumbing demanded greater complexity, safety
and precision in building design.
The era of "bigness" was emerging. Businesses were acquiring
the infrastructure needed to become the behemoths
of the 1900’s. These enterprises required large
specialized spaces and desired a fitting edifice
suited to their image and aspirations. The nouveau
riche emerged in large numbers, swelling the demand
for aesthetically endowed custom homes.
There is a compelling analogy between building and system construction.
It is not new, but it has never taken root and bloomed.
The analogy is not just convenient or superficial.
It is truly profound. It not only raises the right
questions, it has the answer to what has been called
"The Software Crisis."
Enterprise architecture is now at a point identical to where building
architecture was in the mid 1800’s as it faced the
inventive momentum of the industrial revolution.
Now, as then, people with very different skills
and roles can - and do - call themselves architects.
Today, they refer to themselves as Enterprise architects,
information (IT) architects or software architects
despite training as engineers, system analysts or
programmers, not architects. However, it is no longer
adequate for a software craftsman or engineer with
a flair for design to build the huge, complex infrastructures
of the information revolution [WWISA 99].
IT systems are being built in a manner akin to build an office building
without an architect and without clear roles. It
is as though a collection of specialists is brought
together, many with degrees in "Building Science."
They all have their favorite tools and materials
and plan to use them wherever they go. Some are
in charge of bathrooms; there is an office designer
and carpenter. An electrician is hired and sometimes
functions as an engineer, designer, and even a plumber.
Problems in
function and layout become evident as construction
continues. Some of the tools are inadequate for
the scope of the job. There are stairways leading
to nowhere; dead space; bad lighting. Subcontractors
are waiting for others to finish their work before
they can proceed. The building looks and feels unappealing
to the users. No number of change requests, money,
or rolling deadlines can fix this building, which
just doesn't "work." Style? Aesthetics?
It’s very difficult to be artistic in a crisis.
3.1
Are
Enterprise Architects Like Building Architects?
For the past several years, IFEAD has
successfully used its Enterprise Architecture Methods
to design Enterprise architectures. Why should we
care about enterprise architectural design? We should
care because an Enterprise architecture is not the
same as the IT systems themselves, and a great looking
"building" might be impossible to build!
The intent of architectural design study is to detect
as early as possible whether we are dealing with
an illusion or a feasible design. However, architectural
design is no panacea even if the architecture passes
the design hurdle, the implementation might not
be adequate, or the organization has not the right
capabilities! Positive results are only a temporary
"go ahead," and every result must be confirmed
by measurements or more detailed design at a later
phase of the architecture process cycle. Can we
make the complementary statement? That is, if an
architecture does not pass the hurdle, no amount
of hacking will compensate for the deficiency. Inevitably,
the focus on architectural design leads us to view
the IT engineer as a kind of architect of an IT
system.
In this chapter, I want to suggest and show
the reader that this analogy may not be entirely
accurate, and that there are different roles in
an architecture team. A more precise analogy may
be available to us in the emerging field of architectural
engineering for the roles of IT architects [Barbacci 98].
It is common for IT engineers to
mention building architecture as a model to follow,
often using Gothic cathedrals as examples! But as
Bass, Clements, and Kazman point out [Bass
98], "Analogies between buildings and IT
systems should not be taken literally; they break
down fairly quickly. Rather, such analogies help
us understand that the viewer’s
perspective is important and that structure
can have different meanings depending upon the motivation
for examining it."
The analogy
is not entirely without merit. In both cases, multiple
stakeholders care about the architecture of the
"building." The
stakeholders (e.g., buyers/sellers, users/producers,
builders/maintainers) care about fitness along multiple
dimensions (e.g., size, maintainability, strength)
and uses (e.g., new and legacy systems, one of a
kind, and product lines) throughout the life cycle
[Theory W].
But the analogy works only at a superficial level,
because we tend to idealize building architectures
and the role of the building architect, there is
a lot more engineering in modern buildings than
architecture purists might care to admit. Perhaps
we would do better to model the role of an IT architect
on an emerging profession that bridges the two camps
of architecture and engineering.
Circa 25 BCE,
Vitruvius described the role of an architect as:
The ideal
architect should be a man of letters,
a mathematician, familiar with historical studies,
a diligent of philosophy, acquainted with music,
not ignorant of medicine, learned in the responses
of jurisconsultis, familiar
with astronomy and
astronomical calculations.
The characteristics that distinguish a work
of architecture from other man-made structures are
(1) the suitability
of the work to use by human beings in general
and the adaptability of it to particular human activities; (2) the stability and permanence of the work's construction; and (3) the communication of experience and ideas through
its form.
All these conditions must be met in architecture. The second is a
constant, while the first and third vary in relative
importance according to the social function of buildings.
If the function is chiefly utilitarian, as in a
factory, communication is of less importance. If
the function is chiefly expressive, as in a monumental
tomb, utility is a minor concern. In some buildings,
such as churches and city halls, utility and communication
may be of equal importance.
The three characteristics are described by Vitruvious
in firmitas, utilitas, and venustas (i.e.,
structural stability, appropriate spacial accommodation,
and attractive appearance), although the relative
order of the terms (and by implication, which of
these characteristics has a primary or supporting
role) varies according to the function. (Although
this might seem obvious today, the ordering was
a matter of controversy for several centuries as
different theories of architecture were proposed
in which any of these three characteristics had
an absolute priority over the others.)
Barbacci [Barbacci
98] describes; traditionally, the architect
was a master in control of all functional, structural,
and aesthetic decisions; the method of construction;
and the supervision of the building process. This
tradition survived until the 19th century, where
the complexity of the application of structural
steel forced architects to collaborate with steel
experts (civil engineers). The primacy of the architect
was further eroded in the 20th century by the growth
in complexity of building environmental systems
(e.g., passenger elevators); architects now had
to collaborate with mechanical and electrical engineers
as well. Engineers in these disciplines were experts
in their subject matter but not on buildings and
could not assume the role of the architect. The
need for people whose professional focus was on
the design of buildings but whose education as engineers
allowed them to master the technologies and materials
in structural, mechanical, and electrical systems
led to the emergence of architectural engineering as a new profession.
3.3
What
is architectural engineering?
Architectural
engineering is the application of engineering principles
to the design of technical systems of buildings.
The profession of architectural engineering includes
practicing engineers designing, managing, and constructing
mechanical, electrical, or structural systems for
buildings. The profession also includes engineers
educated as mechanical, electrical, or civil engineers
who practice the application of engineering principles
to the design of building systems. Some of the great
architectural engineers of past and present are
Gustave Eiffel, Buckminster Fuller, Ove Arup, and
Santiago Calatrava. [NSAE]
Belcher [Belcher
96] characterizes architecture and engineering
as "two dissimilar disciplines, which must
work together due to the vast array of aesthetic
and technical needs of a complex modern building."
The dissimilarity stems from the motivations and
training of traditional architects and engineers.
Architects are trained
to think top down, to synthesize a global solution,
which may be later refined or abandoned in light
of emerging information.
Engineers are trained
to analyze available data and to solve problems
bottom up, following a more systematic process toward
a single, "best" solution.
Belcher writes, Architectural engineers, however,
receive training in both analysis and synthesis.
They take courses in the theory and practice of
aesthetic design side by side with students of architecture;
they take courses in calculus, physics, and material
sciences right along with students in traditional
engineering fields. Thus they understand the creative
process and are able to use that mode of thinking
when appropriate. They are also taught to analyze,
so they know the importance of that mode of thinking
and when to use it.
Finally, architects do not think of themselves as
engineers.
It might be misleading to say that
an IT architect is like a building architect. The
IT architect is more likely to be trained in an
engineering or science school and is usually familiar
with one or more of the technologies (e.g., security,
communications, storage, operating systems) used
to build the system. Chances are when she came from
one of these fields before being promoted to IT
architect and she could change places with technology/domain
experts on a different project. This is different
from traditional building architects who come from
different schools and have different training than
say, steel/concrete/heat, ventilation, and air conditioning
engineers.
Is architectural engineering and the motivation and training of an
architectural engineer a better analogy most of
the time for IT architecture and the activities
of an IT architect?
So do we have architectural engineers and architects, where the latest
are the people who can lead and abstract these complex
architecture projects?
3.5
References
[ATAM
98] R. Kazman, M. Klein, M. Barbacci, T. Longstaff,
H. Lipson, J. Carriere, “The Architecture Tradeoff
Analysis Method”, Carnegie Mellon University, CMU/SEI-98-TR-008,
1998.
[Barbacci 98] Mario R. Barbacci , “The Architect” . Volume
1 . Issue 2 . September 1998.
[Bass
98] L.;
Clements, P.; & Kazman, R. “Software Architecture
in Practice”. Reading, MA: Addisson-Wesley Publishing
Company, 1998.
[Belcher 96] M. Clay Belcher, University of Kansas, “What
is Architectural Engineering?” 1996.
[Theory W ] B. Boehm and R. Ross, “Theory
W Software Project Management: Principles and Examples,”
IEEE Trans. Software Eng.,1989.
[NSAE] National Society of Architectural
Engineers, USA.
[WWISA 99] World Wide Institute of Software
Architects, 2774 North Cobb Parkway, Suite 109-211,
Kennesaw, Georgia 30152, USA.
