Pages: pp. 100-102
Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives by Nick Rozanski and Eoin Woods, Addison-Wesley, 2005, ISBN 0-321-11229-6, 576 pp., US$49.99.
Software Systems Architecture is one of the more recent books on system design's most important consideration. As Frederick P. Brooks said, "it is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good independent and uncoordinated ideas." That is the software architect's role—giving a software system conceptual integrity.
This practitioner-oriented guide is the kind of book I would have liked to read when beginning my professional career. Filled with principles, practical strategies, checklists, and examples, it provides a comprehensive understanding of software architecture's role in software development projects.
The book's first half covers architecture fundamentals, emphasizing the importance of addressing project stakeholders' needs and concerns. Stakeholders should receive a tailored architectural description to facilitate communication. The description should include several interrelated views because no single model can completely describe a software architecture. Authors Nick Rozanski and Eoin Woods elaborate on Philippe Kruchten's "4+1" view model and propose their own views, which are complemented by crosscutting perspectives. Perspectives, orthogonal to viewpoints, help ensure that the system exhibits a particular set of quality properties.
The book also deals with architecture definition's main activities. Fortunately, it doesn't advocate yet another software development method. It just tackles important issues such as system scoping, identifying and engaging stakeholders, and documenting and evaluating software architectures. These chapters share effective use guidelines for functional and system quality scenarios. The authors also introduce different architectural styles (such as multitiered or pipes-and-filters architectures) and scenario-based architectural evaluation methods (such as the Software Architecture Analysis Method or the Architecture Trade-off Analysis Method).
The book's second half features two catalogs:
It's not hard to see that Software Systems Architecture is an outstanding book. It's difficult to pack so much practical information in a single volume, but Rozanski and Woods have succeeded in doing so. Their book ties together many available SEI books, particularly Software Architecture in Practice, Second Edition (Len Bass, Paul Clements, and Rick Kazman, Addison-Wesley, 2003), Documenting Software Architectures: Views and Beyond (Paul Clements et al., Addison-Wesley, 2002), and Evaluating Software Architectures: Methods and Case Studies (Paul Clements, Rick Kazman, and Mark Klein, Addison-Wesley, 2002). It also makes software architecture's role easy to understand by looking beyond particular design techniques and practices. In short, Software Systems Architecture is a thorough survey of software architecture and the value it adds to software development projects.
Competitive Engineering by Tom Gilb, Addison-Wesley, 2005, ISBN 0-321-11229-6, 576 pp., US$49.99.
In almost three decades of software development, I have used many of the structured, object-oriented, and agile methodologies that have appeared. Results from these experiences gradually improved but were ultimately limited. Over the past decade, however, Tom Gilb's methods have matured, helping increase success and finding publication in Competitive Engineering.
Competitive Engineering is concerned with the key software engineering tasks and concepts that most determine project outcome. So you think you know what requirements are? Tom Gilb's book will definitely make you think again. How do you know if your design is any good or if your process is improving? Is your project really progressing, and what should you do next? Gilb's book will help you answer these questions.
If you accept the maxim that "you can't manage what you can't measure," then competitive engineering defines a unified methodology for managing the software engineering process in measurable terms. It demands serious thought about what other methodologies frequently take for granted or gloss over.
Gilb describes his competitive engineering approach using Planguage ( plan merged with language), a "specification language and a set of related methods for systems engineering." Planguage applies true engineering concepts and practices to software development (although I've also used it in other types of projects). It consists of requirements specification, impact estimation, specification quality control (also called inspection), and evolutionary project management.
Planguage methods are fueled by requirements that are specified in quantifiable terms, particularly (but not exclusively) performance and resource requirements. The strict emphasis on quantification is hardly surprising from the man who coined the term software metrics.
Gilb makes fundamental and far-reaching statements about requirements. Most methodologies concentrate exclusively on functional requirements and only briefly discuss so-called "nonfunctional requirements." Gilb argues that, in real-world situations, the latter are usually most important. In fact, he never uses the term nonfunctional. Competitive Engineering provides a complete method to specify performance and other types of requirements and shows how to incorporate them seamlessly into the software engineering process. Indeed, Planguage is, among other things, a requirements-driven management process.
Planguage communicates numerous key concepts in a consistent, comprehensive methodology. Languages limit or enable our thinking, and Planguage is no different. Just as you might think in English (or Spanish, German, or Dutch), Planguage makes you think in engineering terms. With experience, you'll begin to think in Planguage, and you'll find yourself translating into natural language for others.
For example, other methodologies lack the vocabulary and methods to specify performance requirements properly, so many people don't think deeply enough about these. The lack of an adequate language might even be the reason why design is so often confused with functional requirements (Planguage's function requirements) in the first place; other methodologies can't clearly distinguish between the two.
This is a typical challenge that Gilb meets head-on. Competitive Engineering addresses difficult software engineering problems that other methodologies don't even recognize. This is important, groundbreaking stuff.
In other methodologies, you can ask "what?" and "how?" In Planguage, you can also ask "why?" and specify the answers. If nothing else, its requirements specification method will force you to know why your projects exist. You can't do this easily in other methodologies.
See what answers you get when you ask yourself "why?" Then have a go using Planguage—you'll get more meaningful answers in quantifiable terms.
Gilb insists on specific and consistent use of terms to avoid ambiguity. To get a feel for what Planguage addresses, scan the glossary—one-third of the book, containing 180 key concepts underpinning the Planguage process. Investigate the entry on "Requirements," for example, or study the amazingly profound diagram (page 53) that defines the relationship between system attributes and system requirements. When you understand how all the big concepts fit together, you'll begin to understand the book.
The Plan-Do-Study-Act continuous process improvement cycle dominates the book's material. It seems so natural, you'll wonder why practitioners ever did software development otherwise.
Gilb explains the relationship between requirements and design better than any other author. Design engineering lets you compare alternative designs by quantifying their impacts on specified requirements. Among its many uses, its versatile Impact Estimation method cleverly demonstrates the dynamic nature of prioritizing—through cost benefit analysis or "the relative claim [of requirements] on limited resources," it solves the question of what to do next or whether to stop a project altogether. It has practical strategies to manage risk and built-in methods for dealing with it quantifiably.
Each chapter offers rules, processes, principles, and examples. The book doesn't contain any padding but is dense with ideas and concepts. No wonder Gilb advises you to slow down to understand it.
Competitive engineering offers different things to different people. It can be a project management, monitoring, and control process; a requirements specification and management process; or a design engineering process. But at all times, it's a process improvement process.
I've heard information technology leaders publicly state that they don't believe in software engineering or that they've never seen any evidence of "engineering" in software development. But Planguage's methods prove software engineering's existence and also show that it has finally come of age. For this reason and many others, Competitive Engineering is a masterpiece.
Server Architectures by Rene J. Chevance, Idea Group, 2005, ISBN 1-59140-427-4, 413 pp., US$69.95.
To build proper and adaptable architecture, architects must know about all available choices. It's no longer acceptable to simply choose the type of operating system you see fit—an overall architecture requires knowledge and expertise in all aspects of technology. Rene Chevance's Server Architectures should be required reading for any architect who must choose daily the correct technology to solve a problem. I explicitly mean choosing the technology or product for the problem at hand, not choosing the product first and then trying to figure out what problems it solves. Chances are you need more than one vendor to solve the different problems facing your enterprise. For one project, you might need a 64-bit processor's power regardless of the cost, but for another project, a Pentium-4 will do the trick.
The book's numerous topics include
In part 2, Chevance discusses the system-level view. Various options for system architecture are symmetric multiprocessor systems, massively parallel processor systems, grids, high-performance computing options, cluster computing, and mainframe architecture.
In addition to extensively describing each system architecture, Chevance also details why and under what circumstances you would choose one over another. The book describes each option's scalability, reliability, availability, and cost. The author also discusses these systems' top contenders, including the Tandem/HP Guardian system (nonStop), IBM Sysplex architecture, and SGI Altix.
Next, the book discusses networking and communication technologies in detail. Storage and database systems are growing fast, and according to the book's research data, will only grow and expand further. The second half of the book focuses on storage technology and database systems. It showcases many top database vendors and their products, including the Oracle Real Application Cluster and IBM DB2 UDB Enterprise.
Server Architectures is the most comprehensive system architecture book I've ever read. It covers everything from microprocessors to database management software and architecture. And because the topics are broken down in sections, readers can pick and choose specific topics, making the book more useful.