The process of software architecting

A Comprehensive Process for Defining Software Architectures That Work A good software architecture is the foundation of any successful software system. Effective architecting requires a clear understanding of organizational roles, artifacts, activities performed, and the optimal sequence for performing those activities. With The Process of Software Architecting, Peter Eeles and Peter Cripps provide guidance on these challenges by covering all aspects of architecting a software system, introducing best-practice techniques that apply in every environment, whether based on Java EE, Microsoft .NET, or other technologies. Eeles and Cripps first illuminate concepts related to software architecture, including architecture documentation and reusable assets. Next, they present an accessible, task-focused guided tour through a typical project, focusing on the architect’s role, with common issues illuminated and addressed throughout. Finally, they conclude with a set of best practices that can be applied to today’s most complex systems. You will come away from this book understanding: - The role of the architect in a typical software development project - How to document a software architecture to satisfy the needs of different stakeholders - The applicability of reusable assets in the process of architecting - The role of the architect with respect to requirements definition - The derivation of an architecture based on a set of requirements - The relevance of architecting in creating complex systems - The Process of Software Architecting will be an indispensable resource for every working and aspiring software architect—and for every project manager and other software professional who needs to understand how architecture influences their work. Cover......Page 1 Contents......Page 10 Foreword......Page 18 Preface......Page 20 Acknowledgments......Page 24 About the Authors......Page 26 Chapter 1 Introduction......Page 28 The Process in Brief......Page 29 Summary......Page 35 Architecture......Page 36 An Architecture Defines Structure......Page 38 An Architecture Defines Behavior......Page 39 An Architecture Focuses on Significant Elements......Page 40 An Architecture Balances Stakeholder Needs......Page 41 An Architecture May Conform to an Architectural Style......Page 42 An Architecture Is Influenced by Its Environment......Page 43 An Architecture Is Present in Every System......Page 44 An Architecture Has a Particular Scope......Page 45 The Architect Is a Technical Leader......Page 48 The Architect Role May Be Fulfilled by a Team......Page 49 The Architect Has Knowledge of the Business Domain......Page 50 The Architect Has Design Skills......Page 51 The Architect Has Programming Skills......Page 52 The Architect Is Aware of Organizational Politics......Page 53 Architecting......Page 54 Architecting Spans Many Disciplines......Page 57 Architecting Is an Ongoing Activity......Page 58 Architecting Is Driven by Many Stakeholders......Page 59 Architecting Often Involves Making Trade-Offs......Page 60 Architecting Is Both Top-Down and Bottom-Up......Page 61 Architecting Addresses System Qualities......Page 62 Architecting Supports the Planning Process......Page 63 Architecting Drives Architectural Integrity......Page 65 Architecting Reduces Maintenance Costs......Page 66 Summary......Page 67 Key Concepts......Page 70 Role......Page 73 Work Product......Page 75 Activity......Page 76 Process......Page 77 Waterfall Processes......Page 78 Iterative Processes......Page 79 Agile Processes......Page 85 Summary......Page 86 Chapter 4 Documenting a Software Architecture......Page 88 The End Game......Page 89 Key Concepts......Page 91 Viewpoints and Views......Page 92 Basic Viewpoints......Page 94 Cross-Cutting Viewpoints......Page 95 Views and Diagrams......Page 97 Benefits of Viewpoints and Views......Page 98 Models......Page 99 Levels of Realization......Page 100 Characteristics of an Architecture Description Framework......Page 102 The 4 + 1 View Model of Software Architecture......Page 103 Zachman Framework......Page 104 Rozanski and Woods......Page 106 Viewpoints......Page 108 Work Products......Page 111 Levels of Realization......Page 112 The Software Architecture Document......Page 114 Summary......Page 115 Sources of Architecture......Page 116 An Architecture Asset Metamodel......Page 117 Run-Time Assets......Page 119 Development Method......Page 121 Architectural Style......Page 122 Pattern......Page 123 Architecture Decision......Page 127 Packaged Application......Page 128 Application Framework......Page 129 Attributes of an Architecture Asset......Page 130 Summary......Page 133 Applying the Process......Page 134 Scope of the Case Study......Page 137 The Project Team......Page 139 External Influences......Page 140 Application Overview......Page 142 Problem Statement......Page 145 Stakeholders......Page 146 Functionality......Page 147 Constraints......Page 149 Summary......Page 150 Chapter 7 Defining the Requirements......Page 152 Relating Requirements to Architecture......Page 155 Functional and Non-Functional Requirements......Page 157 Techniques for Documenting Requirements......Page 158 Applying the Process......Page 159 Understanding the Task Descriptions......Page 160 Define Requirements: Activity Overview......Page 161 Task: Collect Stakeholder Requests......Page 163 Task: Capture Common Vocabulary......Page 168 Task: Define System Context......Page 170 Task: Outline Functional Requirements......Page 176 Task: Outline Non-Functional Requirements......Page 183 Task: Prioritize Requirements......Page 187 Task: Detail Functional Requirements......Page 191 Task: Detail Non-Functional Requirements......Page 198 Task: Update Software Architecture Document......Page 201 Task: Review Requirements with Stakeholders......Page 202 Summary......Page 203 Chapter 8 Creating the Logical Architecture......Page 206 Moving from Requirements to Solution......Page 209 Minimizing Logical Architecture......Page 212 Logical Architecture as an Investment......Page 213 The Importance of Traceability......Page 214 Create Logical Architecture: Activity Overview......Page 215 Task: Survey Architecture Assets......Page 219 Task: Define Architecture Overview......Page 221 Task: Document Architecture Decisions......Page 227 Task: Outline Functional Elements......Page 231 Task: Outline Deployment Elements......Page 249 Task: Verify Architecture......Page 255 Task: Build Architecture Proof-of-Concept......Page 259 Task: Detail Functional Elements......Page 261 Task: Detail Deployment Elements......Page 272 Task: Validate Architecture......Page 278 Task: Update Software Architecture Document......Page 283 Task: Review Architecture with Stakeholders......Page 285 Summary......Page 287 Chapter 9 Creating the Physical Architecture......Page 288 Moving from Logical to Physical Architecture......Page 290 Applying the Process......Page 292 Creating the Physical Architecture: Activity Overview......Page 293 Task: Survey Architecture Assets......Page 296 Task: Define Architecture Overview......Page 297 Task: Document Architecture Decisions......Page 300 Mapping Logical Functional Elements to Physical Functional Elements......Page 301 Identifying Physical Functional Elements......Page 304 Procuring Products......Page 306 Accommodating Technology-Specific Patterns......Page 307 Mapping Logical Deployment Elements to Physical Deployment Elements......Page 316 Identifying Physical Deployment Elements......Page 317 Task: Verify Architecture......Page 319 Task: Build Architecture Proof-of-Concept......Page 320 Task: Detail Functional Elements......Page 321 Task: Detail Deployment Elements......Page 323 Task: Validate Architecture......Page 327 Task: Review Architecture with Stakeholders......Page 328 Summary......Page 329 The Architect and the Project Team......Page 330 The Architect and Development......Page 331 The Architect and Test......Page 333 The Architect and Project Management......Page 334 The Architect and Configuration Management......Page 335 The Architect and Change Management......Page 337 The Architect and the Development Environment......Page 338 The Architect and Business Analysis......Page 339 The Architect and External Influences......Page 340 Enterprise Architecture......Page 342 Design Authority......Page 343 Infrastructure Provider......Page 344 Architecting Complex Systems......Page 345 Many Distinct Functions Are Being Developed......Page 346 Many People Are Involved in Development......Page 347 The System Is Highly Distributed......Page 351 The Development Team Is Distributed......Page 352 Operational Qualities Are Extremely Challenging......Page 353 There Is a System of Systems......Page 354 Summary......Page 357 In Conclusion: A Note from the Authors......Page 358 Appendix A: Software Architecture Metamodel......Page 360 Definition of Metamodel Terms......Page 362 Appendix B: Viewpoint Catalog......Page 366 Stakeholder Summary......Page 367 Basic Viewpoints......Page 368 Cross-Cutting Viewpoints......Page 371 View Correspondence......Page 374 Roles......Page 378 Work Products......Page 381 Tasks......Page 383 Activity: Define Requirements......Page 385 Activity: Create Logical Architecture......Page 387 Inception......Page 389 Construction......Page 390 Transition......Page 391 Appendix D: Architectural Requirement Checklist......Page 392 Usability Requirements......Page 393 Performance Requirements......Page 394 Constraints......Page 395 Architecture Constraints......Page 396 Physical Constraints......Page 397 A......Page 400 D......Page 401 P......Page 402 S......Page 403 W......Page 404 References......Page 406 A......Page 412 B......Page 414 C......Page 415 D......Page 418 E......Page 421 I......Page 422 L......Page 423 O......Page 424 P......Page 425 R......Page 427 S......Page 428 T......Page 430 V......Page 431 Z......Page 432

A Comprehensive Process for Defining Software Architectures That Work

A good software architecture is the foundation of any successful software system. Effective architecting requires a clear understanding of organizational roles, artifacts, activities performed, and the optimal sequence for performing those activities.

With The Process of Software Architecting, Peter Eeles and Peter Cripps provide guidance on these challenges by covering all aspects of architecting a software system, introducing best-practice techniques that apply in every environment, whether based on Java EE, Microsoft .NET, or other technologies. Eeles and Cripps first illuminate concepts related to software architecture, including architecture documentation and reusable assets. Next, they present an accessible, task-focused guided tour through a typical project, focusing on the architect’s role, with common issues illuminated and addressed throughout. Finally, they conclude with a set of best practices that can be applied to today’s most complex systems.

You will come away from this book understanding

• The role of the architect in a typical software development project
• How to document a software architecture to satisfy the needs of different stakeholders
• The applicability of reusable assets in the process of architecting
• The role of the architect with respect to requirements definition
• The derivation of an architecture based on a set of requirements
• The relevance of architecting in creating complex systems

The Process of Software Architecting will be an indispensable resource for every working and aspiring software architect—and for everyproject manager and other software professional who needs to understand how architecture influences their work.