Book: Just Enough Software Architecture
This book reflects the author’s rare mix of deep knowledge of software architecture concepts and extensive industry experience as a developer. If you’re an architect, you will want the developers in your organization to read this book. If you’re a developer, do read it. The book is about architecture in real (not ideal) software projects. It describes a context that you recognize and then it shows you how to improve your design practice in that context.
This book is different from other books about software architecture. Here is what sets it apart:
It teaches risk-driven architecting. There is no need for meticulous designs when risks are small, nor any excuse for sloppy designs when risks threaten your success. Many high-profile Agile software proponents suggest that some up-front design can be helpful, and this book describes a way to do just enough architecture. It avoids the “one size fits all” process tar pit with advice on how to tune your architecture and design effort based on the risks you face. The rigor of most techniques can be adjusted, from quick-and-dirty to meticulous.
It democratizes architecture. You may have software architects at your organization — indeed, you may be one of them. Every architect I have met wishes that all developers understood architecture. They complain that developers do not understand why constraints exist and how seemingly small changes can affect a system’s properties. This book seeks to make architecture relevant to all software developers, not just architects.
It cultivates declarative knowledge. There is a difference between being able to hit a tennis ball and knowing why you are able to hit it, what psychologists refer to as procedural knowledge and declarative knowledge. If you are already an expert at designing and building systems then you will have employed many of the techniques found here. This book will make you more aware of what you have been doing and provide names for the concepts. That declarative knowledge will improve your ability to mentor novice developers.
It emphasizes the engineering. People who design and build software systems have to do many things, including dealing with schedules, resource commitments, and stakeholder needs. Many books on software architecture already cover software development processes and organizational structures. This book, in contrast, focuses on the technical parts of software development and deals with what the developers do to ensure the system works — its engineering. It shows you how to build models and analyze architectures so that you can make principled design tradeoffs. It describes the techniques software designers use to reason about medium to large sized problems and points out where you can learn specialized techniques in more detail.
It provides practical advice. This book offers a practical treatment of architecture. Software architecture is a kind of software design, but design decisions influence the architecture and vice versa. What the best developers do is drill into obstacles in detail, understand them, then pop up to relate the nature of those obstacles to the architecture as a whole. The approach in this book embraces this drill-down/pop-up behavior by describing models that have various levels of abstraction, from architecture to data structure design.
|Frontmatter: Table of Contents and Preface|
|Part I: Risk-Driven Software Architecture||8. The Domain Model|
|1. Introduction||9. The Design Model|
|2. Software Architecture||10. The Code Model|
|3. Risk-Driven Model||11. Encapsulation and Partitioning|
|4. Example: Home Media System||12. Model Elements|
|5. Modeling Advice||13. Model Relationships|
|Part II: Architecture Modeling||14. Architectural Styles|
|6. Engineers Use Models||15. Using Architecture Models|
|7. Conceptual Model of Software Architecture||16. Conclusion|
E-book and Hardback
- E-book: For download now. It includes three DRM-free versions of the book (ePub, Mobi, and PDF formats) for $19.50.
- Hardback: “For sale now at Amazon for $34.50.
- Searchable: Both Google Books and Amazon Search Inside have full text, searchable versions. Also see the three chapters above.
About this book
This book is divided into two parts. This first part introduces software architecture and the risk-driven approach. The second part helps you build up a mental conceptual model of software architecture and describes in detail the abstractions like components and connectors. What follows is short summaries of each part.
Part I: Risk-driven software architecture
A definition of software architecture is difficult to pin down precisely, but several things about it are quite clear. Software developers, like engineers in other specialties, use abstraction and models to solve large and complex problems. Software architecture acts as the skeleton of a system, influences quality attributes, is orthogonal to functionality, and uses constraints to influence a system’s properties. Architecture is most important when the solution space is small, the failure risks are high, or you face difficult quality attribute demands. You can choose from architecture-indifferent design, architecture-focused design, or even architecture hoisting.
Risks can be used to guide you regarding which design and architecture techniques you should use and regarding how much design and architecture you should do. At its core, the risk-driven model is simple: (1) identify and prioritize risks, (2) select and apply a set of techniques, and (3) evaluate risk reduction.
To reveal the risk-driven model in practice, Chapter 4 provides an example of applying the risk-driven model to a Home Media Player system. The developers on that system have the challenges of team communication, integration of COTS components, and ensuring metadata consistency.
The first part of the book concludes with advice on using models and software architecture, including: use models to solve problems, add constraints judiciously, focus on risks, and distribute architecture skills throughout your team.
Part II: Architecture modeling
The second part of the book helps you build a mental conceptual model of software architecture. It starts with the canonical model structure: the domain model, the design model, and the code model. The domain model corresponds to things in the real world, the design model is the design of the software you are building, and the code model corresponds to your source code. You can build additional models that show selected details, called views, and these views can be grouped into viewtypes.
Building encapsulation boundaries is a crucial skill in software architecture. Users of a component or module can often ignore how it works internally, freeing their minds to solve other hard problems. And the builders of an encapsulated component or module have the freedom to change the implementation without perturbing its users. Builders will only have that freedom if the encapsulation is effective, so you will learn techniques for ensuring that it is.
A great number of architectural abstractions and modeling techniques have been built up over the years. This book consolidates software architecture techniques found in a variety of other sources, integrating techniques emphasizing quality attributes as well as techniques emphasizing functionality. It also discusses pragmatic ways of building effective models and debugging them.
The second part of the book concludes with advice on how to use the models effectively. Any book that covered the advantages but not the pitfalls of a technology should not be trusted, so it also covers problems that you are likely to encounter. By the end of the second part, you should have built up a rich conceptual model of abstractions and relationships that will help you see software systems the way a coach sees a game.
The manuscript will be going to the printer at the end of July and available on Amazon by the end of August. There is now a page on Amazon for Just Enough Software Architecture.
If you are interested in the risk-centric approach to software architecture, you should take a look at the slides from the presentation. Presentation on Risk-Centric Model of Software Architecture from the joint IASA / Agile Denver meeting on 16 Nov 2009.
Updated 20 January 2012