NEWS AT SEI
This library item is related to the following area(s) of work:Software Architecture
This article was originally published in News at SEI on: September 1, 1998
Welcome to The Architect. The purpose of this column is to discuss software architecture and software architecture analysis. We will emphasize practical results that can be used by practicing software designers, developers, and other stakeholders involved in developing the architecture of software systems.
We will feature opinion pieces by SEI staff and guests, techniques, case studies, announcements, etc. Future articles will highlight emerging techniques for architecture analysis developed by the SEI (Software Architecture Analysis Method, Architecture Tradeoff Analysis Method) and their application to systems developed by SEI customers as well as techniques developed by other organizations.
Mario R. Barbacci
For the past several years, the SEI has successfully used its Software Architecture Analysis Method to evaluate software architectures. Why should we care about software architecture analysis? We should care because a software system architecture is not the same as the software system, and a great looking "building" might be impossible to build! The intent of architecture analysis is to detect as early as possible whether we are dealing with an illusion or a feasible design. However, architecture analysis is no panacea—even if the architecture passes the analysis hurdle, the implementation might not be adequate! Positive results are only a temporary "go ahead," and every result must be confirmed by measurements or more detailed analyses at a later phase of the life 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 architecture analysis leads us to view the software engineer as a kind of architect of a software system. In this column, I want to suggest that this analogy may not be entirely accurate, and that there may be a more precise analogy available to us in the emerging field of architectural engineering.
Webster’s [Webster] defines "architect" and "architecture" thus:
Architect: 1: a person who designs buildings and advises in their construction. 2: a person who designs and guides a plan or undertaking.
Architecture: 1: the art or science of building; specifically: the art or practice of designing and building structures and especially habitable ones. 2a: formation or construction as or as if the result of conscious act <the architecture of the garden>. b: a unifying or coherent form or structure <the novel lacks architecture>. 3: architectural product or work. 4: a method or style of building. 5: the manner in which the components of a computer or computer system are organized and integrated.
Although the emphasis is on "buildings" and "habitable structures," the software engineering community has adopted the terms and attempted to adapt the definitions to software systems. Consensus definitions are still emerging, but we seem to be comfortable with the terms and use them frequently. We do this in part because architects of buildings have been "architecting" for a very long time and buildings tend to stay up--obviously, they must be doing something right.
It is common for software 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], "Analogies between buildings and software 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. 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 a software architect on an emerging profession that bridges the two camps of architecture and engineering. But first, let’s take a short detour on the origin of the problem.
The Encyclopedia Britannica [EB] provides a wealth of material on the topic of architecture, and it is interesting to read the articles under the topic "The Art of Architecture."
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 derived from Vitruvious' s 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.)
But M. C. Belcher points out [Belcher] that the role of the architect is more ambiguous. 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.
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]
This definition is taken from the National Society of Architectural Engineers (NSAE). This is a young profession -- the NSAE was incorporated only in 1984 and at present there are fewer than 20 accredited architectural engineering programs in the U.S. Nevertheless, things are moving fast in the new profession and, on October 1st, the NSAE will merge with the Architectural Engineering (AE) Division of the American Society of Civil Engineers (ASCE) to form the Architectural Engineering Institute (AEI). (It is an odd feeling to learn of a profession younger than ours--the ACM and the IEEE Computer Society are both over 50 years old! )
Belcher [Belcher] 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. The American Institute of Architects offers career advice to architects and includes suggestions for architects that might be considering a change:
Sometimes interests and experience lead architects beyond the conventionally defined edges of the profession into other professions and occupations. The aim may be to "function as an architect in the [fill in the blank] field" or to shift disciplines more completely. Very often, a shift in career requires additional education or training, new credentials, or professional registration or certification. While there are no limitations on where or how far an architect may migrate from the field, some migration paths are more common and clearly marked than others.
One of the more common and clearly marked paths? Go back to school and become an engineer!
The design of buildings often requires the special expertise of civil, structural, mechanical, and electrical engineers. The options for engineers are many, and there is considerable demand for them in industry--from corporate clients and manufacturers of building products--as well as in private practice. Engineers offering design services for building projects typically practice as independent consultants in one of the areas listed or as a specialty engineer (e.g., acoustical, illumination, fire protection). Some engineering firms combine two or more of these areas; some offer architecture, construction management, or design/build services as well.
It might be misleading to say that a software architect is like a building architect. The software 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 she came from one of these fields before being promoted to software 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 for software architecture and the activities of a software architect?
Mario Barbacci is a senior member of the technical staff at the SEI. He was one of the founders of the SEI, where he has served in several technical and managerial positions, including project leader (Distributed Systems), program director (Real-Time Distributed Systems, Product Attribute Engineering), and associate director (Technology Exploration Department). Before coming to the SEI, he was a member of the faculty in the School of Computer Science at Carnegie Mellon.
Barbacci is a fellow of the Institute of Electrical and Electronic Engineers (IEEE), a member of the Association for Computing Machinery (ACM), and a member of Sigma Xi. He was the founding chairman of the International Federation for Information Processing (IFIP) Working Group 10.2 (Computer Descriptions and Tools) and has served as vice president for Technical Activities of the IEEE Computer Society and chair of the Joint IEEE Computer Society/ACM Steering Committee for the Establishment of Software Engineering as a Profession. He was the 1996 president of the IEEE Computer Society. He is the 1998-1999 IEEE Division V Director.
Barbacci is the recipient of several IEEE Computer Society Outstanding Contribution Certificates, the ACM Recognition of Service Award, and the IFIP Silver Core Award. Barbacci received bachelor's and engineer's degrees in electrical engineering from the Universidad Nacional de Ingenieria, Lima, Peru, and a doctorate in computer science from Carnegie Mellon.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.