A transformational guide to the profession of software architecture.
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 visiona planthat 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:
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.
1. Simple Analogy.
The Perfect Analogy. Finally, a Cognitive Map. The Analogy Reveals the Missing Ingredient Architecture. The Analogy Confers Clarity of Role and Purpose. It All Begins with a Client and an Architect. With the Analogy, Words Are Meaningful. With the Analogy, Processes Are Predictable. The Analogy Brings Order to Complexity and Flexibility. Conclusion.
The Paradox of the Software Industry. The March of the Notorious. The Federal Aviation Administration. Internal Revenue Service Tax System Modernization (TSM). Conclusion.
Technology: The Common Thread of Architecture. Many Definitions of the Indefinable. Utilitas, Venustas, Firmitas. The Mystery of Design. The Lesson of St. Peter's: Harmony and Unity. The Quality Without a Name. Conclusion.
The Greek Ideal. Architects: Anonymous Craftsmen and Superstars. Modern Architecture: Rise and Demise. The Architect as Social Philosopher. Architecture and the Third Wave. Conclusion.
Architect, Builder, Engineer, Scientist. Guiding Principles. Software Architects Decide How the Structure Will Look and Act. Software Engineers Make the Structure Sound. Developers Build the Structure. Computer Scientists Further Knowledge. The Role of the Client. Defining, Not Limiting. An Indelicate, but Trenchant, Illustration of the Roles of Construction. Conclusion.
The Role of the Architect Begins with the Client. The Architect as Client Advocate and Design Champion. The Art of Listening. The Art of Observation. The Art of Strategy. The Pyramid in Paris. Conclusion.
Two Overall Phases. Architectural Phases, with Caveats. The Design Is Not the Deliverable. Caution: These Design Phases Are Not Linear. The Building Phases. Conclusion: The Party Phase.
The Characteristics of an Architectural Plan. Good Architects, Good Plans. Why Have Plans at All? The Levels of the Plan. Conclusion.
Second Wave Education, Third Wave Needs. Still Another Crisis. We Are What We Do. What Is the Profile of a Computer Scientist? Architecture Education. Establishing Software Architecture Education. Can Design Be Taught? Conclusion.
What Is a Profession? Client Expectations. A Standard Body of Knowledge. Education. Identity. A Code of Ethics and Standards. Where to Begin.
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 experiencehindering 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 constructionthe history, roles, and processesfrom 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 transformationnot 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