Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives
- By Nick Rozanski, Eóin Woods, Eóin Woods
- Published Apr 20, 2005 by Addison-Wesley Professional.
Book
- Sorry, this book is no longer in print.
Also available in other formats.
Register your product to gain access to bonus material or receive a coupon.
About
Features
An essential guide for software architects; explains key things they need to know and how to make their architectural designs successful.
° A thorough handbook for software architects that builds upon legacies of best practice
° A highly practical, practitioner-oriented guide that explains how to design and implement solid architectures
° Improves an organization's chance for software success by clearly defining the boundaries between requirements, architecture, and design
Description
- Copyright 2005
- Edition: 1st
- Book
- ISBN-10: 0-321-11229-6
- ISBN-13: 978-0-321-11229-3
Software Systems Architecture is a practitioner-oriented guide to designing and implementing effective architectures for information systems. It is both a readily accessible introduction to software architecture and an invaluable handbook of well-established best practices. It shows why the role of the architect is central to any successful information-systems development project, and, by presenting a set of architectural viewpoints and perspectives, provides specific direction for improving your own and your organization's approach to software systems architecture.
With this book you will learn how to
- Design an architecture that reflects and balances the different needs of its stakeholders
- Communicate the architecture to stakeholders and demonstrate that it has met their requirements
- Focus on architecturally significant aspects of design, including frequently overlooked areas such as performance, resilience, and location
- Use scenarios and patterns to drive the creation and validation of your architecture
- Document your architecture as a set of related views
- Use perspectives to ensure that your architecture exhibits important qualities such as performance, scalability, and security
The architectural viewpoints and perspectives presented in the book also provide a valuable long-term reference source for new and experienced architects alike.
Whether you are an aspiring or practicing software architect, you will find yourself referring repeatedly to the practical advice in this book throughout the lifecycle of your projects.
A supporting Web site containing further information can be found at www.viewpoints-and-perspectives.info
Extras
Related Article
So Now I'm A Software Architect. What Do I Actually Do?
Author's Site
Visit the Author's Web Sites related to this title.
Sample Content
Downloadable Sample Chapter
Download the Sample
Chapter related to this title.
Table of Contents
Preface.
Acknowledgments.
About the Authors.
1. Introduction.
Stakeholders, Viewpoints, and Perspectives.
The Structure of This Book.
Who Should Read This Book.
Conventions Used.
I. ARCHITECTURE FUNDAMENTALS.
2. Software Architecture Concepts.
Software Architecture.
Architectural Elements.
Stakeholders.
Architectural Descriptions.
Interrelationships between the Core Concepts.
Summary.
Further Reading.
3. Viewpoints and Views.
Architectural Views.
Viewpoints.
Interrelationships between the Core Concepts.
The Benefits of Using Viewpoints and Views.
Viewpoint Pitfalls.
Our Viewpoint Catalog.
Summary.
Further Reading.
4. Architectural Perspectives.
Quality Properties.
Architectural Perspectives.
Applying Perspectives to Views.
Consequences of Applying a Perspective.
Interrelationships between the Core Concepts.
The Benefits of Using Perspectives.
Perspective Pitfalls.
Our Perspective Catalog.
Summary.
Further Reading.
5. The Role of the Software Architect.
The Architecture Definition Process.
The Role of the Architect.
Interrelationships between the Core Concepts.
Architectural Specializations.
The Organizational Context.
The Architect's Skills.
The Architect's Responsibilities.
Summary.
Further Reading.
II. THE PROCESS OF SOFTWARE ARCHITECTURE.
6. Introduction to the Software Architecture Process.
7. The Architecture Definition Process.
Guiding Principles.
Process Outcomes.
The Process Context.
Supporting Activities.
Architecture Definition Activities.
Process Exit Criteria.
Architecture Definition in the Software Development Lifecycle.
Summary.
Further Reading.
8. Scope, Concerns, Principles, and Constraints.
Business Goals and Drivers.
Architectural Scope.
Architectural Concerns.
Architectural Principles.
Other Architectural Constraints.
Checklist.
Summary.
Further Reading.
9. Identifying and Engaging Stakeholders.
Selection of Stakeholders.
Classes of Stakeholders.
Examples.
Proxy Stakeholders.
Stakeholder Groups.
Stakeholders' Responsibilities.
Checklist.
Summary.
Further Reading.
10. Identifying and Using Scenarios.
Types of Scenarios.
Uses for Scenarios.
Identifying and Prioritizing Scenarios.
Capturing Scenarios.
Applying Scenarios.
Effective Use of Scenarios.
Checklist.
Summary.
Further Reading.
11. Using Styles and Patterns.
Software Patterns.
Styles, Patterns, and Idioms.
An Example of an Architectural Style.
The Benefits of Using Architectural Styles.
Styles and the Architectural Description.
Common Architectural Styles.
Design Patterns and Language Idioms in Architecture.
Checklist.
Summary.
Further Reading.
12. Producing Architectural Models.
Why Models Are Important.
Types of Models.
Modeling Languages.
Guidelines for Creating Effective Models.
Agile Modeling Techniques.
Checklist.
Summary.
Further Reading.
13. Creating the Architectural Description.
Properties of an Effective Architectural Description.
Glossaries.
The IEEE Standard.
Contents of the Architectural Description.
Checklist.
Summary.
Further Reading.
14. Validating the Architecture.
Why Validate the Architecture?
Validation Techniques.
Scenario-Based Evaluation Methods.
Validation during the Software Lifecycle.
Recording the Results of Validation.
Checklist.
Summary.
Further Reading.
III. THE VIEWPOINT CATALOG.
15. Introduction to the Viewpoint Catalog.
16. The Functional Viewpoint.
Concerns.
Models.
Problems and Pitfalls.
Checklist.
Further Reading.
17. The Information Viewpoint.
Concerns.
Models.
Problems and Pitfalls.
Checklist.
Further Reading.
18. The Concurrency Viewpoint.
Concerns.
Models.
Problems and Pitfalls.
Checklist.
Further Reading.
19. The Development Viewpoint.
Concerns.
Models.
Problems and Pitfalls.
Checklist.
Further Reading.
20. The Deployment Viewpoint.
Concerns.
Models.
Problems and Pitfalls.
Checklist.
Further Reading.
21. The Operational Viewpoint.
Concerns.
Models.
Problems and Pitfalls.
Checklist.
Further Reading.
22. Achieving Consistency across Views.
Relationships between Views.
Functional and Information View Consistency.
Functional and Concurrency View Consistency.
Functional and Development View Consistency.
Functional and Deployment View Consistency.
Functional and Operational View Consistency.
Information and Concurrency View Consistency.
Information and Development View Consistency.
Information and Deployment View Consistency.
Information and Operational View Consistency.
Concurrency and Development View Consistency.
Concurrency and Deployment View Consistency.
Deployment and Operational View Consistency.
IV. THE PERSPECTIVE CATALOG.
23. Introduction to the Perspective Catalog.
24. The Security Perspective.
Applicability to Views.
Concerns.
Activities: Applying the Security Perspective.
Architectural Tactics.
Problems and Pitfalls.
Checklists.
Further Reading.
25. The Performance and Scalability Perspective.
Applicability to Views.
Concerns.
Activities: Applying the Performance and Scalability Perspective.
Architectural Tactics.
Problems and Pitfalls.
Checklists.
Further Reading.
26. The Availability and Resilience Perspective.
Applicability to Views.
Concerns.
Activities: Applying the Availability and Resilience Perspective.
Architectural Tactics.
Problems and Pitfalls.
Checklists.
Further Reading.
27. The Evolution Perspective.
Applicability to Views.
Concerns.
Activities: Applying the Evolution Perspective.
Architectural Tactics.
Problems and Pitfalls.
Checklists.
Further Reading.
28. Other Perspectives.
The Accessibility Perspective.
The Development Resource Perspective.
The Internationalization Perspective.
The Location Perspective.
The Regulation Perspective.
The Usability Perspective.
V. PUTTING IT ALL TOGETHER.
29. Working as a Software Architect.
The Architect in the Project Lifecycle.
The Architect in Different Types of Projects.
Appendix: Other Viewpoint Sets.
Kruchten "4+1".
RM-ODP.
Siemens (Hofmeister, Nord, and Soni).
SEI Viewtypes.
Garland and Anthony.
Bibliography.
Index.
Preface
The authors of this book are both practicing software architects who have worked in this role, together and separately, on information system development projects for quite a few years. During that time, we have seen a significant increase in the visibility of software architects and in the importance with which our role has been viewed by colleagues, management, and customers. No large software development project nowadays would expect to go ahead without an architect--or a small architectural group--in the vanguard of the development team.
While there may be an emerging consensus that the software architect's role is an important one, there seems to be little agreement on what the job actually involves. Who are our clients? To whom are we accountable? What are we expected to deliver? What is our involvement once the architectural design has been completed? And, perhaps most fundamentally, where are the boundaries between requirements, architecture, and design?
The absence of a clear definition of the role is all the more problematic because of the seriousness of the problems that today's software projects (and specifically, their architects) have to resolve.
- The expectations of users and other stakeholders in terms of functionality, capability, time to market, and flexibility have become much more demanding.
- Long system development times result in continual scope changes and consequent changes to the system's architecture and design.
- Today's systems are more functionally and structurally complex than ever and are usually constructed from a mix of off-the-shelf and custom-built components.
- Few systems exist in isolation; most are expected to interoperate and exchange information with many other systems.
- Getting the functional structure--the design--of the system right is only part of the problem. How the system behaves (i.e., its quality properties) is just as critical to its effectiveness as what it does.
- Technology continues to change at a pace that makes it very hard for architects to keep their technical expertise up-to-date.
When we first started to take on the role of software architects, we looked for some sort of software architecture handbook that would walk us through the process of developing an architectural design. After all, other architectural disciplines have behind them centuries of theory and established best practice.
For example, in the first century A.D., the Roman Marcus Vitruvius Pollio wrote the first ever architectural handbook, De architectura libri decem ("Ten Books on Architecture"), describing the building architect's role and required skills and providing a wealth of material on standard architectural structures. In 1670, Anthony Deane, a friend of diarist Samuel Pepys, a former mayor of the English town of Harwich and later a member of Parliament, published a ground-breaking textbook, A Doctrine of Naval Architecture, which described in detail some of the leading methods of the time for large ship design. Deane's ideas and principles helped systematize the practice of naval architecture for many years. And in 1901, George E. Davis, a consulting engineer in the British chemical industry, created a new field of engineering when he published his text A Handbook of Chemical Engineering. This text was the first book to define the practical principles underpinning industrial chemical processes and guided the field for many years afterward.
The existence of such best practices has a very important consequence in terms of uniformity of approach. If you were to give several architects and engineers a commission to design a building, a cruise liner, or a chemical plant, the designs they produced would probably differ. However, the processes they used, the ways they represented their designs on paper (or a computer screen), and the techniques they used to ensure the soundness of their designs would be very similar.
Sadly, our profession has yet to build any significant legacy of mainstream industrial best practices. When we looked, we found a dearth of introductory books to guide practicing information systems architects in the details of doing their jobs.
Admittedly, we have an abundance of books on specific technologies, whether it's J2EE, CORBA, or .NET, and some on broader topics such as Web services or object orientation (although, because of the speed at which software technology changes, many of these become out-of-date within a few years). There are also a number of good general software architecture books, several of which we refer to in later chapters. But many of these books aim to lay down principles that apply across all sorts of systems and so are written in quite general terms, while most of the more specific texts are aimed at our colleagues in the real-time and embedded-systems communities.
We feel that if you are a new software architect for an information system, the books that actually tell you how to do your job, learn the important things you need to know, and make your architectural designs successful are few and far between. While we don't presume to replace the existing texts on software architecture or place ourselves alongside the likes of Vitruvius, Deane, and Davis, addressing these needs was the driving force behind our decision to write this book.
Specifically, the book shows you
- What software architecture is about and why your role is vitally important to successful project delivery
- How to determine who is interested in your architecture (your stakeholders), understand what is important to them (their concerns), and design an architecture that reflects and balances their different needs
- How to communicate your architecture to your stakeholders in an understandable way that demonstrates that you have met their concerns (the architectural description)
- How to focus on what is architecturally significant, safely leaving other aspects of the design to your designers, without neglecting issues like performance, resilience, and location
- What important activities you most need to undertake as an architect, such as identifying and engaging stakeholders, using scenarios, creating models, and documenting and validating your architecture
Throughout the book we primarily focus on the development of large-scale information systems (by which we mean the computer systems used to automate the business operations of large organizations). However, we have tried to present our material in a way that is independent of the type of information system you are designing, the technologies the developers will be using, and the software development lifecycle your project is following. We have standardized on a few things, such as the use of Unified Modeling Language (UML) in most of our diagrams, but we've done that only because UML is the most widely understood modeling language around. You don't have to be a UML expert to understand this book.
We didn't set out to be the definitive guide to developing the architecture of your information system--such a book would probably never be finished and would require the collaboration of a huge number of experts across a wide range of technical specializations. Also, we did not write a book of prescriptive methods. Although we present some activity diagrams that explain how to produce your deliverables, these are designed to be compatible with the wide range of software development approaches in use today.
What we hope we have achieved is the creation of a practical, practitioner-oriented guide that explains how to design successful architectures for information systems and how to see these through to their successful implementation. This is the sort of book that we wish had been available when we started out as software architects, and one that we expect to refer to even now.
You can find further useful software architecture resources, and contact us to provide feedback on the book's content, via our Web page: www.viewpoints-and-perspectives.info. We look forward to hearing from you.
Index
Download the Index
file related to this title.