Software Systems Architecture: Working With Stakeholders Using Viewpoint (pdf)

oftware Systems Architecture: Working With Stakeholders Using Viewpoint Who the Book is For We wrote this book primarily for people like us: software architecture practitioners who need to get to grips with the development of practical architectures for their information systems that meet the needs of those they are intended to se rve. We also hope the book will be of interest to people studying software architecture at university, and others involved in the software lifecycle, such as development managers, testers, software developers and technical specialists. The knowledge that you will gain by reading of the book includes: An understanding of what software architecture is, 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. Key Concepts In order to help to organise the material in the book, we have identified three key architectural concepts that we use as themes throughout the text. Stakeholders are the people for whom we build systems. A key part of your role as an architect is knowing how to work with stakeholders in order to create an architecture that meets their complex, overlapping, and often conflicting needs. Viewpoints (and views) are an approach to structuring the architecture definition process and the architectural description, based on the principle of separation of concerns. Viewpoints contain proven architectural knowledge to guide the creation of an architecture, described in a particular set of views (each view being the result of applying the guidance in a particular viewpoint). Perspectives are a complementary concept to viewpoints that we introduce in this book. Perspectives contain proven architectural knowledge and help structure the architecture definition process by separating concerns but focusing on cross-structural quality properties rather than architectural structures. Structure The book is divided into five sections as follows. Part I provides an introduction to and review of the basic concepts we use throughout the book (e.g., stakeholder, architectural description, viewpoint, view, and perspective) and describes the role of the software architect. Part II describes the most important activities you need to undertake as an architect, such as agreeing on a project's scope, identifying and engaging stakeholders, using scenarios and patterns, creating models, and documenting and validating your architecture. Part III is a catalog of the six most important viewpoints you will need when creating your architectural description: the Functional, Information, Concurrency, Development, Deployment, and Operational viewpoints. Part IV is a catalog of the most important perspectives for information systems, including Security, Performance and Scalability, Availability and Resilience, Evolution, Location, Development Resource, Internationalization, and a number of others. Part V pulls these concepts together and explains how you can start to put our ideas into practice. rve. We also hope the book will be of interest to people studying software architecture at university, and others involved in the software lifecycle, such as development managers, testers, software developers and technical specialists. The knowledge that you will gain by reading of the book includes: An understanding of what software architecture is, 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. Key Concepts In order to help to organise the material in the book, we have identified three key architectural concepts that we use as themes throughout the text. Stakeholders are the people for whom we build systems. A key part of your role as an architect is knowing how to work with stakeholders in order to create an architecture that meets their complex, overlapping, and often conflicting needs. Viewpoints (and views) are an approach to structuring the architecture definition process and the architectural description, based on the principle of separation of concerns. Viewpoints contain proven architectural knowledge to guide the creation of an architecture, described in a particular set of views (each view being the result of applying the guidance in a particular viewpoint). Perspectives are a complementary concept to viewpoints that we introduce in this book. Perspectives contain proven architectural knowledge and help structure the architecture definition process by separating concerns but focusing on cross-structural quality properties rather than architectural structures. Structure The book is divided into five sections as follows. Part I provides an introduction to and review of the basic concepts we use throughout the book (e.g., stakeholder, architectural description, viewpoint, view, and perspective) and describes the role of the software architect. Part II describes the most important activities you need to undertake as an architect, such as agreeing on a project's scope, identifying and engaging stakeholders, using scenarios and patterns, creating models, and documenting and validating your architecture. Part III is a catalog of the six most important viewpoints you will need when creating your architectural description: the Functional, Information, Concurrency, Development, Deployment, and Operational viewpoints. Part IV is a catalog of the most important perspectives for information systems, including Security, Performance and Scalability, Availability and Resilience, Evolution, Location, Development Resource, Internationalization, and a number of others. Part V pulls these concepts together and explains how you can start to put our ideas into practice.