Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives [NOOK Book]

Overview

Software Systems Architecture, Second Edition is a highly regarded, 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.

 

With this book you will learn how to

  • Design and communicate an architecture that reflects and ...
See more details below
Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives

Available on NOOK devices and apps  
  • NOOK Devices
  • Samsung Galaxy Tab 4 NOOK 7.0
  • Samsung Galaxy Tab 4 NOOK 10.1
  • NOOK HD Tablet
  • NOOK HD+ Tablet
  • NOOK eReaders
  • NOOK Color
  • NOOK Tablet
  • Tablet/Phone
  • NOOK for Windows 8 Tablet
  • NOOK for iOS
  • NOOK for Android
  • NOOK Kids for iPad
  • PC/Mac
  • NOOK for Windows 8
  • NOOK for PC
  • NOOK for Mac
  • NOOK for Web

Want a NOOK? Explore Now

NOOK Book (eBook)
$31.99
BN.com price
(Save 42%)$55.99 List Price

Overview

Software Systems Architecture, Second Edition is a highly regarded, 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.

 

With this book you will learn how to

  • Design and communicate an architecture that reflects and balances the different needs of its stakeholders
  • 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

 

Reflecting new standards and developments in the field, this new edition extends and updates much of the content, and

  • Adds a “system context viewpoint” that documents the system’s interactions with its environment
  • Expands the discussion of architectural principles, showing how they can be used to provide traceability and rationale for architectural decisions
  • Explains how agile development and architecture can work together
  • Positions requirements and architecture activities in the project context
  • Presents a new lightweight method for architectural validation

 

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.

Read More Show Less

Product Details

  • ISBN-13: 9780132906128
  • Publisher: Pearson Education
  • Publication date: 11/8/2011
  • Sold by: Barnes & Noble
  • Format: eBook
  • Edition number: 2
  • Pages: 704
  • File size: 12 MB
  • Note: This product may take a few minutes to download.

Meet the Author

Nick Rozanski has worked in IT since 1980 for several large and small systems integrators, including Logica, Capgemini, and Sybase, and end user organizations including Marks and Spencer and Barclays Global Investors. He has taken senior roles on a wide range of programs in finance, retail, manufacturing, and government. His technology background includes enterprise application integration, package implementation, relational database, data replication, and object-oriented software development. He is also an experienced technical instructor and certified internal project auditor.

 

Eoin (pronounced “Owen”) Woods is a lead system architect in the equities technology group of a major European investment bank with architecture and design responsibility for a number of the organization’s key systems. Prior to this, he led the application architecture group at Barclays Global Investors and has worked as a software engineer for Group Bull, Sybase, InterTrust, and Zuhlke, as well as through his own consultancy company, Artechra.

Read More Show Less

Read an Excerpt

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.

Read More Show Less

Table of Contents

Preface to the Second Edition         xv

Acknowledgments for the Second Edition         xvi

 

Preface to the First Edition           xvii

Acknowledgments         xx

 

Chapter 1: Introduction        1

Stakeholders, Viewpoints, and Perspectives   1

The Structure of This Book   7

Who Should Read This Book   7

Conventions Used   8

 

Part I: Architecture Fundamentals          9

Chapter 2: Software Architecture Concepts        11

Software Architecture   11

Architectural Elements   20

Stakeholders   21

Architectural Descriptions   24

Relationships between the Core Concepts   26

Summary   27

Further Reading   28

 

Chapter 3: Viewpoints and Views         31

Architectural Views   34

Viewpoints   36

Relationships between the Core Concepts   37

The Benefits of Using Viewpoints and Views   38

Viewpoint Pitfalls   39

Our Viewpoint Catalog   39

Summary   43

Further Reading   43

 

Chapter 4: Architectural Perspectives        45

Quality Properties   45

Architectural Perspectives   47

Applying Perspectives to Views   51

Consequences of Applying a Perspective   54

Relationships between the Core Concepts   56

The Benefits of Using Perspectives   56

Perspective Pitfalls   58

Comparing Perspectives to Viewpoints   58

Our Perspective Catalog   60

Summary   61

Further Reading   62

 

Chapter 5: The Role Of The Software Architect         63

The Architecture Definition Process   64

The Role of the Architect   68

Interrelationships between the Core Concepts   71

Architectural Specializations   72

The Organizational Context   73

The Architect’s Skills   76

The Architect’s Responsibilities   77

Summary   78

Further Reading   79

 

Part II: The Process of Software Architecture        81

Chapter 6: Introduction to the Software Architecture Process         83

 

Chapter 7: The Architecture Definition Process        85

Guiding Principles 85

Process Outcomes 86

The Process Context 87

Supporting Activities 89

Architecture Definition Activities 92

Process Exit Criteria 97

Architecture Definition in the Software Development Lifecycle 98

Summary 102

Further Reading 103

 

Chapter 8: Concerns, Principles, and Decisions        105

Problem-Focused Concerns   108

Solution-Focused Concerns   111

Other Real-World Constraints   114

What Makes a Good Concern   116

Architectural Principles   117

Architectural Decisions   122

Using Principles to Link Concerns and Decisions   125

Checklist   128

Summary   128

Further Reading   129

 

Chapter 9: Identifying and Engaging Stakeholders        131

Selection of Stakeholders   131

Classes of Stakeholders   133

Examples   138

Proxy Stakeholders   140

Stakeholder Groups   141

Stakeholders’ Responsibilities   141

Checklist   142

Summary   142

Further Reading   143

 

Chapter 10: Identifying and Using Scenarios        145

Types of Scenarios   146

Uses for Scenarios   147

Identifying and Prioritizing Scenarios   148

Capturing Scenarios   149

What Makes a Good Scenario?   153

Applying Scenarios   154

Effective Use of Scenarios   157

Checklist   159

Summary   159

Further Reading   160

 

Chapter 11: Using Styles and Patterns         161

Introducing Design Patterns   161

Styles, Patterns, and Idioms   164

Patterns and Architectural Tactics   166

An Example of an Architectural Style   167

The Benefits of Using Architectural Styles   170

Styles and the Architectural Description   172

Applying Design Patterns and Language Idioms   172

Checklist   174

Summary   174

Further Reading   175

 

Chapter 12: Producing Architectural Models        177

Why Models Are Important   178

Types of Models   181

Modeling Languages   184

Guidelines for Creating Effective Models   187

Modeling with Agile Teams   193

Checklist   194

Summary   195

Further Reading   196

 

Chapter 13: Creating the Architectural Description         197

Properties of an Effective Architectural Description   198

Glossaries   206

The ISO Standard   206

Contents of the Architectural Description   207

Presenting the Architectural Description   213

Checklist   215

Summary   216

Further Reading   216

 

Chapter 14: Evaluating the Architecture        217

Why Evaluate the Architecture?   218

Evaluation Techniques   219

Scenario-Based Evaluation Methods   226

Evaluation during the Software Lifecycle   230

Validating the Architecture of an Existing System   233

Recording the Results of Evaluation   236

Choosing an Evaluation Approach   237

Checklist   238

Summary   238

Further Reading   239

 

Part III: A Viewpoint Catalog         241

Chapter 15: Introduction to the Viewpoint Catalog         243

 

Chapter 16: The Context Viewpoint         247

Concerns   248

Models   255

Problems and Pitfalls   261

Checklist   265

Further Reading   266

 

Chapter 17: The Functional Viewpoint          267

Concerns   268

Models   271

Problems and Pitfalls   285

Checklist   291

Further Reading   292

 

Chapter 18: The Information Viewpoint         293

Concerns   294

Models   311

Problems and Pitfalls   322

Checklist   330

Further Reading   330

 

Chapter 19: The Concurrency Viewpoint         333

Concerns   335

Models   340

Problems and Pitfalls   351

Checklist   355

Further Reading   355

 

Chapter 20: The Development Viewpoint          357

Concerns   358

Models   360

Problems and Pitfalls   367

Checklist   370

Further Reading   371

 

Chapter 21: The Deployment Viewpoint         373

Concerns   374

Models   378

Problems and Pitfalls   387

Checklist   391

Further Reading   392

 

Chapter 22: The Operational Viewpoint          393

Concerns   394

Models   402

Problems and Pitfalls   419

Checklist   423

Further Reading   424

 

Chapter 23: Achieving Consistency Across Views         425

Relationships between Views   426

Context and Functional View Consistency   427

Context and Information View Consistency   427

Context and Deployment View Consistency   428

Functional and Information View Consistency   428

Functional and Concurrency View Consistency   429

Functional and Development View Consistency   430

Functional and Deployment View Consistency   430

Functional and Operational View Consistency   431

Information and Concurrency View Consistency   431

Information and Development View Consistency   432

Information and Deployment View Consistency   432

Information and Operational View Consistency   432

Concurrency and Development View Consistency   433

Concurrency and Deployment View Consistency   433

Deployment and Operational View Consistency   434

 

Part IV: The Perspective Catalog            435

Chapter 24: Introduction to the Perspective Catalog         437

 

Chapter 25: The Security Perspective          439

Applicability to Views   441

Concerns   442

Activities: Applying the Security Perspective   446

Architectural Tactics   456

Problems and Pitfalls   465

Checklists   473

Further Reading   474


Chapter 26: The Performance and Scalability Perspective         475

Applicability to Views   476

Concerns   476

Activities: Applying the Performance and Scalability Perspective   482

Architectural Tactics   491

Problems and Pitfalls   502

Checklists   509

Further Reading   510

 

Chapter 27: The Availability and Resilience Perspective         511

Applicability to Views   512

Concerns   512

Activities: Applying the Availability and Resilience Perspective   516

Architectural Tactics   526

Problems and Pitfalls   533

Checklists   539

Further Reading   541

 

Chapter 28: The Evolution Perspective         543

Applicability to Views   544

Concerns   545

Activities: Applying the Evolution Perspective   549

Architectural Tactics   552

Problems and Pitfalls   560

Checklists   564

Further Reading   565

 

Chapter 29: Other Perspectives          567

The Accessibility Perspective   568

The Development Resource Perspective   573

The Internationalization Perspective   579

The Location Perspective   585

The Regulation Perspective   591

The Usability Perspective   595

 

Part V: Putting It All Together         603

Chapter 30: Working As A Software Architect          605

Architecture in the Project Lifecycle   605

Supporting Different Types of Projects   615

 

Appendix: Other Viewpoint Sets         621

Kruchten “4+1”   621

RM-ODP   623

Siemens (Hofmeister, Nord, and Soni)   623

SEI “Views and Beyond” Views   624

Garland and Anthony   626

IAF   627

Enterprise Architecture Frameworks   627

Other Enterprise Architecture Frameworks   629

 

Bibliography          631

About the Authors           643

 

Index            645

Read More Show Less

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.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)