The Software Architect's Profession: An
Introduction
Authors: Marc Sewell and Laura Sewell
ISBN: 0-1306079-6-7
Publisher: Prentice Hall
Pub.
Date: September 2001
Format: Paperback, 0.17" x 8.56" x 5.60",
144pp
Abstract:
Whether a structure is built of bricks, steel, or
computer code, the process begins with an architect and client. Together they
arrive at a shared vision—a plan—that the architect guides through the bidding,
construction, and implementation phases. The Parthenon and the Empire State
Building were built according to architectural designs, but the software
industry has been building information skyscrapers without architects. It is
time for the profession to become a reality. Successful software-based
technology is designed, then built. It does not "develop." Who creates the
design? An enormous grass-roots demand exists for software architects-but a true
profession of software architecture is not yet established. Many software
professionals adopt the gravitas of the title "software architect," but fail to
fulfill the true, classical role. Drawing on deep metaphors from traditional
architecture, Marc T. Sewell, President of the Worldwide Institute of Software
Architects, and Laura M. Sewell examine the nature of architecture, what defines
a software architect, and how the profession is coming of age. The Software
Architect's Profession is lingo-free. It is a book of philosophy that will
enable anyone to understand software construction, and it is the first "line in
the sand" defining the parameters of this fledgling, yet ancient, e-profession.
Key areas include:
- Bridging the chasm that separates clients from technical professionals
- Differentiating the professions within the software construction industry
and defining the roles and accountabilities of software engineers and software
"builders"
- Discussing the vocational temperament and aptitudes that characterize
architects
- Reviewing the phases of architecture
- >Describing the critical role of the client in understanding and
validating the design and construction of software
Whether you are a CIO, CEO, IT manager, software professional, or student,
you inhabit software structures, and your world is profoundly affected by their
design. The Software Architect's Profession offers a simple cognitive map that
will change your world view of software architecture, construction, and the
information structures we live and work in everyday.
Excerpted from The Software
Architect's Profession: An Introduction by Marc T. Sewell, Laura M. Sewell.
Copyright © 2001. Reprinted by permission. All rights
reserved.
Table of Contents:

- click image to enlarge
-
Forward:
Andrea Palladio is one of the
most influential architects of all times. His seminal work – The Four Books of
Architecture, published in Venice in 1570 – had an immediate and profound
influence upon Renaissance construction. Palladio’s genius lay in his ability to
distill the essence of Roman architectural principles, build upon them to
establish a broad vocabulary for the entire domain of architecture, and then
articulate a set of pragmatic rules to aid the architect in creating functional
yet beautiful structures. As Palladio noted, “Three things…ought to be
considered in every fabric, without which no edifice will deserve to be
commended; and these are utility or convenience, strength, and beauty.” Palladio
was passionate about his profession, and through his writings was able to share
that passion.
Marc and Laura are equally passionate about the emerging profession of the
software architect. In this book, they share their deep experience in the
pragmatics of that trade. With clear parallels to the history of civil
engineering, from Imhotep to Le Corbusier, from I. M. Pei to Christopher
Alexander, the authors offer a clear statement as to what the role of the
software architect is, what it is not, and what it can be.
Software is the ultimate building material, infinitely malleable and
incapable of wearing out. Economic forces lead us to build systems of increasing
complexity and thus, because of our fundamental human limitations in coping with
complexity, we abstract. The history of software engineering is, therefore, the
history of abstraction. In the drive to higher levels of abstraction, functional
decomposition was superseded by object-oriented design. Next, design patterns
surfaced, giving the development team a vocabulary sufficient to talk about the
mechanisms formed by societies of objects. Beyond design patterns lay
architectural frameworks, representing common, significant design decisions that
shape the structure and behavior of entire systems. Indeed, the presence (or
absence) of a strong architectural vision is a key predictor in the success (or
failure) of a complex system. As such, the importance of the role of the
software architect has grown. This trade is in its fledgling state, but in this
book, Marc and Laura establish it as a true profession, something that can be
learned and that is worth of pursuit in and of itself.
If you are already a software architect, this book will give you a broader
perspective that will help you become more effective in your role. If you aspire
to become a software architect, then this book will help you in your journey by
explaining the meaning of architecture, the process of architectural design, and
the pragmatics of the profession, from ethical considerations to deep technical
activities.
As software professionals, we seek to build useful things that work, using a
process that is both efficient and economical. The software architect has the
demanding yet incredibly rewarding opportunity to lead the construction of such
systems. Thus, at its best, just as Palladio notes, the software architect can
craft beautiful systems.
May you also go on to build beautiful software.
Grady Booch
IBM Fellow
Preface:
It's
fun to be on the right side of a transformation. Being on the wrong side is
frustrating, because nothing ever seems to fit. Some people make it through the
change, others don't. To do so requires a shift in the way we see, an alteration
of what psychologists call our mental set. That is the purpose of this book: To
change the way people see software design and construction, supplying the reader
with a new cognitive map.
This is not a technical book--on purpose. We present the case that there is a
perfect analogy between constructing a building and constructing software and
that this analogy is the tool for making the transformation. If we delved deeply
into the familiar terms and practices of software design and construction,
readers with technical backgrounds would be pulled down by the thick layer of
associations and habits they have built up in their minds from
experience—hindering change.
Instead, we talk largely about building architecture and construction,
bringing the subject back to the software industry to illustrate the truisms of
the analogy. We hope the reader is able to really see architecture and
construction—the history, roles, and processes—from a fresh perspective, not in
the light cast from their software experience. Seeing architecture and
construction in their classical forms creates a separate template in the mind,
one that can then be superimposed on the familiar milieu of software
construction. In this way, the transformation can take place and we can build
software predictably and reliably.
The analogy is the tool that makes things fit. Don't be fooled by its seeming
simplicity. Simplicity does not equate with superficiality, and something does
not have to be impossibly confusing to be profound. Buildings are highly complex
and their construction difficult, but everyone understands how they get built
and the roles of those involved. That clarity of role and process is what is
missing from software construction. Bringing the clarity to the software
industry is what the transformation is about.
This book is written for a broad audience of technical and nontechnical
people alike. It can be understood by anyone and would be helpful to clients of
software projects, software professionals, students, and interested inhabitants
of software systems. Clients are especially important because they are driving
this transformation—not academia or software professionals.
In the 1990s, clients and employers began to use an architectural approach to
software construction. They bestowed the new title of architect on software
professionals, wrote their job descriptions, and established architecture
departments.
Even those clients and employers not in sync with the analogy saw a need for
the architectural role. They created the title CTO and assigned this person the
guardianship of the technology, enterprise architecture, and software strategy.
They only erred with the title. This person is fulfilling the role of chief
architect.
The clients have a natural, intuitive understanding of the analogy. It gives
them a mental image needed to understand and manage software construction and,
simply stated, it just seems right to them to design something first and then
carefully build it under the supervision of the guardian of the design.
We hope this book will, in its small way, give the reader insights into
architecture along with a tool for thinking in a new way.
Marc and Laura Sewell
marcandlaura@wwisa.org