The process of software architecting 0321357485, 9780321357489

Citation preview

Praise for The Process of Software Architecting “The role of software architect has really come into its own in the last few years and is now recognized as a key determinant of project success. However, even today there is little common understanding of how to do the job: analyze requirements, understand concerns, evaluate alternatives, and construct and document an architectural description that is fit for purpose. Eeles and Cripps have filled this gap in their useful and practical book. The material is clearly and simply laid out, and follows a logical progression from inception through delivery, with tasks and work products clearly explained and illustrated using a real-world case study. This is a vital handbook for everyone from brand new architects to seasoned professionals.” —Nick Rozanski, coauthor of Software Systems Architecture “If you need a thorough and authoritative reference for a complete software architecture process, then look no further. Peter Eeles and Peter Cripps have produced a definitive guide and reference to just such a process. Being precisely defined using a metamodel, illustrated with a realistic case study, and clearly related to key standards such as UML, RUP, and IEEE 1471, the process presented in this book provides a valuable guide for those developing software architectures for large projects. I have no doubt that it will become a valued reference for many software architects.” —Eoin Woods, coauthor of Software Systems Architecture “Eeles and Cripps distill years of experience into a single guide that helps the reader understand not just what architects produce, but how they produce it. The Process of Software Architecting is a very practical guide filled with lessons learned and pitfalls to avoid. Practicing architects will want to refer to it as they hone their skills, and aspiring architects will gain key insights that otherwise could take painful years of experience to acquire.” —Bob Kitzberger, program director, Strategy, IBM Software Group “For most of my career in this field, software architecture has had the feel of being a black art that only a select few gurus and wizards had a talent for. This book follows on from industry best practice and a wealth of author experience to bring solutions architecture into the realms of being a true engineering discipline. Now I have a real guide I can pass on to new practitioners, a guide that embodies what used to require years of trial and error.” —Colin Renouf, enterprise architect and technology author, vice chairman, WebSphere User Group, UK

This page intentionally left blank

The Process of Software Architecting

This page intentionally left blank

The Process of Software Architecting

Peter Eeles Peter Cripps

Upper Saddle River, NJ • Boston • Indianapolis • San Francisco New York • Toronto • Montreal • London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact: U.S. Corporate and Government Sales (800) 382-3419 [email protected] For sales outside the United States, please contact: International Sales [email protected] Visit us on the Web: informit.com/aw Library of Congress Cataloging-in-Publication Data Eeles, Peter, 1962– The process of software architecting / Peter Eeles, Peter Cripps. p. cm. Includes bibliographical references and index. ISBN 0-321-35748-5 (pbk. : alk. paper) 1. Software architecture. 2. System design. I. Cripps, Peter, 1958– II. Title. QA76.754.E35 2009 005.1'2—dc22 2009013890 Copyright © 2010 Pearson Education, Inc. All rights reserved. Printed in the United States of America.This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to: Pearson Education, Inc Rights and Contracts Department 501 Boylston Street, Suite 900 Boston, MA 02116 Fax: (617) 671-3447 ISBN-13: 978-0-321-35748-9 ISBN-10: 0-321-35748-5 Text printed in the United States on recycled paper at Courier in Stoughton, Massachusetts. First printing, July 2009

To my wife and best friend, Karen, and our sons, Daniel, Thomas, and Christopher. —Peter Eeles

To Gail and David for being patient and supportive, and to Mum for setting me on the right track. —Peter Cripps

This page intentionally left blank

Contents

Foreword Preface

Chapter 1

Chapter 2

xvii xix

Acknowledgments

xxiii

About the Authors

xxv

Introduction 1 Applying the Process The Process in Brief Scope 8 Summary 8

2 2

Architecture, Architect, Architecting Architecture 9

9

An Architecture Defines Structure 11 An Architecture Defines Behavior 12 An Architecture Focuses on Significant Elements 13 An Architecture Balances Stakeholder Needs 14 An Architecture Embodies Decisions Based on Rationale An Architecture May Conform to an Architectural Style An Architecture Is Influenced by Its Environment 16 An Architecture Influences Development Team Structure An Architecture Is Present in Every System 17 An Architecture Has a Particular Scope 18

15 15 17

ix

x | Contents

Architect

21

The Architect Is a Technical Leader 21 The Architect Role May Be Fulfilled by a Team 22 The Architect Understands the Software Development Process The Architect Has Knowledge of the Business Domain 23 The Architect Has Technology Knowledge 24 The Architect Has Design Skills 24 The Architect Has Programming Skills 25 The Architect Is a Good Communicator 26 The Architect Makes Decisions 26 The Architect Is Aware of Organizational Politics 26 The Architect Is a Negotiator 27

Architecting

27

Architecting Is a Science 30 Architecting Is an Art 30 Architecting Spans Many Disciplines 30 Architecting Is an Ongoing Activity 31 Architecting Is Driven by Many Stakeholders 32 Architecting Often Involves Making Trade-Offs 33 Architecting Acknowledges Experience 34 Architecting Is Both Top-Down and Bottom-Up 34

The Benefits of Architecting

35

Architecting Addresses System Qualities 35 Architecting Drives Consensus 36 Architecting Supports the Planning Process 36 Architecting Drives Architectural Integrity 38 Architecting Helps Manage Complexity 39 Architecting Provides a Basis for Reuse 39 Architecting Reduces Maintenance Costs 39 Architecting Supports Impact Analysis 40

Summary

Chapter 3

40

Method Fundamentals Key Concepts 43 Method Content 46 Role 46 Work Product Activity 49 Task 50

Process

48

50

Waterfall Processes 51 Iterative Processes 52 Agile Processes 58

Summary

59

43

23

Contents | xi

Chapter 4

Documenting a Software Architecture The End Game 62 Key Concepts 64 Viewpoints and Views 65 Basic Viewpoints 67 Cross-Cutting Viewpoints 68 Views and Diagrams 70 Benefits of Viewpoints and Views

Models

61

71

72

Levels of Realization Benefits of Models

73 75

Characteristics of an Architecture Description Framework The 4 + 1 View Model of Software Architecture Zachman Framework 77 Rozanski and Woods 79

An Architecture Description Framework Viewpoints 81 Work Products 84 Levels of Realization View Correspondence

85 87

The Software Architecture Document Summary 88

Chapter 5

Reusable Architecture Assets Sources of Architecture 89 An Architecture Asset Metamodel Development-Time Assets Run-Time Assets 92

Asset Types

81

87

89 90

92

94

Reference Architecture 94 Development Method 94 Viewpoint Catalog 95 Architectural Style 95 Architectural Mechanism 96 Pattern 96 Reference Model 100 Architecture Decision 100 Existing Application 101 Packaged Application 101 Application Framework 102 Component Library/Component

Attributes of an Architecture Asset

103

103

76

75

xii | Contents

Other Reuse Considerations Summary 106

Chapter 6

106

Introduction to the Case Study Applying the Process 107 Scope of the Case Study 110 The Project Team External Influences

Application Overview The YourTour Vision

107

112 113

115 118

Problem Statement 118 Stakeholders 119 Functionality 120 Qualities 122 Constraints 122

Summary

123

Chapter 7

Defining the Requirements 125 Relating Requirements to Architecture 128 Functional and Non-Functional Requirements 130 Techniques for Documenting Requirements 131 Applying the Process 132 Understanding the Task Descriptions 133 Define Requirements: Activity Overview 134 Task: Collect Stakeholder Requests 136 Task: Capture Common Vocabulary 141 Task: Define System Context 143 Task: Outline Functional Requirements 149 Task: Outline Non-Functional Requirements 156 Task: Prioritize Requirements 160 Task: Detail Functional Requirements 164 Task: Detail Non-Functional Requirements 171 Task: Update Software Architecture Document 174 Task: Review Requirements with Stakeholders 175 Summary 176

Chapter 8

Creating the Logical Architecture 179 Moving from Requirements to Solution 182 How Much Logical Architecture? 185 Minimizing Logical Architecture 185 Logical Architecture as an Investment 186 The Importance of Traceability 187

Contents | xiii

Applying the Process 188 Create Logical Architecture: Activity Overview 188 Task: Survey Architecture Assets 192 Task: Define Architecture Overview 194 Task: Document Architecture Decisions 200 Task: Outline Functional Elements 204 Task: Outline Deployment Elements 222 Task: Verify Architecture 228 Task: Build Architecture Proof-of-Concept 232 Task: Detail Functional Elements 234 Task: Detail Deployment Elements 245 Task: Validate Architecture 251 Task: Update Software Architecture Document 256 Task: Review Architecture with Stakeholders 258 Summary 260

Chapter 9

Creating the Physical Architecture 261 Moving from Logical to Physical Architecture 263 Applying the Process 265 Creating the Physical Architecture: Activity Overview Task: Survey Architecture Assets 269 Task: Define Architecture Overview 270 Task: Document Architecture Decisions 273 Task: Outline Functional Elements 274

266

Mapping Logical Functional Elements to Physical Functional Elements Identifying Physical Functional Elements 277 Procuring Products 279 Accommodating Technology-Specific Patterns 280

Task: Outline Deployment Elements

289

Mapping Logical Deployment Elements to Physical Deployment Elements 289 Identifying Physical Deployment Elements 290 Procuring Hardware 292

Task: Verify Architecture 292 Task: Build Architecture Proof-of-Concept 293 Task: Detail Functional Elements 294 Task: Detail Deployment Elements 296 Task: Validate Architecture 300 Task: Update Software Architecture Document 301 Task: Review Architecture with Stakeholders 301 Summary 302

274

xiv | Contents

Chapter 10

Beyond the Basics 303 The Architect and the Project Team

303

The Architect and Requirements 304 The Architect and Development 304 The Architect and Test 306 The Architect and Project Management 307 The Architect and Configuration Management 308 The Architect and Change Management 310 The Architect and the Development Environment 311 The Architect and Business Analysis 312

The Architect and External Influences Enterprise Architecture 315 Design Authority 316 Infrastructure Provider 317 Application Maintenance Provider

Architecting Complex Systems

313

318

318

Many Distinct Functions Are Being Developed 319 Many People Are Involved in Development 320 The System Is Highly Distributed 324 The Development Team Is Distributed 325 Operational Qualities Are Extremely Challenging 326 There Is a System of Systems 327

Summary 330 In Conclusion: A Note from the Authors

331

Appendix A

Software Architecture Metamodel 333 Definition of Metamodel Terms 335

Appendix B

Viewpoint Catalog 339 Stakeholder Summary 340 Basic Viewpoints 341 Cross-Cutting Viewpoints 344 View Correspondence 347

Appendix C

Method Summary 351 Roles 351 Work Products 354 Activities 356 Tasks 356 Activity: Define Requirements 358 Activity: Create Logical Architecture Activity: Create Physical Architecture

360 362

Contents | xv

Phases

362

Inception 362 Elaboration 363 Construction 363 Transition 364

Appendix D

Architectural Requirement Checklist Functional Requirements 366 Usability Requirements 366 Reliability Requirements 367 Performance Requirements 367 Supportability Requirements 368 Constraints 368 Business Constraints 369 Architecture Constraints 369 Development Constraints 370 Physical Constraints 370

Glossary

373

References Index

385

379

365

This page intentionally left blank

Foreword by Grady Booch

The study of the architecting of software-intensive systems is currently a vibrant concern. Although a number of books and papers describing the concepts of software architecture have emerged, far fewer address the practice of architecting. This is such a book. Here, the authors offer their seasoned perspective on architecture: what it is, how it manifests itself, who does it, how it relates to the other artifacts of a software development project. Although this book covers all the important fundamentals of representing a system’s architecture, the strength of this work lies in its deep examination of a method for architecting. I say deep because the authors explain their ways by using well-defined models, but happily, they do so in a manner that is understandable and comprehensive, with particular emphasis on attending to the various views that comprise a complete picture of a system’s architecture. They also cover, in some detail, bridging the gap between a system’s logical architecture and its physical one. I’m particularly delighted by their inclusion of peopleware issues—namely, the roles of the architect and the architecture team, and the connection of architectural artifacts to the activities of various team members. Using a fairly complete case study, the authors bring their concepts to practice. Their explanation of the pitfalls that one should avoid comes from their practical experience in industry and, thus, is particularly useful. Indeed, this is a most useful book, for it contains ideas that are immediately actionable by any software development organization.

xvii

This page intentionally left blank

Preface

Several years ago, the authors became aware of Grady Booch’s Handbook of Software Architecture initiative (www.handbookofsoftwarearchitecture.com). The purpose of Grady’s initiative is To codify the architecture of a large collection of interesting software-intensive systems, presenting them in a manner that exposes their essential patterns and that permits comparisons across domains and architectural styles.

While Grady is focusing on the resulting architectures, we felt that it would be equally interesting to understand the processes that successful architects follow when creating their architectures. Our ultimate objective was, of course, to replicate their success. This journey has taken us several years to complete. Many projects have been executed, many architects have been interviewed, and many development methods have been teased apart—all contributing to our understanding of the essence of what works, and what doesn’t, when architecting a software system. This book is the pinnacle of our journey. A number of excellent books describe a particular aspect of the process of software architecting, and we draw from these books where relevant. Some of these books focus on documenting a software architecture, for example, and others focus on evaluating a software architecture. Each of these aspects fits into a bigger picture, because each represents an important element of the process of software architecting. One objective of this book, therefore, is to

xix

xx | Preface

present this big picture by providing a consolidated look at all aspects of architecting in the context of a typical software development project. It should be noted that this book does not prescribe a particular software development method. Rather, it describes the key elements that one would expect to encounter in any modern development method in supporting the architecting process.

Who This Book Is For Clearly, this book is aimed at software architects (or aspiring software architects) wanting to understand how their role fits into an overall software development process. It is also applicable to specialist architect roles such as an application architect and security architect. In more general terms, this book is applicable to anyone who wants to gain a better appreciation of the role of the software architect. As such, it will also be of some benefit to all members of a software development team, including developers, testers, business analysts, project managers, configuration managers, and process engineers. It is also of particular relevance to undergraduates who want to gain insight into the increasingly important role of the software architect in a software development effort.

How to Read This Book The book is roughly divided into three parts. The first part, Chapters 1 through 5, summarizes the core concepts of architecture, architect and architecting, documenting a software architecture, and reusable architecture assets. The second part, Chapters 6 through 9, contains the case study–related chapters, which provide a guided tour through a typical software development project based on an example application, with a focus on the role of the architect. These chapters have been written to make them easy to read at a glance and to permit you to find specific topics of interest easily. Each case study–related chapter is organized primarily by tasks, and in these chapters we have used a few styles and conventions. In particular, all references to process elements, such as tasks, work products, and roles, are emphasized in bold text, such as when we describe the Software Architecture Document work product. The third part, Chapter 10, contains additional discussion topics and considers, in particular, how the concepts described in the preceding chapters apply to architecting complex systems.

Preface | xxi

In this book, you’ll also find helpful sidebars that are categorized as follows: ■

Concept sidebars introduce ideas or sets of ideas that are relevant to the topics under discussion.

■

Checklist sidebars contain useful lists of items that can be checked when performing a particular task.

■

Best Practice sidebars introduce effective approaches that have been proved in practice.

■

Pitfall sidebars introduce approaches that are best avoided because they result in negative consequences.

We use the Unified Modeling Language (UML) to a large extent in this book to describe certain aspects of the architecture. All UML diagrams have been created with IBM Rational Software Architect.

Website This book has an accompanying website, processofsoftwarearchitecting.com, where readers can find additional information and also interact with the authors.

This page intentionally left blank

Acknowledgments

Two pivotal figures were involved as this book was written. The first is Grady Booch, who not only sowed the seed from which this book grew, but also kindly wrote the foreword, provided detailed review comments, and was supportive throughout. The second is Philippe Kruchten, who never ceases to amaze with his anecdotes and experience. Again, Philippe was supportive throughout by providing many suggestions, acting as an interviewee and reviewer, and providing introductions to several architects to whom we spoke in the course of writing this book. We would also like to thank Brad Appleton, Dave Braines, Alan Brown, Mark Dickson, Celso Gonzalez, Holger Heuss, Bobby Higgins, Rich Hilliard, Kelli Houston, Brad Jackson, Robert Kitzberger, Colin Renouf, Nick Rozanski, Rick Smith, and Eoin Woods for their detailed review comments. This book is so much better for them. Of all the architects and project managers who were interviewed, several gave up a significant amount of their time to work with us. They are Ian Charters, Philippe Kruchten, Helen McCann, Gordon McClean, and Nick Rozanski. We’d also like to thank the many customers, colleagues, and acquaintances who have influenced our work and, therefore, this book. Unfortunately, there are too many individuals to mention, but we’d specifically like to thank our many IBM colleagues, attendees of the WICSA (Working IEEE/IFIP Conference on Software Architecture) conferences, members of IFIP (the International

xxiii

xxiv | Acknowledgments

Federation for Information Processing) Workgroup 2.10 (Software Architecture), and the British Computer Society (BCS) Software Practice Advancement (SPA) specialist group. The meetings and conferences in particular have given us exposure to the leading lights in both industry and academia. Finally, we’d like to thank everyone at Pearson Education who has been part of this project. In particular, we’d like to thank our acquisitions editor, Chris Guzikowski, as well as Raina Chrobak, Sheri Cain, and the production team.

About the Authors

Peter Eeles is an IBM executive IT architect, working within the Rational brand of IBM’s Software Group. In this capacity he helps organizations improve their software development capability, with a particular focus on and interest in improving the architecting process. Peter has been in the software industry since 1985 and has spent much of his career architecting and implementing large-scale, distributed systems. Peter is coauthor of Building J2EE Applications with the Rational Unified Process (Addison-Wesley, 2002) and coauthor of Building Business Objects (John Wiley & Sons, 1998). He is a fellow of the British Computer Society (FBCS), a fellow of the Institute of Engineering and Technology (FIET), an IBM technical staff member, an Open Group Master Certified IT architect, and a Chartered IT Professional (CITP). Peter Cripps is an IT architect in IBM Global Business Services in the United Kingdom. He has been in the software industry since 1980, during which time he has worked as a programmer, real-time software engineer, and process engineer across a range of industries, including telecommunications, financial services, retail, and government. Peter’s particular areas of technical expertise and interest are the application of component- and service-based development techniques and the development of good architecture practice. He is a member of the British Computer Society (MBCS) and a Chartered IT Professional (CITP).

xxv

This page intentionally left blank

Chapter 1 Introduction

Bjarne Stroustrup, the inventor of the C++ programming language, once said, “Our civilization runs on software.” Software does indeed touch many aspects of our everyday lives and is found in something as simple as a birthday card that sings “Happy Birthday” when opened through to the ubiquitous cell phone and, of course, in very complex systems such as airplanes and nuclear power stations. In fact, many of the innovations that we take for granted today, and organizations such as eBay or Amazon, simply wouldn’t exist if it weren’t for software. Even traditional organizations, such as those in the finance, retail, and public sectors, depend heavily on software. In this day and age, it’s difficult to find an organization that isn’t in the software business in some way. This is where the process of architecting comes in. If this increasing reliance on software is to be sustained, the software needs to provide the required capability, be of sufficient quality, be available when promised, and get delivered at an acceptable price. All these characteristics are directly influenced by the architecture of the software, and it follows that if we do a good job of architecting it, we’re more likely to meet our desired objectives. The purpose of this book is to guide you through the tasks and associated best practices that are applied in architecting a software system. In meeting this objective, the book will address some basic questions, such as these: ■

What is an architecture?

■

What is the role of the architect on a software development project?

1

2 | Chapter 1 Introduction ■

What is the relationship of the architect to the other project roles?

■

What is the architect’s role with respect to requirements?

■

How is an architecture described?

■

When and how does the architect produce an initial architecture?

■

How does the architect refine the architecture?

■

When does the architect consider reuse?

■

How is an architecture validated?

Applying the Process In answering such questions, we present a series of best practices that are manifest in the roles, tasks, and work products described throughout this book. A practice is an approach to solving one or several commonly occurring problems. Practices are intended as “chunks” of process for adoption, enablement, and configuration. (RUP 2008)

These practices can be incorporated within any process you might use, including those characterized as a waterfall process, an iterative development process (such as the Rational Unified Process), or an agile process (such as Scrum). As such, we don’t associate the practices with any process in particular, although we do present the practices in a sequence that allows us to demonstrate the relationships among them and their relevance at different points in the project lifecycle. You are encouraged to pick and choose those practices that will add the most value to your projects and, of course, your architectures.

The Process in Brief Getting straight to the point, we thought it would be worthwhile to provide a brief tour of the key process elements described in this book to whet your appetite. Here, we focus on a single pass through the tasks described in detail in this book (which we will refer to as an iteration) although, of course, we may execute each of the tasks many times on a project. A high-level overview of the macro activities that comprise the process is shown in Figure 1.1, aligned with software engineering disciplines. [A discipline is a] primary categorization mechanism for organizing tasks that define a major “area of concern: and/or cooperation of work effort. (OpenUP 2008)

The Process in Brief | 3

Requirements

Architecture

Development

Define Requirements

Create Logical Architecture

Create Logical Detailed Design

Create Physical Architecture

Create Physical Detailed Design

Figure 1.1 Activity Overview

As you can see, the architecting activities sit between requirements and development. The iteration starts with the definition of the software requirements in the Define Requirements activity. Although this activity is primarily the responsibility of the business analyst, the architect will participate in some of the detailed tasks that comprise this activity. The architect subsequently creates a first-cut architecture in the Create Logical Architecture activity. The resulting architecture is independent of any technology considerations and is referred to as the logical architecture. Consider this a stepping stone in getting from the requirements to a physical architecture, which is technology-specific and forms the basis of implementation (coding). The logical architecture is input to any detailed design that is performed in the Create Logical Detailed Design activity. This activity results in the addition of any remaining detail that may be required at a logical level but is not considered to be architectural. For an explanation of the difference between architecture and detailed design, see the sidebar “Concept: Architecture versus Design.” Based on the requirements, logical architecture, and logical detailed design, the architect then refines the architecture in the Create Physical Architecture activity, which takes technology into account, resulting in the physical architecture. This is input to any detailed design that is performed in the Create Physical Detailed Design activity, which forms the basis of implementation.

4 | Chapter 1 Introduction

Concept: Architecture versus Design All architecture is design, but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. (Booch 2009) Put another way, architecture can be considered to be strategic design, whereas detailed design is considered to be tactical design.

Although the detailed design and implementation activities are not the responsibility of the architect, they provide guidance to the team as needed. The arrows linking the activities aren’t intended to show a hard-and-fast sequence—just a likely sequence. Based on the architecting performed, you may find that clarification of the requirements is needed and may revisit the requirements as a result, for example. So let’s now look a little deeper into a few of these activities so that you can better appreciate the role of the architect within the iteration. The detailed tasks that comprise the Define Requirements activity are shown in Figure 1.2. The iteration starts with the Collect Stakeholder Requests task, which, as its name suggests, focuses on understanding the needs of the various stakeholders. The requests provide the architect an initial indication of the scope of the system to be architected. After a vocabulary of terms is developed in the Capture Common Vocabulary task, the Define System Context task is of particular interest to the architect, because it defines the external elements that must interact with the system, such as end users and other systems. Based on this context, the Outline Functional Requirements and Outline Non-Functional Requirements tasks identify the functional and non-functional requirements, respectively. The architect is interested not only in the key functional requirements, but also in the system qualities (such as performance) and solution constraints that comprise the non-functional requirements, which are often more challenging to address than the functional requirements. The architect is involved, to some extent, throughout the Define Requirements activities to ensure that the requirements are specified in a manner that can be realistically achieved with available technology, within the required schedule, and within budget. This often requires a degree of negotiation with stakeholders in which the architect actively participates. As far as requirements tasks are concerned, the architect is particularly involved in the Prioritize Requirements task, in which the architect ensures that the priorities are influenced by those requirements and risks that will allow the architecture to stabilize as soon as possible.

The Process in Brief | 5

Collect Stakeholder Requests

Capture Common Vocabulary

Define System Context

Outline Functional Outline Non-Functional Requirements Requirements

Prioritize Requirements

Detail Functional Requirements

Detail Non-Functional Requirements

Update Software Review Requirements Architecture Document with Stakeholders

Figure 1.2 Tasks in the Define Requirements Activity

The prioritized requirements drive the content of the remainder of the iteration, in the sense that only the highest-priority requirements are considered, because the extent to which you address these requirements determines whether you have a viable system. (Lower-priority requirements are considered in subsequent iterations.) The high-priority requirements are detailed in the Detail Functional Requirements and Detail Non-Functional Requirements tasks. Then the architect formally documents a summary of the architecturally significant requirements in the Update Software Architecture Document task. The requirements-related tasks conclude with a review of the requirements in the Review Requirements with Stakeholders task. As for activities, the arrows linking the tasks aren’t intended to show a hard-and-fast sequence (just a likely sequence), and tasks may be revisited as required.

6 | Chapter 1 Introduction

The tasks that comprise the Create Logical Architecture activity are shown in Figure 1.3. Throughout this activity, the architect considers the use of existing assets in the Survey Architecture Assets task. Even early in the project, you may, as an architect, select an asset such as a reference architecture that has a significant influence on your architecture. As each task is performed, the architect captures those decisions in the Document Architecture Decisions task. Based on the highest-priority requirements, the architect outlines the candidate solution in the Define Architecture Overview task. The architecture overview provides the “big picture” outline of the architecture. Then the Outline Functional Elements and Outline Deployment Elements tasks are performed concurrently, subsequently refining this outline in terms of components, their interactions and relationships, and their deployment on nodes. The Verify Architecture task ensures that the various functional and deployment elements that make up the architecture are consistent with one another and, in

Survey Architecture Assets

Outline Functional Elements

Document Architecture Decisions

Define Architecture Overview

Outline Deployment Elements Verify Architecture

Detail Functional Elements

Build Architecture Proof-of-Concept

Detail Deployment Elements

Validate Architecture

Update Software Review Architecture Architecture Document with Stakeholders

Figure 1.3 Tasks in the Create Logical Architecture Activity

The Process in Brief | 7

particular, ensures that any concerns that cut across these elements (for example, a quality such as performance that influences both functional and deployment elements) have been addressed appropriately. We acknowledge that functional and deployment elements do not necessarily dominate every architecture (for example, concurrency elements may dominate a real-time, embedded system), so in Chapter 4, “Documenting a Software Architecture,” we introduce an extensible architecture description framework for accommodating such concerns. The architect also focuses on proving certain aspects of the architecture in the Build Architecture Proof-of-Concept task. The objective is to synthesize at least one solution (which may simply be conceptual rather than physical) that satisfies the architecturally significant requirements to determine whether such a solution, as envisaged by the architect, exists. In particular, the proof-of-concept provides a vehicle for mitigating certain architecture-related risks and often takes the form of executable software that allows system functionality and qualities to be assessed. Next, the architectural elements are detailed in the Detail Functional Elements and Detail Deployment Elements tasks. The Validate Architecture task ensures that the architectural elements will satisfy the requirements as stated (both functional and non-functional), as well as project considerations such as resource, budget, and schedule constraints. Then the architect documents a summary of the platform-independent architecture in the Update Software Architecture Document task. The resulting architecture description is used to communicate the architecture to the relevant stakeholders, including designers, programmers, testers, project manager, maintainers, and support personnel. Finally, the Review Architecture with Stakeholders task allows agreement on the architecture to be established. As indicated in Figure 1.1, the set of architecture-related work products subsequently feeds into the Create Logical Detailed Design activity, which adds detail to the identified architecture elements, before moving on to the Create Physical Architecture activity. The Create Physical Architecture activity contains exactly the same tasks as those in the Create Logical Architecture activity but takes technology considerations into account. Therefore, the tasks adopt additional best practices that acknowledge this difference. The set of architecture-related work products that is output from the Create Physical Architecture activity feeds into the Create Physical Detailed Design activity, which adds the relevant level of detail to the identified architecture elements and which can be used as the basis of implementation. The implementation ultimately results in an executable release of software that is then tested to ensure that it meets the requirements associated with the current iteration. Feedback on the architecture from

8 | Chapter 1 Introduction

the architecture review and testing activities helps guide the priorities for, and content of, the next iteration. So there you have it—a complete iteration in terms of those tasks that most influence the architecture! Much more detail exists behind each of these tasks, which we briefly outline in this chapter. We elaborate on these tasks and the architecture principles on which they are based in the remainder of this book.

Scope This book focuses on software-intensive systems. Thus, the terms architecture, architect, and architecting, when unqualified, are synonymous with the terms software architecture, software architect, and software architecting, respectively. Although this book focuses on software-intensive systems, several additional considerations are discussed later in this book. It is important to remember, for example, that a software-intensive system still needs hardware to execute and that certain qualities, such as reliability or performance, are achieved only through a combination of software and hardware. Therefore, this aspect of the total solution cannot be ignored and will be considered in subsequent discussions. You should also be conscious that software-intensive systems support an even broader picture in which you may consider systems that comprise people and information to be first-class citizens, as well as software and hardware. An even broader perspective is consideration of an enterprise architecture that provides, among other things, a landscape of business processes and existing IT systems, as well as a view of business change initiatives that include transition planning and governance. Enterprise architecture and systems engineering are outside the scope of this book, although we do acknowledge such perspectives and the influences they have in terms of guiding and constraining our work as software architects.

Summary This chapter focused on setting the scene for the remainder of the book. Before diving into the details, we need to establish some core concepts, which we use extensively in the remaining chapters. These concepts are the role of the architect, the characteristics of the architecting tasks that they perform, and the architecture that results. All these concepts are described in Chapter 2.

Chapter 2 Architecture, Architect, Architecting

This chapter provides an overview of three of the core concepts related to the subject of this book and concludes with a discussion of the benefits of architecting. These concepts, as shown in Figure 2.1, are the role of the architect, the characteristics of the architecting tasks they perform, and the architecture that results.

Architecture There is no shortage of definitions when it comes to architecture. Even some websites maintain collections of definitions (SEI 2009). The definition used in this book is that taken from IEEE 1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems (IEEE 1471 2000). This definition follows, with key characteristics highlighted: [Architecture is] The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. (IEEE 1471 2000)

9

10 | Chapter 2 Architecture, Architect, Architecting

- performs Architect

Architecting

- creates

- results in Architecture

Figure 2.1 Core Concepts Used in This Book

This standard also defines the following terms related to this definition: [A system is] a collection of components organized to accomplish a specific function or set of functions. The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest. A system exists to fulfill one or more missions in its environment. (IEEE 1471 2000) The environment, or context, determines the setting and circumstances of developmental, operational, political, and other influences upon that system. (IEEE 1471 2000) A mission is a use or operation for which a system is intended by one or more stakeholders to meet some set of objectives. (IEEE 1471 2000) [A system stakeholder is] an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. (IEEE 1471 2000)

As you can see, the term component is used in this definition. Most definitions of architecture do not define the term component, however, and IEEE 1471 is no exception, choosing to leave it deliberately vague because the term is intended to cover the many interpretations in the industry. A component may be logical or physical, technology-independent or technology-specific, large-grained or small-grained. For the purposes of this book, we use the definition of component from the Unified Modeling Language (UML) 2.2 specification: A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces. As

Architecture | 11

such, a component serves as a type whose conformance is defined by these provided and required interfaces (encompassing both their static as well as dynamic semantics). One component may therefore be substituted by another only if the two are type conformant. (UML 2.2 2009)

It is worth considering some other definitions of architecture so that you can observe similarities among those definitions. Consider the following definitions, in which some of the key characteristics are highlighted: An architecture is the set of significant decisions about the organization of a software system, the selection of structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these elements into progressively larger subsystems, and the architectural style that guides this organization—these elements and their interfaces, their collaborations, and their composition. (Kruchten 2000) The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. (Bass 2003) The software architecture of a system or a collection of systems consists of all the important design decisions about the software structures and the interactions between those structures that comprise the systems. The design decisions support a desired set of qualities that the system should support to be successful. The design decisions provide a conceptual basis for system development, support, and maintenance. (McGovern 2004)

You can see that although the definitions are somewhat different, they have a large degree of commonality. Most definitions indicate that an architecture is concerned with both structure and behavior, is concerned with significant elements only, may conform to an architectural style, is influenced by its stakeholders and its environment, and embodies decisions based on rationale. All these themes and others are discussed in the following sections.

An Architecture Defines Structure If you were to ask someone to describe architecture to you, nine times out of ten, that person would make some reference to something related to structure, quite often in relation to a building or some other civil-engineering structure,

12 | Chapter 2 Architecture, Architect, Architecting

Order Entry

Customer Management

Account Management

Figure 2.2 UML Component Diagram Showing Structural Elements

such as a bridge. Although other characteristics of these items exist, such as behavior, fitness for purpose, and even aesthetics, the structural characteristic is the most familiar and the most often mentioned. It should not surprise you, then, that if you ask someone to describe the architecture of a software system that he or she is working on, you’ll probably be shown a diagram that shows the structural aspects of the system, whether these aspects are architectural layers, components, or distribution nodes. Structure is indeed an essential characteristic of an architecture. The structural aspects of an architecture manifest themselves in many ways, and most definitions of architecture are deliberately vague as a result. A structural element could be a subsystem, a process, a library, a database, a computational node, a legacy system, an off-the-shelf product, and so on. Many definitions of architecture also acknowledge not only the structural elements themselves, but also the composition of structural elements, their relationships (and any connectors needed to support these relationships), their interfaces, and their partitioning. Again, each of these elements can be provided in a variety of ways. A connector, for example, could be a socket, be synchronous or asynchronous, be associated with a particular protocol, and so on. Figure 2.2 shows an example of some structural elements. This figure shows a UML component diagram containing some structural elements in an order processing system. You see three components, named Order Entry, Customer Management, and Account Management. The Order Entry component is shown as depending on the Customer Management component and also on the Account Management component, indicated by a UML dependency.

An Architecture Defines Behavior As well as defining structural elements, an architecture defines the interactions among these structural elements. These interactions provide the desired system behavior. Figure 2.3 is a UML sequence diagram showing several interactions that, together, allow the system to support the creation of an order in an order pro-

Architecture | 13

:Sales Clerk

:Order Entry

:Customer Management

:Account Management

1: create order 1.1: get customer details

1.2: create order

loop [1,*]

1: add order item

1.3: place order

Figure 2.3 UML Sequence Diagram Showing Behavioral Elements

cessing system. The figure shows five interactions. First, a Sales Clerk actor creates an order by using an instance of the Order Entry component. The Order Entry instance gets customer details by using an instance of the Customer Management component. Then the Order Entry instance uses an instance of the Account Management component to create the order, populate the order with order items, and place the order. It should be noted that Figure 2.3 is consistent with Figure 2.2 in that you can derive the dependencies shown in Figure 2.2 from the interactions defined in Figure 2.3. An instance of Order Entry, for example, depends on an instance of Customer Management during its execution, as shown by the interactions in Figure 2.3. This dependency is reflected in a dependency relationship between the corresponding Order Entry and Customer Management components, as shown in Figure 2.2.

An Architecture Focuses on Significant Elements Although an architecture defines structure and behavior, it is not concerned with defining all the structure and all the behavior. It is concerned only with those elements that are deemed to be significant. Significant elements are those

14 | Chapter 2 Architecture, Architect, Architecting

that have a long and lasting effect, such as the major structural elements, those elements associated with essential behavior, and those elements that address significant qualities such as reliability and scalability. In general, the architecture is not concerned with the fine-grained details of these elements. Architectural significance can also be phrased as economical significance, because the primary drivers for considering certain elements over others are the cost of creation and the cost of change. Because an architecture focuses on significant elements only, it provides a particular focus of the system under consideration—the focus that is most relevant to the architect. In this sense, an architecture is an abstraction of the system that helps an architect manage complexity. It is also worth noting that the set of significant elements is not static and may change over time. As a consequence of requirements being refined, risks identified, executable software built, and lessons learned, the set of significant elements may change. The relative stability of the architecture in the face of change, however, is to some extent the sign of a good architecture, the sign of a well-executed architecting process, and the sign of a good architect. Continual revision of the architecture due to relatively minor changes is not a good sign. If the architecture is relatively stable, however, the converse is true.

An Architecture Balances Stakeholder Needs An architecture is created ultimately to address a set of system stakeholder needs, but often, meeting all the expressed needs is not possible. A stakeholder may ask for some functionality within a specified time frame, for example, but the two needs—functionality and time frame—are mutually exclusive. Either the scope can be reduced to meet the schedule, or all the functionality can be provided within an extended time frame. Similarly, different stakeholders may express conflicting needs, and again, an appropriate balance must be achieved. Making trade-offs, therefore, is an essential aspect of the architecting process, and negotiation is an essential characteristic of the architect. Just to give you an idea of the task at hand, consider the following needs of a set of stakeholders: ■

The needs of the end user are associated with intuitive and correct behavior, performance, reliability, usability, availability, and security.

■

The needs of the system administrator are associated with intuitive behavior, administration, and tools to aid monitoring.

■

The needs of the marketer are associated with competitive features, time to market, positioning with other products, and cost.

Architecture | 15 ■

The needs of the customer are associated with cost, stability, and schedule.

■

The needs of the developer are associated with clear requirements and a simple, consistent design approach.

■

The needs of the project manager are associated with predictability in the tracking of the project, schedule, productive use of resources, and budget.

■

The needs of the maintainer are associated with a comprehensible, consistent, and documented design approach, as well as the ease with which modifications can be made.

Another challenge for the architect, as you can see from this list, is that the stakeholders are not concerned only that the system provide the required functionality. Many of the concerns that are listed are non-functional in nature (in that they do not contribute to the functionality of the system). Such concerns represent system qualities or constraints. Non-functional requirements are quite often the most significant requirements as far as an architect is concerned; they are discussed in detail in Chapter 7, “Defining the Requirements.”

An Architecture Embodies Decisions Based on Rationale An important aspect of an architecture is not just the end result—the architecture itself—but also the rationale that explains why it is the way it is. Thus, as described in Chapter 4, “Documenting a Software Architecture,” important considerations are the documenting of the decisions that led to this architecture and the rationale for these decisions. This information is relevant to many stakeholders, especially those who must maintain the system. This information is often valuable to the architects themselves when they need to revisit the rationale behind the decisions that were made, so that they don’t end up having to retrace their steps unnecessarily. This information is used when the architecture is reviewed and the architect needs to justify the decisions that have been made, for example. Also, some of these decisions may have been imposed on the architect and, in this sense, represent constraints on the solution. A companywide policy to use particular technologies and products may exist, for example, and this policy needs to be accommodated in the solution.

An Architecture May Conform to an Architectural Style Most architectures are derived from systems that have a similar set of concerns. This similarity can be described as an architectural style, a term borrowed from the styles used in building architectures. You can think of an architectural

16 | Chapter 2 Architecture, Architect, Architecting

style as being a particular kind of pattern, albeit an often complex and composite pattern (several patterns applied together). Every well-structured software-intensive system is full of patterns. (Booch 2009)

An architectural style represents a codification of experience, and it is good practice for architects to look for opportunities to reuse such experience. Examples of architectural styles include a distributed style, a pipes-and-filters style, a data-centered style, a rule-based style, service-oriented architecture, and so on. Architectural styles are discussed further in Chapter 5, “Reusable Architecture Assets.” A given system may exhibit more than one architectural style. [An architectural style] defines a family of systems in terms of a pattern of structural organization. More specifically, an architectural style defines a vocabulary of components and connector types, and a set of constraints on how they can be combined. (Shaw 1996)

The application of an architectural style (and reusable assets in general) makes the life of an architect somewhat easier because such assets are already proved, thereby reducing risk and, of course, effort. A style is normally documented in terms of the rationale for using it (so there is less thinking to be done) and in terms of its key structures and behaviors (so there is less architecture documentation to be produced because you can simply refer to the style instead). Architecture assets are discussed in detail in Chapter 5, “Reusable Architecture Assets.”

An Architecture Is Influenced by Its Environment A system resides in an environment, and this environment influences the architecture. This is sometimes referred to as architecture in context. In essence, the environment determines the boundaries within which the system must operate, which then influence the architecture. The environmental factors that influence the architecture include the business mission that the architecture will support, the system stakeholders, internal technical constraints (such as the requirement to conform to organizational standards), and external technical constraints (such as the need to use a specified technology, interface to an external system, or conform to external regulatory standards). Conversely, as eloquently described in Software Architecture in Practice, 2nd ed. (Bass 2003), the architecture may also influence its environment. The

Architecture | 17

creation of an architecture may contribute reusable assets to the owning organization, for example, thereby making such assets available to the next development effort. Another example is the selection of a software package that is used within the architecture, such as a customer relationship management (CRM) system, which subsequently requires users to change the processes they follow to accommodate the way that the package works.

An Architecture Influences Development Team Structure An architecture defines coherent groupings of related elements that address a given set of concerns. An architecture for an order processing system, for example, may have defined groupings of elements for order entry, account management, customer management, fulfillment, integrations with external systems, persistence, and security. Each of these groupings may require different skill sets. Therefore, it makes perfect sense to align the software development team structures with the architecture after it has been defined. Often, however, the architecture is influenced by the initial team structure and not vice versa. This pitfall is best avoided, because the result typically is a less-than-ideal architecture. Conway’s Law states, “If you have four groups working on a compiler, you’ll get a four-pass compiler.” In practice, architects often unintentionally create architectures that reflect the organization creating the architecture. Although organizing work in line with the architecture can be beneficial, this somewhat idealized view is not always practical. For purely pragmatic reasons, the current team structure and the skills available (both in the current team and the maintenance teams) represent a very real constraint on what is possible, and the architect must take this constraint into account. The geographic distribution of the team is another constraint that needs to be accommodated: The architectural partitioning should reflect the geographic partitioning, and vice versa. Architectural responsibilities should be assigned so decisions can be made (geographically) locally. (Coplien 2005)

An Architecture Is Present in Every System It is also worth noting that every system has an architecture, even if this architecture is not formally documented or if the system is extremely simple and, say, consists of a single element. Documenting the architecture usually has

18 | Chapter 2 Architecture, Architect, Architecting

considerable value; this topic is discussed in detail in Chapter 4, “Documenting a Software Architecture.” Ultimately, every software-intensive system has an architecture, be it intentional or accidental. Every such architecture serves to hold back the forces upon that system in a manner that is functional, economical and elegant. (Booch 2009)

If an architecture is not documented, it is difficult (if not impossible) to assess the architecture and prove that it meets the stated requirements in terms of development-time qualities such as flexibility, accommodation of best practices, and so on. A lack of documentation can also make it extremely difficult to maintain the system over time.

An Architecture Has a Particular Scope Many kinds of architecture exist, the best known being the architecture associated with buildings and other civil-engineering structures. Even in the field of software engineering, you often come across different forms of architecture. In addition to the concept of software architecture, for example, you may encounter concepts such as enterprise architecture, system architecture, information architecture, hardware architecture, application architecture, infrastructure architecture, and data architecture. You also hear other terms mentioned. Each of these terms defines a specific scope of the architecting activities. Unfortunately, the industry has come to no agreement on the meanings of all these terms or their relationships to one another, resulting in different meanings for the same term (homonyms) and two or more terms that mean the same thing (synonyms). You can infer the scope of some of these terms, as used in this book, from Figure 2.4, in which we focus on the architecture of softwareintensive systems. As you consider this figure and the discussion that follows it, you will almost certainly find elements that you disagree with or that you use differently within your organization. Consider this example to be an acknowledgment of (and one interpretation of) several possible scopes of architecting activities. Inspiration for the elements shown in Figure 2.4 came from various sources. IEEE Std 12207-1995, the IEEE Standard for Information Technology— Software Life Cycle Processes, defines a system as follows: [A system is] an integrated composite that consists of one or more of the processes, hardware, software, facilities and people, that provides a capability to satisfy a stated need or objective. (IEEE 12207 1995)

Architecture | 19

Enterprise System Software

Hardware

Workers

Information

Figure 2.4 Different Architecting Scopes

A configuration of the Rational Unified Process for Systems Engineering (RUP SE), also known as Model-Driven Systems Development (MDSD), contains a similar definition: [A system is] a set of resources that provide services that are used by an enterprise to carry out a business purpose or mission. System components typically consist of hardware, software, data, and workers. (Cantor 2003)

The various elements shown in Figure 2.4 are ■

Software. This element is the main focus of this book and considers items such as components, relationships between components, and interactions between components.

■

Hardware. This element considers items such as CPUs, memory, hard disks, peripheral devices such as printers, and the elements used to connect these elements.

■

Information. This element considers the information used within the system.

■

Workers. This element considers the people-related aspects of a system, such as business processes, organizational structures, roles and responsibilities, and core competencies of the organization.

■

System. As described in the preceding definitions, a system comprises software, hardware, information, and workers.

■

Enterprise. This element is similar to a system in that it, too, considers elements such as hardware, software, information, and workers. An enterprise, however may span multiple systems and place constraints on the

20 | Chapter 2 Architecture, Architect, Architecting

systems that are part of the enterprise. An enterprise also has a stronger link to the business than a system does, in that an enterprise focuses on the attainment of the business objectives and is concerned with items such as business strategy, business agility, and organizational efficiency. Further, an enterprise may cross company boundaries. Because we focus on software-intensive systems in this book, it is worth making some additional observations. In particular, we should note that a softwareintensive system is a system. Therefore, you should understand the relationship between the software and those elements with which it must coexist: ■

Software and workers. Although workers are not considered to be part of the systems considered by this book, a relationship exists in terms of the functionality that the system must provide to support any people who interact with the system. Ensuring that this functionality is provided is, in this book, the responsibility of the application architect.

■

Software and hardware. A particular aspect of the environment that must always be considered in software-intensive systems is the hardware on which the software executes. The resulting system, therefore, is a combination of software and hardware, and this combination allows properties such as reliability and performance to be achieved. Software cannot achieve these properties in isolation from the hardware on which it executes. Ensuring the appropriate consideration of hardware is, in this book, the responsibility of the infrastructure architect.

■

Software and information. Software elements may produce and consume persistent information during their execution. Ensuring the appropriate consideration of information is, in this book, the responsibility of the data architect.

For each specific type of architecture, a corresponding type of architect exists (software architect, hardware architect, and so on), as well as a corresponding type of architecting (software architecting, hardware architecting, and so on). Now that you’ve gotten through these definitions, you may have many unanswered questions. What is the difference between an enterprise architecture and a system architecture? Is an enterprise a system? Is an information architecture the same as the data architecture found in some data-intensive software applications? Unfortunately, no set of agreed-on answers to these questions exists. For now, be aware that these different terms exist but that the

Architect | 21

industry has no consistent definition of these terms and how they relate to one another. We recommend, therefore, that you select the terms that are relevant to your organization and define them appropriately. Then you will achieve some consistency, at least, and reduce the potential for miscommunication.

Architect Now that we have defined what we mean by architecture, we can turn our attention to the role that is responsible for the creation of the architecture: the architect. The role of the architect is arguably the most challenging in any software development project. The architect is the technical lead on the project and, from a technical perspective, ultimately carries responsibility for the technical success or failure of the project. [An architect is] the person, team, or organization responsible for systems architecture. (IEEE 1471 2000)

As the technical lead on the project, the architect must have skills that are typically broad rather than deep (although architects should have deep skills in particular areas).

The Architect Is a Technical Leader First and foremost, the architect is a technical leader, which means that in addition to having technical skills, the architect exhibits leadership qualities. Leadership can be characterized in terms of both position in the organization and the qualities that the architect exhibits. In terms of position in the organization, the architect (or lead architect, if the architect role is fulfilled by a team) is the technical lead on the project and should have the authority to make technical decisions. The project manager, on the other hand, is more concerned with managing the project plan in terms of resources, schedule, and cost. Using the film industry as an analogy, the project manager is the producer (making sure that things get done), whereas the architect is the director (making sure that things get done correctly). As a result of their positions, the architect and project manager represent the public persona of the project and, as a team, are the main contact points as far as people outside the project are concerned. The architect in particular should be an advocate of the investment made in creating an architecture and the value it brings to the organization.

22 | Chapter 2 Architecture, Architect, Architecting

The architect should also be involved in determining how the team is populated, because the architecture will imply the need for certain skills. Dependencies among elements of the architecture influence the sequencing of tasks and, therefore, when these skills are required, so the architect should contribute actively to planning activities. On a related note, because the success of the architect is closely linked to the quality of the team, participation in interviewing new team members is also highly appropriate. In terms of the qualities that the architect exhibits, leadership can also be characterized in terms of interactions with other team members. Specifically, the architect should lead by example and show confidence in setting direction. Successful architects are people-oriented, and all architects take time to mentor and train members of their team. This practice benefits the team members in question, the project, and ultimately the organization itself, because some of its most valuable assets (people) become better skilled. Also, architects need to be very focused on the delivery of tangible results and must act as the driving force for the project from a technical perspective. Architects must be able to make decisions (often under pressure) and make sure that those decisions are communicated, that they are understood, and that they ultimately stick.

The Architect Role May Be Fulfilled by a Team There is a difference between a role and a person. One person may fulfill many roles (Mary is a developer and a tester), and a role may be fulfilled by many people (Mary and John fulfill the role of tester). Given the requirement for a very broad set of skills in an architect, it is often the case that the architect role is fulfilled by more than one person. This practice allows the skills to be spread across several people, each bringing his or her own experiences to bear. In particular, the skills required to understand both the business domain and various aspects of technology are often best spread across several people. The resulting team needs to be balanced, however. Throughout this book, the term architect refers to the role, which may be fulfilled by either an individual or a team. [A team is] a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable. (Katzenbach 1993)

If the architect role is to be fulfilled by a team, it is important to have one individual who is considered to be the lead architect, who is responsible for owning the vision, and who can act as a single point of coordination across the

Architect | 23

architecture team. Without this point of coordination, there is a danger that members of the architecture team will not produce a cohesive architecture or that decisions will not be made. For a team that is new to the concept of architecture, it has been suggested that to achieve this common purpose, goals, and approach, the team should create and publish a team charter (Kruchten 1999). Good architects know their strengths and weaknesses. Whether or not the architect role is fulfilled by a team, an architect is supported by several trusted advisors. Such architects acknowledge where they are weak and compensate for these weaknesses by obtaining the necessary skills or by working with other people to fill the gaps in their knowledge. The best architectures usually are created by a team rather than an individual, simply because there is greater breadth and depth of knowledge when more than one person is involved. One pitfall with the concept of an architecture team, especially on large projects, is that it may be perceived as an ivory tower whose output is intellectual rather than useful. This misconception can be minimized from the outset by ensuring that all the stakeholders are actively consulted, that the architecture and its value are communicated, and that any organizational politics in play are considered.

The Architect Understands the Software Development Process Most architects have been developers at some point and should have a good appreciation of the need to define and endorse best practices used on the project. More specifically, the architect should have an appreciation of the software development process, because this process ensures that all the members of the team work in a coordinated manner. This coordination is achieved by defining the roles involved, the tasks undertaken, the work products created, and the handoff points among the different roles. Because architects are involved with many of the team members on a daily basis, it is important for them to understand the team members’ roles and responsibilities, as well as what they are producing and using. In essence, team members look to the architect for guidance on how to fulfill their responsibilities, and the architect must be able to respond in a manner that is consistent with the development process being followed by the team.

The Architect Has Knowledge of the Business Domain As well as having a grasp of software development, it is also highly desirable (some would say essential) for architects to have an understanding of the business domain so that they can act as intermediaries between stakeholders and

24 | Chapter 2 Architecture, Architect, Architecting

users, who understand the business, and the members of the development team, who may be more familiar with technology. [A domain is] an area of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that area. (UML User Guide 1999)

Knowledge of the business domain also allows the architect to better understand and contribute to the requirements on the system, as well as to be in a position to ensure that likely requirements are captured. Also, a particular domain often is associated with a particular set of architectural patterns (and other assets) that can be applied in the solution, and knowing this mapping can greatly assist the architect. Therefore, a good architect has a good balance of software development knowledge and business domain knowledge. When architects understand software development but not the business domain, a solution may be developed that does not fit the problem, but instead reflects the comfort zone of things that the architect is familiar with. Familiarity with the business domain also allows architects to anticipate likely changes in their architecture. Given that the architecture is heavily influenced by the environment in which it will be deployed, which includes the business domain, an appreciation of the business domain allows the architect to make better-informed decisions in terms of likely areas of change and the areas of stability. If the architect is aware that new regulatory standards will need to be adhered to at some point in the future, this requirement should be accommodated in the architecture, for example.

The Architect Has Technology Knowledge Certain aspects of architecting clearly require knowledge of technology, so an architect should have a certain level of technology skills. An architect does not need to be a technology expert as such, however, and needs to be concerned only with the significant elements of a technology, not the detail. The architect may understand the key frameworks available in a platform such as Java EE or .NET, but not necessarily the detail of every application programming interface (API) that is available to access these platforms. Because technology changes fairly frequently, it is essential that the architect keep abreast of these changes.

The Architect Has Design Skills Although architecting is not confined solely to design (as you have seen, the architect is also involved in requirements tasks), design clearly is the core

Architect | 25

aspect of architecting. The architecture embodies key design decisions, so the architect should possess strong design skills. Such decisions could represent key structural design decisions, the selection of particular patterns, the specification of guidelines, and so on. To ensure the architectural integrity of the system, these elements are typically applied across the board and can have farreaching effects in terms of the success of the system. Therefore, such elements need to be identified by someone who has the appropriate skills. One does not acquire design prowess overnight; instead, such skill is the result of years of experience. Even expert designers look back on their early work and shudder at how bad it was. As with every other skill, one must practice design in order to obtain proficiency. (Coplien 2005)

The Architect Has Programming Skills The developers on the project represent one of the most important groups that the architect must interact with. After all, their work products ultimately deliver the working executable software. The communication between the architect and the developers can be effective only if the architect is appreciative of the developers’ work. Therefore, architects should have a certain level of programming skills, even if they do not necessarily write code on the project, and those skills need to be kept up to date with the technologies being used. The Architect should be organizationally engaged with Developers and should write code. If the architect implements, the development organization perceives buy-in from the guiding architects, and that perception can directly avail itself of architectural expertise. The architects also learn by seeing the first-hand results of their decisions and designs, thus giving them feedback on the development process. (Coplien 2005)

Most successful software architects have, at some stage, been hard-core programmers. To some extent, this experience is how they learned certain aspects of their trade. Even as technologies evolve and new programming languages are introduced, good architects can abstract out the concepts in any programming language and apply this knowledge to learning a new programming language to the depth required. Without this knowledge, the architect will be unable to make decisions with respect to the architecturally significant elements of the implementation, such as the organization of the source code and the adoption of programming standards, and a communication barrier will exist between the architect and the developers.

26 | Chapter 2 Architecture, Architect, Architecting

The Architect Is a Good Communicator Of all of the soft skills associated with the architect, communication is the most important. Effective communication involves several dimensions, and the architect needs to be proficient in all of them. Specifically, the architect should have effective verbal, written, and presentation skills. Also, the communication should be two-way. The architect should be a good listener and a good observer also. Being able to communicate effectively is a skill that is fundamental to the success of the project for many reasons. Clearly, communication with stakeholders is particularly important to understand their needs and also to communicate the architecture in a way that gains (and maintains) agreement with all stakeholders. Communication with the project team is particularly important, because the architect is not responsible simply for conveying information to the team, but also for motivating the team. Specifically, the architect is responsible for communicating (and reinforcing the communication of) the vision for the system so that the vision becomes shared, not something that only the architect understands and believes in.

The Architect Makes Decisions An architect who is unable to make decisions in an environment where much is unknown, where insufficient time to explore all alternatives is available, and where pressure to deliver exists is unlikely to survive. Unfortunately, such environments are the norm rather than the exception, and successful architects acknowledge the situation rather than try to change it. Even though the architect may consult others when making decisions and foster an environment in which others are included in decision-making, it is still the architect’s responsibility to make the appropriate decisions, which do not always prove to be right. Thus, architects need to be thick-skinned, because they may need to correct their decisions and backtrack. An inability to make decisions will slowly undermine the project. The project team will lose confidence in the architect, and the project manager will be concerned because those waiting for the architecture cannot make the required progress. The very real danger is that if the architect does not make and document decisions about the architecture, team members will start to make their own, possibly incorrect, decisions.

The Architect Is Aware of Organizational Politics Successful architects are not only concerned with technology. They also are politically astute and conscious of where the power in an organization resides. They use this knowledge to ensure that the right people are communicated

Architecting | 27

with and that support for a project is aired in the right circles. Ignoring organizational politics is, quite simply, naïve. Politics involves a great deal of ambiguity, which makes many technical people nervous. It forces them to play on “someone else’s court,” as it were, a place where they feel they are at a disadvantage because their technical prowess doesn’t count for much. (Marasco 2004)

The reality is that many forces at work in organizations lie outside the project delivering the system, and these forces need to be accounted for. Human beings tend not to all think alike; in order to resolve differences of opinion, a political process is unavoidable. So, rather than condemn it, it is better to understand politics as an effective means of dealing with the inevitable need to resolve differences of opinion. (Marasco 2004)

The Architect Is a Negotiator Given the many dimensions of architecting, the architect interacts with many stakeholders. Some of these interactions require negotiation skills. A particular focus for the architect is minimizing risk as early as possible in the project, because minimizing risk has a direct correspondence to the time it takes to stabilize the architecture. Because risks are associated with requirements (and changes in requirements), one way to remove a risk is to refine the requirements so that the risk is no longer present—hence, the need to push back on such requirements so that stakeholders and architect can reach a mutually agreeable position. This situation requires the architect to be an effective negotiator who is able to articulate the consequences of different trade-offs.

Architecting Having described what an architecture is, and having defined the characteristics of the architect role, now we can look at some of the themes, or characteristics, that underlie the process of architecting. We will not go into the detail of each task, because this detail is covered throughout the remainder of this book. Also, those characteristics of architecting that can be described in terms of benefits are described later in this chapter. [Software architecting represents] the activities of defining, documenting, maintaining, improving, and certifying proper implementation of an architecture. (IEEE 1471 2000)

28 | Chapter 2 Architecture, Architect, Architecting

The scope of architecting is fairly broad. Figure 2.5 shows a metamodel that defines various aspects of the process of software architecting. This metamodel is derived from that given in the IEEE 1471 standard and can be considered to be a road map through the various aspects of architecting that an architect is concerned with. Additional elements of the metamodel will be considered throughout this book. We elaborate on the Architectural Description element, for example, in Chapter 4, “Documenting a Software Architecture,”

Development Project

- is staffed by

- follows

Team

Development Process

- includes

- includes - performs

Architect

Architecting

- justifies

Rationale 1..*

Architecture Decision

1..*

- provides

- creates

1..*

- results in - described by

Architecture

Architectural Description

1 - has an

- identifies 1..* Stakeholder

- identifies 1..* - is important to 1..*

- has 1..*

- develops System - influences - fulfills 1..* Mission

- inhabits Environment

Figure 2.5 A Metamodel of Architecting-Related Terms

- has 1..*

Concern

1..* - addresses

Architecting | 29

where we consider how an architecture is documented. We provide a complete description of the metamodel used in this book in Appendix A, “Software Architecture Metamodel.” The relationships in this metamodel that are taken directly from the IEEE 1471 standard, in words, are ■

A system has an architecture.

■

A system fulfills one or more missions.

■

A system has one or more stakeholders.

■

A system inhabits an environment.

■

An environment influences a system.

■

An architecture is described by an architectural description.

■

An architectural description identifies one or more stakeholders.

■

An architectural description identifies one or more concerns.

■

An architectural description provides rationale.

■

A stakeholder has one or more concerns.

■

A concern is important to one or more stakeholders.

A side benefit of the IEEE 1471 standard is that it not only applies to documenting a software architecture, but also can be thought of as being a reasoning framework for concepts that architects need to be concerned with in their work. Additional relationships in the figure that are not part of the IEEE 1471 standard are ■

A development project is staffed by a team.

■

A development project follows a development process.

■

A development project develops a system.

■

The development process includes architecting.

■

The team includes an architect.

■

The architect performs architecting

■

The architect creates an architecture.

■

The architect is a kind of stakeholder.

■

Architecting results in an architecture.

■

Rationale justifies one or more architecture decisions.

■

An architecture decision addresses one or more concerns.

30 | Chapter 2 Architecture, Architect, Architecting

Architecting Is a Science Architecting is a recognized discipline, albeit one that is still emerging. With this recognition comes an emphasis on techniques, processes, and assets that focus on improving the maturity of the process of architecting. One way to advance this maturity is to draw on an existing body of knowledge. In general terms, architects look for proven solutions when developing an architecture rather than reinventing the wheel, thereby avoiding unnecessary creativity. Codified experience in terms of reference architectures, architectural and design patterns, and other reusable assets also has a part to play. There is still some way to go, however, before the process of software architecting is anywhere near as mature as, for example, the processes in civil engineering. This maturity can be considered in many dimensions, including the use of standards and an understanding of best practices, techniques, and processes.

Architecting Is an Art Although architecting can be seen as a science, there is always a need to provide some level of creativity, particularly true when dealing with novel and unprecedented systems. In such cases, no codified experience may be available to draw on. Just as painters look for inspiration when faced with a blank canvas, architects may on occasion see their work as being more like an art than a science. For the most part, however, the artistic side of architecting is minimal. Even in the most novel of systems, it normally is possible to copy solutions from elsewhere and then adapt them to the system under consideration. As the process of software architecting becomes more mainstream, it is likely that it will no longer be seen as some mysterious set of practices that only the chosen few are able to comprehend, but as a broadly accessible set of welldefined and proven practices that have some scientific basis and are widely accepted.

Architecting Spans Many Disciplines The architect is involved in many aspects of the software development process beyond architecting: ■

The architect assists in the requirements discipline, for example, ensuring that those requirements of particular interest to the architect are captured.

■

The architect is involved in prioritizing requirements.

Architecting | 31 ■

The architect participates in implementation, defining the implementation structures that will be used to organize the source code as well as executable work products.

■

The architect participates in the test discipline, ensuring that the architecture is both testable and tested.

■

The architect is responsible for certain elements of the development environment, in terms of defining certain project standards and guidelines.

■

The architect assists in defining the configuration management strategy, because the configuration management structures (which support version control) often reflect the architecture that has been defined.

■

The architect and project manager work closely together, and the architect has input in the project planning activities.

All these elements are described further later in this book.

Architecting Is an Ongoing Activity Experience shows that architecting is not something that’s performed once, early in a project. Rather, architecting is applied over the life of the project; the architecture is grown through the delivery of a series of incremental and iterative deliveries of executable software. At each delivery, the architecture becomes more complete and stable, which raises the obvious question of what the focus of the architect is through the life of the project. Successful software architecting efforts are results-driven. Thus, the focus of the architect changes over time as the desired results change over time. This profile is indicated in Figure 2.6, which is attributed to Bran Selic. Figure 2.6 shows that early in the project, the architect focuses on discovery. The emphasis is on understanding the scope of the system and identifying the critical features and any associated risks. These elements clearly have an impact on the architecture. Then the emphasis changes to invention; the architect’s primary concern is developing a stable architecture that can provide the foundation for full-scale implementation. Finally, the emphasis changes to implementation when the majority of discovery and invention has taken place. It should be noted that the concerns of discovery, invention, and implementation are not strictly sequential. Some implementation occurs early in the project as architectural prototypes are constructed, and some discovery occurs late in the project as lessons are learned and different strategies for implementing certain elements of the architecture are put in place. This changing emphasis of architecting over time is discussed in more detail in Chapter 3, “Method Fundamentals.”

32 | Architecture, Architect, Architecting

Discov

ery

Invention

n

entatio

Implem

Focus

Time

Figure 2.6 Project Emphasis over Time

The process of architecting is not complete until the system is delivered; therefore, the architect must be involved until the end of the project. An organization often has a strong desire to remove the architect from a project when the architecture has stabilized so as to use this precious resource on other projects. However, architectural decisions may still need to be made late in the project. In practice, a middle ground is often found: After the major decisions that affect the architecture have been made, the architect becomes a part-time member of the team. The architect should not disengage completely, however. A much more flexible situation exists when the role of the architect is fulfilled by a team, because some of the members may be used on other projects, whereas those who remain continue to ensure the architectural integrity of the system.

Architecting Is Driven by Many Stakeholders An architecture fulfills the needs of a number of stakeholders. The process of architecting, therefore, must accommodate all these stakeholders to ensure that their concerns—specifically, those that are likely to have an impact on the architecture—are captured, clarified, reconciled, and managed. It is also necessary to involve the relevant stakeholders in any reviews of the solution to these concerns. Involving all the stakeholders is critical to ensuring a successful outcome in terms of the resulting architecture. The stakeholders influence many aspects of the process, as discussed further in this book, including the manner in which

Architecting | 33

the requirements are gathered, the form in which the architecture is documented, and the way in which the architecture is assessed.

Architecting Often Involves Making Trade-Offs Given the many factors that influence an architecture, it is clear that the process of architecting involves making trade-offs. Quite often, the trade-off is between conflicting requirements, and the stakeholders may need to be consulted to assist in making the correct trade-off. An example of a trade-off is between cost and performance; throwing more processing power at the problem will improve performance, but at a cost. This may be a conflict in requirements and, assuming that the architect has been diligent in his or her work by exploring all options, is a matter that needs to be resolved with the stakeholders whose needs are in conflict. Other trade-offs occur in the solution space. The use of one technology over another, one third-party component over another, or even the use of one set of patterns over another are all trade-offs concerned with the solution rather than the requirements. Making trade-offs is not something that the architect can or should avoid. The architect is expected to consider alternatives, and making trade-offs among them is an essential aspect of the process of architecting. Figure 2.7 provides a simple classification of some of the forces at work in architecting a solution. In addition to the function provided by the system, you must be concerned with nonfunctional requirements that include run-time

Functional Requirements Run-Time Qualities

Non-Run-Time Qualities

Business Constraints

Technical Constraints

Figure 2.7 Making Trade-Offs Addresses Opposing Forces

34 | Chapter 2 Architecture, Architect, Architecting

qualities (such as performance and usability), non-run-time qualities (such as maintainability and portability), business constraints (such as regulatory and resource constraints), and technical constraints (such as mandated technology standards and mandated solution components).

Architecting Acknowledges Experience Architects rarely work from a blank sheet of paper. As noted earlier, they actively seek experience that may be codified in architectural patterns, design patterns, off-the-shelf components, and so on. In other words, the architect seeks out reusable assets. Only the most ignorant architect does not consider what has gone before. A reusable asset is a solution to a recurring problem. A reusable asset is an asset that has been developed with reuse in mind. (RAS 2004)

Although it is true that elements of an architecture are reusable in the context of the current system, architects may also look upon their architecture, or elements of it, as reusable assets that can be used outside the current system. The subject of reuse is discussed later in this chapter and in Chapter 5, “Reusable Architecture Assets.”

Architecting Is Both Top-Down and Bottom-Up Many architectures are often considered in a top-down manner, where stakeholder needs are captured and requirements developed before the architecture is defined, architectural elements are designed, and these elements are implemented. Architectures rarely are driven totally from the top down, however. The primary reason is that most systems do not start from a blank sheet of paper. Some heritage usually exists, in the form of existing solution elements that need to be accommodated and that influence the architecture. Such elements range from complete applications that are to be reengineered to mandated design or implementation elements that constraint the architecture. An example might be a constraint that the design will use a relational database or interface to an existing system. An architecture may also be driven from the bottom up as a result of lessons being learned from any executable software that has been created, such as

The Benefits of Architecting | 35

an architecture proof of concept, where these lessons result in the architecture being refined accordingly. Successful architects acknowledge that both approaches to architecting are necessary and that their architectures are created both top-down and bottom-up, which could be referred to as the “meet-in-the-middle” approach to architecting.

The Benefits of Architecting In general terms, architecting is a key factor in reducing cost, improving quality, supporting timely delivery against schedule, supporting delivery against requirements, and reducing risk. In this section, we focus on more specific benefits that contribute to meeting these objectives. Also, because architects sometimes have to justify their existence, this section provides some useful ammunition for treating architecting as a critical part of the software development process.

Architecting Addresses System Qualities The functionality of the system is supported by the architecture through the interactions that occur among the various elements that comprise the architecture. One of the key characteristics of architecting, however, is that it is the vehicle through which system qualities are achieved. Qualities such as performance, security, and maintainability cannot be achieved in the absence of a unifying architectural vision; these qualities are not confined to a single architectural element but permeate the entire architecture. To address performance requirements, for example, it may be necessary to consider the time for each component of the architecture to execute and also the time spent in intercomponent communication. Similarly, to address security requirements, it may be necessary to consider the nature of the communication among components and introduce specific security-aware components where necessary. All these concerns are architectural and, in these examples, concern themselves with the individual components and the connections among them. A related benefit of architecting is that it is possible to assess such qualities early in the project life cycle. Architectural proofs of concept are often created to specifically ensure that such qualities are addressed. Demonstrating that such

36 | Chapter 2 Architecture, Architect, Architecting

qualities are met through an actual implementation (in this case, an architectural proof of concept) is important because no matter how good an architecture looks on paper, executable software is the only true measure of whether the architecture has addressed such qualities.

Architecting Drives Consensus The process of architecting drives consensus among the various stakeholders because it provides a vehicle for enabling debate about the system solution. To support such debate, the process of architecting needs to ensure that the architecture is clearly communicated and proved. An architecture that is communicated effectively allows decisions and trade-offs to be debated, facilitates reviews, and allows agreement to be reached. Conversely, an architecture that is poorly communicated does not allow such debate to occur. Without such input, the resulting architecture is likely to be of lower quality. Clearly, an important aspect of communicating the architecture effectively is documenting it appropriately. This topic is a primary concern for the architect and is the subject of Chapter 4, “Documenting a Software Architecture.” On a related note, the architecture can drive consensus between architects (and their vision) and new or existing team members as part of training. Again, the architecture must be communicated effectively for this benefit to be achieved. Development teams with a good vision of what they are implementing have a better chance of implementing the product as desired. Driving consensus is also achieved by validating that the architecture meets the stated requirements. As mentioned in the preceding section, the creation of an executable proof of concept is an excellent way of demonstrating that the architecture meets certain run-time qualities.

Architecting Supports the Planning Process The process of architecting supports several disciplines. Clearly, it supports the detailed design and implementation activities, because the architecture is a direct input to these activities. In terms of the benefits that the process of architecting brings, however, arguably the major benefits are those related to the support provided to project planning and project management activities in general—specifically scheduling, work allocation, cost analysis, risk management, and skills development. The process of architecting can support all these concerns, which is one of the main reasons why the architect and the project manager should have such a close relationship.

The Benefits of Architecting | 37

Much of this support is derived from the fact that the architecture identifies the significant components in the system and the relationships among them. Consider the UML component diagram in Figure 2.8, which has been kept deliberately simple for the purposes of this discussion. This figure shows four components with dependencies among them. For the purposes of this discussion, consider a simple case in which each component is always implemented in its entirety (that is, we do not create partial implementations of each element, and no separation of interface from implementation exists). In terms of scheduling, the dependencies imply an order in which each of these elements should be considered. From an implementation perspective, for example, the dependencies tell you that the Error Log component must be implemented before anything else, because all the other components use this component. Next, the Customer Management and Fulfillment components can be implemented in parallel because they do not depend on each other. Finally, when these two components have been implemented, the Account Management component can be implemented. From this information, you can derive the Gantt chart (one of the conventional planning techniques used by a project manager) shown in Figure 2.9. The duration of each of the tasks shown does require some thought but can be derived partially from the complexity of each of the architectural elements. The architect can also assist in the cost estimation for the project. The costs associated with a project come from many areas. Clearly, the duration of the tasks and the resources allocated to the task allow the cost of labor to be

Account Management

Customer Management

Fulfillment

Error Log

Figure 2.8 UML Component Diagram Showing Architecturally Significant Elements

38 | Chapter 2 Architecture, Architect, Architecting

Implement Error Log Implement Customer Management Implement Fulfillment Implement Account Management

Figure 2.9 Gantt Chart Based on Dependencies among Architecturally Significant Elements

determined. The architecture can also help determine costs related to the use of third-party components to be used in the delivered system. Another cost is derived from the use of particular tools that are required to support the creation of the architectural elements. Architecting also involves prioritizing risks and identifying appropriate risk mitigation strategies, both of which are provided as input to the project manager. Finally, the architecture identifies discrete components of the solution that can provide input in terms of the skills required on the project. If appropriately skilled resources are not available within the project or within the organization, the architecture clearly helps identify areas in which skills acquisition is required. This acquisition may be achieved by developing existing personnel, outsourcing, or hiring new personnel.

Architecting Drives Architectural Integrity One of the primary objectives of the process of architecting is making sure that the architecture provides a solid framework for the work undertaken by the designers and implementers. Clearly, this objective is more than simply conveying an architectural vision. To ensure the integrity of the resulting architecture, the architect must clearly define the architecture itself, which identifies the architecturally significant elements, such as the components of the system, their interfaces, and their interactions. The architect must also define the appropriate practices, standards, and guidelines that will guide the designers and implementers in their work. Another objective of architecting is eliminating unnecessary creativity on the part of the designers and implementers, and this objective is achieved by imposing the necessary constraints on what designers and implementers can do, because deviation from the constraints may cause breakage of the architecture. Still another aspect of architecting that helps ensure architectural integrity is the adoption of appropriate review and assessment activities that confirm adherence to architectural standards and guidelines by designers and implementers.

The Benefits of Architecting | 39

We discuss architecture assessment further in Chapter 8, “Creating the Logical Architecture,” and Chapter 9, “Creating the Physical Architecture.”

Architecting Helps Manage Complexity Systems today are more complex than ever, and this complexity needs to be managed. As mentioned earlier in this chapter, because an architecture focuses on only those elements that are significant, it provides an abstraction of the system and therefore provides a means of managing complexity. Also, the process of architecting considers the recursive decomposition of components, which is clearly a good way of taking a large problem and breaking it down into a series of smaller problems. Finally, another aspect of managing complexity is using techniques that allow abstractions of the architecture to be communicated. You might choose to group components into subsystems or to separate interfaces from implementation, for example. The adoption of industry standards that allow abstractions to be expressed, such as UML, is commonplace in the industry today for documenting the architecture of software-intensive systems.

Architecting Provides a Basis for Reuse The process of architecting can support both the production and consumption of reusable assets. Reusable assets are beneficial to an organization because they can reduce the overall cost of a system and also improve its quality, given that a reusable asset has already been proved (because it has already been used). In terms of asset consumption, the creation of an architecture supports the identification of possible reuse opportunities. The identification of the architecturally significant components and their associated interfaces and qualities supports the selection of off-the-shelf components, existing systems, packaged applications, and so on that may be used to implement these components. In terms of asset production, the architecture may contain elements that are, by their very nature, applicable outside the current system. The architecture may contain an error logging mechanism that could be reused in several other contexts. Such reuse generally is opportunistic, whereas a strategic reuse initiative considers candidate assets ahead of time. We touch on this topic in Chapter 10, “Beyond the Basics.”

Architecting Reduces Maintenance Costs The process of architecting can help reduce maintenance costs in several ways. First and foremost, the process of architecting should always ensure that the

40 | Chapter 2 Architecture, Architect, Architecting

maintainer of the system is a key stakeholder and that the maintainer’s needs are addressed as a primary concern, not as an afterthought. The result should be an architecture that is appropriately documented to ease the maintainability of the system; the architect also ensures that appropriate mechanisms for maintaining the system are incorporated and considers the adaptability and extensibility of the system when creating the architecture. In addition, the architect considers the skills available to maintain the system, which may be different from those of the team members who created the system. The architect should consider the areas of the system that are most likely to require change and then isolate them. This process can be fairly straightforward if the change affects a single component or a small number of components. Some changes, however, such as those relating to system qualities such as performance or reliability, cannot be isolated in this way. For this reason, the architect must consider any likely future requirements when architecting the current system. Scaling up a system to support thousands of users rather than the tens of users for which the system was originally designed may not be possible without changing the architecture in fundamental ways, for example. The issue of maintainability is a primary concern only for those systems that will evolve over time, not for systems whose purpose is to provide a tactical solution and whose life is limited.

Architecting Supports Impact Analysis An important benefit of architecting is that it allows architects to reason about the impact of making a change before it is undertaken. An architecture identifies the major components and their interactions, the dependencies among components, and traceability from these components to the requirements that they realize. Given this information, a change to a requirement can be analyzed in terms of the impact on the components that collaborate to realize this requirement. Similarly, the impact of changing a component can be analyzed in terms of the other components that depend upon it. Such analyses can greatly assist in determining the cost of a change, the impact that a change has on the system, and the risk associated with making the change.

Summary This chapter defined and explained the core concepts used throughout this book: architecture, architect, and architecting. The benefits of taking an architecturecentric approach to the software development process were also dis-

Summary | 41

cussed. Many issues remain unresolved, however, such as what the architect actually does on a software development project, what the architect produces, and how the role of the architect relates to other project roles. Having defined these core concepts, we turn our attention to the application of these concepts within the overall software development process in Chapter 3, “Method Fundamentals.”

This page intentionally left blank

Chapter 3 Method Fundamentals

Having discussed some core concepts, we now turn our attention to some of the details that underpin the process of architecting, such as work products, tasks, and roles. To provide this summary, we consider various architecturerelated best practices that have developed in the software industry and draw on elements of various approaches, including the Rational Unified Process, IBM Unified Method Framework, OpenUP, eXtreme Programming (XP), Scrum, FeatureDriven Development (FDD), and Lean. We also consider relevant standardization initiatives, such as the Software and Systems Process Engineering Metamodel Specification (SPEM). The purpose of this chapter is to provide an overview of the key method elements on which this book is based. Therefore, this chapter sets the scene for the remaining chapters, in which we elaborate on these concepts. A summary of the method elements described in this book is also given in Appendix C, “Method Summary.”

Key Concepts For subsequent discussion in this chapter to make sense, it is important for us to establish some basic concepts present in a method. The Software and Systems Process Engineering Metamodel Specification (SPEM) Object Management Group (OMG) standard (SPEM 2007) can help, because it provides definitions of such concepts, and we use them in this book. The SPEM standard is influenced

43

44 | Chapter 3 Method Fundamentals

by and supports several existing software development methods, including OpenUP (OpenUP 2008), the Rational Unified Process (RUP 2008), IBM Unified Method Framework, Fujitsu DMR Macroscope, and Unisys QuadCycle. The SPEM standard defines various concepts in a significant amount of detail. For the purposes of this book, however, we adopted a simple subset and made some simplifying assumptions. The relevant terms used in this book are shown in Figure 3.1, which uses, where defined, relationships and icons from the SPEM standard. In essence, an effective software development method should describe who does what, how, and when. This book does exactly that in terms of the following key concepts: ■

Roles: The who

■

Work products: The what

■

Tasks: The how

■

Phases, iterations, and activities: The when

In addition, a method includes guidance in the form of templates, examples, and techniques. With reference to Figure 3.1, a software development project typically moves through several phases, each of which is divided into several iterations (although, as you will see, not all processes are organized by

divided into

Process Phase

considers

Iteration

Activity references performed by

Task Method Content

Role

uses and produces

responsible for

Work Product Figure 3.1 Key Method Concepts and Their Relationships

Key Concepts | 45

phases and iterations). Within each iteration, we consider various activities and the tasks they reference, which are executed to achieve a particular result. Tasks are performed by appropriate roles, and relevant work products are used and produced. Also, as shown in Figure 3.1, a method can be considered to comprise method content and process. Method content describes the life-cycle-independent elements, such as roles, tasks, and work products. Then a process takes these elements and defines a sequence in which they are applied, depending on the nature of the project being considered, and considers concepts such as phases, iterations, and activities. An example of the separation of method content and process is provided by OpenUP, a visualization of which is provided in Figure 3.2. In this figure, the vertical axis represents the method content, grouped by discipline, and the horizontal access describes the process. [A discipline is a] primary categorization mechanism for organizing tasks that define a major “area of concern” and/or cooperation of work effort. (OpenUP 2008)

A discipline is a collection of activities that are related to a major area of concern within the overall project. As shown in Figure 3.2, OpenUP is organized around five disciplines, which are described in Table 3.1.

Inception

Phases Elaboration Construction

Incep Incep #n #1

Elab #1

Transition

Method Content

Requirements Architecture Development Test Project Management Elab #n

Const #1

Const #2

Const #n

Iterations Process Figure 3.2 Method Content and Process Dimensions of OpenUP

Tran #1

Tran #n

46 | Chapter 3 Method Fundamentals

Table 3.1 OpenUP Discipline Summary OpenUP Discipline

Description

Requirements

This discipline explains how to elicit, analyze, specify, validate, and manage the requirements for the system to be developed. This discipline explains how to create software architecture from architecturally significant requirements. The architecture is built in the Development discipline. This discipline explains how to design and implement a technical solution that conforms to the architecture and supports the requirements. This discipline explains how to provide feedback about the maturing system by designing, implementing, running, and evaluating tests. This discipline explains how to coach, facilitate, and support the team, helping it deal with risk and obstacles when building software.

Architecture

Development

Test

Project Management

As the “humps” in Figure 3.2 demonstrate, the relative emphasis of the disciplines changes over the life of the project. In early iterations, for example, more time is spent on requirements, and in later iterations, more time is spent on development. The definitions of roles, tasks, and work products usually are considered to be highly reusable because, unlike the process-related elements, they do not tend to vary greatly among different types of life cycles and projects. A software development project that is developing a system from a blank sheet of paper will perform a task such as Identify Functional Requirements by using much the same steps as a project that is changing an existing system, but the emphasis on this task will be very different through the life cycle.

Method Content As we mention in the preceding section of this chapter, method content refers to the roles, work products, and tasks that comprise the method being followed.

Role A role defines the responsibilities of an individual or a set of individuals working together as a team within the context of a software development organization. A role is responsible for one or more work products and performs a set of tasks. The Business Analyst role, for example, is responsible for the Func-

Method Content | 47

tional Requirements work product and performs the Identify Functional Requirements task. In this book, when a role performs a task, the role is considered to be either primary or secondary, as discussed in the sidebar “Concept: Primary and Secondary Roles.” It is important to emphasize that roles are not individuals. Individuals may play multiple roles (wear multiple hats), and multiple individuals may play a single role. The Project Manager is responsible for performing the mapping of individuals to roles when planning and staffing the project, although the Project Manager of course consults others when doing this. The architectrelated roles used in this book are shown in Figure 3.3 (although not all projects require these specialized roles, and a single role of architect may be sufficient). The Lead Architect has overall responsibility for the major technical decisions that define the architecture of the system. This role also is responsible for providing rationale for these decisions; balancing the concerns of the various stakeholders; managing technical risks and issues; and ensuring that decisions are effectively communicated, validated, and adhered to. The Application Architect focuses on those elements of a system that automate business processes and meet business needs. This role focuses primarily on satisfying the functionality required by the business, but it is also concerned with how the application-related elements meet the non-functional requirements of the system (qualities and constraints). The Infrastructure Architect concentrates on those elements of the system that are independent of business functionality, such as a persistence mechanism, hardware, and middleware. Such elements support the execution of the application-related elements. This role focuses on elements that have a significant bearing on the qualities exhibited by the system and, therefore, the extent to which certain non-functional requirements are addressed. The Data Architect focuses on the data elements of a system, especially data that is made persistent in an appropriate mechanism, such as a database, a file system, a content management system, or some other storage mechanism. This role defines appropriate data-related properties, such as structure, source, location, integrity, availability, performance, and age.

Lead Architect

Application Architect

Infrastructure Architect

Figure 3.3 Roles Related to Software Architecture

Data Architect

48 | Chapter 3 Method Fundamentals

Concept: Primary and Secondary Roles The primary role for a given task is considered to be responsible for the task and is never optional. A secondary role is considered to contribute to the task but is not responsible for it and may be considered optional. A more complete characterization of roles is given by the RACI classification, wherein each role may be Responsible for the task, Accountable for the task, Consulted (the role player’s opinion is sought), and Informed (the role player is kept informed of progress on the task and its content). Our simplified characterization treats a primary role as the role that is both responsible and accountable and a secondary role as the role that is consulted and informed.

Work Product A work product is a piece of information or physical entity that is produced and/or used during the execution of the process. Examples of work products include models, plans, code, executables, documents, databases, and so on. A work product is the responsibility of a single role, although multiple roles may collaborate to produce a work product. Roles use work products as input to tasks, and roles produce or modify work products as an output from tasks that perform. The architect participates in various tasks that produce and use work products, as described later in this chapter and in the case study–related chapters (Chapters 6 through 9). The SPEM defines three types of work products: artifact, deliverable, and outcome. An artifact is a tangible work product, such as a document, model, source code, executable, or project plan. A deliverable is also a tangible work product that represents content packaged for delivery. Deliverables are used to represent a work product that is of value (material or otherwise) to a stakeholder. An outcome represents a result or state as the result of task execution. Unlike artifacts and deliverables, outcomes do not represent potentially reusable assets. The approach described in this book focuses primarily on artifacts. In addition to artifacts, the architect is responsible for the Software Architecture Document deliverable. The work products for which the architect is specifically responsible are shown in Figure 3.4, which also shows the different architect roles. Any given method may add or remove some of the work products summarized in this figure.

Method Content | 49

Lead Architect

Application Architect

Architecture Assessment

Functional Model

Architecture Decisions

Infrastructure Architect

Architecture Architecture Software Overview Proof-of-Concept Architecture Document

Deployment Model

Data Architect

Data Model

Figure 3.4 Work Products Owned by Architecture-Related Roles

This figure may give two misleading impressions. The first is that all the work products are documents (because the SPEM icon for a work product looks like a document!). This is not the case, however. The Functional Model and Deployment Model, for example, may be represented as Unified Modeling Language (UML) models in an appropriate modeling tool, and the Architecture Decisions work product may be captured in a project wiki. The second is that the level of ceremony associated with the creation of each work product is very much dependent on context (such as the complexity of the system, the point in the life cycle, and the like). The Architecture Overview work product could be one page, for example, and the Architecture Decisions work product may comprise three items in a spreadsheet. Although not shown in Figure 3.4, there are also work products that the architect contributes to but does not own, such as the Prioritized Requirement List. Another example is the RAID Log work product, which the architect contributes to but which is owned by the Project Manager. As you would expect, a correlation exists between the role that is responsible for a task and the ownership of any work products that are output. The Business Analyst is responsible for the Collect Stakeholder Requests task and is the owner of the Stakeholder Requests work product, for example.

Activity An activity represents a grouping of tasks. The architect performs tasks within the activities shown in Figure 3.5, which we elaborate on in Chapter 8, “Creating the Logical Architecture,” and Chapter 9, “Creating the Physical Architecture.”

50 | Chapter 3 Method Fundamentals

Create Logical Architecture

Create Physical Architecture

Figure 3.5 Architecture-Related Activities

Task A task is a unit of work that provides a meaningful result in the context of the project. It has a clear purpose, which usually involves creating or updating work products. All tasks are performed by appropriate roles. Tasks may be repeated several times, especially when an iterative development approach is taken (iterations are discussed later in this chapter). The architecture-related tasks, which are described in detail in Chapter 8, “Creating the Logical Architecture,” and Chapter 9, “Creating the Physical Architecture,” are shown in Figure 3.6, together with the primary roles involved. You should remember, however, that this set of tasks represents only the core architecting tasks and that an architect typically is involved in other tasks, too, such as development of a technology strategy and skills development. As you will see, the architect also assists other roles, such as overseeing the development process, identifying stakeholders, defining and prioritizing requirements, estimating, and planning.

Process We now turn our attention to the application of the method content in terms of a sequence in which they are applied. As you will see, many of the differences among various methods used in the software industry primarily involve the process being followed rather than the roles, work products, activities, and tasks performed. In this section, we consider three types of process, which are characterized as waterfall, iterative, and agile. As we do so, we not only examine the key characteristics of each approach, but also highlight those practices that are of most relevance to the software architect and also explore some of myths that seem to pervade such discussions.

Process | 51

Survey Architecture Assets

Define Architecture Overview

Document Architecture Decisions

Build Architecture Proof-of-Concept

Validate Architecture

Update Review Software Architecture Architecture with Stakeholders Document

Application Architect

Outline Functional Elements

Detail Functional Elements

Infrastructure Architect

Outline Deployment Elements

Detail Deployment Elements

Lead Architect

Verify Architecture

Figure 3.6 Architecture-Related Tasks

Waterfall Processes A traditional waterfall development process is shown in Figure 3.7, using discipline names taken from OpenUP. In this approach, each discipline is deemed to be complete when all the appropriate work products for that discipline have been created and signed off on. The requirements discipline, for example, may be considered to be complete when all the requirements have been identified, defined in detail, and reviewed. Then the output from requirements flows into the architecture discipline. This process continues until the system has been designed in detail and coded (in the development discipline), tested, and made available to its end users. Changes in the work products (shown by the backward-pointing arrows) typically are handled through a formal change process. This approach is widely used, especially in those projects that represent minor enhancements of an existing system or in the development of a system

52 | Chapter 3 Method Fundamentals

Requirements Architecture Development Test

Figure 3.7 A Waterfall Process

that involves a relatively small amount of risk. On greenfield projects (in which the architect starts from a blank sheet of paper), however, or projects that are changing extensively, this approach can be problematic for several reasons: ■

Project progress cannot be measured accurately, because it is based on the creation of work products rather than the achievement of results. Completing the requirements for a time machine without doing any architecture, development, or testing, for example, won’t give you an accurate indication of how long the project will take, because you can’t really determine whether a feasible solution exists!

■

User feedback cannot be obtained until late in the project, when the system is available to use, delaying ultimate convergence on the real requirements.

■

Resolution of certain risks is deferred until late in the project, after the system has been built, integrated, and tested. Such activities often identify flaws in the design and even the stated requirements, which is why certain classes of project that follow a waterfall approach are prone to schedule slippage.

An alternative approach is to use an iterative development process, which we discuss in the next section.

Iterative Processes [An iteration is a] short and set duration division of a project. Iterations allow you to demonstrate incremental value and obtain early and continuous feedback. (OpenUP 2008)

Process | 53

Within an iteration, a pass is made through each of the disciplines, including requirements, architecture, development, and test. An iteration is a distinct, time-boxed sequence of activities that results in a release (internal or external) of an executable product. As the project progresses, releases provide incremental improvements in capability until the final system is complete. An iterative development process is similar to growing software, in which the end product matures over time. Each iteration results in better understanding of the requirements, a more robust architecture, a more experienced development organization, and a more complete implementation. The notion of growing an architecture through a series of iterations and executables appears to be a common practice in organizations that we would consider to be productive and successful in architecting their software systems. Figure 3.8 illustrates how the focus of a project shifts across successive iterations. In this figure, you see that each discipline is addressed during every iteration, and the size of the boxes within each of the disciplines illustrates the relative time spent performing the activities (and tasks) within that discipline. In this simple example, you see that iteration 1 focuses on requirements definition, but some architecting is performed (focusing on the highest-priority

Iteration 1

Iteration 2

Iteration 3

Requirements

Requirements

Requirements

Architecture

Architecture

Architecture

Development

Development

Development

Test

Test

Test

Figure 3.8 An Iterative Process

54 | Chapter 3 Method Fundamentals

requirements to be considered in the iteration), together with some development and testing. In this example, iteration 2 focuses on stabilizing the architecture, which is why you see the emphasis on the architecting activities. Iteration 3 focuses on completing the solution based on a relatively stable set of requirements and architecture, which is why you see an emphasis on development and testing. Following are some important characteristics of iterations in projects that are successful in following an iterative process: ■

The iteration has clear evaluation criteria.

■

The iteration has a planned capability that is demonstrable.

■

The iteration is concluded by a minor milestone, where the result of the iteration is assessed relative to the objective success criteria for that particular iteration.

■

During the iteration, work products are updated (work products evolve with the system).

■

During the iteration, the system is integrated and tested.

An iterative development approach is particularly appealing to the architect because it specifically acknowledges that adjustments to the architecture will need to be made as the project progresses. The number of architectural changes should reduce over time, of course. The point is that such changes are not afterthoughts but are considered to be essential aspects of the project life cycle. An iterative development process involves more than a stream of iterations, however. It also must have an overall framework in which the iterations are performed, which represents the strategic plan for the project and drives the goals and objectives of each iteration. Such a framework is provided by phases. [A phase is] a specialized type of activity that represents a significant period in a project normally ending with a decision checkpoint, major milestones, or a set of deliverables. Phases typically have well-defined objectives and provide the basis for how the project work will be structured. (OpenUP 2008)

Phases provide well-defined business milestones that ensure that the iterations make forward progress and converge on a solution, rather than just iterating indefinitely. Iterations are time-boxed (of a fixed duration), whereas phases are goal-based. A phase is not time-boxed, because the completion of a phase is assessed based on the state of the project. Some organizations fail to acknowledge this important principle, as discussed in the sidebar “Pitfall: Declaring Victory Too Soon.”

Process | 55

Pitfall: Declaring Victory Too Soon A very common mistake is for the Project Manager to declare victory by stating that a phase has been completed when it really hasn’t, simply because the date on which the phase should have been completed has been reached. This scenario is the software equivalent of false accounting, and Project Managers who cook the books in this manner often become unstuck as their misguided decisions come back to haunt them. It usually is far better for a Project Manager to bite the bullet and convey the news that the phase has not been completed as planned, rather than delude themselves, and everyone else, that everything is on track—a situation that normally results in additional and unnecessary pressure being placed on the project.

Phases and iterations together provide the foundation for an iterative development process. The objectives of each phase are achieved by executing one or more iterations within the phase. Each phase concludes with a major milestone and an assessment to determine whether the objectives of the phase have been met. A satisfactory assessment allows the project to move to the next phase. OpenUP defines four sequential phases, which we use in this book: Inception, Elaboration, Construction, and Transition (see Figure 3.9).

Milestone

Inception Preliminary Iteration(s)

Milestone

Elaboration Iteration #1

Iteration #2

Milestone

Construction

Transition

Iteration Iteration Iteration Iteration Iteration #m+1 #n #n+1 #n+2 #m

Releases Time Figure 3.9 Project Phases

Milestone

56 | Chapter 3 Method Fundamentals

A phase-based approach supports the convergence of several elements as the project progresses. Risks reduce over the project life cycle, for example, and cost and schedule estimates become more accurate. The architecture also stabilizes over time, as indicated in Figure 3.10. As it happens, most phasebased software development processes have a phase that focuses on stabilizing the architecture. In this book, this phase is the Elaboration phase, which clearly is a particular focus for the architect. Figure 3.10 also characterizes the Inception and Elaboration phases as engineering, whereas the Construction and Transition phases are treated as production. This distinction is discussed in detail in Software Project Management: A Unified Framework (Royce 1998). Moving from Elaboration to Construction (that is, engineering to production) is particularly interesting because this move represents a significant milestone as far as the business is concerned. The production stage generally is more predictable than the engineering stage, because there is usually a good understanding of both the problem and the solution. Therefore, a much higher level of fidelity exists in cost and schedule estimates, and funding decisions can be made with greater confidence. This is not to say that all the requirements have been defined by the end of elaboration or that requirements never change, but the majority of requirements are expected to have been defined, and any changes are expected to have minimal impact on the architecture. Should this not be the case (when a significant requirement is added, for example), a case exists for reviewing the project and its timeline and adjusting accordingly. This may require essentially resetting the project and possibly revisiting the elaboration (and even inception) phase.

Engineering Stage Inception

Production Stage

Elaboration

Construction

High

Architecture Stability

Low

Time Figure 3.10 Architecture Stability over Time

Transition

Process | 57

As indicated in Figure 3.11, a direct relationship exists between the emphasis on architecture in each of the phases and the number of resources typically dedicated to architecture (which, of course, will vary depending on the nature of the system under development). This graph is derived from information in Software Project Management: A Unified Framework (Royce 1998). Clearly, moving from one phase to another is a significant moment in the project life cycle, so it is important to understand the criteria under which the transition from one phase to the next is made. A detailed summary of the primary objectives of each of the phases and their milestone evaluation criteria is provided in Appendix C, “Method Summary.” Following is an overview of each of the phases: ■

The Inception phase is where the business case for the project is established and where concurrence among all stakeholders on the objectives for the project is established. Inception is where the focus is on ensuring that the project is both valuable and feasible.

■

The Elaboration phase is where the architecture is established to provide a stable foundation for the activities performed during the Construction phase. This phase, therefore, is of particular relevance to the architect and certainly is where the architect expends the most effort.

■

The Construction phase is where the remaining requirements are clarified and where development of the system is completed on the baselined architecture established during the Elaboration phase. Between the Elaboration and Construction phases, the focus shifts from understanding the problem and identifying key elements of the solution to developing a deployable product.

Inception

Elaboration

Construction

Transition

100 75

% Resources Focused on 50 Architecture 25 0

Time Figure 3.11 Percentage of Resources Focused on Architecture over Time

58 | Chapter 3 Method Fundamentals ■

The Transition phase ensures that the software is available to, and accepted by, its end users. This phase is where the system is deployed in the users’ environment for evaluation and testing. The focus is on finetuning the product and on addressing configuration, installation, and usability issues. By the end of the Transition phase, the project should be in a position to be closed out.

Iterative Development and Waterfall Development Compared with a waterfall development process, an iterative development process is results-driven (in that it focuses on the results to be achieved within a given iteration) rather than work-product-driven and lends itself to providing more accurate measures of project progress. An iterative approach allows early user feedback through the execution of incremental releases of the system, and such feedback accelerates convergence on the real requirements. Also, an iterative approach ensures that integration and testing occur within each iteration and that an executable release is produced. Risks are attacked head on and early in the project, thereby supporting the business in making decisions before substantial investment in the project is made. As Royce puts it: Establish an iterative life-cycle process that confronts risk early. With today’s sophisticated software systems, it is not possible to define the entire problem, design the entire solution, build the software, then test the end product in sequence. Instead, an iterative process that refines the problem understanding, an effective solution, and an effective plan over several iterations encourages a balanced treatment of all stakeholder objectives. Major risks must be addressed early to increase predictability and avoid expensive downstream scrap and rework. (Royce 1998)

Agile Processes Interest in agile processes has increased in recent years, expressed in methods such as eXtreme Programming (XP), Scrum, Lean, and Feature-Driven Development. Although some differences exist with respect to each specific agile method and the practices they advocate, all are based on the same fundamental principles. One articulation of such principles is the Agile Manifesto (Agile Manifesto 2009) which states the following values: ■

Individuals and interactions over processes and tools

■

Working software over comprehensive documentation

Summary | 59 ■

Customer collaboration over contract negotiation

■

Responding to change over following a plan

It is the authors’ view that these principles are complementary to those found in an iterative development approach. Also, as you can see from the Agile Manifesto, the main distinction is the emphasis placed on principles that guide the execution of the process, rather than new or different method content. An example comes from Scrum: Scrum is a management and control process that cuts through complexity to focus on building software to meet business needs. Scrum is superimposed on top of and wraps existing engineering practices, development methodologies and standards. (Schwaber 2002)

Scrum also exemplifies the emphasis on process. It focuses on the content of an iteration (referring to an iteration as a Sprint), the prioritized requirements to be considered in the iteration (the Sprint Backlog), and a short daily status meeting (a Scrum). Agile principles are also relevant to architects, and it is surprising how often the principles are misrepresented. A common perception is that agile processes do not advocate up-front design and that somehow the architecture simply emerges from the code. The principle of working software over comprehensive documentation, however, does not mean that no documentation exists (including architecture-related documentation); it simply means that just enough documentation exists for the purposes of the current iteration. There seems to be a fear in the agile community that if we use terms such as “model” or “document” that suddenly the “evil bureaucrats” will dig their claws into our projects and force us to write detailed, big requirements specifications or to take a big-design-up-front approach . . . the strange thing is that agilists are, in fact, modeling on a regular basis, even though they’re not directly talking about it. (Ambler 2008)

Summary This chapter provided a brief overview of the method fundamentals used in this book, using the Software and Systems Process Engineering Metamodel Specification (SPEM) standard as a framework for explaining these concepts. The

60 | Chapter 3 Method Fundamentals

chapter emphasized the distinction between method content and the processes that enact this content, and considered different types of processes, including waterfall, iterative, and agile. The chapter discussed the relevance of these concepts to the architect and to the process of architecting. The method used in this book borrows from all these types of processes. The next two chapters—Chapter 4, “Documenting a Software Architecture,” and Chapter 5, “Reusable Architecture Assets”—focus on specific aspects of the method that warrant a more detailed discussion and that pervade the project life cycle.

Chapter 4 Documenting a Software Architecture

The primary purpose of documenting a software architecture is to allow the architecture to be communicated. This communication is essential in ensuring that all stakeholders understand the architecture and can provide their input accordingly. This communication is critical in ensuring that certain stakeholders are comfortable with the proposed solution, for example, and that the project team has a consistent view of the system to be built. Accommodating all the concerns of all the stakeholders is often challenging, however. Therefore, we dedicate this chapter to exploring various aspects of describing a software architecture. Documenting a software architecture is beneficial for the following reasons: ■

A documented architecture contributes to effective communication between different stakeholders, such as communication between those developing the system and those maintaining the system, even if the individuals involved never meet physically.

■

A documented architecture provides the context for deriving other work products, such as detailed design work products or even training materials.

■

A documented architecture can convey alternative architectural solutions and the pros and cons of each.

■

A documented architecture can help with the planning of the transition from an existing architecture to a new architecture.

61

62 | Chapter 4 Documenting a Software Architecture ■

A documented architecture can help with planning in general by identifying the elements that comprise the architecture and the dependencies among them. This information can help in planning an appropriate sequence for implementing the architecture and also understand the impact of making a change in the architecture.

■

A documented architecture can remind the architect of the rationale behind certain decisions that have been made.

■

A documented architecture can help identify reuse opportunities in terms of both the creation and use of reusable assets.

■

A documented architecture can help with the assessment of the architecture and can, for example, help determine if the implementation is in accordance with the specification provided.

Some simple concepts that can be applied when documenting a software architecture are particularly useful to architects who have little experience in documenting architectures. We start this chapter by discussing these concepts. Then we discuss several architecture description frameworks (ADF) and close by describing the architecture description framework used in this book.

The End Game Before jumping into the elements that comprise a documented software architecture, we present a very simple example of what we’re aiming for, as shown in Figure 4.1.

Developers

Functional Model Lead Architect

Deployment Model

Users Software Architecture Document

Figure 4.1 Elements Involved in Documenting a Software Architecture

The End Game | 63

When documenting a software architecture, you should follow some simple steps: ■

Identify the stakeholder groups. In documenting a software architecture, the first thing to understand is the target audience. One of the first items that the Lead Architect will consider is the target audience in terms of stakeholders of the architecture. Stakeholders can be organized in groups that share related concerns. The two groups of stakeholders shown in the figure are Developers and Users.

■

Select the viewpoints. After identifying the stakeholder groups, you need to identify the corresponding viewpoints that will allow the stakeholders’ concerns to be expressed. Viewpoints are fundamental to documenting a software architecture and are discussed in detail in “Viewpoints and Views” later in this chapter. A viewpoint, for example, defines the work products needed so that the architecture can be communicated to the identified stakeholders in an appropriate manner. In the example in Figure 4.1, the selection of a functional viewpoint requires the architect to create a Functional Model to describe the functionality (logic) of the system in terms of, for example, components, relationships among components, and their interactions. The selection of a deployment viewpoint requires the architect to create a Deployment Model to describe the deployment of the system in terms of, for example, nodes and the connections among them. For simplicity, other viewpoints and their corresponding work products, such as the Architecture Decisions and Architecture Proof-of-Concept work products, are not shown in the figure.

■

Create the work products. The architect (or architecture team) populates the work products accordingly. You may add elements to any models that you decided to create, as well as any diagrams that allow you to express these elements visually. In Figure 4.1, we show two diagrams in the Functional Model and one in the Deployment Model. In general terms, every work product can be considered to be a model of the system under development; we discuss this topic in the next section.

■

Package the architecture description. Rather than communicating the architecture using all the work products that have been created, the architect typically packages elements in a form that is more easily consumed by the stakeholders. (Not all stakeholders may not have access to any modeling tools used to create certain work products, for example.) In our example in Figure 4.1, the architect creates a Software Architecture Document

64 | Chapter 4 Documenting a Software Architecture

deliverable. This deliverable is organized by the different views of the architecture, with each view representing the application of a particular viewpoint for a given system. The extent of architecture documentation required is discussed in the sidebar “Best Practice: Documentation Is Minimal but Sufficient.” The concepts of viewpoint, view, and model are discussed in detail in the next section.

Best Practice: Documentation Is Minimal but Sufficient One of the agile principles is “Working software over comprehensive documentation” (Agile Manifesto), and this principle reminds you that the creation of any work products should be minimal but sufficient. When documenting a software architecture, you determine what you mean by sufficient by considering the needs of the identified stakeholders. Given that stakeholders of the architecture may be team members or maintainers, you also need to pay appropriate attention to the upkeep of any work products you create and ensure, where appropriate, that they are kept up to date and consistent with one another.

Key Concepts The key architecture description concepts are viewpoint, view, and model. These concepts are defined in IEEE 1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. Figure 4.2 shows a subset of the elements defined in this standard. This figure expands on the discussion in Chapter 2, “Architecture, Architect, Architecting,” by specifically identifying those elements that are related to an architectural description. All the relationships shown in this figure come from the IEEE 1471 standard. Those relationships not described in Chapter 2 are provided in the following list; we expand on these relationships later in this chapter. ■

An architectural description is organized by one or more views.

■

A view consists of one or more models.

■

A model participates in one or more views.

■

A model participates in one or more architectural descriptions.

Viewpoints and Views | 65

Rationale

Architecture

- provides

- identifies 1..*

- described by

Stakeholder

- addresses 1..*

- organized by 1..*

1

Architectural Description

- is important to 1..*

- has 1..*

- participates in

- participates in

1..*

1..* 1..*

- identifies

- aggregates

Concern

1..*

View

*

- consists of 1..*

Model

- used to cover

- establishes methods for 1..* - selects 1..* - conforms to Viewpoint

Figure 4.2 A Metamodel of Elements Related to an Architectural Description

■

A view conforms to a viewpoint.

■

An architectural description selects one or more viewpoints.

■

A viewpoint establishes methods for one or more models.

■

A viewpoint is used to cover one or more concerns.

As you can see, the concepts of viewpoint, view, and model are fundamental to describing a software architecture, and all of them are described in more detail in the following sections.

Viewpoints and Views It would be nice to think that you could communicate the architecture of a system by using a single diagram that satisfies the needs of all stakeholders. Although this approach may be an effective means of informally communicating some aspects of the architecture to interested parties, taking such a narrow approach—an informal technical description intended to cover all facets of the architecture—usually leads to confusion, because such diagrams tend to be overly complex. Such diagrams also tend to mix different aspects of the

66 | Chapter 4 Documenting a Software Architecture

architecture. An innocent-looking box in such a diagram, for example, may mix functional responsibilities with deployment concerns, and an arrow between boxes may mix control flow with a simple dependency between elements. Another common flaw is emphasizing one aspect of the architecture to the detriment of others. The diagram may emphasize the functional partitioning of the architecture into components, their relationships, and interactions to the detriment of concerns regarding the deployment of the system, for example. The solution to such failings is to describe a software architecture by applying several viewpoints concurrently, with each viewpoint addressing a particular set of concerns. [An architectural viewpoint is] a specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis. (IEEE 1471 2000) [An architectural view is] a representation of a whole system from the perspective of a related set of concerns. (IEEE 1471 2000)

A viewpoint has several characteristics that are worth noting: ■

A viewpoint has an identified audience. A primary concern of a viewpoint is that it addresses the needs of a particular audience, where the audience represents one or more stakeholders in the system. A functional viewpoint can address the needs of a developer (who must undertake detailed design activities and implement code), a tester (who must test the system), and so on.

■

A viewpoint serves one or more purposes. Although a viewpoint supports a set of stakeholders who have similar concerns, those concerns may not be identical. A developer may use a functional viewpoint to understand context for designing the internals of a specific design element before implementing that element in a given programming language, whereas a tester may use the same functional viewpoint to understand the key components of the system for the purposes of determining whether the system meets certain requirements.

■

A viewpoint is a pattern or template for a view. In simple terms, a view conforms to a viewpoint. The viewpoint defines the rules by which the view is created and used. In object-oriented terminology, a viewpoint represents a class (of view), and a view is a particular instance of a viewpoint. Therefore, when documenting the architecture of a particular sys-

Viewpoints and Views | 67

tem, you select the appropriate set of viewpoints and, as a result, create the views that are specific to the architecture of the system under development. Because a viewpoint can be considered to be a template, it is no surprise that some organizations invest in the creation of a viewpoint catalog from which viewpoints can be selected for any given project. ■

A viewpoint defines techniques. Finally, a viewpoint defines the conventions by which a view is created, depicted, and analyzed. A viewpoint defines the language in which a view that conforms to the viewpoint is defined, perhaps including notations and specific techniques for deriving the content of the view. A deployment viewpoint may state that a deployment view contains a Deployment Model; that the Deployment Model will be created with the Unified Modeling Language (UML); that the Deployment Model will be created by applying certain techniques and conventions; and that the Deployment Model should be applied in certain situations (with corresponding benefits accrued and pitfalls to be avoided). As a consequence, you can see that a viewpoint has a bearing on the manner in which the work products that comprise the view are created.

Basic Viewpoints We’ve already mentioned two viewpoints that architects often encounter in practice: a functional viewpoint, which is concerned with elements that support the functionality of the system (such as components, their relationships, and their behavior), and a deployment viewpoint, which is concerned with elements that support the distribution of the system (such as nodes, devices, and the connections among them). The rationale for considering viewpoints can be extended further, as shown in Figure 4.3, in which viewpoints appear to be on the fringes of an architecture

Stakeholder Group A

Stakeholder Group B

Stakeholder Group C

Stakeholder Group D

Requirements Viewpoint

Functional Viewpoint

Deployment Viewpoint

Validation Viewpoint

Figure 4.3 Basic Viewpoints

68 | Chapter 4 Documenting a Software Architecture

description: a requirements viewpoint and a validation viewpoint. The purpose of the requirements viewpoint is to provide an indication of the system requirements that have shaped the architecture; it includes functional requirements, qualities, and constraints. The purpose of the validation viewpoint is to provide an indication of whether the system will provide the required functionality, exhibit the required qualities, and accommodate the defined constraints.

Cross-Cutting Viewpoints In their book Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives (Rozanski 2005), Nick Rozanski and Eoin Woods give special significance to the term perspective to represent the collection of elements that address a cross-cutting concern: An architectural perspective is a collection of activities, tactics, and guidelines that are used to ensure that a system exhibits a particular set of related quality properties that require consideration across a number of the system’s architectural views. (Rozanski 2005)

A perspective is really a special kind of viewpoint that focuses on the qualities the system must exhibit. To address the security requirements in a system, for example, you may need to specify security requirements, introduce security-related functional elements and deployment elements in the solution, and subsequently validate the security implemented in the architecture. This situation is shown in Figure 4.4, in which we introduce both a performance viewpoint and a security viewpoint. The corresponding views created by applying these viewpoints are considered to cut across the requirements, functional, deployment, and validation views in that they may share the same elements. More specifically, given the examples shown in Figure 4.4, you can consider the following intersections among the views implied by these viewpoints: ■

The performance view identifies the performance-related requirements in the requirements view and how those requirements are realized.

■

The performance view identifies the elements in the functional view that contribute to meeting the performance requirements, which may result in the need to couple elements tightly when a lot of communication occurs, for example.

■

The performance view identifies the elements in the deployment view that contribute to meeting the performance requirements. This view would con-

Viewpoints and Views | 69

Stakeholder Group E

Performance Viewpoint

Security Viewpoint Stakeholder Group F

Stakeholder Group A

Stakeholder Group B

Stakeholder Group C

Stakeholder Group D

Requirements Viewpoint

Functional Viewpoint

Deployment Viewpoint

Validation Viewpoint

Performance requirements

Component coupling

Component location Hardware specification

Performance validation elements

Distribution topology Security requirements

Security policies User authentication

Firewalls

Security validation elements

User authorization

Figure 4.4 Basic Viewpoints and Cross-Cutting Viewpoints

sider the location of communicating elements, the specification of the hardware supporting the system, and the distribution of the system as a whole (taking into account elements such as network latency, for example). ■

The performance view identifies the elements in the validation view that support the validation of the performance requirements. This view would consider how well the architecture meets the required performance characteristics, the rationale for any trade-offs made, and the outstanding risks and issues.

■

The security view identifies the security-related requirements in the requirements view and how those requirements are realized. Security requirements may be functional in nature, such as how users authenticate themselves to the system, or they may be constraints that are placed on the system, such as what strength of encryption must be used to encrypt data in the system.

■

The security view identifies the elements in the functional view that contribute to meeting the security requirements, such as components that handle authentication, authorization, auditing, and nonrepudiation. This view may also show which components and data elements need to be protected.

70 | Chapter 4 Documenting a Software Architecture ■

The security view identifies the elements in the deployment view that contribute to meeting the security requirements. The view may identify the need for specialized hardware or software (such as firewalls).

■

The security view identifies the elements in the validation view that support the validation of the security requirements. This view would consider how well the architecture meets the required security characteristics, the rationale for any trade-offs made, and the outstanding risks and issues.

Consideration of cross-cutting viewpoints can be extended further, beyond a consideration of qualities. You may decide to introduce an infrastructure viewpoint that focuses on elements that underpin the system under development but that are independent of the business domain (such as an error log or persistency mechanism). Again, the corresponding view would cut across the basic views. You may have infrastructure-related requirements (such as a constraint to use a particular relational database), infrastructure-related functional elements (such as an error-logging mechanism), infrastructure-related deployment elements (such as hardware nodes used to host the error-logging mechanism), and infrastructure-related validation elements (such as an assessment of how well the error-logging mechanism addresses the stated requirements). In practice, the authors have found that focusing on both basic and crosscutting views provides us a simple mental model for considering certain aspects of our architecture and can ensure that appropriate emphasis is placed on key architectural characteristics throughout the project life cycle.

Views and Diagrams A common misconception among architects is the assumption that a view is a diagram or that a diagram is a view, largely due to the similarity of these terms in IT circles. Although a view may be entirely represented by a single diagram, more often a view is represented in many diagrams. Consider a Boeing 747 jumbo jet, which consists of more than 6 million parts that weigh hundreds of thousands of pounds, contains wiring that runs more than 160 miles, has a cockpit that contains hundreds of control items, and can carry hundreds of passengers thousands of miles nonstop. Boeing produced more than 75,000 engineering drawings when the first 747 was designed in the 1960s. If each diagram were a view, the result would be not only an explosion of views (because many diagrams would be involved), but also an unmanageable number of diagrams. Therefore, different diagrams often target the same set of concerns and should be considered as a group. Each group of diagrams is considered to be a view, given our definitions. In essence, a view is a window onto the whole architecture from a particular vantage point.

Viewpoints and Views | 71

The relationship between views and diagrams is indicated in Figure 4.5, which shows two views: a functional view and a deployment view. In this example, the functional view, which is relevant to the concerns of stakeholder group A, is concerned with the components and their interactions, and consists of two diagrams. The deployment view, which is relevant to the concerns of stakeholder group B, is concerned with the deployment topology in terms of nodes and connections among nodes, and consists of a single diagram.

Benefits of Viewpoints and Views In addition to the general benefits of documenting a software architecture, you can achieve some specific benefits by taking an approach based on viewpoints and views: ■

To manage the complexity of the system. A view represents a simplification of reality. This simplification is achieved by focusing on a particular aspect of the system under consideration. A physical view of an airplane may focus on its aerodynamic properties, whereas a view of a software system’s deployment focuses on the operational environment in which the system will execute.

■

To focus on a specific aspect of the system. Most complex systems have several related but different views. An airplane has an external structure manifested in its wings, fuselage, and undercarriage; electrical circuitry; hydraulic systems; and so on. Similarly, a software system has

Stakeholder Group A

Stakeholder Group B

Functional View

Deployment View

Diagram

Diagram

Figure 4.5 An Example of Views and Diagrams

Diagram

72 | Chapter 4 Documenting a Software Architecture

functional characteristics, deployment characteristics, and so on. Views provide a clear separation of these various concerns. This separation allows you to consider a subset of the overall system without getting bogged down in the complexity of the system as a whole. ■

To communicate with stakeholders. To communicate a system to its various stakeholders effectively, you often have to represent different aspects of the same system in different views to address the needs of each stakeholder. A view that considers the external structure of an airplane may be used to communicate with an aerodynamics engineer. Similarly, a view of the deployment of a software system may be used to communicate with designers and systems administrators.

Models Model is the term used in the IEEE 1471 standard to represent a work product that participates in a view. Models contain the specific elements that are present within a view. A good example of a model is a mockup of an airplane that is placed in a wind tunnel to get a better understanding of its aerodynamic properties. As you will see, in terms of purpose, there is no difference between this example and the creation of models that represent different aspects of a software system, in that a model represents an abstraction of the system under consideration. Models provide the specific description, or content, of an architecture. For example, a structural view might consist of a set of models of the system structure. The elements of such models might include identifiable system components and their interfaces, and interconnections among those components. (IEEE 1471 2000)

The models described in this book include a Functional Model, a Deployment Model, and a Data Model. In addition, in a general sense, even work products that are represented in documents or spreadsheets (for example) can be considered to be models, because they conform to the definition of a model given in the preceding paragraph. Figure 4.6 shows the relationship among views, diagrams, and models. As you can see from this figure, models may be shared across views. Specifically, although the functional view presents elements in the Functional Model and the deployment view presents elements in the Deployment Model, you can also see that the deployment view presents elements in the Functional Model

Models | 73

Stakeholder Group A

Stakeholder Group B

Functional View

Deployment View

Diagram

Diagram

Functional Model

Diagram

Deployment Model

Figure 4.6 An Example of Views, Diagrams, and Models

because we want to show the deployment of components (from the Functional Model) to nodes (from the Deployment Model).

Levels of Realization Although different models are used to capture different aspects of the system, a given model may itself go through a series of refinements, particularly models that represent aspects of the solution, such as the Functional Model work product. The discrete levels of realization that a model moves through during its life can provide stepping stones in getting from an initial model whose content is very conceptual to a model whose content is detailed enough to be used as the basis of implementation. It is possible to consider the content of the Functional Model work product in both a logical (or technology-independent) manner and a physical (or technology-specific) manner, for example. These two aspects of the same model represent different levels of realization of the model. The same thinking can be applied to other models. The Data Model, for example, can be considered in terms of a logical data model (that identifies entities and their relationships) or in terms of a physical data model (that also

74 | Chapter 4 Documenting a Software Architecture

acknowledges implementation concerns, such as index tables and stored procedures that improve the performance of data access). This thinking is reflected in Figure 4.7. If appropriate, the architect may also choose to retain the logical models and create separate physical models. This topic is discussed further in Chapter 8, “Creating the Logical Architecture.” Note that a level of realization is not the same as a level of abstraction. A level of abstraction is concerned with a particular amount of detail, where the higher the level of abstraction, the less detail. When considering levels of realization, however, you are not simply adding or removing detail; you are fundamentally making choices that result in different elements being considered. A component representing an Order Manager in the logical Functional Model may be realized, in a Java EE environment, as an Enterprise JavaBean (EJB) and provide Java EE-specific interfaces in the physical Functional Model, for example. Therefore, when moving from the logical architecture to the physical architecture, the architect may need to consult technical specialists who are deeply familiar with any technologies being considered, because a one-to-one, one-to-many, or many-to-one mapping may exist between logical elements and physical elements, depending on the technologies (and patterns) being used. We discuss this topic further in Chapter 8, “Creating the Logical Architecture.” Finally, we should note that the distinction between logical and physical elements is not black and white. Is a Load Balancer component logical, for example? The answer, of course, is “It depends.” The component certainly is not technology specific, because we’ve not stated what technology will be used to provide the load balancing. It’s not technology independent either, because it assumes that we have chosen an environment that requires load balancing! In summary, just remember that the terms logical and physical are not clear-cut.

Level

View

Functional View

Deployment View

Logical Architecture

Functional Model Data Model

Deployment Model

Physical Architecture

Functional Model Data Model

Deployment Model

Figure 4.7 Views, Models, and Levels of Realization

Characteristics of an Architecture Description Framework | 75

Benefits of Models In addition to the general benefits of documenting an architecture, creating models has some specific benefits: ■

Detecting errors and omissions early in the life cycle. It is a lot cheaper to create a scale model of an airplane and place it in a wind tunnel than to construct an actual airplane and fly it to understand its aerodynamic properties. Similarly, it is a lot cheaper to create a model of the design of a software system and test this model than to construct the actual software system to validate the design.

■

Examining the relative merits of different options. Creating several models of an airplane, all satisfying the same requirements, allows the relative merits of each solution to be debated without having to move to actual full-scale production of several aircraft. Similarly, several designs of a software system, captured in appropriate models, can be used to discuss the relative merits of the proposed software solutions.

■

Understanding the impact of change. If a model contains elements that are derived from elements of other models (such as solution elements that are derived from requirements), documenting the relationships among elements in the various models may be possible. These relationships are often called traceability relationships, because they show how elements in one model trace to elements in another. Then the architect can use these to understand the impact of making a change. The impact of changing a requirement can be assessed in terms of the impact on solution elements, for example. Conversely, the impact of changing a solution element (such as rewriting a computational algorithm) can be determined in terms of its coverage by looking at the requirements that this solution element wholly or partially satisfies.

■

Assisting with project planning. The elements of a model can assist with project planning in terms of schedule and resource. Having a model of the solution that shows which elements are dependent on others can provide an indication of the sequence in which these elements can be implemented, the skills required, and the effort required.

Characteristics of an Architecture Description Framework In simple terms, an architecture description framework represents a set of viewpoints (and, therefore, views, models, other work products, techniques, and so on) that can be used together to describe an architecture. Rather than

76 | Chapter 4 Documenting a Software Architecture

starting from scratch, an architect typically selects viewpoints from a viewpoint catalog and, if necessary, tailors them to his or her needs. The choice of viewpoints is often specified by some organizational standard (a requirements viewpoint and a functional viewpoint may be mandatory, for example), as well as the nature of the system under consideration (a system that executes on a single node may not use a deployment viewpoint, for example). The purpose of this section is to set the scene for the architecture description framework used in this book by examining specific characteristics that are exemplified in certain architecture description frameworks in use today and to put some meat on the bones of the earlier discussion. This section is not intended to be a comprehensive discussion of all architecture description frameworks that you may encounter—simply those that help demonstrate a particular characteristic. The characteristics emphasized in this section are ■

Multiple views and the use of a scenarios view, taken from Philippe Kruchten’s “The “4+1” View Model of Software Architecture” (Kruchten 1995)

■

Levels of realization, taken from the Zachman Framework, created by John Zachman (Zachman 1987)

■

Cross-cutting concerns, taken from Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives (Rozanski 2005)

As you will see, each architecture description framework we discuss focuses on ensuring that the many aspects of the architecture are clearly separated but have well-defined relationships and, thus, are consistent. Several of the architecture description frameworks also include elements of process guidance. Additional considerations for documenting a software architecture effectively are given in Documenting Software Architectures: Views and Beyond (Clements 2003). In the following descriptions, it is important to remember that a one-to-one correspondence exists between a view and a viewpoint (if you consider a view to be an instance of a viewpoint) for any given project, although different architecture description frameworks prefer to use one term instead of the other in their descriptions.

The 4 + 1 View Model of Software Architecture A commonly used architecture description framework is “The “4+1” View Model of Software Architecture,” as defined by Philippe Kruchten (Kruchten

Characteristics of an Architecture Description Framework | 77

1995). This architecture description framework defines five views and is shown in Figure 4.8. The author describes the various viewpoints as follows: ■

The logical view is the object model of the design (when an object-oriented design method is used).

■

The process view captures the concurrency and synchronization aspects of the design.

■

The development view describes the static organization of the software in its development environment.

■

The physical view describes the mapping(s) of the software to the hardware and reflects its distributed aspect.

■

The description of an architecture is illustrated by a few selected use cases or scenarios that become a fifth view (the scenarios view).

An interesting characteristic of this architecture description framework is the use of a scenarios view. The scenarios typically are selected based on the architecturally significant requirements that the scenarios will exercise, which allows the architect to validate whether these requirements have been addressed.

Zachman Framework The Zachman Framework, created by John Zachman and discussed in “A Framework for Information Systems Architecture” (Zachman 1987), targets enterprise architecture rather than software architecture. This architecture description framework, which exhibits some characteristics that are worth mentioning specifically, is shown in Figure 4.9. In particular, this framework

Logical View

Development View Scenarios

Process View

Physical View

Figure 4.8 The “4+1” View Model of Software Architecture

78 | Chapter 4 Documenting a Software Architecture

Abstractions

Data

Perspectives

Scope

Business Model

System Model

Function

Time

Motivation

List of processes List of locations the business in which the performs business operates

List of organizations important to the business

List of events/cycles significant to the business

List of business goals/strategies

e.g. Semantic model

e.g. e.g. Business process Business model logistics system

e.g. Workflow model

e.g. Master schedule

e.g. Business plan

e.g. Logical data model

e.g. Application architecture

e.g. Distributed system architecture

e.g. e.g. Human interface Processing architecture structure

e.g. Business rule model

e.g.

e.g. System design

e.g. Technology architecture

e.g. Presentation architecture

e.g. Control structure

e.g. Rule design

e.g. Data definition

e.g. Program

e.g. Network architecture

e.g. Security architecture

e.g. Timing definition

e.g. Rule Specification

e.g. DATA

e.g. FUNCTION

e.g. NETWORK

e.g. e.g. ORGANIZATION SCHEDULE

model

Functioning Enterprise

People

List of things important to the business

Technology Model Physical data Detailed Representations

Network

e.g. STRATEGY

Figure 4.9 The Zachman Framework

not only defines several viewpoints (the columns), but also explicitly defines several levels of realization (the rows). The Zachman Framework uses the term perspective to represent a level of realization (as described in this book) and the term abstraction to represent a view. The viewpoints (the columns) are ■

Data (the what). This column describes the entities in the enterprise, such as business entities and relational tables.

■

Function (the how). This column describes the functions in the enterprise, such as business processes and software application functionality.

■

Network (the where). This column describes locations in the enterprise, such as major business geographical locations and system nodes.

■

People (the who). This column describes the people in the enterprise.

Characteristics of an Architecture Description Framework | 79 ■

Time (the when). This column describes the impact of time on the enterprise, such as scheduling of capabilities.

■

Motivation (the why). This column describes the motivations of the enterprise, such as goals and objectives. The levels of realization (the rows) are

■

Scope. This row defines a contextual perspective.

■

Business model. This row defines a conceptual perspective.

■

System model. This row defines a logical perspective.

■

Technology model. This row defines a physical perspective.

■

Detailed representations. This row defines modules that can be implemented.

■

Functioning enterprise. This row defines the operational system.

Rozanski and Woods In Software Systems Architecture:Working with Stakeholders Using Viewpoints and Perspectives (Rozanski 2005), Nick Rozanski and Eoin Woods emphasize a set of cross-cutting viewpoints (referred to as perspectives) in addition to several basic viewpoints, as shown in Figure 4.10. The authors describe their various viewpoints in the form of a catalog. The basic viewpoints, as described in their work, are ■

Functional. Describes the system’s functional elements and their responsibilities, interfaces, and primary interactions.

■

Information. Describes the way that the architecture stores, manipulates, manages, and distributes information.

■

Concurrency. Describes the concurrency structure of the system, and maps functionality elements to concurrency units to identify clearly the parts of the system that can execute concurrently and how this execution is coordinated and controlled.

■

Development. Describes the architecture that supports the software development process.

80 | Chapter 4 Documenting a Software Architecture

Security Perspective

Accessibility Perspective

Performance Perspective

Location Perspective

Availability Perspective

Regulation Perspective

Usability Perspective

etc.

Functional View

Development View

Information View

Deployment View

Concurrency View

Operational View

Figure 4.10 The Rozanski and Woods Framework

■

Deployment. Describes the environment in which the system will be deployed, including capturing the dependencies of the system on its runtime environment.

■

Operational. Describes how the system will be operated, administered, and supported when it is running in its production environment. The perspectives described (although not all are shown in Figure 4.10) are

■

Security. The ability of the system to control, monitor, and audit reliably who can perform what actions on what resources, and to detect and recover from failures in security mechanisms.

■

Performance (and scalability). The ability of the system to execute predictably within its mandated performance profile and to handle increased processing volumes.

■

Availability (and resilience). The ability of the system to be fully or partly operational as and when required, and to handle effectively failures that could affect system availability.

■

Evolution. The ability of the system to be flexible in the face of the inevitable change that all systems experience after deployment, balanced against the costs of providing such flexibility.

An Architecture Description Framework | 81 ■

Accessibility. The ability of the system to be used by people with disabilities.

■

Development resource. The ability of the system to be designed, built, deployed, and operated within known constraints around people, budget, time, and materials.

■

Internationalization. The ability of the system to be independent of any particular language, country, or cultural group.

■

Location. The ability of the system to overcome problems brought about by the absolute locations of its elements and the distances between them.

■

Regulation. The ability of the system to conform to local and international laws, quasilegal regulations, company policies, and other rules and standards.

■

Usability. The ease with which people who interact with the system can work effectively.

An Architecture Description Framework The architecture description framework used in this book builds on several of the architecture description frameworks discussed in this chapter. This architecture description framework can be reused for the architectures of different systems, and each architect using this framework should select the appropriate viewpoints, depending on the nature of the system under consideration. In addition, the framework should be considered to be extensible, in that viewpoints may be added as necessary.

Viewpoints Figure 4.11 shows a summary of the viewpoints (and, therefore, views) used in this book. Table 4.1 provides a summary of the stakeholders of the architecture and identifies those who are potentially interested in each viewpoint. The table also indicates the scope of each stakeholder; internal stakeholders are members of the current development team, and external stakeholders are not members of that team. Table 4.2 summarizes the viewpoints. For a more complete description of each of these viewpoints, turn to Appendix B, “Viewpoint Catalog.” It is important to ensure that the correct viewpoints are applied in any given situation. The architecture description framework presented here is only an example that demonstrates the principles inherent in such a framework.

82 | Chapter 4 Documenting a Software Architecture

Basic Viewpoints

Requirements Viewpoint

Functional Viewpoint

Deployment Viewpoint

Validation Viewpoint

Cross-Cutting Viewpoints

Application Viewpoint Infrastructure Viewpoint Systems Management Viewpoint Availability Viewpoint Performance Viewpoint Security Viewpoint

Figure 4.11 The Architecture Description Framework

Table 4.1 Stakeholder Summary Role

Scope

Primary Responsibility

Application Owner Business Administrator Configuration Manager

External External Internal

Developer Maintainer

Internal External

Project Manager

Internal

Supplier

External

Support Personnel System Administrator Tester

External External Internal

Commissions (and funds) the system Manages business-related elements of the operational system Defines the structure of the configuration management repository and the elements that reside within it Performs detailed design and implementation of the system Manages the ongoing evolution of the system after it has been deployed Manages the execution of the development project in terms of planning, staffing, monitoring, and risk management Provides software or hardware elements required in the development or running of the system Provides system support and performs diagnostic functions Manages the operational execution of the system Tests the system to ensure that it is fit for its purpose

User

External

Uses the system’s business functionality

An Architecture Description Framework | 83

Table 4.2 Viewpoint Summary Viewpoint

Stakeholders

Requirements

All stakeholders

Functional

Deployment

Validation

Application

Infrastructure

Systems Management Availability

Performance

Description

This viewpoint is concerned with the system requirements that have shaped the architecture and includes functional requirements, qualities, and constraints. All stakeholders This viewpoint is concerned with those architectural elements that support the functionality (logic) of the system and includes the structural elements from which the system is built, the relationships among them, and their behavior. Configuration Manager, This viewpoint is concerned with those architectural Developer, Maintainer, elements that support the distribution of the system Project Manager, Supplier, and includes elements such as location, nodes, Support Personnel, devices, and the connections among them. System Administrator, Tester Application Owner, This viewpoint is concerned with assessing whether the Project Manager, Tester system will provide the required functionality, exhibit the required qualities, and accommodate the defined constraints. Business Administrator, This viewpoint is concerned with those architectural Developer, Maintainer, elements that provide the application-specific behavSupplier, System ior of the solution—that is, behavior that the system Administrator, Tester must provide to meet its business requirements. Developer, Maintainer, This viewpoint is concerned with those architectural Supplier, System elements that provide the application-independent Administrator, Tester behavior of the solution—that is, behavior that the system must provide to support the business purpose of the system. Developer, Maintainer, This viewpoint is concerned with those architecture eleSupplier, System ments that contribute to the operational running of Administrator, Tester the system when it has been deployed to production. Developer, Maintainer, This viewpoint is concerned with those architectural Supplier, System elements that allow the system to meet the specified Administrator, Tester availability requirements. This viewpoint is also concerned with those architectural elements that allow the system to recover from failures (that make the system fully or partially unavailable). Developer, Maintainer, This viewpoint is concerned with those architectural Supplier, System elements that allow the system to meet the specified Administrator, Tester performance requirements (such as response time and throughput). Continued

84 | Chapter 4 Documenting a Software Architecture

Table 4.2 Viewpoint Summary (Continued) Viewpoint

Stakeholders

Description

Security

Developer, Maintainer, Supplier, System Administrator, Tester

This viewpoint is concerned with those architectural elements that allow the system to meet the specified security requirements, such as authorized access to the system functions and resources. This viewpoint is also concerned with those architectural elements that allow the system to detect, and recover from, failures in the system’s security mechanisms.

Therefore, for any given system, you may remove or add views as required. If you are building a system that always executes on a single node, for example, you can ignore the deployment view (which considers distribution). Conversely, you may choose to add views if you require a particular emphasis that is not an inherent consideration of the architecture description you selected, such as adding an evolution view if system evolution is a primary concern of the architecture.

Work Products In the “Models” section earlier in this chapter, we state that a view refers to elements contained in one or more models (work products) and that a model may participate in one or more views. Figure 4.12 shows the following work products, which are used in the architecture description framework that we use in this book: ■

The requirements view refers to elements contained in the Business Entity Model, Business Process Model, Business Rules, Change Request, Enterprise Architecture Principles, Existing IT Environment, Functional Requirements, Glossary, Non-Functional Requirements, Prioritized Requirements List, Stakeholder Requests, System Context, and Vision work products.

■

The functional view refers to elements contained in the Architecture Decisions, Architecture Overview, Data Model, and Functional Model work products.

An Architecture Description Framework | 85

Requirements Viewpoint Application Viewpoint Infrastructure Viewpoint Systems Management Viewpoint Availability Viewpoint Performance Viewpoint Security Viewpoint

Business Entity Model Business Process Model Business Rules Change Request Enterprise Architecture Principles Existing IT Environment Functional Requirements Glossary Non-Functional Requirements Prioritized Requirements List Stakeholder Requests System Context Vision

Functional Viewpoint Architecture Decisions Architecture Overview Data Model Functional Model

Deployment Viewpoint Architecture Decisions Architecture Overview Deployment Model

Validation Viewpoint Architecture Assessment Architecture Proof-ofConcept RAID Log Review Record

Figure 4.12 Viewpoints and Work Products

■

The deployment view refers to elements contained in the Architecture Decisions, Architecture Overview, and Deployment Model work products.

■

The validation view refers to elements contained in the Architecture Assessment, Architecture Proof of Concept, Issue List, RAID Log, and Review Record work products.

A cross-cutting view potentially references elements in all these work products.

Levels of Realization This architecture description framework used in this book also incorporates different levels of realization and is represented in Figure 4.13. The important item to note is that the framework is used to describe both the logical architecture and the physical architecture. The logical architecture is discussed in detail in Chapter 8, “Creating the Logical Architecture,” and the physical architecture is discussed in Chapter 9, “Creating the Physical Architecture.”

86 | Chapter 4 Documenting a Software Architecture

Logical Requirements Viewpoint Application Viewpoint Infrastructure Viewpoint Systems Management Viewpoint Availability Viewpoint Performance Viewpoint Security Viewpoint

Business Entity Model Business Process Model Business Rules Change Request Enterprise Architecture Principles Existing IT Environment Functional Requirements Glossary Non-Functional Requirements Prioritized Requirements List Stakeholder Requests System Context Vision

Functional Viewpoint Architecture Decisions Architecture Overview Data Model Functional Model

Deployment Viewpoint Architecture Decisions Architecture Overview Deployment Model

Validation Viewpoint Architecture Assessment Architecture Proof-ofConcept RAID Log Review Record

Physical Requirements Viewpoint Application Viewpoint Infrastructure Viewpoint Systems Management Viewpoint Availability Viewpoint Performance Viewpoint Security Viewpoint

Business Entity Model Business Process Model Business Rules Change Request Enterprise Architecture Principles Existing IT Environment Functional Requirements Glossary Non-Functional Requirements Prioritized Requirements List Stakeholder Requests System Context Vision

Figure 4.13 Levels of Realization

Functional Viewpoint Architecture Decisions Architecture Overview Data Model Functional Model

Deployment Viewpoint Architecture Decisions Architecture Overview Deployment Model

Validation Viewpoint Architecture Assessment Architecture Proof-ofConcept RAID Log Review Record

The Software Architecture Document | 87

View Correspondence Although you may think of views as being independent, this is not necessarily the case. You may want to enforce a rule that says that all components described in a functional view are deployed to nodes in a deployment view, for example. The term view correspondence is used to describe such relationships.

The Software Architecture Document The Software Architecture Document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. (RUP 2008)

As we mention in Chapter 3, “Method Fundamentals,” the Software and Systems Process Engineering Metamodel Specification (SPEM) defines three types of work products: artifact, outcome, and deliverable. A deliverable is a work product that is provided to an internal or external third party. The Software Architecture Document is an example of a deliverable and is the primary vehicle for documenting and communicating the software architecture. Rather than reinventing content defined in other work products, the Software Architecture Document makes reference to these work products, as discussed in Chapter 3. As one would expect, the Software Architecture Document deliverable conforms to the chosen architecture description framework. An outline for a Software Architecture Document, which conforms to the architecture description framework on which we elaborate in this chapter, is as follows: ■

Front matter (title page, change history, table of contents, list of figures, references)

■

Objectives of the Software Architecture Document

■

Overview of the Architecture

■

Architecture Decisions

■

Requirements View

■

Functional View

■

Deployment View

■

Validation View

■

Application View

88 | Chapter 4 Documenting a Software Architecture ■

Infrastructure View

■

Systems Management View

■

Availability View

■

Performance View

■

Security View

■

Appendices

Summary This chapter discussed many of the fundamental concepts in documenting a software architecture, including views and viewpoints and their relationships with the underlying work products. We also presented an architecture description framework that builds on proven practices when documenting a software architecture. This architecture description framework is exemplified in the case study– related chapters (Chapters 6 through 9). First, we touch on another foundational concept of architecting a software-intensive system: the reuse of existing assets. This topic is the subject of Chapter 5, “Reusable Architecture Assets.”

Chapter 5 Reusable Architecture Assets

The life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark. (Kruchten 1999)

The purpose of this chapter is to shed some light on the darkness by discussing a key characteristic of successful software architectures: the use of reusable assets. Reusable assets provide a valuable vehicle for capitalizing on the work of other successful architects, from fine-grained design patterns to large-grained off-the-shelf packaged applications. However, consideration of reusable assets can itself be a mine field. You have many types of assets to consider, and it is not always clear what each of them means and the value it provides. What is the difference between an architectural style and a reference architecture? How does a mechanism differ from a framework? The purpose of this chapter is to discuss the different types of reusable assets available to the architect, their characteristics, and their use.

Sources of Architecture Inspiration for deriving an architecture comes from many places and varies depending on many factors, including the novelty of the system, the method being followed, and the skills of the architect. This was succinctly described in “Mommy, Where Do Software Architectures Come From?” (Kruchten 1995-2), where the author suggests three main sources of architecture: theft, method, and intuition, as shown in Figure 5.1. 89

90 | Chapter 5 Reusable Architecture Assets

Method Theft

Method Intuition

A Classical System

Theft

Intuition

An Unprecedented System

Figure 5.1 Sources of Architecture, Taken from Kruchten.

In terms of theft, most elements of a software architecture are derived from a previous system of the same kind, another system with overall similar characteristics, or an architecture found in technical literature—in other words, the use of existing assets. Method refers to a systematic way by which an architecture is derived from the system’s requirements. Finally, intuition reflects the experience of the software architect who recognizes some pattern or finds other inspiration for an architectural element. The relative widths of the arrows shown in Figure 5.1 also provide an indication of the relative emphasis of the three sources, depending on the novelty of the system. A classical system may comprise 80 percent theft, 19 percent method, and 1 percent intuition, and an unprecedented system may comprise 30 percent theft, 50 percent method, and 20 percent intuition. In both cases, the reuse of existing assets is significant. Put another way, a good architect does not reinvent the wheel.

An Architecture Asset Metamodel Not surprisingly, successful architects tend to be those who are conscious of the assets available. Consideration of reusable assets can significantly help architects in their work because it reduces the number of things that architects need to be concerned with; they do not need to reinvent the wheel. From a project perspective, the reuse of assets within the project can have a significant bearing on the project schedule, cost, and quality of the delivered system. In a general sense, reusable assets can be applied in all the software engineering disciplines. A reusable asset could represent a reusable requirement (a requirement that occurs over and over within different systems), a reusable

An Architecture Asset Metamodel | 91

solution element (such as an architectural pattern or reusable code), a reusable test, a reusable method, and so on. In this book, we focus on those reusable assets that are of most relevance to the software architect in defining an architecture. Keep in mind that the assets discussed here are based on the authors’ experiences of working with clients. The industry has no agreed-on definition for several of these assets, so we offer definitions based on our experiences. Understanding the characteristics of each type of asset and the relationships among assets can help you understand their applicability when trying to find an asset for a particular situation. To help you build this understanding, Figure 5.2 shows a partial asset metamodel, which we use to describe the different types of assets and their relationships. From this figure you can see that to a large extent, architecture assets can be divided into development-time assets (such as design patterns) and run-time assets (such as packaged applications). For more details, see the sidebar “Concept: Development-Time and Run-Time Assets.” Figure 5.2 tells you that ■

An architecture may be based on a reference architecture.

■

An architecture has any number of associated development-time assets.

■

An architecture has any number of associated run-time assets.

■

A reference architecture is a kind of architecture.

■

A reference architecture may be used as the basis of any number of architectures.

■

A development-time asset may be used in any number of architectures.

Reference Architecture

0..1 based upon

Architecture

*

* *

*

uses

*

* DevelopmentTime Asset

*

*

Figure 5.2 An Architecture Asset Metamodel

*

*

uses

Run-Time Asset *

92 | Chapter 5 Reusable Architecture Assets ■

A development-time asset may use any number of other development-time assets.

■

A development-time asset may influence any number of run-time assets.

■

A run-time asset may be used in any number of architectures.

■

A run-time asset may use any number of other run-time assets.

■

A run-time asset may influence any number of development-time assets.

Development-Time Assets A metamodel of development-time assets is shown in Figure 5.3. Figure 5.3 tells you that ■

A development method, architectural style, architectural mechanism, pattern, reference model, and architecture decision are all kinds of development-time assets.

■

A development method is associated with any number of viewpoint catalogs.

■

A viewpoint catalog is associated with any number of development methods.

■

An architectural pattern, design pattern, and idiom are all kinds of patterns.

Run-Time Assets A metamodel of run-time assets is shown in Figure 5.4.

Concept: Development-Time and Run-Time Assets The asset metamodel described in this chapter characterizes the majority of assets as being either development-time assets or run-time assets. In general terms, this characterization is based on the level of articulation. A development-time asset has no concrete run-time implementation, whereas a run-time asset does. Almost all assets, however, exhibit their influence at both developmenttime and run-time. A design pattern may not have a concrete implementation, but run-time elements and interactions may conform to the pattern. Similarly, a packaged application has a concrete implementation, but you also need to consider this element in any architecture models at development time.

An Architecture Asset Metamodel | 93

DevelopmentTime Asset

Development Method

Architectural Style

Architectural Mechanism

Pattern

Architectural Pattern

Design Pattern

Reference Model

Architecture Decision

* *

Viewpoint Catalog

Idiom

Figure 5.3 Metamodel of Development-Time Assets

Run-Time Asset

Existing Application

Application Framework

Component Library * *

Packaged Application

Component

Figure 5.4 Metamodel of Run-Time Assets

Figure 5.4 tells you that ■

An existing application, application framework, and component library are all kinds of run-time assets.

■

A packaged application is a kind of existing application.

■

A component library contains any number of components.

■

A component may be contained in any number of component libraries.

94 | Chapter 5 Reusable Architecture Assets

Asset Types This section contains a detailed description of each of the assets in the metamodel described in the preceding section, in the sequence in which they were introduced.

Reference Architecture One asset in particular can have a major bearing on the architecture: a reference architecture. The idea of a reference architecture is that it provides an initial starting point upon which to build a new system. This type of asset is relatively large-grained in comparison with some other reusable assets. A reference architecture is associated with a particular domain of interest and typically includes many different architectural patterns, applied in different areas of its structure. In 1999 IBM published a series of technical reference architectures that described the architectures of systems across different business domains (such as e-business, Life Sciences, and Wireless). Because a reference architecture is an architecture, it is no surprise to find that a reference architecture is described in exactly the same manner as any other architecture. It may be described in a Software Architecture Document that refers to several other architecture work products, such as architecture models that describe different aspects of the architecture. On occasion, reference architectures also may include concrete implementation elements. Reference architectures are most successful when they are exemplified with concrete reference implementations.

Development Method As we discuss extensively in this book, a development method codifies best practices and associated guidance, techniques, and standards, and also typically contains reusable elements associated with the creation of work products, such as templates and examples. As such, the development method is itself a reusable asset at the disposal of the architect. As with other assets, it also makes sense to apply appropriate standards to maximize the reuse potential. Also, from the perspective of a development method, consideration of the Software and Systems Process Engineering Metamodel Specification (SPEM) Object Management Group (OMG) standard (SPEM 2007) (discussed in Chapter 3, “Method Fundamentals”) is warranted. The development method is just one part of a complete development environment, all aspects of which are potentially reusable assets at the disposal of the architect. The development method, for example, is augmented by appro-

Asset Types | 95

priate tools that automate aspects of the method, such as modeling tools, compilers, and debuggers.

Viewpoint Catalog In this chapter we describe those reusable assets that are of most relevance to the software architect, so we should explicitly mention a particular standard associated with the development method: the viewpoint catalog. As discussed in Chapter 4, “Documenting a Software Architecture,” architects typically describe their architecture by using a set of viewpoints that have been selected from a viewpoint catalog and tailored to their needs. Each viewpoint addresses a related set of stakeholder concerns.

Architectural Style The concept of an architectural style was introduced by Mary Shaw and David Garlan in their seminal work Software Architecture: Perspectives on an Emerging Discipline (Shaw 1996). [An architectural style] defines a family of systems in terms of a pattern of structural organization. More specifically, an architectural style defines a vocabulary of components and connector types, and a set of constraints on how they can be combined. (Shaw 1996)

An architectural style applies to the system as a whole and, therefore, has a major impact on the architecture. Also, a given system may exhibit more than one architectural style. As touched on in Chapter 2, “Architecture, Architect, Architecting,” service-oriented architecture (SOA) can be considered to be an architectural style. Some examples of other architectural styles, as described in Software Architecture: Perspectives on an Emerging Discipline (Shaw 1996) and Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives (Rozanski 2005), are ■

Client-server. This widely used style supports the physical (distributed) separation of client-side processing (on a user workstation) and server-side processing (on a remote server that may, for example, access a database).

■

Event-based. This style is similar to the Observer pattern (described in the “Pattern” section later in this chapter) in that it promotes a publish– subscribe way of working in which one or more observers subscribe to a particular event occurring in the system and a subject publishes a notification when the event occurs. Rather than being confined to specific

96 | Chapter 5 Reusable Architecture Assets

instances within the architecture, however, this style is applied strategically across large areas of the architecture. ■

Pipes-and-filters. This style comprises a series of filters that provide data transformation and pipes that connect the filters. Examples of a pipes-andfilters style include compilers, signal processing, and even elements of a Straight Through Processing (STP) solution used in financial markets, in which the trade process for capital markets and payments transactions is conducted electronically. This concept is also used in the energy sector for electricity, oil, and gas trading.

Architectural Mechanism Architects frequently characterize solution elements as mechanisms, as in “the mechanism for achieving X” or “this element is underpinned by mechanism Y.” Examples of mechanisms include a persistency mechanism, an error-logging mechanism, a communication mechanism, and a shopping cart. Like an architectural style, a mechanism may comprise one or more patterns. Architectural mechanisms represent common concrete solutions to frequently encountered problems. They may be patterns of structure, patterns of behavior, or both. (SPEM 2007)

Of all of the terms introduced in this chapter, an architectural mechanism is possibly the least well defined, because it is simply an overarching term for the many different (and more precise) types of architectural elements you may encounter.

Pattern The term pattern is used to represent many types of reusable elements that may be conceived and, therefore, represents a very general type of asset. [A pattern is] a common solution to a common problem in a given context. (UML User Guide 1999)

Because a pattern is such a general concept, it can be applied throughout the development life cycle in many areas, resulting in requirements patterns, architectural patterns, design patterns, programming patterns (referred to as idioms), testing patterns, project management patterns, process patterns, organizational patterns, and so on.

Asset Types | 97

Given the importance of patterns to the architect, it is not surprising that some emphasis has been placed on identifying patterns and on techniques for documenting patterns. Applying lessons learned from civil engineering, the patterns movement has risen rapidly over the past ten years. Many publications and websites are dedicated to various types of patterns, including platformindependent design patterns (Fowler 1997), architectural patterns (Buschmann 1996), and design patterns (Gamma 1995). The inspiration for these publications stems from the influential works of building architect Christopher Alexander (Alexander 1964, Alexander 1977, and Alexander 1979). There are even sources of antipatterns (Brown 1998). [An antipattern is] a commonly occurring pattern or solution that generates decidedly negative consequences. An antipattern may be a pattern in the wrong context. (Brown 1998)

Architects are particularly interested in those patterns that influence their work directly, as well as those that influence detailed design and implementation. These patterns generally include the following: ■

Architectural patterns. These patterns are large-grained, an example of which is the Layers pattern as defined in Pattern-Oriented Software Architecture: A System of Patterns (Buschmann 1996). This pattern structures applications into groups, where each group represents a particular level of abstraction. One of the most familiar examples of layering is the OSI 7-layer model, defined by the International Standardization Organization (ISO), where each layer builds upon the capabilities in lower layers.

■

Design patterns. These patterns are finer-grained, an example of which is the Observer pattern as defined in Design Patterns: Elements of Reusable Object-Oriented Software (Gamma 1995). This pattern, also known as Publish-Subscribe, allows an object to subscribe to events that occur in a target object and to be notified when such events occur. The architect often identifies the design patterns to be used in a project because such decisions constrain the designers in their work, ultimately resulting in a level of consistency and, therefore, architectural integrity.

■

Idioms (programming patterns). These patterns are reusable programming expressions defined in a particular programming language. Architects typically are not involved in the identification of idioms, although they may want to influence certain areas, such as the manner in which programming exceptions are raised and handled.

98 | Chapter 5 Reusable Architecture Assets

Patterns are of interest to architects in terms of reusing existing experience; they are also valuable mechanisms for defining elements of the solution that should be applied consistently and represent an opportunity for architects to share their knowledge with the project in a codified form. Although many templates exist for describing patterns (or antipatterns), they have much commonality. Most pattern descriptions include ■

The name of the pattern

■

The context within which the pattern is used

■

The specific problem(s) that the pattern solves

■

The solution provided by this pattern

■

The patterns that are related to this pattern

The pattern solution can be represented visually, in terms of both structure and behavior. Figure 5.5 is a Unified Modeling Language (UML) class diagram showing the participants in the Observer pattern, which is derived from Design Patterns: Elements of Reusable Object-Oriented Software (Gamma 1995). One of the primary goals of this pattern is to remove the need for the subject to have any knowledge of the elements observing it. In this pattern, this goal is achieved by introducing a superclass (Subject) that maintains a list of observers.

Subject Observer notify() { for all o in observers { o->notification() } }

attach ( observer ) detach ( observer ) notify ( )

*

ConcreteSubject

*

notification ( )

ConcreteObserver

Client setState ( )

notification ( )

setState() { notify() }

Figure 5.5 Structural Elements in the Observer Pattern

Asset Types | 99

As well as showing the structure of a pattern, you may show its behavior. Figure 5.6 is a UML sequence diagram showing how the structural elements within the Observer pattern collaborate. This diagram shows the behavior when the subject is updated. This update results in a notification message being sent to the observers, informing them that the subject has changed. The point here is not simply to demonstrate the Observer pattern, but to show how architectural experience can be captured and communicated. Architects typically reuse patterns identified from external sources, as well as defining their own patterns to be used in the project, to ensure some level of architectural consistency. Also, of course it is more efficient to capture a pattern once and note where it has been applied than to describe every use of the pattern in detail. Describing a pattern in a UML modeling tool also opens opportunities to apply the pattern automatically to existing model elements. Then you may be able to identify those model elements that satisfy particular roles within a pattern and subsequently update the model (automatically) by applying the pattern in the relevant places. In our Observer pattern example, any elements identified as observers would have a notification operation added to them. The application of a pattern in a modeling tool could be more extensive, resulting in the creation of attributes, operations, relationships, and even new modeling elements. This capability supports a model-driven development approach to software development.

:Client

:ConcreteSubject

A:ConcreteObserver

1: setState 1.1: notify 1.1.1: notification

1.1.2: notification

Figure 5.6 Behavior in the Observer Pattern

B:ConcreteObserver

100 | Chapter 5 Reusable Architecture Assets

Patterns (in the broadest sense) can also be applied when transforming an input to an output. You may want to generate code from a UML model, for example. The rules that govern the transformation could be specified as a pattern. Similarly, you can use the same philosophy when transforming from one model to another model. The concept of model transformation is one of the cornerstones of the Model Driven Architecture (MDA) initiative from the OMG (MDA 2009). Patterns can also be combined to form a pattern language, which defines a collection of patterns and the rules to combine them. Pattern languages are often used to describe a family of systems. IBM Patterns for e-Business (IBM 2009), for example, define a set of architectural patterns that describe various web-based applications. One aspect of this offering is a pattern-selection process that supports the identification of an application pattern and, based on that pattern, the selection of an appropriate run-time pattern. The linkage between the application pattern and the runtime pattern is part of the pattern language that has been implemented.

Reference Model A reference model is an abstract representation of entities, their relationships, and behavior in a given domain of interest, which typically forms the conceptual basis for the development of more concrete elements. Examples include a business model, an information model, and a glossary of terms. An example of a reference model is a business model that defines the business entities and business processes that you would expect to find in a financial organization. Because such entities and processes influence the IT systems that support them, it is clearly of benefit to architects to consider such reference models in their work. The business entities typically represent crisp abstractions that influence elements in the different layers of the architecture in terms of their identification and naming. IBM’s Insurance Application Architecture (IAA) is a concrete example of a reference model. This model provides more than 200 business processes and 700 individual business activities representing best practices used throughout the insurance industry.

Architecture Decision [Architecture decisions are] conscious design decisions concerning a software system as a whole, or one or more of its core components. These decisions determine the non-functional characteristics and quality factors of the system. (Zimmermann 2008)

Asset Types | 101

Architects make decisions throughout the project life cycle, and the decision rationale may come from experience, method, or some other asset. Nevertheless, thinking of an architecture decision as a first-class reusable asset can help ensure that you don’t reinvent the wheel by retracing steps already taken by other architects. Architectural decisions often are more informative than the final architectural solution, because they typically discuss alternatives considered and the rationale for choosing the option selected. Consideration of architecture decisions as reusable assets is an emerging field. As such, method and tool support for such assets is relatively immature compared with other assets discussed in this chapter.

Existing Application A highly reusable asset is, of course, any existing application. Such applications are often referred to as legacy applications. The term legacy can come across as being rather negative, and it is not uncommon for inexperienced architects to look upon legacy applications as things to be avoided rather than the valuable assets that they truly are. A cynic is a man who knows the price of everything but the value of nothing. —Oscar Wilde

The level of reuse clearly is very high when you incorporate existing applications into your architecture, and the effort in this area is focused on integration rather than custom development. This integration is sometimes referred to as legacy integration or enterprise application integration (EAI).

Packaged Application A packaged application is a large-grained commercial-off-the-shelf (COTS) product that provides a significant amount of capability (and reuse), such as a customer relationship management (CRM) or enterprise resource planning (ERP) application. Examples of packaged applications include Siebel and SAP. Packaged applications may be deployed as part of a solution or treated as a hosted service (see the sidebar “Concept: Software as a Service”). Clearly, if the packaged application represents a substantial part of our system, the amount of custom development required is greatly reduced, with the effort moving to configuration of, and integration with, the packaged application. In addition, many of the significant decisions that you would make as an architect have already been made and are manifest in the chosen packaged applications being used.

102 | Chapter 5 Reusable Architecture Assets

Concept: Software as a Service Software as a Service (SaaS) is an approach to software deployment in which an application is made available as a hosted service over the Internet. The main advantage of this approach is that a consumer of the services doesn’t need to worry about application installation, operations, and support. The main disadvantage of this approach is that control of the application is relinquished in terms of, for example, product upgrades that may destabilize the architecture.

One of the areas to focus on when applying a packaged application is a fit/ gap analysis of how close the packaged application is in terms of satisfying the requirements. In some cases, when adopting a packaged application, it is easier to accommodate any constraints imposed by the application than to try to change the application itself. In this sense, the use of a packaged application can have a bottom-up influence on the architecture, because the chosen technology is influencing the architecture, rather than the top-down influence of requirements on the architecture. The selection of such a significant asset may also have a bearing on the approach you take to developing the system under consideration. Selecting a packaged application may result in the application of different software development practices than if you were integrating a legacy system or building custom code. Quite often, architects take a hybrid approach, because many software development projects apply many types of reusable assets concurrently.

Application Framework An application framework (sometimes referred to simply as framework) represents the partial implementation of a specific area of an application. Application frameworks can vary widely in scope. Some represent complete platforms, such as Java EE and .NET; others focus on a particular area (possibly within the scope of a platform), such as data access or the user interface. Hibernate, for example, is a framework that maps an object model to a relational database in a Java environment. Java Server Faces and ASP.NET are frameworks that support the creation of user interfaces. One of the key characteristics of an application framework (just like a pattern) is that it clearly defines the boundaries of what is fixed in the framework (in terms of both structure and behavior) and what is intended to be varied by any application using the framework. Not surprisingly, an application frame-

Attributes of an Architecture Asset | 103

work is frequently based on one or more patterns and is often documented in a similar manner. The term application framework should not be confused with architecture description framework (discussed in Chapter 4, “Documenting a Software Architecture”), which is a standard for describing a software architecture based on a set of viewpoints.

Component Library/Component In the most general sense, several asset types considered here represent components of a solution, including existing applications and packaged applications. In the context of reusable assets, however, we use the term component to represent something that has a complete implementation but is finer-grained than a complete application. Even so, such components can vary widely in granularity. A component may represent a significant element in the architecture, such as a message broker. It also could represent a service in SOA or a technology-specific component such as an Enterprise JavaBean. A widely understood form of reuse is with respect to even finer-grained elements, such as a user interface widget representing a table. Components also may be provided in the form of a component library, class library, or procedure library. An example of a component library is the Java class library.

Attributes of an Architecture Asset As you will see, assets can be qualified with several attributes. As an example, Figure 5.7 shows a subset of the architecture assets discussed earlier in this chapter characterized by two attributes: granularity and articulation (the level of implementation). Consumers use these attributes when trying to locate an asset for any given situation. As shown in this figure, assets can be considered in terms of their granularity (size) and their level of articulation (implementation). Granularity is related to both the number of elements that comprise the asset and the asset’s impact on the overall architecture. Articulation is concerned with the extent to which the asset can be considered to be complete and may be one of the following: ■

Specification. Such assets have no implementation and are represented in an abstract form, such as a model or document. Such assets include various types of pattern, architectural styles, and reference models.

104 | Chapter 5 Reusable Architecture Assets

Granularity CoarseGrained

Packaged Application Reference Model

Reference Architecture

Architectural Style

Application Framework

Architectural Pattern

Architectural Mechanism

Design Pattern FineGrained

Existing Application

Component Library Component

Idiom Specification

Partial Implementation

Complete Implementation

Articulation

Figure 5.7 Using Attributes to Characterize Asset Types

■

Partial Implementation. Such assets are considered to be partial implementations but require additional elements before they can be instantiated. Such assets include application frameworks and packaged applications.

■

Complete Implementation. Such assets are considered to be complete implementations and can be instantiated as is, without modification. Such assets include components and existing applications.

This is all well and good, but granularity and articulation are just two attributes that may be of interest. If the purpose of assigning attributes to particular types of assets is to help a potential consumer locate the asset, you may want to consider many more attributes. A basic set of attributes that are relevant to any asset includes ■

Articulation. The extent to which the asset provides a concrete implementation

■

Author. The person who originally created the asset

■

Concerns addressed. The concerns that the asset is aimed at addressing

■

Contained artifacts. The physical files that comprise the asset

Attributes of an Architecture Asset | 105 ■

Granularity. An indication of the size of the asset in relation to other assets

■

Name. The name of the asset

■

Prerequisites. The conditions that must apply before the asset can be used

■

Related assets. Any assets that are related to this asset and the nature of these relationships

■

State. The current state of the asset in terms of any asset life cycle (such as submitted or approved)

■

Type. The asset type (such as a reference architecture or design pattern)

■

Use instructions. The instructions for using the asset

■

Variability. The extent to which the asset may be varied (such as none, limited, or extensive)

■

Version. The asset version number Attributes that result from the use of the asset include

■

Feedback. Any feedback comments associated with the asset

■

Rating. An indication of the rating associated with the asset

■

Usage count. An indication of the number of times the asset has been requested Attributes related to the context within which the asset is applied include

■

Business domain. The domain to which the asset applies (such as telecoms or financial services)

■

Development discipline. The discipline to which the asset applies (such as requirements or architecture)

■

Development method. The method to which the asset applies (such as Scrum)

■

Development phase. The development phase to which the asset applies (such as Inception)

■

Development scope. The scope of the asset from a development perspective (such as software engineering or enterprise architecture)

■

Technical domain. The technical (rather than business) domain to which the asset applies (such embedded systems)

In addition, a variety of non-functional properties may be associated with the asset: cost, performance, scalability, and the like.

106 | Chapter 5 Reusable Architecture Assets

Other Reuse Considerations The past few years have seen renewed focus on reusable assets as a means of improving project performance and decreasing time to value. The seemingly widespread acceptance of SOA, for example, has led to renewed focus on how the associated reusable assets (services, in this case) are identified, specified, realized, deployed, managed, supported, maintained, upgraded, and (ultimately) retired. In more general terms, there are considerations related to a strategic approach to reuse. Unfortunately, a detailed discussion of such topics warrants a book of its own, although we do discuss a system-of-systems approach to the identification of large-scale reusable assets in Chapter 10, “Beyond the Basics.” Underpinning any reuse initiative is a means of describing reusable assets, which is where the Reusable Asset Specification (RAS) comes in (RAS 2004). This OMG standard fundamentally defines two aspects of a reuse strategy. The first aspect is a standard for describing a reusable asset. The second aspect is a standard that defines an interface to a RAS-compliant repository (referred to as a RAS repository service). Any organization that wants to be consistent in its handling of reusable assets would do well to look at the RAS and reuse repositories that implement this standard. Achieving successful asset reuse involves more than just resolving the purely technical challenges, of course. Specifically, we’ve not gone into any detail regarding the roles that may exist in an organization in support of a strategic reuse initiative, the tasks that are performed (especially around the creation, use, and maintenance of assets), and any specific work products that specifically support a reuse initiative (such as an asset catalog). There are also broader implications at an organizational level, such as the embedding of a reuse culture and assessing what level of reuse culture is practical or beneficial to the organization.

Summary Many types of reusable assets are at the disposal of software architects, and the use of such assets can improve project performance dramatically when the assets are applied correctly. This chapter provided an overview of commonly encountered assets available to architects in their work, as well as a discussion of asset attributes. We consider the application of reusable assets in the case study–related chapters (Chapters 6 through 9).

Chapter 6 Introduction to the Case Study

The purpose of this chapter is to introduce the case study used as an example in Chapters 7 through 9. The detailed requirements and the corresponding solution, with an emphasis on the architectural elements, are progressively introduced and discussed in these chapters. This chapter sets the context and describes the high-level requirements for the solution. It contains information commonly found in work products, such as a business case, a vision document, or a business model. This information is input to several tasks undertaken during the definition of the detailed requirements, as you will see in Chapter 7, “Defining the Requirements.”

Applying the Process Before discussing the case study, we should first make some general comments regarding the application of the elements described in this chapter and in Chapters 7 through 9. As we mention at the very start of this book, what you have in your hands is an articulation of a series of practices that you can apply in many ways and on many types of projects. This section (and the equivalent section in Chapters 7 through 9) provides guidance on their application. A practice is an approach to solving one or several commonly occurring problems. Practices are intended as “chunks” of process for adoption, enablement, and configuration. (RUP 2008)

107

108 | Chapter 6 Introduction to the Case Study

Given the discussion in Chapter 3, “Method Fundamentals,” we could more correctly say that a practice is a chunk of method, because a method has two dimensions: method content and process, both of which are configurable. We said in Chapter 3 that method content describes the life cycle–independent elements, such as roles, tasks, and work products. A process then takes these elements and defines a sequence in which they are applied and considers concepts such as iterations. We discuss each of these dimensions in Chapters 7 through 9. We can make some general statements, however, regarding the application of the various method elements described in these chapters (roles, tasks, work products, iterations, and the like). In particular, the content in these chapters represents our attempt to strike a balance between an extremely simple project that executes in weeks or months and a very large and complex project that executes in years. The various elements described in this book, therefore, need to be rightsized for your development project. Put another way, you need to consider the level of ceremony that needs to be applied. For the purposes of exemplification, the case study applies all the elements described in this book—no more and no less. The first elements that need to be right-sized are those that comprise the method content: the roles, tasks, and work products. The obvious question that must be asked is “How much of each of these items do we need?” The answer, of course, is “It depends.” A general comment is that all elements should be considered and then right-sized. Examples of right-sizing for two fictitious projects, small and large, are given in Table 6.1. In these examples, we consider the selection of viewpoints, which is discussed further in the sidebar “Best Practice: Select the Relevant Set of Viewpoints.” Similarly, the process elements within the method—phases, iterations, and the like—also need to be right-sized. Some of the items you need to consider include ■

The definition of any phases in the process and any milestones associated with them.

■

The emphasis applied to each of the architecting tasks within an iteration, based on where the iteration is in the overall life cycle and the phase within which the iteration occurs.

■

The number of times a given task is performed within an iteration. It may make perfect sense to apply a task more than once.

■

The sequencing of tasks within an iteration. (The sequencing suggested in this book is just that—a suggestion.)

Applying the Process | 109

Table 6.1 Examples of Right-Sizing Element

Small Project

Large Project

Role

A single person is assigned to play the roles of Lead Architect, Application Architect, Infrastructure Architect, and Data Architect.

Task

Different individuals are assigned to each of the architecture roles: Lead Architect, Application Architect, Infrastructure Architect, and Data Architect. In addition, the team includes a Security Architect and a Performance Architect. The Architecture Overview is created as a formal work product that is maintained through the life of the project.

The Architecture Overview is created as a sketch on a whiteboard and then photographed, because it has been decided not to keep this work product up to date. An Architecture Proof-ofAn Architecture Proof-ofConcept is created on paper Concept is created as executable only (no executable software software. needs to be built). The Requirements, Functional, Only the Requirements, FuncDeployment, Validation, Systems tional, Deployment, and PerManagement, Performance, and formance viewpoints are Security viewpoints are selected selected from the Architecfrom the Architecture Description ture Description Framework, Framework, and an Information and the corresponding views Viewpoint is added to ensure that are described in the Software this particular aspect of the system Architecture Document. is emphasized appropriately. The corresponding views are described in the Software Architecture Document.

Work product

The reason for such flexibility is that most elements of a project are rarely made concrete at the start. The scope and requirements often evolve (and are even discovered) as the project progresses, for example. The architecture in turn also evolves over time. The involvement of different roles in the project therefore varies over time, in line with the emphasis on the associated tasks. We discuss this topic further in Chapters 7 through 9. Additionally, depending on the duration of the project, the expectations and influences of key stakeholders can fluctuate during the project life cycle as factors such as budget cycles, organizational change, new business priorities, and corporate initiatives are established and this may influence the right-sizing performed.

110 | Chapter 6 Introduction to the Case Study

Best Practice: Select the Relevant Set of Viewpoints In this book, as discussed in Chapter 4, “Documenting a Software Architecture,” we select viewpoints based on the nature of the system being built. Given a basic description standard, we may choose to add or remove viewpoints accordingly. Additional viewpoints we could have included are ■

A data (or information) viewpoint that places a specific focus on the persistent data in the system. Such concerns are considered to be part of the functional viewpoint in this book.

■

A user experience viewpoint that places an emphasis on capturing the interactions that the user has with the system through one or more user interfaces. User experience modeling is introduced in Building Web Applications with UML, 2nd ed. (Conallen 2003).

■

A concurrency viewpoint that considers concurrency and synchronization elements, such as executable processes and threads in the system. Concurrency is one of the viewpoints in “The ‘4+1’ View Model of Software Architecture” (Kruchten 1995).

■

A development viewpoint that describes the static organization of the software in its development environment. This viewpoint is also one of the viewpoints in “The ‘4+1’ View Model of Software Architecture” (Kruchten 1995).

Scope of the Case Study If this book were to acknowledge all possible business challenges, business domains, architectural styles, available technologies, and so on, it would be a very large book indeed. Instead, as we discuss in Chapter 1, “Introduction,” this book focuses on those architecture-related tasks that are often encountered and that may be applied across many types of organizations, business domains, systems, and projects. Although the process described in this book can be applied to many types of initiatives, we have confined ourselves to a single case study, which allows us to exemplify the key tasks in which the architect is involved. An “at a glance” characterization of this case study is provided in Table 6.2. Although this set of characteristics could never fit all projects perfectly, we do believe that the tasks described in this book can be adjusted appropriately for any given situation, including the extent to which each task is applied. We discuss addi-

Scope of the Case Study | 111

tional considerations in dealing with complex systems in Chapter 10, “Beyond the Basics.” Table 6.2 uses the terms brownfield and greenfield, which are discussed in the sidebar “Concept: Brownfield and Greenfield Development.”

Table 6.2 Characteristics of the Case Study Characteristic

Included in Case Study

Excluded from Case Study

Number of systems Number of projects Life-cycle scope Business context

One One Development Business context is considered to be an input. Software

Many Many Operations and maintenance Defining the business context is in scope. Software, hardware, people, and information Other (e.g., image processing) Other (e.g., event-driven) Low (largely brownfield) COTS package is a substantial amount of the system.

Development scope Application style Architectural style Degree of freedom Commercial offthe-shelf (COTS) packages Legacy systems

Information systems Client–server High (largely greenfield) COTS package is a component of the system.

Business domain Technology domain

Legacy system is a component of the system. Retail Web technologies

Team location

Co-located

Legacy system is a substantial amount of the system. Other (e.g., financial systems) Other (e.g., safety-critical systems, embedded real-time systems) Geographically distributed

Concept: Brownfield and Greenfield Development In their book Eating the IT Elephant: Moving from Greenfield Development to Brownfield (Hopkins 2008), the authors use the terms brownfield development and greenfield development through analogy with the construction industry. In software engineering, brownfield sites present a level of constraint on architects’ work and recognizes that architects are not starting from a blank sheet of paper. Brownfield sites are those in which redevelopment or reuse of the site is complicated by existing contaminants. Greenfield sites are clean, previously undeveloped land. (Hopkins 2008)

112 | Chapter 6 Introduction to the Case Study

Project Manager Lead Architect Business Analyst

Application Architect

Developer

Infrastructure Architect Data Architect

Tester

Figure 6.1 The Project Team

The Project Team Throughout the case study–related chapters, we refer to the roles that comprise the project team. These roles are shown in Figure 6.1, and definitions of the roles follow. Note that the various architecture roles may be fulfilled by a single individual or, on occasion, by an architecture team. The tasks described in this book make no assumptions about the size of the team involved, although each chapter contains a section on how to apply the tasks that we describe. ■

The Project Manager is responsible for leading the project team that will deliver the solution by applying a range of project management principles, tools, and techniques.The Project Manager has overall responsibility for managing scope, cost, schedule, and contractual deliverables, as well as for the management of issues, risks, and change.

■

The Business Analyst is responsible for identifying and documenting requirements and for analyzing these requirements from a business perspective.The person in this role defines current and future operational scenarios (processes, models, use cases, plans, and solutions), and works with the stakeholders and the architects to ensure proper translation of business requirements into IT solution requirements.

Scope of the Case Study | 113 ■

The Developer is responsible for performing detailed design tasks, defining the organization of the implementation, implementing the detailed design elements, unit-testing the implementation, integrating his work with that of other developers, and ultimately producing an executable system.

■

The Tester is responsible for finding and documenting defects in software quality, generally advising about perceived software quality, and validating that the system functions as designed and as required. Complementing the unit testing performed in the development discipline, the Tester focuses on the integrated units provided by the developers and the system as a whole.

■

The Lead Architect has overall responsibility for the major technical decisions that define the architecture of the system.The person in this role also is responsible for providing rationale for these decisions, balancing the concerns of the various stakeholders, managing technical risks and issues, and ensuring that decisions are effectively communicated, validated, and adhered to.

■

The Application Architect focuses on those elements of a system that automate business processes and meet business needs.The person in this role focuses primarily on satisfying the functionality required by the business but also is concerned with how the application-related elements meet the non-functional requirements of the system (qualities and constraints).

■

The Infrastructure Architect concentrates on those elements of the system that are independent of business functionality, such as a persistence mechanism, hardware, and middleware. Such elements support the execution of the application-related elements.The person in this role focuses on elements that have a significant bearing on the qualities exhibited by the system and, therefore, the extent to which certain non-functional requirements are addressed.

■

The Data Architect focuses on the data elements of a system, especially data that is made persistent in an appropriate mechanism, such as a database, a file system, a content management system, or some other storage mechanism. The person in this role defines appropriate data-related properties, such as structure, source, location, integrity, availability, performance, and age.

External Influences Most development projects do not start from a completely blank sheet of paper. Here, we consider some of the business and technical inputs to the case study; we discuss external influences on the project in more detail in Chapter 10,

114 | Chapter 6 Introduction to the Case Study

“Beyond the Basics.” For the purposes of the case study, we assume that we have several inputs that are from outside the project itself. The availability of such inputs is discussed in the sidebar “Best Practice: Understand the Broader Context.” From a business perspective, the primary input is the identification of, and rationale for, any aspect of the business that can be supported by IT and, therefore, any applications that should be commissioned. The input from the business does not stop there, however, and the following work products may be provided as input: ■

Business Entity Model.This work product (or a similar work product, such as a Domain Model) defines the key concepts in the business domain under consideration.

■

Business Process Model.This work product defines the activities performed by the business and the roles that perform each activity.

■

Business Rules. This work product defines any business-related policies or conditions that must be satisfied by the system under development.

From a more technical perspective, you also may have access to the following work products or similar ones. Such work products help guide and constrain the creation of any applications produced in the organization but are not specific to any particular application. ■

Enterprise Architecture Principles.This work product contains rules, standards, and guidelines that influence the way in which the architecture of any applications will be created.This work product may contain an approved vendor list or a policy such as “buy versus build,” for example. This work product is defined at enterprise level (and is part of an enterprise architecture, as discussed in Chapter 10,“Beyond the Basics”) and applies to all applications that may be created.

■

Existing IT Environment. This work product represents the collection of existing elements that comprise the current IT landscape and that may be used by, or constrain, the system under development. This work product lists both hardware and software assets that are either available or that constrain the architect’s work. A hardware asset may be an existing network or node available in the organization. A software asset may be an existing application that you might use as part of your overall solution. Determining the content of the existing IT environment is discussed in the sidebar “Best Practice: Survey the Existing IT Environment.”

Application Overview | 115

Best Practice: Understand the Broader Context The case study assumes that both business and technical inputs are readily available. In some situations, however, this is not the case. If these inputs are not available, the project team (and the architect in particular) needs to determine how to proceed without these inputs or whether to produce these items within the project itself.

Best Practice: Survey the Existing IT Environment Most of today’s initiatives involve some element of brownfield thinking. Therefore, it is essential to understand the IT environment within which a system will exist. IT architects and business analysts rarely do as thorough a job of surveying a site as building architects do. Unfortunately, in IT, relatively little time is spent on the equivalent of a site survey. (Hopkins 2008)

Application Overview YourTour is a company that connects tour organizers with prospective customers. The YourTour offering is unique in that it not only allows multiple locations to be defined for a tour, but also provides flexibility in terms of the accommodations and transportation required by each participant in the tour. Suppose that the tour organizer wants to define a wildlife-watching tour that takes in four locations. The YourTour application not only allows the tour organizer to define the itinerary in terms of the locations to be visited (and the associated dates), but also allows each tour participant flexibility in terms of both accommodations and transportation based on availability (choosing a four-star hotel over a two-star hotel or traveling by train rather than by air, for example). Another example is a sightseeing tour that takes in several locations in the same country or continent. In simple terms, the YourTour offering sits somewhere between a packaged tour—which typically is defined as a single location, with fixed accommodation and transportation arrangements—and a do-it-yourself tour, which can be quite painful to organize on an individual basis, let alone for a group. Before discussing the high-level requirements for the YourTour application, we should note why we chose this particular example as a case study. As

116 | Chapter 6 Introduction to the Case Study

well as being conceptually simple, in that it does not require specific domain expertise to understand, this example exemplifies many of the challenges that architects typically face on a real project, such as the following: ■

Core functional requirements.The YourTour application must address all the core functional requirements, such as the ability to process payments when bookings are made.

■

Development-time qualities.The application needs to address development-time qualities, such as extensibility and portability.

■

Run-time qualities.The application needs to address certain run-time qualities, such as performance and usability.

■

System constraints.The development of the application needs to conform to specified constraints, such as cost, schedule, and the use of particular technologies.

■

Reusable assets. Most applications are not built from scratch but are derived from an existing system or make significant use of existing assets. Throughout the development of the application, the architect should consider reusable assets such as architectural styles and patterns.

■

Application integration.YourTour already uses IT to maintain customer details, and there is some legacy integration to be considered in terms of an existing customer relationship management (CRM) system.You can consider such a system to represent a reusable asset, albeit a very large-grained asset. In addition, it is anticipated that the YourTour application will need to interact with a third-party payment engine to handle monetary transactions and a third-party reservation system for determining the availability of (and making) accommodation and transportation reservations.

■

Physical distribution. The YourTour application will be physically distributed among a central office, branch offices (where customers can purchase tours in store), and devices that allow Internet access (such as web browsers and personal digital assistants [PDAs]). Again, physical distribution is simply another complexity that the architect must face in deriving a suitable solution to the defined requirements.

Although this list of considerations is not exhaustive, it does give some sense of the breadth of complexity that the architect must address. As you will see in subsequent chapters, it is precisely this sort of complexity that a development process can help address in a systematic fashion. The profitability of the YourTour application essentially depends on the volume of bookings (because YourTour receives a fee for each booking made) and

Application Overview | 117

the cost of running the application. Both of these factors can be greatly influenced by a well-architected, well-designed, and well-implemented tour booking system. If the application is easy to access and use, is reliable, and performs well, it is likely to attract both tour organizers and customers, and the result will be a corresponding increase in the number of bookings. Similarly, if the system is easy to install, administer, and maintain, its cost of operation will be lower. Figure 6.2 shows an extract from a Business Entity Model that is relevant to the YourTour application. This extract includes the key concepts that are supported by the YourTour application. A tour comprises several tour locations and is defined by a tour organizer. A tour location represents a base from which the surrounding area will be explored. The YourTour application is concerned only with arranging transportation between tour locations, however, not with transportation arrangements within a tour location, such as a private-hire bus that transports a group between sites that are visited from the same base. Such transportation needs to be arranged by the tour organizer, along with items such as a tour guide and meals. A tour participant is a person who is booked on a tour.

Tour Organizer

Customer

1

1

*

*

Tour

1

Tour Booking

1

*

Tour Participant

1

*

1

*

1..*

Reservation Tour Location

Flight Reservation

Car Reservation

Figure 6.2 Extract from the Business Entity Model

Train Reservation

Hotel Reservation

118 | Chapter 6 Introduction to the Case Study

Not surprisingly, a tour booking represents the heart of the YourTour application. It represents the relationship between the tour participants and the tour itself. In addition, a distinction exists between a tour participant and the person who actually books the tour: the customer. Although a tour participant and customer may actually be the same person, the customer represents the person who pays for the tour, whereas a tour participant is an actual attendee of the tour. This situation is analogous to the head of a family booking the members of the family and (optionally) herself on a tour. In this example, each family member is considered to be a tour participant, but the family head who is paying for the tour is considered to be the customer. Indirectly, a tour booking also includes any reservations (accommodation or transportation) associated with each participant.

The YourTour Vision Another input that may be provided to the YourTour development team and that is specific to the YourTour application is a Vision. The content of this work product may be found in a project charter, if one exists. The Vision work product may contain a problem statement, a list of stakeholders, a list of features, any qualities that the system must exhibit, and any constraints on the system. We look at these items in the following sections.

Problem Statement The YourTour application must address the following needs of its stakeholders and users: ■

Tour organizers want to reach the largest possible number of potential customers to ensure that tours are run at capacity.

■

Customers require access to a large and diverse catalog of tours, and want control of the amount of money they pay based on the preferred accommodation and transportation options of each tour participant.The tour catalog represents the sum of all tours being offered by all tour organizers.

■

The YourTour application owner wants to provide an environment in which tour organizers and customers can conduct their business, and wants to make a profit by charging a fee for any bookings made.

■

The YourTour application must provide a secure environment in which tour operators can advertise their tours, customers can book them, and an administrator can support this solution effectively.

The YourTour Vision | 119

Stakeholders A stakeholder is an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. (IEEE 1471 2000)

The key stakeholders of the YourTour application are briefly described in Table 6.3. The various stakeholders in the development team (such as the Project Manager or Tester) are represented by the Application Provider stakeholder and are not treated separately. The Tour Organizer, Customer, System Administrator, and Business Administrator are also users of the system. Providers of accommodation and transportation are not included in this list because they are accessed only indirectly through interactions between the YourTour system and an external third-party reservation system. Table 6.3 Stakeholder Summary Role

Description

Responsibilities

Application Owner

The stakeholder who owns the YourTour application

Application Provider

The stakeholder who provides the YourTour application

Business Administrator

The stakeholder who uses the YourTour application to perform business administration functions The stakeholder who uses the YourTour application to book a tour

Defines, reviews, and prioritizes key requirements for the YourTour application. Defines the rules of using the application, including tour organizer fees, rules of conduct, and so on. Receives statistics of application use, such as the number of bookings made, together with application performance. Assumes financial responsibility for the management and development of the application. Understands the requirements of the application and produces an application that meets these requirements. Develops an application that conforms to stated development-time qualities such as maintainability and extensibility. Adopts and follows a suitable delivery process. Collects fees for any tour bookings made. Manages content, which includes links to external services (such as travel insurance companies), advertising, and promotional offers.

Customer

Browses the available tours. Books one or more participants on a tour. Pays the tour organizer for the tour. Continued

120 | Chapter 6 Introduction to the Case Study

Table 6.3 Stakeholder Summary (Continued) Role

Description

Responsibilities

Maintainer

The stakeholder who manages the ongoing evolution of the system after it has been deployed The stakeholder who provides software or hardware elements required for the development or running of the system The stakeholders who provide system support and perform diagnostic functions The stakeholder who uses the YourTour application to perform system administration functions The stakeholder who uses the YourTour application to specify a tour

Modifies the system after delivery, resulting in either a partial or complete release of the system.

Supplier

Support Personnel

System Administrator

Tour Organizer

Provides software or hardware according to defined specifications.

Provide technical assistance to end users of the system.

Administers users, tours, and tour bookings. Monitors application activities and collects statistics.

Describes the tour. Defines the tour price, excluding accommodation and transportation costs (which are variable, depending on the selected options). Provides all facilities within a tour location, such as a tour guide, local transportation, and meals. Pays a fee to the application owner for any bookings made.

Functionality The functional features of the YourTour application should address the needs and concerns of its stakeholders. We define the detailed requirements associated with these features in Chapter 7, “Defining the Requirements.” For now, we are simply putting a stake in the ground regarding the high-level features of the YourTour system. As we mention earlier in this chapter, you may have access to a Business Process Model that defines the anticipated business behavior expected and in which the YourTour application will participate. This model helps you identify the features required of the YourTour application. An extract from such a model is shown in Figure 6.3, which shows the process of identifying a tour,

The YourTour Vision | 121

Locate Tour

Tour participants registered?

[No]

Register Tour Participants

[Yes]

Select Participant Reservations

Book Tour

Figure 6.3 Extract from the Business Process Model

registering tour participants, selecting the reservations for each tour participant, and finally booking the tour. In terms of the stakeholders listed in Table 6.3, in the preceding section, all these tasks are performed by a customer. Here is a list of features envisioned for the YourTour application: ■

Specifying tours.The tour organizer is able to describe all aspects of the tour, including the various locations that will be visited, together with the tour pricing (excluding accommodation and transportation costs, which depend on the selection made by the customer).

■

Browsing tours. A customer is able to browse a structured catalog of available tours and view tour descriptions (including location and price information).The application will indicate which tours have spaces remaining and also will present any promotions that may apply.

■

Booking tours.A customer is able to book a tour.When a customer makes a booking and pays for the tour, the tour organizer receives the payment from the customer.The tour organizer pays a fee to YourTour for every booking made.

122 | Chapter 6 Introduction to the Case Study ■

Managing user accounts.The application supports various types of users, such as tour organizers, customers, or system administrators, each of which has an account. User accounts can be created and subsequently changed if the information is incorrect or changes.The system administrator has access to all user accounts and, as such, is able to browse user accounts, update user accounts, and archive or delete user account information.

■

Managing bookings.A tour organizer may cancel a tour (if the tour guide becomes unavailable, for example) or cancel a booking (if the customer has a poor credit history, for example), a customer may cancel a booking (and may incur a penalty as a result), and a system administrator may archive bookings.

■

Maintaining system security.The application will support system security, in particular providing user authentication of trusted identities and ensuring that users perform only the operations for which they have authorization.

■

Providing access to external services. The application will provide the customer links to tour-related external services, such as travel insurance companies. This capability represents a revenue stream for YourTour through both advertising and click-through capability.

Qualities As well as functional features, the application must support certain qualities and constraints. One important quality that the system must address is availability; backup and maintenance operations should not require the system to be offline. Another quality is performance; specifically, the system should process a tour-booking confirmation (that involves making reservations and processing the associated payment) in less than 10 seconds. Scalability is also a concern, and the system should support 5,000 concurrent users.

Constraints In addition to a Business Entity Model and a Business Process Model, you may be provided Business Rules with which the application must conform. A business rule describes the policies that govern how a business is run. An example is “An individual who is under 18 years of age may not book a tour.” You also may have access to an Existing IT Environment work product that represents the current IT landscape. This work product may contain elements that you reuse or are constrained by. An Enterprise Architecture Principles work product may be provided; this work product contains rules and guide-

Summary | 123

lines that influence the way in which the architecture will be created, such as an approved vendor list. In terms of constraints, then, the YourTour company has decided that the YourTour application will interface with an external payment engine (it has already been decided that the YourTour company will not build this engine part of the overall solution) as well as an external reservation system. The company also has decided that the implementation of the YourTour application will use an existing legacy application to store customer information. The company has determined that the application should be available to end users over the Internet through web browsers and other mobile devices, such as PDAs. It should also be available through a web browser to sales clerks based in one of the YourTour branch offices, working over the company local area network (LAN) behind a firewall. It is anticipated that the system administrator will also work over the LAN, using a web-browser interface to the system.

Summary As we mention in the introduction to this chapter, the information presented here is commonly found in work products such as a Business Entity Model, Business Process Model, Business Rules, Existing IT Environment, Enterprise Architecture Principles, and Vision. The content of the Vision in particular represents a first approximation of what the YourTour application should provide and is used as a major input to the project go/no-go decision. If the project goes ahead, this information often becomes the basis for the development of more detailed requirements, as described in Chapter 7, “Defining the Requirements.”

This page intentionally left blank

Chapter 7 Defining the Requirements

This chapter discusses the requirements discipline, with a particular focus on the role of the architect. As discussed in Chapter 2, “Architecture, Architect, Architecting,” the architect is involved only peripherally in the requirements discipline, because the Business Analyst is primarily responsible for executing the requirements-related tasks. We have a whole chapter dedicated to it, however. Why is that? The section “Relating Requirements to Architecture” in this chapter answers this very question. In this chapter, and for the purpose of this book, we assume that several work products are provided as input to, and are output from, the Define Requirements activity, as shown in Figure 7.1. The Define Requirements activity (introduced in Chapter 1, “Introduction”) comprises the tasks described in detail in this chapter. The input work products, which we discuss briefly in Chapter 6, “Introduction to the Case Study,” are as follows: ■

■

■

■

Business Entity Model. This work product defines the key concepts in the business domain under consideration. Business Process Model. This work product defines the activities performed by the business and the roles that perform each activity. Business Rules. This work product defines any policies or conditions that must be satisfied by the system under development. Change Request. This work product describes the request for a change to the system. Changes may be significant and may dramatically impact the focus of the iteration. 125

126 | Chapter 7 Defining the Requirements

Output Work Products Input Work Products Change Request

Business Entity Model

Functional Requirements

Business Process Model

Glossary

Business Rules

Non-Functional Requirements

Change Request Define Requirements

Prioritized Requirements List

Enterprise Architecture Principles

RAID Log

Existing IT Environment

Review Record

RAID Log

Software Architecture Document

Vision

Stakeholder Requests

System Context

Figure 7.1 Input and Output Work Products of the Define Requirements Activity

Defining the Requirements | 127 ■

■

■

■

Enterprise Architecture Principles. This work product contains rules and guidelines, defined at the enterprise-level, that inform and guide the way in which architectures will be created. Existing IT Environment. This work product represents the collection of existing elements that comprise the current IT landscape and that may be used by, or constrain, the system under development. RAID Log. This is a project management work product that captures the risks, assumptions, issues and dependencies for the project. This work product is an input when we prioritize the requirements for the current iteration, since outstanding risks and issues are factors that we take into consideration. Vision. This work product defines the stakeholders’ view of the system to be developed, and is specified in terms of the stakeholders’ key needs and features. It outlines the envisioned core requirements and may be as simple as a problem statement. This work product provides an initial indication of the scope of the system, which is refined as we move forward. The following requirements-related work products are output:

■

■

■

■

■

■

■

■

Change Request. This work product may be output as a result of changes resulting from a review of the requirements. Such changes are typically accommodated in the next iteration. Functional Requirements. This work product captures the functional requirements of the system under development. Glossary. This work product provides a list of common terms, their meanings, and alternatives used by the business. Non-Functional Requirements. This work product captures the nonfunctional requirements of the system under development. Non-functional requirements represent system qualities (such as reliability) and constraints. Prioritized Requirements List. This work product captures the priority associated with each requirement. RAID Log. As described in the preceding list, this project management work product captures the risks, assumptions, issues, and dependencies for the project. Review Record. This work product defines, in the context of this activity, the result of a requirements review. Software Architecture Document. This work product provides a comprehensive architectural overview of the system, using several architectural views to depict different aspects of the system.

128 | Chapter 7 Defining the Requirements ■

Stakeholder Requests. This work product contains requests that a stakeholder may have for the system to be developed. It also may contain references to any standards to which the system must conform (such as regulatory compliance standards or organizational standards). The difference between a request and a requirement is discussed later in the section “Task: Collect Stakeholder Requests.”

■

System Context. This work product represents the entire system as a single entity or process, and identifies the interfaces between the system and external entities.

The System Context, Functional Requirements, and Non-Functional Requirements work products represent the requirements of the system and serve as a contract between the customer, the users, and the system developers. They allow customers and users to validate that the system will become what they expected and enable developers to build what is required.

Relating Requirements to Architecture The emphasis given to requirements in this book is driven by the close relationship between requirements and architecture that occurs in practice. Although architects are involved only peripherally in the requirements discipline, they are involved. Therefore, it is important to understand the contribution of the architect and where that contribution occurs. The requirements discipline is related to the resulting architecture in several ways: ■

Requirements influence the architecture. The most obvious relationship is that the requirements influence the architecture of the solution, because solution elements are selected that satisfy the stated requirements (therefore, it is essential to understand the work products that you, as the architect, will be receiving). Architects focus on architecturally significant requirements when deriving the architecture, and architectural significance is discussed in the sidebar “Concept: Architectural Significance.”

■

Well-defined requirements result in higher-quality architectures. Because the requirements drive the definition of the architecture, it follows that a well-defined set of requirements will result in a better architectural solution than a set of poorly defined requirements. Having architects participate in certain aspects of requirements elicitation and definition can, given their experience, often result in better-quality requirements.

■

Architectural decisions influence the requirements. When defining the architecture, the architect must often make trade-offs between require-

Relating Requirements to Architecture | 129

ments, such as balancing performance and cost. As a result, feedback goes from the architect to the Business Analyst so that the requirements can be adjusted as necessary. The selection of a particular architectural element may also constrain the requirements that can be fulfilled. The selection of a Commercial-Off-The-Shelf (COTS) product, such as a customer relationship management (CRM) packaged application, may impose certain constraints on the requirements in terms of the terminology used, the functionality provided, and any qualities achieved. In such circumstances, the requirements are often refined to accommodate the chosen architectural element. Any changes in requirements must be renegotiated with the various stakeholders, of course, and this renegotiation may require a formal change process to be in place. ■

The architecture defines requirements on subsystems. Another notso-obvious relationship between requirements and architecture occurs when the architecture is decomposed into its constituent parts. In essence, the specification of any of the parts within the architecture forms the requirements for that part. This is particularly relevant in developing largescale systems in which the parts are developed within separate projects, which may be outsourced to a third party. Such considerations are discussed further in Chapter 10, “Beyond the Basics.”

Concept: Architectural Significance The phrase architecturally significant is often used to characterize the subset of elements relevant to the architecture, whether these elements are architecturally significant requirements, architecturally significant design elements, and so on. But what is architectural significance? We touched on this topic in Chapter 2, “Architecture, Architect, Architecting,” but we can be more specific here. An element is considered to be architecturally significant if: ■

The element is associated with some critical functionality of the system, without which you do not have a viable system.

■

The element is associated with some critical quality of the system, such as performance, without which you do not have a viable system.

■

The element is associated with a critical constraint on the solution, such as the need to integrate with a specific external system.

■

The element incurs a particular technical risk.

■

The element presents a particular architectural challenge.

130 | Chapter 7 Defining the Requirements

Functional and Non-Functional Requirements Before proceeding, we should clarify some terms that are used somewhat inconsistently in the industry to discuss requirements—specifically, the terms functional requirement and non-functional requirement. The term functional requirement is fairly straightforward: Functional requirements describe the behaviors (functions or services) of the [IT] system that support user goals, tasks or activities. (Malan 2001)

In an order processing system, for example, allowing a customer to order goods is clearly a functional requirement. The term non-functional requirement is not so straightforward, because its name describes what it is not rather than what it is. In other words, you know that a non-functional requirement is not a functional requirement! A simple definition is Non-functional requirements include constraints and qualities. (Malan 2001)

This definition introduces two more terms used throughout this chapter (and the book in general): constraint and quality. A constraint is a restriction on the degree of freedom we have in providing a solution. (Leffingwell 2000) [System] qualities are properties or characteristics of the system that its stakeholders care about and hence will affect their degree of satisfaction with the system. (Malan 2001)

As discussed in Chapter 2, “Architecture, Architect, Architecting,” you can think about constraints in terms of both business constraints (such as regulatory and resource constraints) and technical constraints (such as mandated technology standards and mandated solution elements). You can think of qualities in terms of run-time qualities (such as performance and usability) and nonrun-time qualities (such as maintainability and portability). Qualities and constraints are of particular interest to the architect because they often represent the most challenging aspects of their work, as you will see later in the section “Task: Outline Non-Functional Requirements.” Note that some texts use the term quality attribute in addition to quality as explained in the sidebar “Concept: Quality and Quality Attributes.”

Techniques for Documenting Requirements | 131

Concept: Quality and Quality Attributes In discussions of software quality, two terms are often used interchangeably: quality and quality attribute. The difference between the two is summarized in the following quotation: Software quality is the degree to which software possesses a desired combination of attributes. (IEEE 1061 1992)

Performance, scalability, and maintainability are all examples of quality attributes. In this book, however, we tend to use the term quality, which seems to be more commonly used in day-to-day conversation.

Functional requirements and non-functional requirements usually are independent, and as a result, it is possible to build a system that is functionally correct but that fails to meet the qualities and constraints defined by the nonfunctional requirements. Because non-functional requirements are often critical to the success of the system, and often extremely challenging for the architect, you should (as this book suggests) consider them early in a project.

Techniques for Documenting Requirements In documenting all the functional and non-functional requirements, you need to consider what techniques you should use. Although you could describe all your requirements in text, you may choose to use a technique that also has an element of visual modeling to help communicate the requirements. An example of such a technique is use case–driven development, which is used in this book. This technique is used primarily to define functional requirements, with the provisos that: ■

Non-functional requirements may be associated with particular aspects of the use case. A particular step in a use case may need to be performed in a particular amount of time, for example.

■

Some functional requirements are not necessarily best captured in use cases and are referred to in this book as system-wide functional requirements (in the sense that they are not associated with a particular use case). A requirement to provide a secure system, for example, is a functional requirement that pervades the entire system and is not tied to a particular use case.

132 | Chapter 7 Defining the Requirements

In this book, the Functional Requirements work product contains all functional requirements (both those that are captured in use cases and those that are system-wide). In keeping with an approach that advocates the use of models and model-driven development, we refer to the collection of use cases as a use-case model. Good overviews of use-case modeling appear in Use Case Modeling (Bittner 2003) and Writing Effective Use Cases (Cockburn 2000). The Non-Functional Requirements work product contains all nonfunctional requirements. This work product is of particular interest to architects because it contains many of the challenging requirements that architects must address in their work.

Applying the Process As discussed in Chapter 6, “Introduction to the Case Study,” we consider various practices that you can refine and apply as you see fit within your own process. In this section, we make more specific observations regarding the requirements tasks and, in particular, the typical application within the life cycle of a project. Specifically, the requirements tasks vary throughout the development life cycle, as shown in Figure 7.2. Requirements definition is not something that happens once, at the beginning of the project, because normally it is not possible to fully understand and document all the requirements of the system up front. Rather, requirements are refined throughout the life cycle of the project, which emphasizes the need for effective requirements management (and change management). Requirements management represents a systematic approach to eliciting, organizing, and documenting the requirements of the system in such a way that all stakeholders (including the developers) understand them. It is also an approach to establishing and maintaining agreement between the customer and the project team on the system’s changing requirements.

Inception

Phases Elaboration Construction

Incep Incep #1 #n

Elab #1

Transition

Requirements Elab #n

Const #1

Iterations Figure 7.2 Requirements and Iterative Development

Const #2

Const #n

Tran #1

Tran #n

Understanding the Task Descriptions | 133

The greatest emphasis on requirements activities occurs late in the Inception phase, where the scope of the system is being established, and early in the Elaboration phase, where the architecturally significant requirements are detailed to drive the project toward the development of a stable architecture. Some requirements tasks are performed in the Construction phase, as the remaining requirements are detailed, and even into the Transition phase, as requirements are refined based on feedback received when transitioning the system to the end user. Requirements, therefore, are refined as the project progresses. It certainly is not our intention to give the impression that major changes to requirements occur throughout the project! But there may be occasions when exactly this happens, such as the following: ■

A poor requirements management process is in place, accommodating stakeholder requests without any discussion of their effect on the project.

■

A requirement becomes better understood when examined in detail.

■

An unforeseen change of circumstances occurs that requires the requirements to be revisited. Your company may have merged with another organization, for example, and now you have a new set of stakeholder needs to satisfy. In this situation, it may make sense to put the project on hold and revisit earlier phases to validate decisions and assumptions that have been made thus far.

Understanding the Task Descriptions Each of the tasks described in this book starts with a table that provides an overview of the task. The tables should be read as follows: ■

The Purpose section provides a brief summary of the purpose of the task.

■

The Roles section lists both primary and secondary roles involved in the execution of the task.

■

The Inputs section lists the work products that are produced by the task. In an iterative process, in which work products are refined from iteration to iteration, all output work products from the task are implicitly considered to be input to the task.

■

The Outputs section lists the work products that are output from the task.

■

The Steps section lists the steps that are performed to execute the task.

■

The Role of the Architect section summarizes the involvement of the architect in the task.

134 | Chapter 7 Defining the Requirements

Define Requirements: Activity Overview The tasks that comprise the Define Requirements activity (introduced in Chapter 1, “Introduction”) are shown in Figure 7.3. The tasks can be summarized as follows: ■

The purpose of the Collect Stakeholder Requests task is to gather the requests that the various stakeholders place on the system.

■

The purpose of the Capture Common Vocabulary task is to ensure that common business and technical terms used by stakeholders are understood and documented.

■

The purpose of the Define System Context task is to ensure that the boundary of the system under development is understood and that the users and external systems that interact with the system are identified.

■

The purpose of the Outline Functional Requirements task is to outline the set of functional requirements.

■

The purpose of the Outline Non-Functional Requirements task is to outline the set of non-functional requirements. Such requirements may represent qualities or constraints.

■

The purpose of the Prioritize Requirements task is to prioritize the requirements so that iterations are planned based on the highest-priority requirements.

■

The purpose of the Detail Functional Requirements task is to define the functional requirements to the extent that they can be used to drive the definition of the system from a functional perspective.

■

The purpose of the Detail Non-Functional Requirements task is to define the non-functional requirements to the extent that they can be used to drive the definition of the system in terms of the qualities exhibited and the constraints accommodated.

■

The purpose of the Update Software Architecture Document task is to document the architecturally significant requirements in the Software Architecture Document.

■

The purpose of the Review Requirements with Stakeholders task is to obtain stakeholder agreement that the requirements, at their current level of elaboration, satisfy their requests.

We look at each of these tasks in subsequent sections where the role of the architect is highlighted.

Define Requirements: Activity Overview | 135

Collect Stakeholder Requests

Capture Common Vocabulary

Define System Context

Outline Functional Outline Non-Functional Requirements Requirements

An Iteration of the Define Requirements Activity

Prioritize Requirements

Detail Functional Requirements

Detail Non-Functional Requirements

Update Software Review Requirements Architecture Document with Stakeholders

Figure 7.3 Overview of the Define Requirements Activity

136 | Chapter 7 Defining the Requirements

Task: Collect Stakeholder Requests PURPOSE The purpose of this task is to gather the requests that the various stakeholders place on the system. ROLES Application Architect (secondary), Business Analyst, Infrastructure Architect (secondary), Stakeholder INPUTS ◆ Business Process Model (optional), Change Request, Glossary (optional), Vision

OUTPUT ◆ Stakeholder Requests

STEPS ◆ Identify stakeholders. ◆ Collect stakeholder requests. ◆ Prioritize stakeholder requests. ROLE OF THE ARCHITECT ◆ Ensure that the more technical roles, such as System Administrator, are considered. ◆ Ensure that the more technical requirements, such as qualities and constraints, are captured. ◆ Articulate the implications of a requirement on the solution, in terms of cost, time to market, and the like. ◆ Assist with the prioritization of requests by explaining the impact of prioritizing a request one way or another.

When gathering Stakeholder Requests, it is extremely important to remember that a request is not a requirement. Often, requests from different stakeholders are ambiguous, conflicting, or incomplete. Rather than treating requests as requirements, first clarify and consolidate the various requests, and subsequently provide input into the final statement of the requirements as documented in the System Context, Functional Requirements, and NonFunctional Requirements work products, as discussed later in this chapter.

Step: Identify Stakeholders The first step in this task is to determine the stakeholders that will participate in the request-gathering activities. The complete set of stakeholders is normally provided in a work product, such as a Vision document, that is input to this activity. A Business Process Model may also provide inspiration for stakeholders, because such a model will contain a description of the business activi-

Task: Collect Stakeholder Requests | 137

ties that the system will support and, therefore, the associated business roles that may represent stakeholders that you should consider. It is important to ensure that stakeholders are identified appropriately, because different stakeholders will have different concerns, and you should have an appropriate focus and use appropriate techniques when eliciting their requests. In the case of the YourTour system, the stakeholders have indeed been identified, as discussed in Chapter 6, “Introduction to the Case Study.” As a reminder, they are ■

Application Owner

■

Application Provider

■

Business Administrator

■

Customer

■

Maintainer

■

Supplier

■

Support Personnel

■

System Administrator

■

Tour Organizer

To ensure that no stakeholders are inadvertently forgotten, it is often useful to maintain a checklist of stakeholders as discussed in the sidebar “Checklist: Maintain a Checklist of Stakeholders.”

Checklist: Maintain a Checklist of Stakeholders It is all too easy to overlook a stakeholder when you are in the throes of requirements elicitation. Therefore, there is value in maintaining and applying a checklist of stakeholders that should be considered for any software development effort. Certain stakeholders are of particular significance to the architect, because their needs often directly drive aspects of the architecture. Therefore, it is important to ensure that these stakeholders are considered from the outset. Such stakeholders include systems administrators (who support the installation, configuration, and operation of the system) and support personnel (who are responsible for providing front-line support of the system).

138 | Chapter 7 Defining the Requirements

Step: Collect Stakeholder Requests The main aspect of this activity is to gather the potential requirements, which are referred to as requests because they are not yet agreed-upon requirements, as discussed in the sidebar “Pitfall: Treating Requests As Requirements.” You can use several techniques to achieve this goal, including conducting workshops, brainstorming sessions, and interviews, as well as using questionnaires. Another source of requests in an iterative development process is the set of Change Requests that have been raised. These potential requirements may be input to the start of an iteration or even the start of the project (if the project represents an evolution of an existing system). You should use consistent terms, as defined in the Glossary, to capture the requests themselves. This task is typically performed relatively well when it comes to the functionality of the system. When it comes to capturing requirements that represent the elements that are often of most interest to the architect—namely, those requests that are non-functional in nature (those that represent system qualities or constraints)—a less-than-adequate result is often achieved. Successful projects involve the architect in gathering stakeholder requests so that such items are considered from the outset. A simple and effective technique is to maintain a checklist of such potential requirements and ensure that these areas are discussed when gathering stakeholder requests. A checklist is provided in Appendix D, “Architectural Requirement Checklist.” This checklist can form the basis of a questionnaire that you can use when collecting requests. It also can form the basis of a discussion of likely future changes in the system. Specifically, the content of the questionnaire will feed directly into the creation of the Functional Requirements and Non-Functional Requirements work products, as discussed in this chapter. Such an approach could be called architecture-driven requirements elicitation. Various pitfalls that can ensue when using such a questionnaire, and when gathering requests in general, and a summary of these pitfalls is provided in the following “Pitfall” sidebars.

Pitfall: Treating Requests as Requirements A request is not a requirement; it is an expression of what a stakeholder would like to have in the system. It does not become a requirement until explicit agreement has been reached with the relevant parties and any conflicts with existing requirements have been resolved.

Task: Collect Stakeholder Requests | 139

When you apply agile practices and a customer representative is deemed to be part of the team, a request may well be a requirement, and any drawnout negotiation is circumvented. Understanding the difference between requests and requirements is still important even in these circumstances, however, because an individual may state conflicting or ambiguous requests that need reconciliation with existing requirements before they can be accommodated.

Pitfall: The Shopping-Cart Mentality When collecting stakeholder requests, it is important to avoid the shoppingcart mentality of the stakeholders. In the absence of any other criteria, a request-gathering exercise quickly degrades into a fruitless conversation in which the stakeholder decides that everything on offer is absolutely needed. Accommodating such requests isn’t free, however, and this isn’t a shopping cart. It is very easy to fall into the trap of presenting your stakeholders the equivalent of a shopping list from which they pick and choose. The trick is to ensure that the stakeholders understand the cost of their purchases by being able to position the effect of selecting a particular requirement in stakeholderfriendly terms such as cost, schedule, and quality. Supplementing the question “Does the system need to be secure?” with the statement “A highly secure system is likely to double the cost of the overall system” is almost guaranteed to get a different response from the one you would get if the question were not qualified, for example. In both cases, of course, you would need to define what you mean by secure, but you get the point.

Pitfall: The Questionnaire Is Technical A questionnaire given to a stakeholder may be treated as a technical document whose content lies outside the stakeholder’s area of concern. The reason for this perception is that many stakeholders are more comfortable, and more familiar, with business-related concepts. A typical stakeholder will understand the concept of booking a tour, for example, but will be less comfortable talking about availability. Consequently, stakeholders sometimes see Continued

140 | Chapter 7 Defining the Requirements

such a questionnaire as an impediment to the project’s progress rather than as a technique for eliciting some crucial requirements of the system being built. The trick, again, is to ensure that the stakeholders understand the value of spending time answering the questions posed in the questionnaire. Often, it is easier to show this value by giving examples of problems that arise in the absence of a questionnaire!

Pitfall: Requests Are Too General Another pitfall is that requests are too general. A request may state that the response time of any transaction is less than three seconds, for example. More likely, however, the response time for specific transactions must conform to this particular request, while other transactions take significantly longer. If you don’t make requests as specific as possible, and these requests ultimately become requirements, elements of the system are likely to be overengineered, as these elements will be designed based on requirements that may not apply.

Pitfall: Requests Are Not Measurable All requests should be measurable. An example of a request that cannot be measured is “The system will have a state-of-the-art user interface.” This statement is ambiguous because the definition of “state-of-the-art” is subjective and simply cannot be measured. You must ensure that all the stated requests are both unambiguous and measurable as far as possible, although some elaboration of each request is permissible as requests are elaborated through the requirements process.

Pitfall: Talking with the Wrong People Another pitfall sometimes occurs when all the questions are being posed to all the stakeholders. Many types of stakeholders have input to the request gathering process, and you need to ask the right questions of the right people. The ability to license elements of the system, for example, is a request that will be specified by product management (and may be a request captured within your organization). The usability of the system, however, may be specified by an end user (and may be a request captured outside your organization).

Task: Capture Common Vocabulary | 141

Step: Prioritize Stakeholder Requests As discussed in the preceding section, each individual stakeholder assigns his or her own priorities to each request. However, different stakeholders may make the same requests but give them different priorities. In this step, you reconcile the various request priorities, which ultimately influence the priorities of the resulting requirements that you review with the stakeholders in the Review Requirements with Stakeholders task (discussed later in this chapter). Architects have a role to play in this reconciliation because they are often in the best position to articulate the impact of prioritizing a request one way or another in terms of factors, such as cost and time, to implement.

Task: Capture Common Vocabulary PURPOSE The purpose of this task is to ensure that common business and technical terms used by stakeholders are understood and documented. ROLES Application Architect (secondary), Business Analyst, Infrastructure Architect (secondary), Stakeholder INPUTS ◆ Business Entity Model (optional), Business Process Model (optional), Enterprise Architecture Principles (optional), Stakeholder Requests, Vision

OUTPUT ◆ Glossary

STEP ◆ Identify common terms. ROLE OF THE ARCHITECT ◆ Assist with the definition of any technical terms used.

A project should consistently use a common vocabulary that is, where relevant, aligned with the terminology of the problem domain. It is especially important that the requirements work products use this vocabulary consistently to prevent misunderstandings among the project members. The vocabulary terms are documented in the Glossary. Each term should have a clear and concise definition, and all interested parties should agree on these definitions. This particular task may be performed several times within an iteration and across iterations. As requirements are defined, you may define and refine

142 | Chapter 7 Defining the Requirements

the terms used. As requirements are detailed, you may, again, add them to the Glossary. A consistent terminology is particularly relevant to the architect for several reasons. To communicate effectively with stakeholders and the development team, the architect must use terms consistently and unambiguously. Also, these terms often influence the names of requirements and solution elements, so defining these terms appropriately is important. Given the relatively simple task of creating a Glossary, it is surprising how many organizations fail to create such a simple and obvious work product. This failure is likely to lead to delays in the overall project due to the ambiguity and miscommunication that ensue— and that could have been prevented from the outset.

Step: Identify Common Terms The terms themselves are often derived from the work products that are input to a project, such as a Business Entity Model, Business Process Model, Enterprise Architecture Principles, and Vision, or are simply terms that are frequently used to describe the system and what it does, and that may have been documented in the Stakeholder Requests work product. When discussing the YourTour system, for example, you may use terms such as tour, tour organizer, customer, and tour booking. Terms are often documented simply with a name and description. Table 7.1 defines several terms from the Glossary of the YourTour system. The architect often assists with the definition of any technical terms used. In particular, some technical terms may be defined in industry standards and, therefore, should be referenced rather than redefined. The architect should be careful to reconcile synonyms and homonyms, however, as defined in the sidebar “Best Practice: Reconcile Synonyms and Homonyms.”

Table 7.1 YourTour Glossary Terms Name

Description

Customer Reservation

A customer represents a purchaser of tours. A reservation represents a specific transportation or accommodation booking for a particular tour participant. A tour represents an organized trip to several tour locations. A tour booking represents the booking of tour participants on a given tour. A tour location represents a particular destination on a tour. A tour organizer is a person or organization that sells tours. A tour participant is a person who may be booked on a tour.

Tour Tour booking Tour location Tour organizer Tour participant

Task: Define System Context | 143

Best Practice: Reconcile Synonyms and Homonyms It’s very easy, especially on large projects, for different people to use different terms to mean the same thing (synonyms) and for the same term to mean different things (homonyms). In constructing the Glossary, it is important to ensure that the preferred terms are used in all cases (although you may note the alternative names for the terms), because the terms in the Glossary influence the naming of elements in many other work products. A late change in the name of a term can result in much rework, assuming that it is beneficial for terms to be consistent. Having said that, it may be desirable for the same term to be used based on common use in the industry. The term service, for example, can be applied in a technical context in relation to a service-oriented architecture (SOA), where it represents a software capability that is exposed via one or more interfaces. The term service may also be used in a business context in relation to business service management (BSM), where it typically represents an alignment of technology in providing a service to the business.

Task: Define System Context PURPOSE The purpose of this task is to ensure that the boundary of the system under development is understood and that the users and external systems that interact with the system are identified. ROLES Business Analyst, Lead Architect (secondary), Stakeholder (Secondary) INPUTS ◆ Business Entity Model (optional), Business Process Model (optional), Enterprise Architecture Principles (optional), Existing IT Environment (optional), Stakeholder Requests, Vision

OUTPUT ◆ System Context

STEPS ◆ Identify actors. ◆ Identify actor locations. ◆ Identify data flows. ROLE OF THE ARCHITECT ◆ Ensure that external systems, with which the system under development must integrate, are considered. ◆ Ensure that the locations of any actors are defined appropriately. ◆ Ensure that the flow of data between the system and external actors is considered.

144 | Chapter 7 Defining the Requirements

Two critical aspects of the system definition are its scope and, therefore, its boundaries. In this task, you identify the actors, their locations, and the flow of data between the actors and the system, and document them all in the System Context work product.

Step: Identify Actors When defining the system, one of the first things you identify is the system context in terms of system actors and their interfaces to the system. An actor is someone or something outside the system that interacts with the system. An actor can be a person, an external system, or an external device (such as a printer). Inspiration for such actors may come from the roles defined in the Business Process Model work product, mandated elements defined in the Enterprise Architecture Principles work product, existing elements defined in the Existing IT Environment work product, the requests defined in the Stakeholder Requests work product, or the list of stakeholders described in the Vision work product. The actors identified for the YourTour system are shown in Figure 7.4. In this figure, the Customer, Sales Clerk, Tour Organizer, System Administrator, and Business Administrator actors represent people (or, more correctly, the roles undertaken by people using the system), whereas the CRM System, Payment Engine, and Reservation System actors represent external systems. As for stakeholders, it is useful to maintain a checklist of actors to ensure none is forgotten, as discussed in the sidebar “Checklist: Maintain a Checklist of Actors.”

Checklist: Maintain a Checklist of Actors Just as we recommend that you maintain a checklist of stakeholders, you can maintain a checklist of actors. As a technique, use-case modeling encourages the description of business-related functionality and the business users, who are represented as actors. Often, however, other actors interact with the system. Aside from external systems and devices, it is also important to consider actors that ensure the smooth operation of the system, such as a System Administrator that performs systems management functions or a Support Operator that runs diagnostics when required. Often, it is useful to maintain and use a list of such actors to ensure that they are not overlooked. Addressing this pitfall may also result in the identification of additional stakeholders.

Task: Define System Context | 145

Customer

CRM System Sales Clerk

«System» YourTour

Tour Organizer

System Administrator

Payment Engine

Reservation System

Business Administrator

Figure 7.4 System Context of the YourTour System

Table 7.2 provides a description of each actor in Figure 7.4. A system context diagram, such as that shown in Figure 7.4, is particularly useful not only for understanding the external environment within which the system must operate, but also for describing the anticipated interface between the system and its environment without getting bogged down in the details of the internals of the system in terms of its implementation.

146 | Chapter 7 Defining the Requirements

Table 7.2 Actor Definitions Actor

Description

Customer

The Customer is a user of the system and a potential purchaser of tours. A Sales Clerk is a user of the system and acts as a surrogate for either a Customer or a Tour Organizer. The Tour Organizer is a user of the system and registers tours that are available for purchase. The System Administrator is a user of the system and is responsible for ensuring the smooth operation of the system. The Business Administrator is a user of the system and is responsible for administering business-related information in the system. The CRM System is an external system that manages customer-related information. The Payment Engine is an external system and supports the transfer of money between monetary accounts. The Reservation System is an external system and supports accommodation and transportation reservations associated with tour bookings.

Sales Clerk Tour Organizer System Administrator

Business Administrator

CRM System Payment Engine Reservation System

Interactions between the actors and the system are often of interest to architects because they are concerned with any technologies required to support the interface and any qualities that must be achieved when using the interface (such as performance), and they also need to acknowledge any constraints that may be imposed (such as the format of data passed across the interface). Quite often, the architect has several choices to make in realizing such interfaces and has to make appropriate trade-offs. Therefore, the architect ensures that actors representing external systems are considered, because such systems may result in the identification of particular integration concerns.

Step: Identify Actor Locations In addition to identifying the actors, it is important to acknowledge where the actors are physically located. The location of actors subsequently affects the architecture of your system, because you must acknowledge any constraints

Task: Define System Context | 147

incurred as a result of the locations specified. The network latency inherent in a distributed environment, for example, can mean that communication between elements is orders of magnitude slower than communication between elements in a nondistributed environment. Table 7.3 describes the locations identified for the YourTour system and the actors associated with these locations.

Step: Identify Data Flows You can be more precise about the nature of the interface between the system and its external actors and provide details of the information passed across this interface. An example is shown in Table 7.4. The architect may get involved in this exercise to ensure appropriate consideration of the flow of data between the system and external actors. The descriptions of the data items typically make reference to items described in the Business Entity Model, if this work product has been provided as input. Subsequently, identified data items may be used when describing the flows of events in each of the use cases, for example.

Table 7.3 Location Definitions Location

Description

Actor(s)

Remote Office

A location where customers and tour organizers can access the YourTour application from an Internetenabled device, such as a browser, personal digital assistant (PDA), or cell phone. A location where customers and tour organizers can meet with a sales clerk to book a tour. A location where information from all remote offices and branch offices is consolidated. This location also houses the legacy CRM system. A location that houses the MyPay payment system. A location that houses the MyReservation reservation system.

Customer, Tour Organizer

Branch Office

Central Office

MyPay Data Center MyReservation Data Center

Sales Clerk

CRM System, System Administrator, Business Administrator Payment Engine Reservation System

148 | Chapter 7 Defining the Requirements

Table 7.4 Data Flows From

To

Description

Data Items Involved

Customer

System

Tour

Customer

System

System

Customer

Sales Clerk

System

Sales Clerk

System

System

Sales Clerk

Tour Organizer

System

System Administrator

System

System

System Administrator

Business Administrator

System

System System

Business Administrator CRM System

CRM System

System

System

Payment Engine

The customer requests information on available tours. The customer provides information on tour participants and tour booking details (such as payment information and tour participant options). The system provides information on available tours. The sales clerk requests information on available tours. The sales clerk provides information on tour participants and tour booking details (such as payment information and tour participant options). The system provides information on available tours. The tour organizer provides tour description information. The system administrator requests information regarding users, tour, tour participants, and bookings. The system provides information regarding users, tour, tour participants, and bookings. The business administrator requests information regarding bookings. The business administrator provides information regarding booking fees. The system provides information regarding bookings. The system requests customerrelated information. The system provides customerrelated information (when creating and updating information). The CRM system provides customer-related information. The system provides payment information.

Tour Participant, Tour Participant Options, Booking, Payment Details Tour Tour Tour Participant, Tour Participant Options, Booking, Payment Details Tour Tour User, Tour, Tour Participant, Booking User, Tour, Tour Participant, Booking Booking, Booking Fee

Booking Customer Details

Customer Details Payment Details

Task: Outline Functional Requirements | 149

Table 7.4 Data Flows (Continued) From

To

Description

Payment Engine System

System

The payment engine provides payment confirmation information. Reservation System The system provides reservation information. Reservation System System The reservation system provides reservation confirmation information.

Data Items Involved Payment Confirmation Reservation Details Reservation Confirmation

Task: Outline Functional Requirements PURPOSE The purpose of this task is to outline the set of functional requirements. ROLES Application Architect (secondary), Business Analyst, Stakeholder (secondary) INPUTS ◆ Business Process Model (optional), Enterprise Architecture Principles (optional), Glossary, Stakeholder Requests, System Context, Vision

OUTPUT ◆ Functional Requirements

STEPS ◆ Identify functional requirements. ◆ Outline functional requirements. ROLE OF THE ARCHITECT ◆ Ensure that the requirements of the more technical actors, such as a System Administrator, are considered.

In this task, you identify and outline the system’s functional requirements. Each functional requirement is subsequently considered and detailed based on its priority, as defined in the Prioritize Requirements activity, which is discussed later in this chapter. Note that the identification of actors (performed in the Define System Context task), functional requirements, and non-functional requirements is not performed in a strict sequence. As you identify functional requirements, you

150 | Chapter 7 Defining the Requirements

may identify new actors, and vice versa. Also, you may identify requirements that are best captured in the Non-Functional Requirements work product, which is discussed later in this chapter.

Step: Identify Functional Requirements In this step, you consider each actor and their functional requirements of the system. In this book, we employ use cases for documenting functional requirements. In this step, however, we also consider system-wide functional requirements that aren’t readily captured in use cases. A use case is a description of a complete flow of events that results in something of value to an actor. The best way to find use cases is to consider what each actor defined in the System Context work product requires of the system, based on the Stakeholder Requests that have been gathered, because the system exists only to service the requests of the actors that interact with it. You also may refer to the Business Process Model and Vision work products (and not rely only on the stakeholder requests) to ensure that you are addressing the functionality required. The Enterprise Architecture Principles work product may also influence the functional requirements. The principle “Industry regulations will be conformed to” may require the system to provide an audit trail of its execution, supported by use cases that allow the relevant system actors to access this audit trail, for example. Each use case is identified by providing it a name and brief description. The name of the use case should indicate what is achieved through the interactions between the actors and the use case and, by convention, is a verb followed by a noun (such as Browse Tours). The brief description of a use case should reflect its goal and purpose, should refer to the actors involved, and should use the terms defined in the Glossary. A name, a brief description, the identification of related actors, and the identification of the main flow and key alternative flows through the use case (but not the detail behind each flow) usually are all that you need for the use case at this point in the process. We expand on this information when we flesh out the details of the use case in the Detail Functional Requirements task, later in this chapter. Figure 7.5 shows the initial set of use cases identified for the YourTour system. The architect is often involved in this exercise to ensure that the requirements associated with the more technical actors, such as the System Administrator, are acknowledged. In addition to these use cases, you may identify functional requirements that are considered to be system-wide and that are not expressed in use cases. In the case of the YourTour application, we have identified a need for both

Task: Outline Functional Requirements | 151

CRM System

Specify Tour

Administer Registered Users

Tour Organizer

Administer Tours System Administrator

Register

Administer Tour Bookings

Browse Tours Customer

Configure Content

Book Tour

Collect Fees

Sales Clerk

Reservation System

Payment Engine

Figure 7.5 Actors and Use Cases in the Use-Case Model

Business Administrator

152 | Chapter 7 Defining the Requirements

online help and security. Requirements should be negotiated with stakeholders to ensure that a mutually acceptable statement of the requirement is agreed to, as discussed in the sidebar “Pitfall: Requirements Are Non-Negotiable.” You can also benefit from understanding those requirements that may change, as discussed in the sidebar “Concept: Change Cases.”

Pitfall: Requirements Are Non-Negotiable Every requirement comes at a cost, and this cost is not always appreciated by the stakeholder. The architect is often in a good position to articulate this cost in terms of resource, time, skills, and the like. Conversely, the stakeholder is in the best position to articulate the value of the requirement in terms of the solution being provided. The architect and stakeholder need to bring their two perspectives together so that a mutually acceptable requirement is agreed to and communicated. In a software project, you can change almost anything at any time: plans, people, funding, milestones, requirements, designs, tests. Requirements— probably the most misused word in our industry—rarely describe anything that is truly required. Nearly everything is negotiable. (Royce 2005)

Concept: Change Cases Be prepared for change long before it happens by implementing change cases in your design. (Ambler 2000)

A change case represents a potential change in the system requirements and can give the architect insight into those aspects of the architecture that should be easily modified or extended. There is a trade-off to be made when addressing change cases, however, because by definition, a change case is not a requirement; it is a potential requirement. Although not explicitly included in the process described in this book, formally documenting change cases can prove a valuable exercise. Whether the architecture should address a given change case is one of the trade-offs that the architect needs to make, because it may involve additional effort or have an impact on certain system qualities. Given two seemingly equal architectural options, where one option addresses a change case and the other does not, choosing the option that addresses the change case is clearly the thing to do. Understanding the likelihood that a change case will become a requirement can also help architects in their decision-making.

Task: Outline Functional Requirements | 153

Step: Outline Functional Requirements In this step, you provide an outline of the functional requirements. Table 7.5 describes the functional requirements that have been identified for the YourTour system and indicates whether the functional requirement is expressed as a use case or is a system-wide functional requirement.

Table 7.5 Functional Requirement Descriptions Functional Requirement

Type

Description

Register

Use case

Specify Tour

Use case

Browse Tours

Use case

Book Tour

Use case

The Register use case allows a user to register with the system. This registration is required before a Tour Organizer may specify a Tour and before a Customer may book a Tour. The Specify Tour use case allows a Tour Organizer to describe the various aspects of the Tour that he or she is offering. The Browse Tours use case allows a Tour Organizer, Customer, and Sales Clerk to peruse the Tours available. The Book Tour use case allows a Customer or Sales Clerk to make a Tour Booking, which will result in interactions with the Payment System (for making monetary transfers) and the Reservation System (for making specific accommodation and transportation reservations). The Administer Registered Users use case allows a System Administrator to manage Tour Organizers, Customers, and Sales Clerks. Administration tasks include backup, archive, and retrieval. The Administer Tours use case allows a System Administrator to manage Tours. The Administer Tour Bookings use case allows a System Administrator to manage Tour Bookings. The Configure Content use case allows a Business Administrator to define configurable content, such as links to external services (such as travel insurance companies), banner advertising, latest news, and promotional offers. The Collect Fees use case allows a Business Administrator to collect fees for all Tour Bookings made within a given time period, which will result in interactions with the Payment System (for making monetary transfers). The system will provide online help. The system will provide appropriate security. In particular, the system will support user authentication and ensure that users are able to perform only the operations for which they have authorization.

Administer Use case Registered Users Administer Tours Administer Tour Bookings Configure Content

Use case

Collect Fees

Use case

Online Help Security

System-wide System-wide

Use case Use case

154 | Chapter 7 Defining the Requirements

These descriptions give you a hint that some refactoring of the use-case model is in order. Specifically, different categories of user are identified: a Tour Organizer, a Customer, and a Sales Clerk. Therefore, you may refine the initial use case model. Figure 7.6 shows several refinements that have been made, including generalized actors and associated use cases, and also management use cases that have been identified. Such refactoring is typically performed by a

CRM System

Browse Tours

Register

Administer Registered Users

User

Administer Tours Login System Administrator

Specify Tour Administer Tour Bookings Logout

Registered User

Tour Organizer Registered User

Configure Content

Manage Profile Book Tour Collect Fees

Tour Booker

Customer

Sales Clerk

Reservation System

Figure 7.6 Refactored Actors and Use Cases

Payment Engine

Business Administrator

Task: Outline Functional Requirements | 155

Business Analyst and can provide hints to the architect of common behavior in the system, although you always need to ensure a clear separation of requirements and solution. Any refactoring may be reflected back in the System Context work product if it enhances the communication of this work product. As you can see, we added the generalized actors of User, Registered User, and Tour Booker, as well as several use cases. This refactoring allows you to identify common behavior and also allows you to communicate the intent of the use-case model more easily, because it provides some level of abstraction. The definitions of the additional actors are shown in Table 7.6; all other actor definitions remain unchanged. The additional use cases are considered to be self-explanatory and are not detailed here. Although they are not spelled out in the use-case diagram in Figure 7.6 or in the associated descriptions, certain prerequisites exist for the execution of some of the use cases. A Tour Organizer cannot specify a tour, for example, and a Tour Booker cannot book a tour unless he or she is logged into the system. Also, some rather obvious rules must be obeyed. A Tour Booker cannot book a tour that is full, for example. Such rules are used in the relevant use-case descriptions (a use-case description is associated with a particular use case), and references are made to the relevant items in the Business Rules work product. These considerations are discussed later in this chapter, in the Detail Functional Requirements activity.

Table 7.6 Refined Actor Definitions Actor

Description

User

A User represents the general, casual user of the YourTour system who has not yet committed to either selling or purchasing Tours. This role performs a basic set of system features to be accessible to all roles derived from this role.

Registered User

A Registered User is a User who has an account with the YourTour system.

Tour Booker

A Tour Booker represents a Registered User who is interested in purchasing a Tour that is available for sale.

156 | Chapter 7 Defining the Requirements

Task: Outline Non-Functional Requirements PURPOSE The purpose of this task is to outline the set of non-functional requirements. Such requirements represent qualities or constraints. ROLES Application Architect (secondary), Business Analyst, Infrastructure Architect (secondary), Stakeholder (secondary) INPUTS ◆ Business Rules (optional), Enterprise Architecture Principles (optional), Glossary, Stakeholder Requests, System Context, Vision

OUTPUT ◆ Non-Functional Requirements

STEPS ◆ Identify non-functional requirements. ◆ Outline non-functional requirements. ROLE OF THE ARCHITECT ◆ Ensure that the appropriate non-functional requirements have been considered. ◆ Ensure that non-functional requirements are expressed in an appropriate manner.

The identification of non-functional requirements is of particular interest to the architect, because such requirements often present the most challenging requirements to be accommodated in the resulting architecture. As for functional requirements, we do not describe the non-functional requirements in detail at this point. Instead, we concentrate on defining their intent and purpose, and possibly outlining their content. Each of the non-functional requirements is subsequently detailed based on its priority, as defined in the Prioritize Requirements task, which is discussed later in this chapter. It is worth noting that the Outline Functional Requirements and Outline Non-Functional Requirements activities are not performed in strict sequence and typically are performed concurrently. While identifying use cases, for example, you may encounter non-functional requirements that are associated with a particular aspect of the use case, in which case the requirement may be defined in the Non-Functional Requirements work product and referred to from the use case. Conversely, while identifying non-functional requirements, you may encounter requirements that apply only to a particular use case, in which case the requirement is associated with the use case in question and not the system as a whole.

Task: Outline Non-Functional Requirements | 157

Step: Identify Non-Functional Requirements Based primarily on the requests that have been specified in the Stakeholder Requests work product, you can derive the non-functional requirements. This activity is much easier to undertake if you use a questionnaire, such as that discussed in the Collect Stakeholder Requests task, because the requests are already classified in a manner that aligns well with the content of the NonFunctional Requirements work product. This work product typically is organized with the same classification, using the usability, reliability, performance, and supportability non-functional categories of the FURPS classification described in Appendix D, “Architectural Requirement Checklist.” As for stakeholders and actors, it useful to maintain a checklist of non-functional requirements, as described in the sidebar “Best Practice: Maintain a Systematic List of Non-Functional Requirements.” In identifying the non-functional requirements, you may refer to the Business Rules work product that contains explicit constraints on your solution. Business rules are described in the sidebar “Concept: Business Rules.” In addition, you may refer to the Vision, because it may contain features that are actually non-functional in nature, such as system availability. The System Context work product is also used as input because it defines the nature of any integration with external actors, which may imply non-functional requirements of the system, such as a constraint on the nature of the interface to a particular external system. The Enterprise Architecture Principles work product may contain defined technology standards. The architect typically gets involved in this task to ensure that all relevant non-functional requirements are identified. Non-functional requirements that represent qualities associated with the YourTour system include accessibility, availability, scalability, and testability. Non-functional requirements that represent constraints associated with the YourTour system include schedule, integration, platform support, standards compliance, and third-party components.

Best Practice: Maintain a Systematic List of Non-Functional Requirements Unlike functional requirements, a more finite set of non-functional requirements can be considered for any given system (in particular, those nonfunctional requirements representing qualities). Whichever framework you use to classify the non-functional requirements, it is good practice to maintain and apply an appropriate checklist of non-functional requirements to ensure that nothing has been overlooked.

158 | Chapter 7 Defining the Requirements

Concept: Business Rules A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. (Business Rules Group 2000)

Business rules describe the operations, policies, and constraints that an organization puts in place to achieve its goals. Rules help the organization achieve its business goals by acting as a communication mechanism between the organization and interested third parties and by allowing the organization to meet its legal and other statutory obligations. They also allow the organization to operate more efficiently, because rules can be automated and analyzed to look for time and cost savings and the like. Business rules fall into several categories: ■

Rules that provide the conditions that govern business behavior (legislative, regulatory, cultural, and business)

■

Rules that provide the criteria for when an action is successfully or unsuccessfully completed

■

Rules that stipulate what other actions can or cannot be performed as a result of successful or unsuccessful completion

■

Rules that specify the response to some external event that impinges on the enterprise

■

Rules that govern relationships among various business entities

Step: Outline Non-Functional Requirements In Table 7.7, we show a few entries from the Non-Functional Requirements work product of the YourTour system. The categories and requirements shown in this table come from the FURPS classification described in Appendix D, “Architectural Requirement Checklist.” As you would expect, non-functional requirements are documented by using terms defined in the Glossary, and the architect typically gets involved to ensure that the non-functional requirements that have been identified are described in an appropriate manner. Specifically, the non-functional requirements must be measurable to prove or disprove that such requirements have been met. In addition, you may choose to explicitly state what is not required to avoid any ambiguity, as discussed in the sidebar “Best Practice: State What Is Not Required if This Aids Understanding.”

Task: Outline Non-Functional Requirements | 159

Table 7.7 An Extract from the Non-Functional Requirements Work Product of the YourTour System Category

Requirement

Description

Usability

Accessibility

Reliability

Availability

Performance

Speed

Supportability

Scalability

Supportability

Testability

Business Constraint

Schedule

Architecture Constraint Architecture Constraint

Communication

Development Constraint

Platform support

Development Constraint

Standards compliance

Development Constraint

Third-party components

The system will support people with visual, hearing, motor, or cognitive impairments in accordance with the YourTour organization standards. The system will be 99.9% available for functions requiring secure access (such as booking a tour). The system will be 99% available for all other functions (such as browsing tours). Backup and maintenance operations will not require the system to be offline. The system will process a tour-booking confirmation (including any transactions with the MyPay payment engine and MyReservation reservation system) in less than ten seconds. The system will support 100,000 registered users and 5,000 concurrent users. The system will allow the content of any transactions to be logged to allow all transactions and their payloads to be validated. The system will be delivered in less than six months. The system will use industry-standard web protocols for interoperability. The YourTour system will use YourTour’s existing CRM system for storing customer information. The YourTour system will be made available through Internet-enabled devices, such as web browsers and PDAs. The YourTour system will be developed in accordance with the YourTour development standards. The YourTour system will not implement handling of payments and reservations (of accommodations and transportation) directly; it will interface with the MyPay payment engine and the MyReservation reservation system, respectively.

Legacy integration

160 | Chapter 7 Defining the Requirements

Best Practice: State What Is Not Required if This Aids Understanding Sometimes, it is useful to state what is not required of the system to prevent assumptions from being made or to prevent a lack of clarity about the requirements. A good example is “The YourTour system will not implement handling of payments and reservations (of accommodations and transportation) directly; it will interface with the MyPay payment engine and the MyReservation reservation system, respectively.”

Task: Prioritize Requirements PURPOSE The purpose of this task is to prioritize the requirements so that iterations are planned based on the highest-priority requirements. ROLES Business Analyst, Lead Architect, Project Manager (secondary), Stakeholder (secondary) INPUTS ◆ Glossary, Functional Requirements, Non-Functional Requirements, RAID Log, Stakeholder Requests, Vision (optional)

OUTPUT ◆ Prioritized Requirements List

STEP ◆ Prioritize requirements. ROLE OF THE ARCHITECT ◆ Assist with the prioritization of requirements.

As mentioned in Chapter 3, “Method Fundamentals,” one of the premises of architecting software systems successfully is using an iterative development life cycle, which helps architects focus on the results they are trying to achieve at any given time without getting bogged down in whether a particular work product is complete. In other words, architects are results-driven and not documentdriven. More specifically (as also discussed in Chapter 3), architects move from focusing on understanding the scope and associated risks in the system, to focusing on removing risk and stabilizing the architecture, to focusing on completing the system in an incremental fashion. Prioritizing requirements helps you determine which things to focus on within the current iteration based on your goals and focus. Because your focus

Task: Prioritize Requirements | 161

changes through the project life cycle, the priority associated with a particular requirement will also change. Therefore, requirements are not prioritized only once. You examine the relative priorities within each iteration and, where necessary, adjust those priorities based on the current project status (including new requirements, new change requests, discovery of new risks, and mitigation of existing risks). Prioritizing the requirements is based on several factors. One of these factors, associated with an iterative development approach, is ensuring that risks are confronted early. For this reason, the RAID Log, which includes the known and open risks to the project and current issues on the project that need to be addressed, is considered to be an essential work product that is input to this task. Another factor is the key needs of the stakeholders and the corresponding features of the system, as documented in the Vision document, which is also an input to this activity. In addition, the Stakeholder Requests work product is input, because it contains an indication of the stakeholder priorities based on the originating requests that were made. The Glossary is input because it provides clarification of any terms used. The Functional Requirements and Non-Functional Requirements work products are input, of course. The priority given to a particular requirement is captured in the Prioritized Requirements List work product that is output from this task.

Step: Prioritize Requirements You can perform an initial prioritization of the requirements by looking across all requirements, functional and non-functional, resulting in an indication of those high-priority requirements that you should attempt to address in the current iteration. Consideration of these high-priority requirements can entail a significant amount of effort, however, especially if you consider that each requirement may have an element of detailed design and testing associated with it. Therefore, you need to be smart about how you address the high-priority requirements. The fact that requirements are not always truly independent can help you in this regard. If you address the Book Tour use case, for example, you know that it will also address the integration with third-party components. To minimize the effort involved in addressing high-priority requirements, it is beneficial to consider the alignment of use cases and other requirements when prioritizing, which you can show in a simple table. Table 7.8 shows an example from the YourTour system. The rows represent use cases, and the columns represent all other requirements (systemwide functional requirements from Table 7.5 and non-functional requirements from Table 7.7). Coverage of a specific non-functional requirement or systemwide requirement by a use case is indicated with a Y in the relevant cell. You cannot determine the schedule of the system by considering a single use case

162 | Chapter 7 Defining the Requirements

Y Y Y Y Y Y Y Y Y Y Y Y

Y Y Y

Y Y Y Y Y Y Y Y Y Y Y Y

Y Y Y Y Y Y Y Y Y Y Y Y

Third-Party Components

Y Y Y Y Y Y Y Y Y Y Y Y

Testability

Y Y Y Y Y Y Y Y Y Y Y Y

Speed

Y Y Y Y Y Y Y Y Y Y Y Y

Standards Compliance

Y Y

Security

Y

Scalability

Y Y Y Y Y Y Y Y Y Y Y Y

Platform Support

Y Y Y Y Y Y Y Y Y Y Y Y

Online Help

Communication

Y Y Y Y Y Y Y Y Y Y Y Y

Legacy Integration

Availability

Administer Registered Users Administer Tour Bookings Administer Tours Book Tour Browse Tours Collect Fees Configure Content Login Logout Manage Profile Register Specify Tour

Accessibility

Table 7.8 Alignment of Use Cases and Other Requirements

Y Y Y

(all use cases must be considered), however, and so schedule is not included in this table. This table helps inform our decisions regarding the relative priority of each of the use cases. Table 7.9 shows the priority assigned to each use case, together with the rationale for its priority. The priorities are based on the information gleaned from Table 7.8 and other characteristics mentioned in the rationale. Each requirement is shown as being high, medium, or low priority. Any risks that form part of the rationale are taken from the RAID Log. Both the prioritized list and the rationale for the priority are captured in the Prioritized Requirements List. The list may also contain requirements that do not align with any use case in particular, such as a requirement for the system to start up in a given amount of time, in which case you just add them to the list with the associated rationale for their priority. You should also ensure that the use cases really are prioritized against one another, as discussed in the sidebar “Pitfall: All Requirements Are Equal.”

Task: Prioritize Requirements | 163

Table 7.9 Prioritized Use Cases Priority

Use Case

Rationale

High

Book Tour

High

Specify Tour

High

Register

High

Collect Fees

Medium

Browse Tours

Medium

Login

Medium

Administer Tour Bookings

Medium

Configure Content

Low

Logout

Low Low

Administer Registered Users Administer Tours

Low

Manage Profile

This use case represents the heart of the YourTour system. This use case also has specific requirements regarding response time and integration with third-party components, both of which are considered to be high-risk areas. Along with the ability to book a tour, the Specify Tour use case represents the heart of the YourTour system. This use case requires integration with the legacy CRM system, which presents a particular risk. This use case has specific requirements regarding response time and integration with thirdparty components, both of which are considered to be high-risk areas. This use case requires greater consideration of the user interface than the other use cases and is best considered after the core YourTour capabilities are in place. This use case requires consideration of authorization and authentication, which presents a particular risk. Modification of existing tour bookings presents particular challenges, such as the ability to cancel reservations and handle refunds where appropriate. This use case requires consideration of content management. This use case is considered to exercise similar capabilities to the Login use case. This use case is considered to be a refinement of the Register use case. This use case is considered to be a refinement of the Specify Tour use case. This use case is considered to be a refinement of the Register use case.

164 | Chapter 7 Defining the Requirements

Pitfall: All Requirements Are Equal A common pitfall is for all requirements to be given the same priority. Without exception, projects that suffer from this pitfall classify all requirements as high priority. If all requirements have the same priority, providing priorities against requirements is a waste of time, because this information cannot be used to identify those requirements that are more important than others. The requirements need to be prioritized to indicate to the architect (or anyone else) the most important requirements of the system.

Task: Detail Functional Requirements PURPOSE The purpose of this task is to complete the functional requirements to the extent that they can be used to drive the definition of the system from a functional perspective. ROLES Application Architect (secondary), Business Analyst, Stakeholder (secondary) INPUTS ◆ Functional Requirements, Glossary (optional), Prioritized Requirements List, Stakeholder Requests, System Context

OUTPUT ◆ Functional Requirements

STEPS ◆ Detail use cases (for each use case considered in the current iteration). ◆ Detail use-case data items. ◆ Detail system-wide functional requirements. ◆ Detail functional requirement scenarios. ROLE OF THE ARCHITECT ◆ Ensure that all the alternative flows are considered. ◆ Assist with the definition of use-case data items. ◆ Assist with the detailing of system-wide functional requirements. ◆ Assist with the detailing of specific scenarios.

At this point, you have an initial specification of what the system is required to do, what its scope is, and a list of prioritized requirements. Now you turn your attention to refining this initial system definition to gain a deeper

Task: Detail Functional Requirements | 165

understanding of the requirements. Only the highest-priority requirements are considered in the current iteration. As you detail the various requirements, it is important to note that the addition of such detail may require you to revisit some of the tasks already performed. You may find that a use case needs to be split into two or more use cases or that the detail contained within a use-case description makes the use case architecturally significant and, therefore, higher priority. Such refinements may be accommodated in either the current iteration or the next iteration.

Step: Detail Use Cases This step is performed for each use case being considered in the current iteration. In this step, you start with the Functional Requirements work product that contains the use-case model and that in turn contains each of the use cases and, therefore, the associated use-case descriptions. You gradually make the use case description more detailed until all the stakeholders are happy that it unambiguously expresses their requirements. You specify the following information when you detail a use case, elements of which will have been defined in the Outline Functional Requirements task: ■

Name. The name initially defined in the Outline Functional Requirements task.

■

Brief Description. The goal and purpose of the use case (initially defined in the Outline Functional Requirements task).

■

Primary Actors. The names of the initiating actors. You may have more than one primary actor if two or more actors are able to initiate the same use case.

■

Secondary Actors. The names of any other actors involved in the use case.

■

Main Flow of Events. A description of the primary path through the use case when it executes, expressed in terms of interactions between the actors and the system. These interactions may have been outlined when the use case was initially defined in the Outline Functional Requirements task.

■

Alternative Flows of Events. A description of alternative paths through the use case when it executes, also expressed in terms of interactions between the actors and the system. The key alternative flows (and associated interactions) may also have been outlined when the use case was initially defined in the Outline Functional Requirements task.

■

Special Requirements. A textual description of requirements that are not considered in the use case flows of events but that need to be taken care of

166 | Chapter 7 Defining the Requirements

during the detailed design or implementation. Such requirements typically represent non-functional requirements associated with the use case, such as system qualities (performance, for example) or constraints on the solution, and items in this section may reference the Non-Functional Requirements work product. Special requirements are discussed later in this section. ■

Preconditions. The required state of the system to execute the use case.

■

Postconditions. A list of possible states that the system must be in immediately after the use case has finished.

When describing a use case, it is important to consider the context of the use case. The context of the use case is described by the relationships that the use case has with actors and other use cases. If it adds value, this context can be expressed in a local use-case diagram that contains only the use case, its actors, and other use cases that the use case may have relationships with (such as use cases that this use case includes or extends). Figure 7.7 shows the context of the Book Tour use case.

Payment Engine

Book Tour Tour Booker

Reservation System

Customer

Sales Clerk

Figure 7.7 The Context of the Book Tour Use Case

Task: Detail Functional Requirements | 167

The use-case description should also refer to the Glossary to ensure that consistent terms are used. You may also refer to the Stakeholder Requests to get a better understanding of the intent, if required. Some of the items in the use-case description warrant further explanation. We start with the various flows of events. A use case may have several potential flows through it, as shown symbolically in Figure 7.8. A use case always has a main flow (sometimes referred to as the basic flow or happy day path) and may have several alternative flows that arise due to exceptional conditions, for example. The following information should be included in the detailed description of each flow of events: ■

How and when the use case starts

■

When the use case interacts with the actors and what information is exchanged

■

How and when the use case uses information stored in the system or stores information in the system

■

When business rules (referenced from the Business Rules work product) are applied

■

How and when the use case ends

As an example, Table 7.10 contains the description of the main flow of events for the Book Tour use case. As well as detailing the main flow of events, you may detail alternative flows. Table 7.11 describes three of the alternative flows of events for the Book Tour use case. The architect may be involved in helping identify the alternative flows, because the stimulus for the flow being executed may be technical in nature.

Figure 7.8 The Flows of Events of a Use Case

168 | Chapter 7 Defining the Requirements

Table 7.10 Main Flow of Events of the Book Tour Use Case Name

Book Tour

Main Flow

1. The use case starts when the Tour Booker opts to book one or more Tour Participants on a Tour. 2. The Tour Booker identifies the Tour to be booked. 3. The Tour Booker identifies each Tour Participant for the Tour. 4. For each Tour Participant, the Tour Booker specifies the preferred accommodation and transportation options. 5. The Tour Booker provides Payment Details.Accommodation and transportation reservations are made through the Reservation System, and payment is made through the Payment Engine. 6. The Tour Booker receives a unique reference as confirmation of the Tour Booking. 7. The use case ends.

Table 7.11 Alternative Flows of Events of the Book Tour Use Case Name

Book Tour

Alternative If, at step 5 in the main flow, insufficient places are available on Flow 1: Insufficient the selected Tour, the following occurs: tour places are 1. The system notifies the Tour Booker of the number of places available available. 2. The use case ends. Alternative Flow 2: Reservations cannot be made

If, at step 5 in the main flow, accommodation or transportation reservations cannot be made, the following occurs: 1. The system notifies the Tour Booker of the failure to make all reservations. 2. The use case resumes at step 5 in the main flow.

Alternative If, at step 5 in the main flow, the system is unable to process the Flow 3: payment (the Payment Engine responds to the request with a Payment cannot be response such as “invalid credit card number,” for example), processed the following occurs: 1. The system notifies the Tour Booker of the reason for a failure to process the payment. 2. The use case resumes at step 5 in the main flow.

The special requirements associated with a use case also warrant further explanation. Architects sometimes come across requirements that are associated with a use case but that are not associated with any flow of events in particular. Such requirements often represent qualities or constraints that are specific to the use case as a whole and are described in the special requirements section

Task: Detail Functional Requirements | 169

of the use-case description. The Book Tour use case of the YourTour system, for example, specifies the following special requirement: “Booking a tour must take less than 10 seconds, from the time the request is submitted, to the confirmation of the booking being presented to the user.” Because you also have a Non-Functional Requirements work product, it does raise the question of where special requirements that are use case– specific and non-functional in nature should physically reside in terms of any documentation that constitutes the Non-Functional Requirements work product. On the one hand, it is clearly of value to see the requirement in context in the use-case description. On the other hand, it is also of value, especially for the architect, to see all non-functional requirements in one place, whether or not these requirements are associated with a use case. In a perfect world, you would have appropriate development tools that allow use case–specific non-functional requirements to be seen with the usecase description and in a list of all non-functional requirements. In practice, such requirements are often included with the use case, with references to these requirements from a separate document, spreadsheet, or tool that provides a summary of all non-functional requirements. Other items in the use-case description worth describing are the preconditions and postconditions. In detailing a use case, sometimes you need to define that the system be in a particular state before the use case can start. A common example is the “user is logged in” state. The Book Tour use case specifies the preconditions shown in Table 7.12. It also may be necessary to describe what must be true after the use case completes. The Book Tour use case has the postcondition shown in Table 7.13.

Table 7.12 Preconditions of the Book Tour Use Case Precondition

Description

Tour Booker is logged in.

The Tour Booker must be logged in before they can book a tour. The Tour Booker has identified the tour that they are interested in booking.

Tour Booker has identified a tour.

Table 7.13 Postconditions of the Book Tour Use Case Postcondition

Description

The Number of Places on the Tour is Reduced

After the tour has been booked, the number of places available on the tour is reduced by the number of places booked.

170 | Chapter 7 Defining the Requirements

Step: Detail Use-Case Data Items In the Define System Context task, you identified the data that flows between the external actors and the system, and the data items involved in the interactions. Then you used the data items in describing various aspects of the requirements. The purpose of this step is to elaborate on the data items you identified. You will consider these data items further when you think about the solution to the requirements, as discussed in Chapter 8, “Creating the Logical Architecture.” Again, we can use the Book Tour use case as an example. Simply looking at the main flow of events, you can see that this use case makes use of Tour Participants, Tour Participant Options, Tour, Tour Location, Payment Details, and Tour Booking data items, which were originally identified in the Define System Context task. You can also see that the use case may infer additional data items or attributes of these items. The step “The Tour Booker receives a unique reference as confirmation of the Tour Booking” in the use-case flow tells you two things, for example: ■ ■

There probably is a Booking Confirmation data item. A Tour Booking has a unique reference.

If you apply this scrutiny across all use cases, you can see that the definition of the various data items is refined as a result. Any new data items that are identified are added to the System Context work product as required.

Step: Detail System-Wide Functional Requirements For those functional requirements that are not easily expressed in use cases, you generally embellish the textual description of the requirement that has been outlined. You could refine a requirement such as “The system shall provide online help” with a more detailed description of the form in which this online help will be provided. You might add “Online help will be accessible at any point in time, and it will be possible for the help contents to be downloaded as a PDF file.” The architect may assist with this step because any system-wide capabilities may have a significant impact on the architecture.

Step: Detail Functional Requirement Scenarios The functional requirements discussed so far are general enough to cover all possible scenarios. It may also be beneficial to define several concrete scenarios to exemplify and clarify a given functional requirement. This approach can also ensure that specific values that the system must address are made explicit, which can provide valuable information to developers and testers.

Task: Detail Non-Functional Requirements | 171

A specific scenario associated with booking a tour may include a statement such as “John Smith is an existing customer. He would like to book his three sons, Tom, Dick and Harry, on the Around Africa tour.” Even these simple statements can make explicit items that might otherwise go unnoticed. The concept of an existing customer, for example, implies that customer information is retained by the system. Also, this particular scenario does not involve the customer participating in the tour; therefore, it must be possible for a customer to book a tour on behalf of others.

Task: Detail Non-Functional Requirements PURPOSE The purpose of this task is to complete the non-functional requirements to the extent that they can be used to drive the definition of the system in terms of the qualities exhibited and the constraints accommodated. ROLES Application Architect (secondary), Business Analyst, Infrastructure Architect (secondary), Stakeholder (secondary) INPUTS ◆ Glossary (optional), Non-Functional Requirements, Prioritized Requirements Lists, Stakeholder Requests

OUTPUT ◆ Non-Functional Requirements

STEPS ◆ Detail non-functional requirements (for each non-functional requirement considered in the current iteration). ◆ Detail non-functional requirement scenarios. ROLE OF THE ARCHITECT ◆ Ensure that all non-functional requirements are described in an appropriate manner. ◆ Assist with the detailing of specific scenarios.

In this task, you detail those non-functional requirements associated with the high-priority items in the current iteration. As for functional requirements, you may encounter non-functional requirements that have not been stated or characteristics that warrant a fundamental change in the non-functional requirement. Again, such refinements may be accommodated in either the current iteration or the next iteration.

172 | Chapter 7 Defining the Requirements

Step: Detail Non-Functional Requirements The purpose of this step is to augment the relevant non-functional requirements with any additional detail required. Imagine that you had a requirement that simply stated, “The system will be scaleable.” You cannot address this requirement unless you understand what it means in terms of numbers of users, volumes of data, and so on. Supporting a solution that scales to 100,000 concurrent users is likely to result in a different solution from one that must scale to 100 concurrent users, for example. The architectural solution to the requirement is potentially different depending on the details of the requirement. Another example is “The system will interface with the ABC external system.” You need to augment the requirement with information regarding the precise nature of the interface so that our system communicates with the ABC system in an appropriate manner. A simple way to supplement the description of each non-functional requirement is to apply the elements of the SMART acronym. This acronym has many variations, but for the purposes of this discussion, assume that the items are specific, measurable, achievable, realistic, and time-based. Simply thinking about each element of this acronym and applying it to your definition of each nonfunctional requirement can take you some way toward providing the detail required. In particular, if a requirement cannot be measured, it cannot be validated. If a requirement cannot be validated, it cannot be realized in the solution, because there is no way to determine whether the requirement has been satisfied. Providing a sufficient description often requires effort to achieve. As stated succinctly in Principles of Software Engineering Management (Gilb 1988): [Quality] attributes can always be made measurable.This frequently seems difficult, but there is always a way of achieving it. (Gilb 1988)

Each description of a non-functional requirement should also refer to the Glossary to ensure that consistent terms are used. You may also refer to the Stakeholder Requests to get a better understanding of the intent, if required.

Step: Detail Non-Functional Requirement Scenarios The detailing of scenarios associated with non-functional requirements focuses primarily on qualities. A technique for detailing such scenarios is presented in Software Architecture in Practice, 2nd ed. (Bass 2003), where each quality is qualified with one or more quality attribute scenarios, which may be identified in a Quality Attribute Workshop (QAW) (Barbacci 2003). Each scenario consists of six parts:

Task: Detail Non-Functional Requirements | 173 ■

Stimulus. The stimulus defines the condition that must be handled by the system.

■

Source of the stimulus. The source defines the role, system, or system element that causes the scenario to start.

■

Artifact stimulated. The artifact represents the target of the stimulus and represents either the system or a part of the system.

■

Environment. The environment defines the conditions under which the stimulus occurs.

■

Response. The response represents the response of the system to the stimulus under the conditions expressed in the environment.

■

Response Measure. The response measure is a definition of how the outcome is handled. We can exemplify this template by considering a scalability scenario:

■

Stimulus. The initiation of a tour booking.

■

Source of the stimulus. The end user who is causing a booking with the YourTour system to be initiated.

■

Artifact stimulated. The YourTour system.

■

Environment. 5,000 concurrent users are currently logged in to the system.

■

Response. The booking request is rejected because a threshold has been reached (assuming that a limit of 5,000 concurrent users is defined).

■

Response Measure. The end user who initiates the tour booking is notified that currently it is not possible to book a tour and told what action he or she should take.

Describing scalability scenarios in this manner is much more explicit and measurable than simply stating “The system must scale to support 5,000 concurrent users,” because it describes the conditions under which the scenario occurs (the source, stimulus, and environment), what the scenario applies to (the artifact), and the desired outcome (the response and response measure).

174 | Chapter 7 Defining the Requirements

Task: Update Software Architecture Document PURPOSE The purpose of this task is to document the architecturally significant requirements in the Software Architecture Document. ROLE Lead Architect INPUTS ◆ Business Process Model, Functional Requirements, Glossary, Non-Functional Requirements, RAID Log, Stakeholder Requests, System Context

OUTPUT ◆ Software Architecture Document

STEP ◆ Update software architecture document. ROLE OF THE ARCHITECT ◆ The architect is responsible for this task.

The requirements view of the Software Architecture Document is used to document the architecturally significant requirements. As discussed in Chapter 4, “Documenting a Software Architecture,” several cross-cutting views allow you to also consider a particular focus on the architecture, and this focus allows you to describe the requirements for a specific set of concerns. A checklist of requirements associated with each of the cross-cutting views is given in Appendix B, “Viewpoint Catalog.”

Step: Update Software Architecture Document In this step, you update the requirements view, and any cross-cutting views, of the Software Architecture Document. This requirements view contains the architecturally significant functional and non-functional requirements. You should always bear in mind that the purpose of the Software Architecture Document is to allow the architecture to be communicated. From the perspective of requirements, you are trying to communicate the requirements that have a major bearing on the architecture and that provide rationale for why the architecture is the way it is. This information is particularly valuable when, for example, you have to defend your architecture in an architecture review.

Task: Review Requirements with Stakeholders | 175

Task: Review Requirements with Stakeholders PURPOSE The purpose of this task is to obtain stakeholder agreement that the requirements, at their current level of elaboration, satisfy their requests. ROLES Application Architect (secondary), Business Analyst, Data Architect (secondary), Infrastructure Architect (secondary), Lead Architect, Stakeholder INPUTS ◆ Business Entity Model, Business Process Model, Business Rules, Enterprise Architecture Principles, Existing IT Environment, Functional Requirements, Glossary, Non-Functional Requirements, Prioritized Requirements List, RAID Log, Software Architecture Document, Stakeholder Requests, System Context, Vision

OUTPUTS ◆ Change Request, RAID Log, Review Record

STEPS ◆ Baseline work products. ◆ Assemble work products. ◆ Review work products. ROLE OF THE ARCHITECT ◆ Participate in the review. ◆ Respond to any questions of a technical nature.

The purpose of reviewing the requirements with the stakeholders is to ensure that the requirements, at their current level of elaboration, satisfy their requests. Before performing the review of the various requirements, you baseline work products so that you have a clear record of what was reviewed and can refer to these work products if necessary (to clarify a review comment against one of these work products, for example).

Step: Baseline Work Products Baselining is one aspect of configuration management (which also includes version control of work products), and the approach to configuration management is a project concern that should be addressed very early in the project. In

176 | Chapter 7 Defining the Requirements

this step, the various requirements work products are baselined, which simply means that the correct versions of the work products that will be input to the review are clearly identifiable. Although a configuration management approach can be very simple (when, for example, files are manually renamed to include a version number and a spreadsheet is used to describe a baseline of work products), you may find that even for small teams, using appropriate tooling to support the configuration management approach is a far more effective and less error-prone approach.

Step: Assemble Work Products In this step, you assemble the requirements work products that have been created or updated (and baselined) during the iteration in a form that stakeholders can review. Work products may be defined in various forms (such as a modeling tool or as stand-alone documents in a shared work area) and must be assembled into one or more deliverables. The work products assembled potentially include all work products that are input into, or output from, the Define Requirements activity.

Step: Review Work Products In this step, you review the requirements work products and document any problems discovered in the work products in Change Requests. Document any issues that arise in the RAID Log. When the review is complete, you briefly capture the results of the review, including any action items, in a Review Record. This review serves as a quality gate for the iteration that ensures that the requirements work products are mature enough to support subsequent tasks. It is important that people outside the development team (such as users and customers) approve the requirements work products at this stage, although all stakeholders are involved to some extent in many of the tasks discussed in this chapter, of course. They should verify that the work products capture the detailed requirements accurately. It is also important that the members of the development team be involved to make sure that they understand what needs to be built, as well as to identify areas where more information is needed.

Summary In this chapter, we described the process for documenting the requirements of the system, resulting in the following key work products: Glossary,

Summary | 177

Stakeholder Requests, System Context, Functional Requirements, NonFunctional Requirements, and Prioritized Requirements List. We also updated the Software Architecture Document with the architecturally significant requirements. These work products drive the development activities in Chapter 8, “Creating the Logical Architecture,” and Chapter 9, “Creating the Physical Architecture.”

This page intentionally left blank

Chapter 8 Creating the Logical Architecture

In this chapter we describe the tasks that produce the logical architecture that realizes the requirements defined in Chapter 7, “Defining the Requirements.” The sidebar “Concept: Logical Architecture versus Physical Architecture” describes the meaning of a logical architecture and how it differs from a physical architecture. Figure 8.1 shows the work products that are inputs to and outputs from the Create Logical Architecture activity, which contains the tasks that we discuss in this chapter.

Concept: Logical Architecture versus Physical Architecture A logical architecture represents an initial stepping stone in getting from the requirements to the solution—a first step that considers the architecture in a largely technology independent manner. A physical architecture, on the other hand, is more specific—and takes technology into account. The logical architecture may contain an Account component, for example, whereas the physical architecture may use the Java Platform Enterprise Edition (Java EE) and implement this logical component as an Account EJB (Enterprise JavaBean).

179

180 | Chapter 8 Creating the Logical Architecture

Input Work Products

Output Work Products

Business Entity Model

Architecture Assessment

Business Rules

Architecture Decisions

Enterprise Architecture Principles

Architecture Overview

Existing IT Environment

Architecture Proof-of-Concept

Functional Requirements

Change Request

Glossary

Create Logical Architecture

Data Model

Non-Functional Requirements

Deployment Model

Prioritized Requirements List

Functional Model

RAID Log

RAID Log

System Context

Review Record

Software Architecture Document

Figure 8.1 Input and Output Work Products of the Create Logical Architecture Activity

Creating the Logical Architecture | 181

The input work products (discussed in Chapter 7, “Defining the Requirements”) are ■

Business Entity Model. This work product defines the key concepts in the business domain under consideration.

■

Business Rules. This work product defines any policies or conditions that must be satisfied by the system under development.

■

Enterprise Architecture Principles. This work product contains rules and guidelines, defined at enterprise level, that inform and guide the way in which architectures will be created.

■

Existing IT Environment. This work product represents the collection of existing elements that comprise the current IT landscape and that may be used by, or constrain, the system under development.

■

Functional Requirements. This work product captures the functional requirements of the system under development.

■

Glossary. This work product provides a list of common terms, their meanings, and alternatives used by the business.

■

Non-Functional Requirements. This work product captures the nonfunctional requirements of the system under development.

■

Prioritized Requirements List. This work product captures the priority associated with each requirement.

■

RAID Log. This project management work product captures the risks, assumptions, issues, and dependencies for the project.

■

System Context. This work product represents the entire system as a single entity or process and identifies the interfaces between the system and external entities.

The following work products are output from the Create Logical Architecture tasks: ■

Architecture Assessment. This work product records the results of an assessment of the requirements and architecture performed at various stages during the project life cycle. An assessment identifies issues and risks associated with the architecture or its requirements and describes the actions and mitigation strategies to address them.

■

Architecture Decisions. This work product records the significant decisions made in shaping the overall architecture. It describes the rationale used in making the decision, the options considered, and the implications of the decision.

182 | Chapter 8 Creating the Logical Architecture ■

Architecture Overview. This work product provides an overview of the key elements of the architecture, such as the major structural elements, important behavior, and significant decisions.

■

Architecture Proof-of-Concept. This work product is used to prove and validate key parts of the architecture to reduce project risk. It may take the form of a model of a solution using a notation such as Unified Modeling Language (UML), a simulation of a solution, or an executable prototype.

■

Change Request. This work product describes the request for a change in the system. Changes may be significant and may dramatically affect the focus of the iteration.

■

Data Model. This work product describes the representation of the data used by the system.

■

Deployment Model. This work product shows the configuration of nodes, the communication links between them, and the components that are deployed on them.

■

Functional Model. This work product describes the software components, including their responsibilities and relationships, and the collaborations of components in delivering the required functionality.

■

RAID Log. As described in the preceding list, this project management work product captures the risks, assumptions, issues, and dependencies for the project.

■

Review Record. This work product defines, in the context of this activity, the result of an architecture review.

■

Software Architecture Document. This work product provides a comprehensive architectural overview of the system, using several architectural views to depict different aspects of the system.

Moving from Requirements to Solution This chapter is the first time we consider the transition from requirements to solution. Figure 8.2 is a subset of the work products that architects consider when making this transition and helps us demonstrate some simple but important concepts. In this figure, you see two of the key requirements work products: the Functional Requirements and Non-Functional Requirements. You also see two of the key solution work products: the Functional Model and the

Moving from Requirements to Solution | 183

Requirements

Functional Requirements

Non-Functional Requirements

Functional Model

Deployment Model

Solution

Figure 8.2 Key Work Products in Moving from Requirements to Solution

Deployment Model. Some important and fairly obvious concepts are represented by the arrows (which indicate various influences) in this figure: ■

Functional requirements influence the Functional Model. A use case that allows an order to be placed requires appropriate functional elements in the solution that provide this capability, for example.

■

Functional requirements influence the Deployment Model. The interaction between an actor representing a human being and the system may require the presence of a user workstation in the solution, for example.

■

Non-functional requirements influence the Functional Model. A particular third-party package that provides some of the functionality required may be mandated as a constraint, for example.

■

Non-functional requirements influence the Deployment Model. An availability requirement may introduce additional nodes that support system failover should a system element fail, for example.

Although each of these individual statements is straightforward to understand, considering all of them simultaneously—and at the same time ensuring that the Functional Model, the Deployment Model, and other work products remain consistent—is not. We take a divide-and-conquer approach in this book by considering each item in turn while at the same time ensuring consistency across the architecture models.

184 | Chapter 8 Creating the Logical Architecture

Different approaches to deriving an architectural solution exist, but their consideration of all elements sketched in Figure 8.2 is variable. Some approaches focus on functional requirements, to the exclusion of their non-functional counterparts. Others focus on the functional solution elements without considering the equally important deployment environment. This book places equal emphasis on functional requirements, non-functional requirements, functional elements, and deployment elements, because the authors believe that any imbalance will result in a suboptimal architecture. Several approaches to deriving an architectural solution exist, and several are worthy of note. The commonality among several approaches is discussed in “Generalizing a Model of Software Architecture Design from Five Industrial Approaches” (Hofmeister 2005), which considers five approaches. Three are listed here: ■

Attribute-Driven Design (ADD) Method, developed at the Carnegie Mellon Software Engineering Institute. In this approach, quality attributes (such as availability) are used to drive the derivation of the architecture and design, at successive levels of decomposition, through the use of architectural tactics and patterns that satisfy quality attribute scenarios. For more information, see Software Architecture in Practice, 2nd ed. (Bass 2003). Tactics are discussed in the sidebar “Concept: Tactics.”

■

Siemens’ 4 Views (S4V) method, developed at Siemens Corporate Research. This approach starts with a global analysis of the factors that influence the architecture, such as functional requirements, desired system qualities, organizational constraints, and technical constraints. The key architectural challenges are identified, and strategies are derived for addressing these challenges iteratively across four views: conceptual, execution, module, and code architecture. For more information, see Applied Software Architecture (Hofmeister 2000).

■

The Rational Unified Process (RUP), developed at Rational Software, now IBM Rational. This approach is driven by the architecturally significant use cases, non-functional requirements, and risks. Each iteration considers the key architectural elements of the solution before realizing the requirements using these solution elements. The solution is validated in executable software. For an overview of RUP, see The Rational Unified Process: An Introduction, 2nd ed. (Kruchten 2000).

This book acknowledges the commonality in these approaches, as well as those practices that we see successful software architects following. Such practices are discussed in this chapter and in subsequent chapters.

How Much Logical Architecture? | 185

Concept: Tactics The concept of a tactic is a key ingredient of the Attribute-Driven Design (ADD) method described in detail in Software Architecture in Practice, 2nd ed. (Bass 2003). Tactics are design decisions that decide how a functional requirement will be met or how a quality attribute will be resolved. A tactic that addresses availability might be to introduce redundancy into the system, for example. This book doesn’t provide a comprehensive catalog of tactics, because this approach would result in a mammoth publication that covered many kinds of reusable assets (reference architectures, architectural patterns, design patterns, and so on), all of which are built around one or more tactics. Instead, we focus on the method framework, which considers the application of reusable assets in general (including tactics). As well as the many books on different kinds of patterns, both Software Architecture in Practice, 2nd ed. (Bass 2003) and Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives (Rozanski 2005) provide an excellent grounding in those tactics that are at the disposal of the architect for addressing specific challenges such as availability, performance, and usability.

How Much Logical Architecture? One way to think of a logical architecture is as a rough-and-ready means of getting, as quickly as possible, from the requirements to a physical (and technology specific) architecture that can be implemented in code. In this approach, the logical architecture essentially is throwaway. Alternatively, you may treat the logical architecture as a strategic asset in its own right that, as a consequence, is actively maintained. In this approach, the logical architecture may provide an excellent abstraction of the system that you can refer to should you want to reengineer your system in a new technology. In many projects, the approach taken lies somewhere between these two extremes, where some, but not all, of a logical architecture is created and maintained. Such considerations are discussed in this section.

Minimizing Logical Architecture If the logical architecture is simply a means of getting to a physical architecture as quickly as possible, you need to produce just enough logical architecture to

186 | Chapter 8 Creating the Logical Architecture

demonstrate that you understand the current set of requirements and that those requirements have been allocated appropriately to parts of the solution. In extreme cases, no logical architecture may be required at all. This is possible in certain situations—when the requirements for the system are similar to those of an existing system, for example. In this case, it may be possible to derive major elements of your architecture by looking at the existing system. Another example is the inclusion of a packaged application or integration with an existing system; much of what is required is already provided, thereby minimizing the need for a logical architecture. Another factor is the complexity of the system. You may choose to develop the logical Deployment Model, for example, only if you anticipate that the system will be highly distributed and that considering deployment at a logical level will help you rationalize about the deployment elements at a physical level.

Logical Architecture as an Investment As well as providing a valuable stepping stone for getting from requirements to a physical architecture, the logical architecture is sometimes maintained to provide a good starting point when a technology change is anticipated. Rather than having to reinvent the wheel as a result of a technology change, you can use the original logical architecture (assuming that the system requirements have not changed) because, in general terms, the logical architecture is technology independent. The flip side of minimizing the emphasis on the logical architecture, then, is considering the logical architecture to be an investment that is immune to technology change. Therefore, it may make sense, from an investment perspective, to maintain the logical architecture in anticipation of a technology change that can support any reengineering of the system in the future. When deciding whether to regard a logical architecture as something that should be maintained moving forward, consider the following questions: ■

Is the system large and complex, and is its development likely to run over a long period? Long-duration projects are more likely to have a return on investment from investing in a logical architecture.

■

Is the system likely to evolve over several releases and potentially need to accommodate changes in technology over its lifetime? When making technology changes, often it is useful to refer to a technology-independent representation of the architecture.

How Much Logical Architecture? | 187 ■

Will the skills be available to both develop and maintain the logical architecture? An organization whose staff consists primarily of developers or programmers may not have people who have the necessary mindset to think architecturally. If the logical architecture cannot be developed or maintained because the skills are not available, the initial investment costs (of training or hiring) will be harder to justify, and building such an architecture simply may not be possible.

The Importance of Traceability Whatever approach you take, it is important to understand how work products are derived from one another, because this knowledge can help you perform an impact analysis of changing a requirement or an architecture element. The sidebar “Concept: Traceability” describes what is meant by traceability and why it is important. As the architect on the project, you need to consider the extent to which you want to describe the traceability through the development process and whether this traceability is explicit (such as adding specific modeling elements that support traceability, for example requirements realizations, described later in this chapter) or implicit (such as naming code elements based on the architecture elements that they implement).

Concept: Traceability Traceability is the mechanism by which the elements in one work product are linked to elements in the same or another work product. In terms of a development life cycle, traceability allows the architect to follow the linkage from, for example, requirements to logical architecture to physical architecture to code. Traceability allows you to perform impact analysis of changing a requirement or the potential impact of optimizing a programming algorithm in terms of its impact on the system as a whole. Both of these scenarios are supported by considering how you (explicitly or implicitly) describe traceability in the work products you create.

188 | Chapter 8 Creating the Logical Architecture

Applying the Process Tasks that support the architecture discipline vary throughout the development life cycle, as shown in Figure 8.3. The logical architecture tasks are most visible during the Elaboration phase, where you focus on baselining the software architecture. During this phase, you concentrate on analyzing those requirements that are considered to be architecturally significant (that is, those that have most influence on the architecture). During the Construction phase, you analyze any remaining requirements, but this work is not as extensive as that performed during the Elaboration phase, as most of the major system elements have already been discovered and major technical decisions made. The time you spend on logical architecture, therefore, tapers off throughout the Construction phase, as the number of requirements that you have yet to analyze decreases and the emphasis shifts to development. You may need to perform some minimal logical architecture tasks even into the Transition phase as changes to the requirements are introduced based on feedback received when transitioning the system to the user, though this situation is unlikely.

Create Logical Architecture: Activity Overview Figure 8.4 shows the tasks that comprise the Create Logical Architecture activity (introduced in Chapter 1, “Introduction”). The tasks can be summarized as follows: ■

The purpose of the Survey Architecture Assets task is to identify reusable architecture assets that can be applied to the system under development.

■

The purpose of the Define Architecture Overview task is to identify and describe the major elements of the system under development.

Inception

Phases Elaboration Construction

Incep Incep #n #1

Elab #1

Transition

Architecture Elab #n

Const #1

Const #2

Iterations Figure 8.3 Logical Architecture and Iterative Development

Const #n

Tran #1

Tran #n

Create Logical Architecture: Activity Overview | 189

An Iteration of the Create Logical Architecture Activity

Survey Architecture Assets

Define Architecture Overview

Document Architecture Decisions

Outline Functional Outline Deployment Elements Elements Verify Architecture Detail Functional Elements

Build Architecture Proof-of-Concept

Detail Deployment Elements

Validate Architecture

Update Software Review Architecture Architecture Document with Stakeholders

Figure 8.4 Overview of the Create Logical Architecture Activity

190 | Chapter 8 Creating the Logical Architecture ■

The purpose of the Document Architecture Decisions task is to capture the key decisions made in shaping the architecture and the rationale behind them.

■

The purpose of the Outline Functional Elements task is to identify the major functional elements (subsystems and components) of the system under development.

■

The purpose of the Outline Deployment Elements task is to identify the locations across which the system under development will be deployed and the nodes within each location.

■

The purpose of the Verify Architecture task is to verify that the architecture work products are consistent and to ensure that any concerns that cut across the architecture work products (a quality such as performance, for example) have been addressed consistently.

■

The purpose of the Build Architecture Proof-of-Concept task is to synthesize at least one solution (which may simply be conceptual) that satisfies the architecturally significant requirements to determine whether a solution, as envisaged by the architect, if possible.

■

The purpose of the Detail Functional Elements task is to refine the functional elements to the point that they can be handed off to detailed design.

■

The purpose of the Detail Deployment Elements task is to refine the deployment elements to the point that they can be handed off to detailed design.

■

The purpose of the Validate Architecture task is to validate that the system as a whole is going to support the various stakeholder requests.

■

The purpose of the Update Software Architecture Document is to document the architecturally significant elements in the Software Architecture Document.

■

The purpose of the Review Architecture with Stakeholders task is to obtain stakeholder agreement that the architecture, at its current level of elaboration, addresses the defined requirements.

As we did for the requirements definition activity described in Chapter 7, “Defining the Requirements,” the activity of creating a logical architecture

Create Logical Architecture: Activity Overview | 191

Concept: Outline Tasks versus Detail Tasks The tasks that focus on functional elements and deployment elements are divided into those that outline the elements and those that detail the elements. In practice, the distinction is somewhat arbitrary, and the tasks are often performed together. Understanding the difference in terms of the content of this book is worthwhile, however. In essence, the outline tasks focus on those elements that are most significant to the architecture and that would be the responsibility of the Lead Architect on the project. These tasks are where major decisions regarding the solution to non-functional requirements are made, for example. The detail tasks focus on those elements that, although important, are less significant for understanding the overall architecture of the system. Detail tasks usually are the responsibility of the architect with the relevant focus, such as the Application Architect, Infrastructure Architect, or Data Architect.

includes both outline and detail tasks. The sidebar “Concept: Outline Tasks versus Detail Tasks” describes why we advocate this approach for deriving an architecture. Table 8.1 summarizes the elements in the outline and detail tasks described in this chapter.

Table 8.1 Elements Considered in the Outline and Detail Tasks Elements

Outline

Detail

Functional

Subsystem Component Operation

Deployment

Location Node

Interface Operation signature Mapping to data Operation preconditions and postconditions Deployment unit Connection

192 | Chapter 8 Creating the Logical Architecture

Task: Survey Architecture Assets PURPOSE The purpose of this task is to identify reusable architecture assets that can be applied to the system under development. ROLES Application Architect (secondary), Data Architect (secondary), Infrastructure Architect (secondary), Lead Architect INPUTS ◆ Architecture Overview, Deployment Model, Existing IT Environment, Enterprise Architecture Principles, Functional Model

OUTPUT ◆ Architecture Decisions

STEP ◆ Survey architecture assets. ROLE OF THE ARCHITECT ◆ The architect is responsible for this task.

As discussed in Chapter 5, “Reusable Architecture Assets,” a key source of inspiration for the architect is to consider available reusable assets. One thing expert designers know not to do is to solve every problem from first principles. Rather, they reuse solutions that have worked for them in the past. When they find a good solution, they use it again and again. Such experience is part of what makes them experts. (Gamma 1995)

This task is typically performed several times in the course of an iteration, because the reuse of architecture assets is always at the forefront of an architect’s mind, as we discuss in some detail in Chapter 5, “Reusable Architecture Assets.” You may execute this task following the creation of the Architecture Overview, Functional Model, or Deployment Model work products, for example, because these work products may have identified elements that can be satisfied by an existing asset.

Step: Survey Architecture Assets An important consideration when you start to work on software architecture is reviewing what work in this area has been done before and what you could reuse within your system. Chapter 5, “Reusable Architecture Assets,” discusses

Task: Survey Architecture Assets | 193

various types of architecture assets and how these reusable elements can be categorized based on many attributes, such as their granularity and level of implementation. These attributes can provide an indication of an asset’s applicability at different stages of architectural definition. The extent of asset reuse is dependent on the context within which the architect is working. In early iterations, architects may select assets that have far-reaching effects on the architecture. A case in point is the selection of a reference architecture that defines a broad range of system elements. Architects also may choose to base their architecture on a packaged application or to reengineer a legacy system. Again, this selection has a significant bearing on the architecture. The other end of the spectrum is selecting a particular set of patterns that may be applied only to the Functional Model or Deployment Model. Such elements are typically considered in conjunction with the Outline Functional Elements and Outline Deployment Elements tasks. Other assets that may be of relevance are so-called industry vertical models such as the Insurance Application Architecture (IAA) from IBM (IAA 2009), which offers a suite of models (including data and process models) developed to help insurance companies apply information technology effectively and consistently. These models clearly have an influence on the models you create. The mandatory use of assets wherever possible may have been stated at the enterprise architecture level, in which case the Enterprise Architecture Principles work product will contain one or more principles indicating this fact. Table 8.2 shows an example of such a principle using attributes suggested by The Open Group Architecture Framework (TOGAF 2009). Given the brownfield nature of many development efforts, the existing IT environment (as documented in the Existing IT Environment work product) provides an inventory of installed applications, data, and computing and net-

Table 8.2 Example Enterprise Architecture Principle Name

Buy Rather than Build

Statement

Business applications and system components will be purchased rather than built in-house unless competitive or technical reasons to do otherwise exist. Purchasing applications and components usually leads to improved time to market together with better quality than is likely to be initially available with a new build. Purchased applications are also likely to offer a greater range of functionality. Ongoing support costs need to be factored in. Business process may need to change to support out-of-the-box functionality.

Rationale

Implications

194 | Chapter 8 Creating the Logical Architecture

work infrastructure—some or all of which may feature in the architecture of your system. (The system may already be using a particular database package, for example.) Therefore, you review the Existing IT Environment work product in this task to decide whether any of the elements described there are potential candidates for reuse in the new system. The result of surveying architecture assets and deciding which assets to use is a particular form of architecture decision and as such is captured in the Architecture Decisions work product, which is discussed in the Document Architecture Decisions task later in this chapter.

Task: Define Architecture Overview PURPOSE The purpose of this task is to identify and describe the major elements of the system under development. ROLES Application Architect (secondary), Data Architect (secondary), Infrastructure Architect (secondary), Lead Architect INPUTS ◆ Functional Requirements, Enterprise Architecture Principles, Glossary, Non-Functional Requirements, System Context

OUTPUT ◆ Architecture Overview

STEP ◆ Define architecture overview. ROLE OF THE ARCHITECT ◆ The architect is responsible for this task.

The Architecture Overview provides a high-level description of the system under development. The Architecture Overview is not meant to be a full specification for the architecture from which a system could be built; it is intended more for information purposes to obtain early consensus and understanding with the system stakeholders and the development team. Very often, something equivalent to an Architecture Overview was developed during earlier phases of the project (when the initial vision was described, for example, or when requests for information were being sent out to vendors). In this case, at the very least you should refer to these diagrams to ensure continuity and traceability back to the initial vision.

Task: Define Architecture Overview | 195

Step: Define Architecture Overview The Architecture Overview may touch on several architectural views but tends to focus on the functional view and deployment view in conveying the major building blocks of the solution. Other views may be provided, such as systems management and security, if particular concerns need to be addressed and clarified at this stage. It also conveys early working assumptions about the solution and is often treated as an informal sketch of the system to be. Subsequent tasks (discussed later in this chapter) result in the creation of the more rigorous and more precise work products, such as the Functional Model and Deployment Model. The Architecture Overview usually is structural in nature and tends to show boxes and lines, with the lines indicating dependencies rather than interactions among the various elements. If certain interactions are fundamental to the architecture of the system, these interactions should be shown, of course. Therefore, several diagrams may actually comprise the Architecture Overview, with different diagrams representing different views and stakeholder concerns. Although we do not recommend a formal notation for describing the Architecture Overview, we do recommend that whatever notation is used, it be explained (with a key) and applied consistently so that, for example, a line with an open-ended arrow means the same thing wherever it is used. This practice not only aids understanding, but also enables stakeholders to quickly grasp the key ideas that are being described by the overview. The Architecture Overview typically includes a number of notational “styles” and often contains boxes indicating groupings of functionality as “components” or “subsystems” and lines separating these boxes that indicate “layers” or “tiers.” Subsystems, components, layers, and tiers are all terms that are used when describing architectures and can sometimes have different meanings. The sidebars “Concept: Subsystem and Component” and “Concept: Tiers and Layers” describe the meanings of these terms used in this book. Where required, the Architecture Overview should reflect any principles as captured in the Enterprise Architecture Principles work product. Typical principles that may apply are ■

■

■

■

Reuse. This principle implies that existing components must be reused where applicable. Buy rather than build. This principle is discussed in Table 8.2 earlier in this chapter. Single point of view. This principle implies combining multiple data sources to make it appear as though the relevant data has a single source. Separation of concerns. This principle implies that components should responsible for a cohesive set of business-focused tasks.

196 | Chapter 8 Creating the Logical Architecture

Finally, although this task represents a less formal approach to defining a candidate architecture than the tasks that follow, it acknowledges all significant requirements, both functional and non-functional. In terms of non-functional requirements in particular, it represents an initial consideration in addressing some of the qualities required of the system. It also accommodates any constraints specified in the requirements, such as constraints imposed by any existing environment (as in the need to deploy the system in an existing network), constraints imposed through the use of external systems (such as integration with a legacy system), and constraints imposed on the use of defined commercial off-the-shelf (COTS) software. Figure 8.5 shows the Architecture Overview for the YourTour system. This overview has been derived by reviewing the System Context to understand what the boundary of the YourTour system is, the Functional Requirements to understand what the major functional areas of the system need to be, and the Non-Functional Requirements to understand what qualities need to be addressed and what constraints need to be complied with. Terms used in these work products should all be collected in the Glossary.

Tour Organizer

[T] Session, Cart

Presentation Integration

[R/W] Tours, Bookings

Tour Process Control

Tour Services

CRM System Application Integration Payment Engine

Customer Content Management Sales Clerk

[R] Rules

Key: [T] Transient Data [R] Read-Only Data [R/W] Read/Write Data

Security Services Reservation System

[R/W] Content

[R/W] Web Pages

Figure 8.5 Architecture Overview for YourTour

[R/W] Users, Operators

Task: Define Architecture Overview | 197

Concept: Subsystem and Component A subsystem is a set of related components. In business systems, components usually are grouped because they collectively support a major business area such as customer relationship management or account processing. Subsystems may also be nested, and this topic is discussed in more detail in Chapter 10, “Beyond the Basics,” where we discuss systems of systems. [A component is] a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a type, whose conformance is defined by these provided and required interfaces (encompassing both their static as well as dynamic semantics). (UML 2.0 2003)

We used the following approach when coming up with the Architecture Overview in Figure 8.5: ■

The Presentation Integration subsystem decouples the user interface devices (web browser on a computer, mobile device, and so on) from the business functions and performs a translation from generic business services to user interface–specific protocols.

■

We believe that the effective management of content is important for providing users access to information that enhances their overall experience of YourTour, such as travel insurance offerings. This content has suggested the inclusion of a dedicated Content Management subsystem to create, edit, manage, search, and publish the various kinds of digital content (that is, images, audio files, video files, electronic documents, and web content) that will be used by YourTour.

■

To facilitate effective decoupling of user interactions from YourTour business functions, we provide a separate process-control subsystem (Tour Process Control) that is responsible for controlling the execution of any business processing logic and that allows the business process to be changed independently of both the user interface and business services (which are in the Tour Services subsystem).

198 | Chapter 8 Creating the Logical Architecture ■

Security is important, as the system is dealing with personal payment details such as credit card information and other personal details. Therefore, a dedicated Security Services subsystem is required for dealing with user authentication and authorization.

■

We want to be able to decouple the YourTour application from the intricacies of the legacy systems, so we added a dedicated Application Integration subsystem for dealing with these interactions.

■

Finally, we drew point-to-point connections between the subsystems we identified based on known (dictated by any patterns we have adopted) or obvious interactions. This initial set of point-to-point connections will be refined as the architecture evolves.

Concept: Tiers and Layers In addition to the concepts of subsystem and component, two concepts related to the structural decomposition of a system are tier and layer. On occasion, these concepts are shown in an Architecture Overview. A tier is used in multitier architectures where each tier represents a related grouping of processing logic. As an example, typical three-tier architectures are often divided into presentation logic, business logic, and integration logic. A tier represents a physical separation of concerns but to some extent is also a logical partitioning, because the tiers can be physically distributed in different ways: ■

In a single system distribution, the presentation, business, and integration tiers all reside on the same physical machine.

■

In a thin-client distribution, the presentation tier is on the client, but the business and integration tiers reside on the server.

■

In a thick-client distribution, the presentation and business tiers reside on the client, but the integration tier resides on the server.

Layers are sometimes confused with tiers, but they are not the same thing. Whereas tiers are abstractions of physical elements, layers are much more general, and the concept of layering a system conforms to the Layers architectural pattern, as described in Pattern-Oriented Software Architecture: A System of Patterns (Buschmann 1996) and elsewhere. In brief, the Layers pattern places components within layers according to their generality, with

Task: Define Architecture Overview | 199

the more general-purpose components (that is, the most reusable components) in lower layers. In simple terms, the components in any given layer may use the services of components in the same layer or in lower layers. Layering is said to be strict if components can communicate only with components in the same layer or the layer immediately below it and non-strict if components can communicate with components in the same layer or any lower layer. Either way, a component should never communicate with components in higher layers, as this situation makes the component less reusable. Also, it is difficult to switch the component with another that provides the same interface, for example. Figure 8.6 shows one example of a layering approach derived from a layering given in Software Reuse: Architecture, Process and Organization for Business Success (Jacobson 1997). The responsibility of each layer is as follows: ■

The Application-Specific layer contains elements that are specific to the application in question. The figure implies many applications.

■

The Business-Specific layer contains elements that are specific to a business or application domain (such as financial systems) but that are reusable across applications.

■

The Business-Independent layer contains elements that are independent of the business or application domain (such as a user interface framework, message bus, operating system, or database).

Application-Specific Business-Specific Business-Independent

Figure 8.6 Example of Layers

200 | Chapter 8 Creating the Logical Architecture

Task: Document Architecture Decisions PURPOSE The purpose of this task is to capture the key decisions made in shaping the architecture and the rationale behind them. ROLES Application Architect (secondary), Data Architect (secondary), Infrastructure Architect (secondary), Lead Architect INPUTS ◆ All architecture-related work products, RAID Log

OUTPUT ◆ Architecture Decisions

STEPS ◆ Capture issue or problem. ◆ Assess options. ◆ Select preferred option. ◆ Document decision. ROLE OF THE ARCHITECT ◆ The architect is responsible for this task.

To truly understand the architecture of an IT system, it’s very important to understand the decisions that have shaped the architecture and the rationale for those decisions. Some decisions are captured explicitly in the various work products (such as the fact that a component is deployed on a particular node). Usually, however, several implicit decisions have been made, and these decisions have had equally significant impact on the overall shape of the system but are known only to the person who made the decision. The purpose of capturing architecture decisions, therefore, is to make explicit what’s in the mind of the architect and to ensure that: ■

Decisions have been documented so that stakeholders can understand why the architecture is the way it is.

■

Decisions are realistic and based on a real business need rather than being purely technology-driven.

■

The rationale used in arriving at the decision is evident and can be reviewed and critiqued by others (including internal and external auditors, if required).

Task: Document Architecture Decisions | 201 ■

The options that are being considered represent a valid and reasonable set.

■

The architect does not have to reinvent the wheel by covering old ground to justify a long-forgotten decision.

Formally capturing architecture decisions normally is confined to those key decisions that have shaped the architecture, so a spectrum of formality is considered. Even in the simplest architectures, however, several key decisions usually have shaped the architecture, and these decisions are not obvious to those who must understand or maintain the system. Explicitly documenting such decisions, therefore, is a valuable exercise. Some decisions are time-sensitive and may have a life span that is less than that of the project within which they are set. A decision may be made that is short-term and tactical to move the project forward but that needs to be revisited before the system goes live. In this case, a note must be made against the decision that it needs to be reviewed by a given date. Conversely, some decisions are fundamental and may actually outlive the project that generated them, as they are applicable to other system development projects within the enterprise. Such decisions are elevated to the status of architecture principles that are adopted at the enterprise architecture level. For a more detailed discussion of architectural decisions, as well as a template for documenting architecture decisions, refer to the paper “Architecture Decisions: Demystifying Architecture” (Tyree 2005).

Step: Capture Issue or Problem An architectural decision usually is made because an issue or problem has been identified that needs to be addressed. Issues usually are captured in the RAID Log work product or may have been communicated by stakeholders or project members verbally or via e-mail. Similarly, certain concerns are formally expressed as risks, also in the RAID Log. As a first step in documenting an architecture decision, it is helpful to capture, clearly and unambiguously, the issue or problem that needs to be considered. This documentation may be a simple sentence stating the issue, or it may need to be a longer statement to describe a lot of history or context. It is worthwhile to give some thought to this step so that there is no doubt about what is being addressed.

Step: Assess Options In this step, you decide what options you have to address the issue or risk. This step may involve looking at patterns (to see how similar problems have been solved), researching products and packages from vendors (if the problem could

202 | Chapter 8 Creating the Logical Architecture

be addressed by procuring a product or package), or brainstorming alternative approaches (if the problem involves a new or challenging area).

Step: Select Preferred Option In this step, you assess each option and decide which one to adopt. You may need to consider several questions when deciding which option to select: ■

Do any functional requirements, qualities, or constraints suggest one option over another? Is cost or the project schedule an important factor, for example?

■

Do you need to adhere to any principles, policies, or guidelines, such as enterprise-wide policies?

■

Are some options more risky to adopt than others? Do they use new or unproven technology, for example, and if so, how willing is the project or organization to take risks?

■

Are the options tactical or strategic? Might some options produce tactical short-term gains whereas others are longer-term and strategically significant? You may be able to support a short-term improvement in the performance of a system by adding more resources to existing machines (that is, adopt vertical scalability) by adding processors, but in the long term, it may be better to add machines (that is, adopt horizontal scalability).

■

Is there actually more than one option that could apply? Sometimes, your decision may not be a case of simply selecting one option. Both short-term (tactical) and long-term (strategic) options may be applicable.

■

Do some decisions have dependencies, either on other decisions or on the result of some prototyping work being performed to validate the decision? If such dependencies exist, you should note the situation.

Step: Document Decision When the decision has been made, the initial problem statement, the options considered, the decision, and the rationale that led to the decision are all captured in the Architecture Decisions work product. Table 8.3 shows an example from the Architecture Decisions work product from the YourTour system.

Task: Document Architecture Decisions | 203

Table 8.3 Example of a Documented Architecture Decision Issue

YourTour will use a small number of business rules (probably fewer than 50) that will need to be updated periodically. The intent is to allow these rules to be updated by business users rather than developers. The rules will be used to check certain conditions (such as whether a customer qualifies for a discount based on previous bookings) or for performing calculations (such as calculating the overall cost of a tour, including any taxes and surcharges).

Architecture Decision

Develop a custom rules engine component rather than using a packaged solution or rules placed inline in code.

Assumptions

The number of business rules to be managed is relatively small (fewer than 50) and will change relatively infrequently (less than twice per year).

Alternatives

Option 1: Embed rules inline in code. Option 2: Develop a custom rules-engine component. Option 3: Purchase a rules-engine package.

Option Chosen

Option 2

Justification

Embedding rules inline in code is bad practice, as it does not follow the software engineering principle of separating concerns and makes rules difficult to maintain. Purchasing a rules-engine package would not be cost-effective, given that the number of rules to be managed is small and the likely change rate is infrequent.

204 | Chapter 8 Creating the Logical Architecture

Task: Outline Functional Elements PURPOSE The purpose of this task is to identify the major functional elements (subsystems and components) of the system under development. ROLES Application Architect, Data Architect (secondary), Infrastructure Architect (secondary) INPUTS ◆ Architecture Decisions, Architecture Overview, Architecture Proof-of-Concept (optional), Business Entity Model, Business Rules, Enterprise Architecture Principles, Existing IT Environment (optional), Functional Requirements, Glossary, NonFunctional Requirements, Prioritized Requirements List

OUTPUT ◆ Functional Model

STEPS ◆ Identify subsystems. ◆ Identify components. ROLE OF THE ARCHITECT ◆ The architect is responsible for this task.

This task focuses on identifying the functional elements (subsystems and components) of the architecture and ensuring that the resulting set of subsystems and components conforms to solid architecture principles. In this book, we use the term component to represent a main building block of the system. We should point out that components, as defined in this book, are not just technical software elements (such as Enterprise JavaBeans), but also are used in a more general sense to represent the architectural elements that make up the system. See the sidebar “Concept: Subsystem and Component” earlier in this chapter for the definitions we are using. When this task is complete, several well-structured, logical subsystems and components will have been defined, together with their relationships and responsibilities. The subsystems and components may be defined in a modeling tool (such as a tool that supports the creation of UML models) or may simply be drawings in a document. When naming functional elements, we use any relevant terms defined in the Glossary.

Task: Outline Functional Elements | 205

Step: Identify Subsystems The initial set of subsystems can be derived from the Architecture Overview work product. Figure 8.7 is an example of a UML component diagram showing the logical subsystems and their dependencies for the YourTour system—the highest-level view of the YourTour architecture. Each of these subsystems contains one or more components that collaborate to support the functionality required by the system. We derived the content of Figure 8.7 by simply transposing the informal notation of the Architecture Overview into UML. As a technique for identifying subsystems, this technique is as good as any. Had we not had an Architecture Overview at the level of detail we developed for YourTour, we would have had to apply some of the following techniques for identifying subsystems: ■

Review the Functional Requirements work product, and look for requirements that are either already grouped or that could be. Requirements that deal with all aspects of customer management might suggest a customer relationship management subsystem, for example.

■

Review the Enterprise Architecture Principles, Non-Functional Requirements, and Existing IT Environment work products to see whether any constraints suggest particular technologies (application servers, message brokers, systems management support, transaction handlers, and so on). At this level of the architecture, these technologies can be identified as separate subsystems.

■

Review the Business Entity Model, and look for groupings of related business entities that might be managed by a group of related components. Grouping the entities that deal with tours suggests a Tour Services subsystem, for example.

«subsystem» Presentation Integration

«use»

«subsystem» Tour Process Control

«use»

«use»

«subsystem» Content Management

«use»

Figure 8.7 YourTour Logical Subsystems

«use»

«subsystem» Tour Services

«use»

«subsystem» Security Services

«use»

«subsystem» Application Integration

«use»

206 | Chapter 8 Creating the Logical Architecture

Step: Identify Components When describing the logical architecture, we identify the components, their responsibilities, and the collaborations among them—all driven by the stated requirements (logical architecture components are described in the sidebar “Concept: Characterizing Logical Architecture Components”). This approach was made popular through the CRC (Classes-Responsibilities-Collaborations) technique devised by Rebecca Wirfs-Brock (Wirfs-Brock 1990). Based on that technique, we consider the following for each component: ■

What the component knows (the data it owns or manages)

■

What the component does (the behavior it exhibits)

■

What the component asks other components to do on its behalf (that is, the components it needs to collaborate with to perform some function)

Identification of components is based on an analysis of the Business Entity Model, Functional Requirements, Non-Functional Requirements, Business Rules, Existing IT Environment, and Architecture Decisions work products. Each of these work products is considered in the following discussion, which describes how they were used to develop the Functional Model for the YourTour system. Although we discuss these work products in a particular sequence, in practice we would tend to consider them and any associated techniques together. In addition, we would consider any Architecture Proof-of-Concept that had been created.

Concept: Characterizing Logical Architecture Components A logical architecture encompasses different aspects of the system, as reflected in the different types of components. In many situations, considering three types of components (Jacobson 1992) can help you “divide and conquer” your work during the development of a logical architecture: ■

Boundary (or presentation) components. These components support the boundary between the system and items outside the system with which the system interacts, such as end users or external systems. Boundary components typically invoke Control components.

■

Control (or execution) components. These components support the control logic of the system as well as the business rules and other logic required to satisfy the functional requirements. Control components

Task: Outline Functional Elements | 207

typically invoke Boundary components, Entity components, and other Control components. ■

Entity (or data) components. These components support the representation of persistent information. Entity components typically invoke other Entity components.

When representing these different types of components in UML, you may also choose to use a UML profile that includes stereotypes for each. The notation used is shown in Table 8.4.

Table 8.4 Component Types Used in the Logical Architecture Component Type

UML Representation

Boundary

Boundary components represent the boundary between the system and its environment.

Control

Control components represent the control and coordination logic of the system.

Entity

Entity components encapsulate the information represented in the system.

Description

Business Entity Model A Business Entity Model can be used to identify components by clustering related entities and then assigning a managing component for each cluster. Figure 8.8 shows a subset of elements from the Business Entity Model of the YourTour case study—those that manage tour-related information. The entities Tour, Tour Category, and Tour Location are grouped in the figure and assigned to the Tour Manager component that manages these entities. You can say, therefore, that one of the responsibilities of Tour Manager is to manage the data related to a tour. Other responsibilities may be assigned to Tour Manager as the architect does further analysis of the requirements and deter-

208 | Chapter 8 Creating the Logical Architecture

Business Entity Model (extract)

Tour Location name from date to date description

1..*

1

Tour reference name capacity is public description margin tour leader

*

*

Tour Category name *

- parent 0..1

- child

«Entity» Tour Manager

Figure 8.8 Identifying Components from a Business Entity Model

mines what additional processing the Tour Manager component must support to contribute to meeting the functional requirements. The Tour Manager component resides in the Tour Services subsystem.

Functional Requirements Analysis of the architecturally significant Functional Requirements is one of the most robust ways of identifying components. Assuming that use cases are your primary means of capturing functional requirements, you can analyze them to identify components, focusing on the highest-priority use cases first. The prioritized requirements are determined from the Prioritized Requirements List, as discussed in Chapter 7, “Defining the Requirements.” This discussion uses the Book Tour use case as an example. The context of the Book Tour use case is shown in Figure 8.9 (which is reproduced from Figure 7.7 in Chapter 7). Table 8.5 (which is reproduced from Table 7.10 in Chapter 7) shows the main flow of events of the Book Tour use case. When analyzing use cases in this manner, you may consider only a subset of the flows of events, depending on the objectives of the current iteration. This example considers only the main flow of events in the Book Tour use case.

Task: Outline Functional Elements | 209

Payment Engine

Book Tour Tour Booker

Reservation System

Customer

Sales Clerk

Figure 8.9 The Context of the Book Tour Use Case

Table 8.5 Main Flow of Events of the Book Tour Use Case Name

Book Tour

Main Flow

1. The use case starts when the Tour Booker opts to book one or more Tour Participants on a Tour. 2. The Tour Booker identifies the Tour to be booked. 3. The Tour Booker identifies each Tour Participant for the Tour. 4. For each Tour Participant, the Tour Booker specifies the preferred accommodation and transportation options. 5. The Tour Booker provides Payment Details. Accommodation and transportation reservations are made through the Reservation System, and payment is made through the Payment Engine. 6. The Tour Booker receives a unique reference as confirmation of the Booking. 7. The use case ends.

210 | Chapter 8 Creating the Logical Architecture

When identifying logical components (and their responsibilities) by using the functional requirements, you proceed as follows: 1. Define an interface (boundary) component that will handle requests from, and send responses to, the primary actor of the use case. For the use case Book Tour, you would define a Tour Booker interface component. 2. Where an external system needs to be invoked to get or send data, create a boundary component that deals with the interface to that system. For the Book Tour use case, you would define a Reservation System boundary component for dealing with the external reservation system and a Payment Engine boundary component for dealing with the payment system. 3. Define a controller component with the same name as the use case that will handle overall control of that use case. For the Book Tour use case, you would create a Book Tour controller component that is responsible for execution of the Book Tour use case. 4. For each step in the use case that requires an actor to system interaction, assign a responsibility to the controller component to manage that interaction. For the Book Tour use case, you would assign responsibilities for obtaining a list of valid tours and selecting the appropriate tour, adding participants to a tour, adding travel options for each participant, and obtaining payment details (which results in accommodation and transportation reservations being placed). 5. Some steps imply use of data, often indicated by the nouns in the use case (Tour,Tour Booking, and so on). For such data elements, create an entity component that is responsible for managing related data.The Book Tour use case needs a Tour Manager entity component to manage tour data and a Tour Booking Manager entity component to manage tour booking data. 6. Repeat steps 1 through 5 for each use-case flow of events being considered in the current iteration. As you do, you may identify new components or add responsibilities to an existing component. The result of applying these steps to the Book Tour use case is shown in Figure 8.10. The dependencies among elements are also derived from the usecase flow of events. These components are related to the subsystems identified earlier in this chapter, as follows: ■

■

The Tour Booker Boundary component resides in the Presentation Integration subsystem. The Payment Engine Boundary and Reservation System Boundary components reside in the Application Integration subsystem.

Task: Outline Functional Elements | 211

Tour Booker

Payment Engine

«Boundary» Tour Booker Boundary

Reservation System

«Boundary» Payment Engine Boundary

get tours ( ) select tour ( ) add tour participant ( ) add tour participant options ( ) book tour ( )

«Boundary» Reservation System Boundary

process payment ( )

make reservations ( )

«Control» Book Tour Controller get tours ( ) select tour ( ) add tour participant ( ) add tour participant options ( ) book tour ( )

«Entity» Tour Manager get tours ( )

«Entity» Tour Booking Manager provide payment details ( ) create tour booking ( ) add tour participant ( ) add tour participant options ( )

Figure 8.10 Components Derived from the Book Tour Use Case

■

■

The Book Tour Controller component resides in the Tour Process Control subsystem. The Tour Manager and Tour Booking Manager components reside in the Tour Services subsystem.

Components usually are allocated to subsystems because they are functionally related and therefore create a cohesive subsystem (the reason for grouping

212 | Chapter 8 Creating the Logical Architecture

Tour Manager and Tour Booking Manager) or because they are technically related and create a subsystem that is likely to be deployed to the same run-time platform (the reason for allocating controller, system interfaces, and user interface components together). You can derive additional responsibilities on components by explicitly modeling the interactions between components to realize the flows of events in each use case. The result is the assignment of responsibilities to the components that respond to a particular message. Figure 8.11 is a sequence diagram for the main flow of the Book Tour use case, showing how the components collaborate to satisfy the use-case description in Table 8.5 earlier in this chapter. It is also good practice to ensure components can be traced back to the requirements from which they are originated. The sidebar “Best Practice: Trace Solution Elements to Requirements” shows one way of doing this using the UML. We should emphasize that this approach will result in a first cut at identifying components and their responsibilities. Components may need to be refactored several times to ensure that they are well architected. Although there is no definitive measure of what makes a well-architected component, adhering to the principles of high cohesion and loose coupling, and also ensuring that components are defined at the correct level of granularity (as discussed in the sidebar “Concept: Component Quality Metrics”) are both ways of ensuring that components are well architected.

Non-Functional Requirements Consideration of functional requirements in such a rigorous manner is only half the picture, so it’s surprising how many development methods stop there. This often results in systems that are functionally correct but that fail to provide the required qualities. Another source that helps shape architects’ understanding of the required components and their associated characteristics is the system’s non-functional requirements, as captured in the Non-Functional Requirements work product. In this section, we consider both the desired qualities that the system must exhibit (such as performance and availability) and any constraints (such as mandated technologies, the use of third-party components, and the use of existing legacy systems) that the system must accommodate. Such considerations may result in the identification of new components. The YourTour system has a testability requirement—“The system will allow the content of any transactions to be logged in order to allow all transactions and their payload to be validated”—that results in a transaction logging component being identified and added to the Tour Services subsystem. Similarly, the YourTour system has an integration constraint—“The YourTour system will make use of YourTour’s existing customer relationship management (CRM) system for storing customer information.” This constraint results in a component being

:Tour Booker Boundary

:Tour Booker

:Book Tour Controller

:Tour Manager

:Tour Booking Manager

:Payment Engine Boundary

:Reservation System Boundary

1: get tours 1.1: get tours 1.1.1: get tours

2: select tour 2.1: select tour 2.1.1: create tour booking

loop

1: add tour participant

[0,*]

1.1: add tour participant 1.1.1: add tour participant

loop [0,*]

1: add tour participant options 1.1: add tour participant options 1.1.1: add tour participant options

3.1: book tour 3.1.1: provide payment details

3.1.2: process payment

3.1.3: make reservations

Figure 8.11 UML Sequence Diagram for the Book Tour Use Case (Main Flow)

Task: Outline Functional Elements | 213

3: book tour

214 | Chapter 8 Creating the Logical Architecture

Best Practice: Trace Solution Elements to Requirements When considering the requirements and how they are satisfied in the solution, often it is beneficial to trace the solution explicitly back to the requirements they address. This traceability can help you determine the impact of changing the requirement. Figure 8.12 shows the concept of a requirement realization that shows this traceability. A requirement realization is a stereotyped UML collaboration that simply indicates which solution elements collaborate to satisfy a particular requirement. In Figure 8.12 the solution elements that realize the Book Tour use case are those contained in the Participants UML component diagram and which interact as shown in the Main Flow of Events UML sequence diagram. References to these diagrams are shown as UML notes in Figure 8.12. By convention, the requirement realization has the same name as the requirement it realizes. The concept of a requirement realization can also be applied to the realization of non-functional requirements, as described in the following section. In addition, a requirement realization may refer to diagrams that show deployment elements (rather than functional elements) and how they, too, realize functional and non-functional requirements. Tracing from the solution back to the requirements (functional and nonfunctional) can be time-consuming to set up and maintain. On relatively small projects, it may be possible to develop a simple form of traceability using a spreadsheet. The traceability defined with this approach can be difficult to maintain, however. A better solution, which is certainly applicable for large or complex projects, is to use appropriate development tools that provide explicit support for tracing between solution elements and the requirements they realize and for maintaining this information.

Participants «Requirement Realization» Book Tour Book Tour

Main Flow of Events

Figure 8.12 Requirement Realization for the Book Tour Use Case

Task: Outline Functional Elements | 215

Concept: Component Quality Metrics The software quality metrics of coupling and cohesion, as applied to computer programs, were first proposed by W. P. Stevens (Stevens 1974) as a way of reducing the maintenance and modification costs of software. Cohesion is a measure of how well the responsibilities that are attributed to the component are related to one another. High cohesion (a component with a set of closely related responsibilities) is considered to be good; low cohesion (a component with a set of poor or unrelated responsibilities) is considered to be bad. High cohesion is good because it makes the architecture easier to understand. Maintenance is also likely to be easier, as changes will be localized to a single component rather than being spread throughout the system. Also, components are more reusable if they exhibit high cohesion because it is more likely that a functionally related set of responsibilities will be used as a whole than if a random set of responsibilities were provided by a component. Coupling is related to cohesion; it is an indication of the strength of the associations between components. Strongly coupled components have tightly bound associations, and the components are highly dependent on one another. Weakly coupled components, however, have very loose (or even non-existent) associations. Weak (or loose) coupling is better than strong (or tight) coupling because it is easier to switch one component for another or to update a component without affecting others. Weakly coupled components are likely to be more reusable than strongly coupled components because, by definition, they can be extracted from one system and inserted into another more easily. Granularity is anaother quality metric, is a measure of the size or amount of functionality assigned to a component. The architect needs to understand the context within which a component exists before making an assessment of the granularity of the component. At one extreme, the system as a whole may be represented as a single component and, in the context of the business processes that it supports, may be wholly appropriate. At the other extreme, the system may consist of many fine-grained components, and again, this may be appropriate in a given context. An interesting discussion of the different levels of granularity in which components may exist is given in Business Component Factory (Herzum 2000). This book discusses not only simple utility components, but also components that are designed to support a distributed environment as well as all-encompassing business components whose elements span the different tiers of a distributed environment.

216 | Chapter 8 Creating the Logical Architecture

added to manage the interface with the CRM system that is added to the Application Integration subsystem. Figure 8.13 shows the components identified as a result of these examples. Consideration of non-functional requirements may not only result in the identification of new components, but also lead you to refine components by indicating that certain qualities may be addressed by a particular component (or, more likely, a group of components), and you may refine the component specification accordingly. Specifically, you may derive the non-functional requirements that apply to a particular component. To do so, you look at each non-functional requirement in turn and, based on the components that have been identified, allocate requirements across them. An example is given in Table 8.6. If you are using UML to capture this additional information, it is appropriate to create a UML profile that allows this additional information to be captured. A UML profile is an extension mechanism that allows, among other things, additional properties to be allocated to standard UML modeling elements (based on the application of UML stereotypes). When allocating non-functional requirements to components, take care that each component is capable of supporting the stated requirements, especially when the component may depend on an external service to fulfill its

«Entity» Transaction Log

«Boundary» CRM System Boundary

Figure 8.13 Components Derived from the YourTour Non-Functional Requirements

Table 8.6 Assigning Non-Functional Requirements to Components Budgeted Requirement

Requirement

Component

Operation

Booking a tour must take less than 10 seconds, from the time the request is submitted to the confirmation of the booking being presented to the user.

Tour Booking Manager Payment Engine Boundary Reservation System Boundary

provide payment details() process payment()

1 second

make reservations()

6 seconds

3 seconds

Task: Outline Functional Elements | 217

responsibility. In Table 8.6, the three-second requirement for processing the payment is dependent on the ability of the Payment Engine (an external system over which you may not have control) to complete its processing within that time. The architect needs to understand what organizational or even commercial agreements are in place to manage and monitor this situation. Architecting a solution to meet potentially conflicting non-functional requirements involves resolving opposing forces, as discussed in Chapter 2, “Architecture, Architect, Architecting.” Often, two or more solutions exist, each with their pros and cons in terms of cost, feasibility, and so on. When considering which option to take, it is helpful to use the Architecture Decisions work product to capture all the options and the rationale behind the chosen approach.

Business Rules Consideration of business rules, as captured in the Business Rules work product, may also result in components being identified. In the YourTour system, several rules relate to the management of tours and how they are booked. It is reasonable to assume that these rules may change over time, and so you may choose to separate the rules into a rules component, which you place inside the Tour Services subsystem. Then all components inside that subsystem use the rules component to access the current rules, as shown in Figure 8.14. For a discussion of the placement and representation of business rules, see the sidebar “Concept: Placement and Representation of Business Rules.”

Responsible for rules related to the management and booking of tours. «Entity» Tour Manager «Entity» Tour Rules «Entity» Tour Booking Manager

Figure 8.14 YourTour Business Rules Component

218 | Chapter 8 Creating the Logical Architecture

Concept: Placement and Representation of Business Rules Placement of business rules can be facilitated by considering the following questions: ■

Is the business rule likely to change frequently? The answer dictates how much flexibility needs to be provided for updating the business rule. A business rule that is likely to change frequently is best assigned to a component that is dedicated to implementing that business rule.

■

Does the business rule apply in many scenarios, or is it specific to a particular use? The answer dictates which component, or set of components, the rule gets assigned to. A business rule that needs to be reused in many scenarios is best assigned to a separate component that is invoked accordingly. A business rule that is used in only one scenario is best placed with the component that requires this business rule to execute.

■

Does the user of the application need to have visibility of the business rules? If so, you may need to allow aspects of the business rule to be made visible in the user interface. In a loan application, for example, the basis on which a loan is given may be provided to the end user (the requester must be over 18 years of age, for example). Similarly, a system administrator may require the ability to change business rules, which requires an interface to access the business-rule definitions to allow such changes to be performed.

■

Where does the data used by the business rule reside? The answer dictates where the components that handle the business rule need to be located in relation to the data that the rules need as input. This consideration is particularly important in a distributed system, where network latency has a major impact on the performance of the system.

■

Is the business rule likely to have an impact on system performance? Sometimes business rules have a hidden or unexpected impact on system performance, and you should consider this impact when placing rules. A rule to determine a person’s creditworthiness, for example, might review that person’s credit history for the past two years. A regulatory change may cause the check to be done over ten years, and suddenly the performance of the system is affected because the credit engine is doing five times as much work.

Task: Outline Functional Elements | 219

■

What middleware components are available, or are being mandated, to manage business rules? If a rules engine is being proposed as part of the system, you can represent the engine as a separate component. (The specific rules engine itself will be selected when the physical architecture is defined.) A rules engine generally provides the ability to define, manage, and run business rules, and almost certainly mandates where and how to place such rules.

Two of the key objectives in placing business rules on components should be to keep the business logic in one place (to support ease of maintenance) and, as far as possible, to prevent it from being duplicated in different parts of the system. It is not always possible to achieve this ideal, given other system characteristics. In a client–server environment, for example, business logic may be distributed between the client (such as field-level validation of data) and the server (such as business processing logic). In terms of representing business rules, you have several options in the logical architecture: ■

Business rules may be specified as algorithms that calculate results or manipulate or check data in some way. The rule Validate Credit Card Number would apply the standard algorithms issued by credit card agencies to check whether a credit card has the right form.

■

Business rules may be specified as relationships between components, such as “An order must have one or more line items.”

■

Business rules may be specified as invariants or constraints on the data managed by a component, such as “An order number has to be eight characters in length.”

■

Business rules may be specified as preconditions and postconditions on an operation signature, such as “An order amount must be less than $200.”

A discussion of principles that apply specifically to business rules is given in Business Rules Applied (von Halle 2001). These principles are referred to as the STEP principles (Separation, Trace, Externalize, and Position). The principles refer to the separation of rules from other components, externalization of business rules, traceability of rules to their origin, and positioning rules for change.

220 | Chapter 8 Creating the Logical Architecture

Architecture Decisions Architecture decisions (as documented in the Architecture Decisions work product) capture important decisions that have been made and that may dictate key structural and relational aspects of the architecture. Architecture decisions may identify a particular product or package that needs to form part of the architecture and therefore influences the components being identified. You may have decided to use a particular security component provided by an external vendor, for example. You should also acknowledge any reusable assets that may have been selected, as discussed in the Survey Architecture Assets task. Confusion can exist about where or how to represent existing components in a logical architecture. Although it is important to capture the fact that an existing (physical-level) element is to be used, it is equally important not to confuse logical- and physical-level elements in the same model. The recommended approach in this case is to abstract the physical-level element for the purpose of representing it in a logical manner while at the same time making a note that the actual implementation of this component has already been decided. Suppose that a decision has been made that the Acme Message Broker will be used as the messaging bus. To represent this decision in a logical Functional Model, you could abstract it to a component called Message Bus and make a note that the implementation will be the Acme Message Broker. Along with all the other components exemplified thus far, the Message Bus component is shown in Figure 8.15, together with the layers that comprise the YourTour architecture, which are derived from the layering given in Software Reuse: Architecture, Process and Organization for Business Success (Jacobson 1997) and discussed in the earlier sidebar “Concept: Tiers and Layers.” You can also show the subsystems that contain these components in a similar diagram, if required.

Task: Outline Functional Elements | 221

Application-Specific «Boundary» Tour Booker Boundary

«Control» Book Tour Controller

«Entity» Tour Manager

«Entity» Tour Booking Manager

«Entity» Tour Rules

Business-Specific «Boundary» Payment Engine Boundary

«Boundary» CRM System Boundary

«Boundary» Reservation System Boundary

Business-Independent «Entity» Transaction Log

Figure 8.15 YourTour Components Aligned with Layers

«Entity» Message Bus

ACME messaging bus

222 | Chapter 8 Creating the Logical Architecture

Task: Outline Deployment Elements PURPOSE The purpose of this task is to identify the locations across which the system under development will be deployed and the nodes within each location. ROLES Application Architect (secondary), Data Architect (secondary), Infrastructure Architect INPUTS ◆ Architecture Decisions (optional), Architecture Overview, Architecture Proof-ofConcept (optional), Enterprise Architecture Principles, Existing IT Environment (optional), Functional Model, Functional Requirements, Glossary, Non-Functional Requirements, System Context

OUTPUT ◆ Deployment Model

STEPS ◆ Identify locations. ◆ Identify nodes. ROLE OF THE ARCHITECT ◆ The architect is responsible for this task.

Any moderately complex IT system architecture consists of several disparate computer platforms (end-user desktops, midrange servers, mainframe computers, web and application servers, database servers, and so on) that typically are distributed across one or more locations. These locations may simply be different rooms or floors in the same building or different buildings at a single site, or they may be geographically distributed sites around the country or even the world. The challenge, then, is to decide what computer platforms need to be used and which locations they should be placed in. The purpose of this task is to identify the locations across which the computer platforms will be distributed and the computer platforms themselves on which the components will be placed. In this book we adopt the systems engineering philosophy of treating software and hardware as peers as discussed in the sidebar “Concept: Software Engineering and Systems Engineering.” In this task, you are identifying logical locations and nodes. You could refer to “a branch office” that might be refined later, when you consider the physical

Task: Outline Deployment Elements | 223

architecture, into actual locations such as “the New York branch office” or “the Tokyo branch office.” An initial set of deployment elements may be derived from the Architecture Overview. As for functional elements, deployment elements are named, where appropriate, according to the terms defined in the Glossary.

Concept: Software Engineering and Systems Engineering As touched on in Chapter 2, “Architecture, Architect, Architecting,” the systems engineering field considers a system to comprise software, hardware, information, and workers. When deriving a solution, systems engineers make trade-offs regarding the use of software, hardware, and people. If performance is key, a decision may be made to implement certain system elements in hardware rather than software or people. Another example is that to provide a usable system to customers, a decision is made to provide a customer interface that is a human being rather than an interface implemented in software or hardware. More complex scenarios require certain system qualities to be achieved through a combination of software, hardware, and people. Accordingly, this book refers to elements other than software where appropriate. It is interesting to note that systems engineering is specifically concerned with treating software and hardware (as well as people) as peers, thus avoiding two kinds of pitfalls: (1) Hardware is treated as a second-class citizen to the software and is simply a vehicle for executing the software, and (2) Software is treated as a second-class citizen with respect to the hardware and is simply a vehicle for making the hardware function as desired. This approach taken in the Outline Deployment Elements task is analogous to the Outline Functional Elements task, in which you consider the architecture in a technology-independent manner. At this stage, you don’t know whether a branch office will be physically implemented as a store, as a country-specific website, as a person with a phone, and so on. All you know, when considering the logical architecture, is that a set of capabilities needs to be offered. The field of systems engineering would take a very broad view of how such a location could be implemented physically. The location could contain any combination of software, hardware, people, and information. This book focuses on software-intensive systems, however. As you will see in the examples, this book assumes that a location is ultimately implemented as a

224 | Chapter 8 Creating the Logical Architecture

physical geographic location containing physical computing resources on which software is deployed. In the field of systems engineering, in which a system comprises hardware and people as well as software, it is well understood that some qualities, such as scalability, are achieved through a combination of software and hardware. Therefore, you should consider these two aspects together when addressing the requirements. The Outline Functional Elements and Outline Deployment Elements tasks are considered separately in practice, however, so that the architect can focus on the practices that are specific to these two aspects of the architecture. The danger is failing to consider software and hardware as two sides of the same coin. The Verify Architecture task is introduced specifically to ensure the alignment of functional and deployment elements and to ensure that, together, they address all requirements in a consistent manner—both functional and non-functional.

Step: Identify Locations In this step, you review the relevant input work products to identify the locations that the system under development is to be distributed across. Identification of locations is based on an analysis of one or more of the following work products: ■

The Architecture Decisions work product may suggest the use of additional reusable assets (beyond those identified in the Existing IT Environment) that are to be used in a particular location. (A decision may have been made to interface to a mainframe program located in a particular city, for example.)

■

The Enterprise Architecture Principles work product may contain principles that can be adhered to only if particular locations are used or created. A principle of business continuity may state that operations must be maintained in spite of system interruptions or exceptional (disaster) incidents, which certainly implies the use of a separate disaster-recovery location.

■

The Existing IT Environment work product may contain elements that you choose to incorporate into your architecture; these elements may suggest particular locations.

■

The Non-Functional Requirements work product may identify constraints that mandate a particular location for certain aspects of the solution (“The call center must be located in our central office,” for example). In

Task: Outline Deployment Elements | 225

addition, certain qualities that the system must exhibit, such as availability, may suggest locations such as the need for both primary and secondary disaster-recovery locations. ■

The System Context work product identifies the location of any actors, whether these actors are people or external systems.

The initial locations identified for the YourTour system as a result of considering the various inputs are shown in the topology in Figure 8.16. This figure shows a Remote Office location where customers and tour organizers can access the YourTour application from an Internet-enabled device, a Branch Office location where Customers and Tour Organizers can meet with a Sales Clerk to book a tour, a Central Office where information from all remote offices and branch offices is consolidated, a MyPay Data Center that houses the MyPay payment system, and a MyReservation Data Center that houses the MyReservation reservation system. Although the MyPay Data Center and MyReservation Data Center are not within your direct control, you may need to deploy elements of the YourTour solution in these locations to facilitate integration with the relevant systems, which is why they are included. This will be confirmed (or otherwise) as you develop the detail of the integration solution.

«Location» Remote Office

«Location» Branch Office

«Location» Central Office

«Location» MyPay Data Center

Figure 8.16 Locations in the YourTour System

«Location» MyReservation Data Center

226 | Chapter 8 Creating the Logical Architecture

Step: Identify Nodes Having identified the locations, you move on to the identification of the nodes that will reside in each of the locations and on which components will eventually be deployed. At this stage, nodes are purely logical containers with no technology or product-specific attributes identified (unless specific constraints that have been mandated are noted). You concern yourself with such detail when you consider the physical architecture. In the step, the architect reviews all available inputs to identify the nodes that the system under development is to be distributed across. Identification of nodes is based on an analysis of, in particular, the Functional Requirements, Non-Functional Requirements, Functional Model, Existing IT Environment, and Architecture Decisions work products. These work products are discussed in the following sections. In addition, you may consider any Architecture Proof-of-Concept that has been created.

Functional Requirements The Functional Requirements work product helps you understand who the system actors are and the functionality that each actor requires. Given this information, you can determine what computing resources are required to support the execution of the system.

Non-Functional Requirements The Non-Functional Requirements work product may suggest the need for particular qualities of service, or different levels of service for a given quality, to be exhibited by the system. This suggestion then implies the need for different nodes to be introduced. The derivation of qualities that each node must exhibit can follow an approach similar to that taken for components, in which you consider each non-functional requirement in turn and allocate requirements to nodes as a result.

Existing IT Environment The Existing IT Environment work product identifies nodes that already exist and which may be used to support the execution of components of the system under development, either new components that are built or existing components that are interfaced to as part of the solution.

Functional Model The Functional Model work product identifies the components to be supported by the deployment environment, which may suggest the need for particular computing resources.

Task: Outline Deployment Elements | 227

Architecture Decisions The Architecture Decisions work product may suggest the use of certain nodes. As an example from the YourTour system, Figure 8.17 shows nodes placed in the Central Office location. This figure is based on the assumption that, for now, all tour-related components (both tour process control and tour services) will be added to one logical server: the Tour Booking Server. You may change this decision later as you refine the architecture based on your understanding of the requirements, the extent to which you have met all the requirements (especially those related to qualities), and the results of the execution of any architecture proof-of-concept that has been created. In addition, the Content Management Server will host a content management application. A separate server is used for content management for security reasons and also because content development has different availability requirements. Specifically, content needs to be developed only during normal working hours, whereas the Tour Booking Server has much more stringent availability requirements. The Security Server contains specific security-related software, and you anticipate that this capability will need to be separated physically from components on other nodes. Similarly, a separate Integration Server is provided to accommodate any specific integration software required.

«Location» Central Office

Content Management Server

Security Server

Tour Booking Server

Integration Server

Figure 8.17 Nodes Assigned to the Central Office Location

CRM Server

228 | Chapter 8 Creating the Logical Architecture

Task: Verify Architecture PURPOSE The purpose of this task is to verify that the architecture work products are consistent and to ensure that any concerns that cut across the architecture work products have been addressed consistently. ROLES Application Architect (secondary), Data Architect (secondary), Infrastructure Architect (secondary), Lead Architect INPUTS ◆ Architecture Decisions, Architecture Overview, Architecture Proof-of-Concept, Deployment Model, Functional Model, Functional Requirements, Non-Functional Requirements, System Context

OUTPUT ◆ Review Record

STEPS ◆ Plan verification. ◆ Hold kickoff meeting. ◆ Perform individual verification. ◆ Hold verification meeting. ◆ Perform rework. ◆ Perform follow-up. ROLE OF THE ARCHITECT ◆ Leading the verification of the architecture to ensure that architecture work products are consistent. ◆ Ensuring that any concerns that cut across the architecture work products (a quality such as performance, for example) have been addressed consistently. ◆ Ensuring that all defects discovered during the verification are addressed without breaking the overall architecture. ◆ Ensuring that any architecture decisions that come out of the verification exercise are captured.

The architecture work products can get out of step for various reasons, such as the fact that they sometimes are developed by different roles. The Functional Model is developed by the Application Architect, for example, whereas the Deployment Model is developed by the Infrastructure Architect. Although you may feel that you’ve addressed certain aspects of integration to external systems in the Functional Model, these assumptions may be invalidated by decisions made with respect to the Deployment Model.

Task: Verify Architecture | 229

The purpose of this task, therefore, is to look at each architecture work product in turn to ensure consistency with any related work products before you move on to provide additional details, as discussed in the Detail Functional Elements and Detail Deployment Elements tasks. This task should ensure that any concerns that cut across the architecture work products (such as security concerns) have been addressed consistently. In examining this alignment, you also refer to the requirements work products, especially the System Context, Functional Requirements, and Non-Functional Requirements work products. Verification is different from validation which focuses on the system as a whole rather than individual work products. See the sidebar “Concept: Verification and Validation” for a discussion on both of these techniques. It is worth noting that the set of work products considered in this task extends beyond the core Functional Model and Deployment Model work products to consideration of the Architecture Decisions and Architecture Proof-of-Concept work products, because any decisions that have been made

Concept: Verification and Validation In this book, we use the terms verification and validation as defined by the Software Engineering Institute (SEI) in its approach to establishing software maturity models (Ahern 2008). Verification allows the architect to determine whether the work products, at the current point in the overall development process, are consistent with the inputs used to create them (such as other work products and any development standards that have been mandated). In general terms, verification helps you detect defects in the work products early and therefore prevent later rework. Verification helps you answer the question “Am I building the system right?” Techniques that support verification include inspection of work products, tracing from solution components to requirements, and using the automatic verification tools that are available in some modeling environments. Validation focuses on the system as a whole rather than on individual work products. It is concerned with ensuring that the system satisfies the stated requirements. Validation helps you answer the question “Am I building the right system?” In other words, does the system satisfy the stated requirements, or has something else been built? This process includes consideration of both functional and non-functional requirements, including the important constraints of time, budget, and resources. Validation typically is performed by reviews with subject-matter experts and stakeholders, as well as black-box testing.

230 | Chapter 8 Creating the Logical Architecture

and any results gleaned from a proof-of-concept must also be consistently applied across the architecture work products. One of the goals of verification is to find and remove any defects present in work products. Many techniques exist for achieving this goal, such as reviews, walk-throughs, and inspections. The level of ceremony attributed to this task depends on many factors, especially the complexity of the architecture. At one end of the spectrum, this task can be a relatively simple informal review that involves the architect looking at the architecture work products, noting any inconsistencies, and correcting the work products accordingly. At the other end of the spectrum, you apply a rigorous technique for systematically walking through each architecture work product in turn, and this approach is the one described here. Our assumption is that the technique described here can easily be varied for any given situation and scaled down as necessary. The technique is based on the concept of an inspection and involves checking a given work product against related work products (such as those that were input to its creation). In addition, a checklist may be used to aid the reviewer. In inspecting the Deployment Model, the reviewer might use a checklist item to ensure that all components in the Functional Model (an input to the inspection) have been placed on nodes in the Deployment Model, for example. The steps in this task follow the classic inspection process first suggested by Michael Fagan (Fagan 1976) and are shown in Figure 8.18, adapted for the purposes of performing inspections of architecture work products. For a more complete description of the inspection process as it refers to software development, refer to Software Inspection (Gilb 1993).

Step: Plan Verification Thorough planning is essential to the success of an architectural verification. All work products to be verified are gathered, all participants are identified, and a decision is made as to how the participants will be briefed (via e-mail or a kickoff meeting, for example).

Plan Verification

Hold Kickoff Meeting

Perform Individual Verification

Figure 8.18 Verification Steps

Hold Verification Meeting

Perform Rework

Perform Follow-Up

Task: Verify Architecture | 231

Step: Hold Kickoff Meeting This step is optional but is performed if the participants are unfamiliar with the concept of inspections, their roles in the inspection, or the material to be inspected. The idea is to provide the team members some background on the materials to be inspected. Participants may be given checklists to help focus their comments, because each participant is asked to look at particular aspects of the work products involved.

Step: Perform Individual Verification The participants are sent or given the material that they are to inspect, and then spend time inspecting the work products and making note of the defects they discover. The time required to do this clearly varies depending on the size of the work products being inspected. Although this exercise may seem to be very heavyweight, finding defects early can reduce rework. To assist in the inspection of work products, participants can be given checklists that identify specific things to look for.

Step: Hold Verification Meeting The purpose of this meeting is to formally record and categorize all defects, as well as other issues or questions, identified during the individual verifications. Having a separate meeting to verify the architecture nearly always leads to additional defects being discovered jointly by the group that were not discovered individually. Verification meetings are not the place to solve problems or discuss issues; they are simply a means of focusing on the recording of defects in a Review Record. For a verification meeting to run smoothly, it usually needs to be run by an experienced moderator who can quickly shut down discussions that are likely to arise when technical people (who like to solve problems) gather.

Step: Perform Rework Rework is the step of the verification task in which the defects found during the verification meeting are resolved by the author. The relevant work products are updated accordingly. It is also wise to understand the likely cause of the defect and where in the process the defect was most likely caused, so that the development process is improved as a result. If the rework is extensive, the process may start again by returning to the “Plan verification” step.

232 | Chapter 8 Creating the Logical Architecture

Step: Perform Follow-Up The follow-up step ensures that all the defects found in the verification meeting have been corrected. The moderator is responsible for verifying that this is indeed the case.

Task: Build Architecture Proof-of-Concept PURPOSE The purpose of this task is to synthesize at least one solution (which may simply be conceptual) that satisfies the architecturally significant requirements to determine whether such a solution, as envisaged by the architect, exists. ROLES Application Architect (secondary), Data Architect (secondary), Infrastructure Architect (secondary), Lead Architect INPUTS ◆ Architecture Decisions, Architecture Overview, Deployment Model, Functional Model, Functional Requirements, RAID Log, NonFunctional Requirements, Prioritized Requirements List

OUTPUT ◆ Architecture Proof-of-Concept

STEPS ◆ Create architecture proof-of-concept. ◆ Document findings. ROLE OF THE ARCHITECT ◆ Initiating the proof-of-concept and establishing the ground rules and scope of the proof-ofconcept. ◆ Working closely with any product vendors to give them clear guidance on what is required of their product for the purposes of the proof-of-concept. ◆ Collating and interpreting the results of the proof-of-concept and for reporting them back to stakeholders. ◆ Making any architecture decisions based on the results obtained from the proof-of-concept.

The purpose of creating an Architecture Proof-of-Concept is to reduce risk. This work product can take many forms, ranging from a list of known technologies that seem appropriate to the solution or a simple sketch of a conceptual model of a solution to an executable prototype.

Task: Build Architecture Proof-of-Concept | 233

For those architectures whose characteristics cannot be determined on paper (or in models) and for which some form of empirical evidence is required to satisfy the architect that certain architectural assumptions do (or do not) hold, the Architecture Proof-of-Concept takes the form of executable software. An example of when an executable prototype is needed is when you need to determine the end-to-end performance of the system, which theoretically can be calculated on paper but is best determined by executing software on an infrastructure that is representative of that envisaged in the solution. Considerable effort and cost may be involved in producing a proof-of-concept, so it should be done only when the risk is considered sufficiently great that not mitigating the risk is likely to lead to even more cost later on. The results from building and running the Architecture Proof-of-Concept are documented and used to validate the assumptions or decide which options are more feasible than others when more than one could apply.

Step: Create Architecture Proof-of-Concept An Architecture Proof-of-Concept is created for many reasons, including the following: ■

The functional requirements are novel or challenging. You may be introducing new business function or processes into your organization, for example.

■

Particularly demanding qualities are demanded of the system under development, such as high levels of availability or extremely fast response times.

■

New or unproven technologies (at least as far as the development team is concerned) are required, such as new commercial-off-the-shelf (COTS) packages.

■

New standards are to be adopted.

■

Interfaces to existing systems are complex or undocumented.

■

New development tools are to be used, and you need to prove that development can proceed with this tooling.

The inputs to this task reflect these different considerations and therefore include the Functional Requirements, Non-Functional Requirements, and Prioritized Requirements List work products, as well as the Architecture Overview, Deployment Model, and Functional Model architecture work products. In addition, one or more of the above concerns may have been identified and captured either as a risk or as a potentially looming issue in the project RAID Log. Alternatively, perhaps one or more architecture decisions, as

234 | Chapter 8 Creating the Logical Architecture

captured in the Architecture Decisions work product, cannot be addressed until some prototyping work has been done to test the various options. In the YourTour system, particular challenges have been identified with respect to the integration with the external MyPay payment engine and the MyReservation reservation system, in terms of both access mechanism and performance. You are also concerned with the security model used in conjunction with these integrations. You create an Architecture Proof-of-Concept to consider all these aspects of your architecture. Putting together an Architecture Proof-of-Concept can be challenging because by definition, it is being done when the architecture is being formulated and is to some extent in a state of flux. Remember, too, that the proof-ofconcept is typically considered to be throwaway and should not be allowed to evolve into the actual system with all the inherent dangers that can result, such as building on a foundation that is not robust or extensible enough to support all the requirements.

Step: Document Findings The results from executing the proof-of-concept are documented accordingly as part of the Architecture Proof-of-Concept work product.

Task: Detail Functional Elements PURPOSE The purpose of this task is to refine the functional elements to the point that they can be handed off to detailed design. ROLES Application Architect, Data Architect (secondary), Infrastructure Architect (secondary) INPUTS ◆ Architecture Decisions, Business Entity Model, Functional Model, Glossary STEPS ◆ Define component interfaces. ◆ Define operations and operation signatures. ◆ Define contracts between components. ROLE OF THE ARCHITECT ◆ The architect is responsible for this task.

OUTPUTS ◆ Data Model, Functional Model

Task: Detail Functional Elements | 235

Having outlined the functional elements in the Outline Functional Elements task, you flesh out some of the details of these elements in this task. Specifically, this task involves ■

Defining the interfaces that your components provide and require. Provided interfaces are those that a component makes available for other components to use. Required interfaces are ones that the component must use to complete some of its responsibilities.

■

Specifying the interface operations and their signatures (that is, the parameters passed, parameter types, and return values).

■

Specifying the contract of behavior for each operation in terms of preconditions and postconditions.

You may be asking, “Why should I be concerned with this level of detail, especially in a logical architecture?” We believe that there are two reasons: ■

If the architect does not specify components to this level of detail, it will be left to the designers and implementers to perform this task. They typically work outside the architect’s immediate sphere of influence (and may not even be in the same company or country) and therefore may make decisions that are inconsistent with the architecture.

■

Specifying components in this way allows you to make a link between the logical Functional Model and the logical Data Model. Often, these models are developed separately and independently, but this approach allows you to ensure these two models are consistent in the early stages of the project.

That said, it may not always be the case that components need to be defined to this level of detail. If a component is expected to be realized by a product or package or other off-the-shelf component, for example, it probably is not necessary to go to the level of detail discussed here. This task acknowledges any decisions captured in the Architecture Decisions work product and names functional elements according to terms defined in the Glossary.

Step: Define Component Interfaces Components interact through interfaces. An interface is the vehicle by which one component accesses the services of, and exchanges data with, another component. Taking this approach is considered to be good practice because

236 | Chapter 8 Creating the Logical Architecture

the consumer is dependent only on the interface, not on the provider’s implementation of the interface. Subsequently, it is easier to replace one implementation with another so long as the same interface is adhered to. A component is characterized by the interfaces it provides (and the operations available through each interface) and the interfaces it requires. In implementing its provided interfaces, a component may require the services of other components, in which case they use the interfaces provided by these components. As you will see, the interfaces a component provides and requires are derived from the responsibilities assigned to the component. The separation of interface from implementation also allows you to make better-informed choices when you move from the logical to physical architecture. The clearer the separation of responsibilities into interfaces (realized by a component implementation), the more effectively you can select the corresponding elements of the physical architecture. Dealing with interfaces (and, as described later in the sidebar “Concept: Preconditions and Postconditions,” operations, preconditions, and postconditions) means that you have a very precise specification, allowing you either to design the physical components more precisely or to find products or packages that fit the interface specification more closely. In this step, you assign interfaces to the components that were identified previously. Figure 8.19 shows an example of a component’s provided interfaces: the Tour Booking Manager component providing ITourBooking and IPayment interfaces. Where do the interfaces in Figure 8.19 come from? Well, you take the responsibilities you assigned to the components previously and grouped them according how similar (or cohesive) they are. Each of these groups of responsi-

«interface» ITourBooking create tour booking ( ) add tour participant ( ) add tour participant options ( )

«provides»

«interface» IPayment provide payment details ( )

«provides»

«Entity» Tour Booking Manager

Figure 8.19 A Component’s Provided Interfaces

Task: Detail Functional Elements | 237

bilities then becomes an interface. In this example, all responsibilities assigned to the Tour Booking Manager component that deal with the actual booking of a tour have been grouped in an ITourBooking interface, and the single responsibility for dealing with payments has been assigned to an IPayment interface. By convention, the name of each interface is prefixed with an I. The assignment of interfaces is applied to all components in turn. You may choose to refine any requirements realizations to show how these interfaces are used rather than the components offering those interfaces. Figure 8.20 provides a refined sequence diagram showing the realization of the main flow of the Book Tour use case, using the interfaces that have been identified (as opposed to the components that offer these interfaces). Diagrams such as that shown in Figure 8.20 allow you to better understand the interfaces that a given component requires. The result is that you can show the provided and required interfaces of a given component. Figure 8.21 shows the interfaces that are provided and required by the Book Tour Controller component; the required interfaces have been derived from Figure 8.20 and other diagrams like it that describe the different flows of events for each use case. This summary diagram can provide a complete specification of one or more components and for this reason is referred to as a component specification diagram (Cheesman 2001). As discussed in the Outline Functional Elements task earlier in this chapter, you could allocate certain non-functional requirements to the operations associated with each component. When defining the interfaces associated with a component, therefore, you can promote this allocation to the equivalent operations on the interfaces. Earlier, a performance requirement of 6 seconds was allocated to the make reservations() operation on the Reservation System Boundary component. This requirement in turn is allocated to the equivalent operation on the IReservationSystem interface.

Step: Define Operations and Operation Signatures In this step, you define interfaces in more detail by specifying the actual operation names and signatures. The operation name usually is the same as the responsibilities you assigned to each interface previously, though it may be shortened or abbreviated if required. The signature of each operation (in terms of inputs and outputs) can be determined from its name to some extent. You could assume that the responsibility add tour participant() is going to require information defining the tour booking to which the participant is added and the tour participant involved. You may also examine the sequence diagrams you developed previously (as shown in Figure 8.20, for example) to determine the data flows.

:Tour Booker Boundary

:Book Tour Controller

:ITour

:ITourBooking

:IPayment

1: get tours 1.1: get tours 1.1.1: get tours

2: select tour 2.1: select tour 2.1.1: create tour booking

loop [0,*]

1: add tour participant 1.1: add tour participant 1.1.1: add tour participant

loop

1: add tour participant options

[0,*] 1.1: add tour participant options 1.1.1: add tour participant options

3: book tour 3.1: book tour 3.1.1: provide payment details

3.1.2: process payment

3.1.3: make reservations

Figure 8.20 UML Sequence Diagram for the Book Tour Use Case (Main Flow)

:IPaymentEngine

:IReservationSystem

238 | Chapter 8 Creating the Logical Architecture

:Tour Booker

Task: Detail Functional Elements | 239

«interface» ITourBookingControl «interface» ITourControl

select tour ( ) add tour participant ( ) add tour participant options ( ) book tour ( )

get tours ( )

«provides»

«provides»

«Control» Book Tour Controller

«requires»

«requires»

«interface» ITour get tours ( )

«interface» IPayment provide payment details ( )

«requires» «interface» ITourBooking create tour booking ( ) add tour participant ( ) add tour participant options ( )

«requires» «interface» IPaymentEngine process payment ( )

«requires» «interface» IReservationSystem make reservations ( )

Figure 8.21 Component Specification Diagram for the Book Tour Controller

Operation parameters and any return values may be simple types, such as String or Integer, or more complex business types. The set of business types represents a logical Data Model, which is similar to and typically derived from the Business Entity Model. A (partial) logical Data Model, based on the Business Entity Model for YourTour, is shown in Figure 8.22, where the business types have the businessType UML stereotype applied. One particular area that can be explored further is the persistent nature of the data that flows in the system. Consider the following characterizations: ■

Data is transient. Such data is relevant only for the duration of the method invocation. A request to add two numbers and return the result, for example, does not require the component to retain any information relating to the calculation beyond the lifetime of the invocation. Sometimes, however, the results of some calculations are retained, such as a calculation that provides an insurance quote.

■

Data represents a conversational state. Data may persist only for the duration of a user session. The data may represent the contents of a shopping cart that is lost when the user session terminates, for example. Even in this case, however, a given implementation may retain the contents of the cart beyond user sessions.

240 | Chapter 8 Creating the Logical Architecture

«businessType» TourParticipant

«businessType» TourBooking reference

1

*

first name last name date of birth passport number contact details

«businessType» Reservation 1

*

reference price

1

* «businessType» TourParticipantOption

«businessType» Car Type Preference

«businessType» Hotel Room Preference «businessType» Flight Seating Preference

«businessType» Train Seating Preference

Figure 8.22 Logical Data Model

■

Data is persisted. Persistent data is written out to a data store so that it can be retained beyond the lifetime of the method invocation, beyond the lifetime of the component instance, and beyond the lifetime of any user session.

Persistent data that is written out to a data store is of particular interest, because a relationship exists between the business types in the logical Data Model and the components (and interfaces) that are responsible for managing these types. A particular technique that provides this linkage is described by Cheesman and Daniels (Cheesman 2001), where the authors introduce an interface responsibility diagram. The purpose of such a diagram is to show which business types are managed by which interfaces. The interface responsibility diagram always includes the interface and all its operations (and can be considered to be the interface equivalent of a component specification diagram) as well as any business types managed by the interface. An example is shown in Figure 8.23.

Task: Detail Functional Elements | 241

«interface» ITourBooking create tour booking ( ) : TourBooking add tour participant ( booking : TourBooking, participant : TourParticipant ) add tour participant options ( participant : TourParticipant, options : TourParticipantOption [1..*] ) 1

*

«businessType» TourParticipant

«businessType» TourBooking reference

1

*

first name last name date of birth passport number contact details

«businessType» Reservation 1

*

reference price

1

* «businessType» TourParticipantOption

«businessType» Car Type Preference

«businessType» Hotel Room Preference «businessType» Flight Seating Preference

«businessType» Train Seating Preference

Figure 8.23 Interface Responsibility Diagram

An interface responsibility diagram is derived from the logical Data Model by assigning a so-called core business type to a particular interface that is responsible for managing that business type (and any related noncore business types). A core business type essentially is one that is not dependent on any other types for its existence. In this example, TourBooking is considered to be a core business type, whereas TourParticipant is not (because it depends on a TourBooking for its existence). An interface usually is associated with a single business type, and each business type is managed by exactly one interface. The association between ITourBooking and TourBooking is shown in the figure as a UML composite aggregation (the solid diamond symbol).

242 | Chapter 8 Creating the Logical Architecture

The interface responsibility diagram, therefore, is a specification of the data that is managed by an interface (and any component that provides this interface). The data itself is persistent, but the specification does not say anything about how persistence is achieved. In other words, the specification is logical rather than physical.

Step: Define Contracts Between Components Having identified the components and their interfaces, you proceed to define the contracts between those components. The concept of design by contract was made famous by Bertrand Meyer (Meyer 1997) in the early 1990s. The contract in this sense is like any legal contract between two parties, in which both parties have certain obligations in fulfilling the contract. For components, the contract comes in the form of preconditions and postconditions on each operation offered by the interface on the component. See the sidebar “Concept: Preconditions and Postconditions” for a brief introduction to the ideas that underlie the concept of design by contract.

Concept: Preconditions and Postconditions A precondition is the condition that must be satisfied before the operation executes. If the precondition is true, you can guarantee that the postcondition will be true also. If the precondition is not true when the operation is invoked, however, the result of the operation cannot be guaranteed and is in fact unspecified (that is, you cannot be sure what the operation will do or what value it will return). A postcondition specifies the state of the component after the operation has executed, provided that the precondition is true. By state, we mean any data (transient or persistent) for which the component is responsible. Just as in law, preconditions and postconditions place obligations on the client and provider of a contract. In terms of software, the client is the component that calls the operation, and the provider is the component that implements the operation, as summarized in Figure 8.24. The purpose of having preconditions and postconditions on the operations of component interfaces is to make explicit the responsibility of the caller before invoking the operation. In other words, if something is listed as a precondition, it does not have to be checked by the provider but is assumed to be true, which ensures against too little or too much checking of the data

Task: Detail Functional Elements | 243

Client Precondition

Contract

Provider Postcondition

What must be true for the operation to succeed

What the operation will guarantee to do if the precondition is true

An obligation for the client and a benefit for the provider

A benefit for the client and an obligation for the provider

A precondition violation means a bug in the client

A postcondition violation means a bug in the provider

Figure 8.24 Client and Provider Obligations, and Benefits of Preconditions and Postconditions

being passed to the operation. In software, too much checking is as bad as too little because it can lead to program bloat, making software overly complex and difficult to maintain, as well as providing more opportunities to introduce errors in the error-checking code itself! As described in Object-Oriented Software Construction (Meyer 1997), a precondition does not stop the operation from being executed, and it is therefore left up to the developer of the operation to determine how invalid preconditions are handled (or not). If handled, this typically involves some form of exception handling, either provided by the runtime environment or explicitly written by the developer of the operation. Preconditions and postconditions may be expressed using either the formal Object Constraint Language (OCL) (Warmer 1999) or natural language. An advantage of using a formal language is that it is possible to generate code that supports the enforcement of constraints in a programming language (although you are more likely to generate code from a physical architecture model than a logical architecture model).

244 | Chapter 8 Creating the Logical Architecture

An example of a precondition in adding tour participant options to a tour is “The number of participant options specified is not zero,” as shown in Figure 8.25, where OCL has been used to specify the constraint. This figure also shows a precondition expressed in natural language.

add tour participant precondition { If the number of participants will exceed the maximum capacity for the Tour associated with the Tour Booking Then the participant is not added to the Tour Booking and the operation returns false Else The specified participant is added to the Tour Booking and the operation returns true }

add tour participant options precondition {options->size() != 0}

«interface» ITourBooking create tour booking ( ) : TourBooking add tour participant ( booking : TourBooking, participant : TourParticipant ) add tour participant options ( participant : TourParticipant, options : TourParticipantOption [1..*] )

«provides»

«Entity» Tour Booking Manager

Figure 8.25 Example of Preconditions

Task: Detail Deployment Elements | 245

Task: Detail Deployment Elements PURPOSE The purpose of this task is to refine the deployment elements to the point that they can be handed off to detailed design. ROLES Application Architect (secondary), Data Architect (secondary), Infrastructure Architect INPUTS ◆ Architecture Decisions, Deployment Model, Functional Model, Glossary, Non-Functional Requirements

OUTPUT ◆ Deployment Model

STEPS ◆ Assign components to nodes. ◆ Define connections between nodes. ◆ Define connections between locations. ROLE OF THE ARCHITECT ◆ The architect is responsible for this task.

Having outlined the deployment elements in the Outline Deployment Elements task, you flesh out some of the details of these elements in this task. Specifically, this task involves ■

Assigning components to the relevant nodes

■

Identifying the deployment units that allow components to be deployed to their assigned nodes

■

Deriving the connections between nodes and locations, based on the messages that flow between components

The results of this task are included primarily in the Deployment Model work product. This task takes into consideration any decisions captured in the Architecture Decisions work product and names deployment elements according to terms defined in the Glossary.

Step: Assign Components to Nodes Having identified the logical deployment elements, you make the connection between the Functional Model and Deployment Model by assigning

246 | Chapter 8 Creating the Logical Architecture

components in the Functional Model to nodes in the Deployment Model. Components are assigned to nodes based on two main factors: ■

The type of component. A boundary component, for example, typically resides on a node that is connected to the associated device (in the case of a user interface) or external system. An entity component resides on or close to the node housing the data access mechanism (such as a database server).

■

The required qualities to be exhibited by the system, such as performance, availability, and security. Components that need to be highly available may need to be placed on nodes that are marked as being high availability or on nodes that are duplicated so that if one fails, the other can take over.

As well as identifying nodes that support components that provide the business functionality, this task identifies nodes needed to support any services required: print servers, application servers, file servers, security servers, data management servers, transaction servers, system management servers, and so on. Figure 8.26 shows an example from the YourTour system of the allocation of components to nodes. This figure introduces the concept of a deployment unit that provides a link between the components to be deployed and the nodes being deployed to. Logical deployment units are discussed in the sidebar “Concept: Logical Deployment Units.” Figure 8.26 depicts the Central Office location. Here, you see three deployment units for those elements deployed to the Tour Booking Server (one for each type of component: boundary, control, and entity), a single deployment unit for those elements deployed to the Content Management Server, a single deployment unit for those elements deployed to the Security Server, and a single deployment unit for those boundary components that represent interfaces to external systems. A deployment unit is represented as a UML artifact.

Step: Define Connections Between Nodes When components that interact have been placed on nodes, you need to ensure that communication can take place among them if they are distributed across nodes. In the logical architecture, you don’t concern yourself with whether the physical connection is point to point or via an intermediary mechanism such as a messaging bus; you simply represent the connection as an association between the two nodes. You consider the physical mechanisms

«Location» Central Office CRM Server

Content Management Components

«deploy»

Content Management Server

Security Server

Tour Booking Server

Integration Server

«deploy»

Security Components

«deploy»

Integration Components «manifest»

«deploy»

Tour Booking UI Components «manifest»

Tour Booking Control Components

«deploy»

«Boundary» CRM System Boundary

Tour Booking Entity Components «manifest»

«manifest»

«manifest»

«manifest»

«Entity» Tour Booking Manager

«Control» Book Tour Controller

«manifest»

«manifest»

«manifest»

«Entity» Tour Manager

«Entity» Tour Rules

«Entity» Transaction Log

Figure 8.26 Components Assigned to Nodes in the Central Office Location

«Boundary» Payment Engine Boundary

«Boundary» Reservation System Boundary

Task: Detail Deployment Elements | 247

«Boundary» Tour Booker Boundary

«deploy»

248 | Chapter 8 Creating the Logical Architecture

Concept: Logical Deployment Units The concept of a deployment unit represents a package of components that is subsequently deployed on one or more nodes. Put another way, it is the concept of a deployment unit that allows a component to be deployed on a node. So why do you need this intermediary? The concept of a deployment unit is particularly relevant in a physical architecture, where you don’t deploy components directly to nodes. In a Java EE environment, for example, you first must package your executables in a JAR file of some sort, and it is the JAR file that is deployed to a physical node. This separation can be useful in a logical architecture, too, when you want to deploy the same set of elements to different nodes for some reason and want to represent the packaging once (in a deployment unit). This technique also provides consistency in the approach taken to specifying the logical architecture and the physical architecture. A more important reason for considering logical deployment units, however, is that it gives the architect an opportunity to associate particular qualities with a set of components. This goal is achieved by grouping those components that require a particular quality of service into a deployment unit, which is then deployed to a node that provides the quality of service required. Boundary components, control components, and entity components, for example, typically require different qualities of service, and you can distinguish them by placing them in separate deployment units. A boundary component is concerned with the nature of the interface to the corresponding external actor, the location of the external actor, the required hours of service, and the amount of concurrent use supported by this interface. A control component is concerned with the amount of concurrent execution that must be supported and the response times required. An entity component is concerned with the amount of information being handled, the volatility of the information, and the amount of concurrent access. As a general rule of thumb, therefore, you separate boundary, control, and entity components into separate deployment units, because this practice gives you a first indication that these elements must be considered differently as you refine the architecture.

involved when you consider the physical architecture. Figure 8.27 shows the nodes previously identified for the Central Office location with simple associations between nodes added. The associations are added as a result of the interactions that take place among the components deployed on each of the nodes. These interactions are

Task: Detail Deployment Elements | 249

«Location» Central Office Content Management Components

«deploy»

«deploy»

Tour Booking UI Components

Content Management Server

Security Server

«deploy»

Security Components

Tour Booking Server

Integration Server

«deploy»

Integration Components

«deploy»

Tour Booking Control Components

CRM Server

«deploy»

Tour Booking Entity Components

Figure 8.27 Nodes and Connections in the Central Office Location

described by sequence diagrams such as that shown in Figure 8.20 earlier in this chapter. Connections have been added as shown in Figure 8.28 because: ■

Some of the components supported by the Tour Booking Server and some of the components supported by the Content Management Server need to access the relevant components supported by the Security Server to authenticate users.

■

Components supported by the Content Management Server need to deploy content using components supported by the Tour Booking Server.

■

Components deployed to the Integration Server may need to access components on the Security Server to ensure that they are authorized to access the external system.

■

Components on the Tour Booking Server need to access external systems, which they do through the Integration Server. In addition, one of those systems is the CRM System that is also located in the Central Office, so you see a connection between the Integration Service and the CRM Server.

250 | Chapter 8 Creating the Logical Architecture

Tour Organizer

«Location» Remote Office

«Location» Branch Office

Sales Clerk

«Location» Central Office

Customer

System Administrator

«Location» MyPay Data Center

Reservation System

Business Administrator

«Location» MyReservation Data Center

Payment Engine

Figure 8.28 Locations and Connections

Step: Define Connections Between Locations You can extend this thinking to derive connections between locations also, although such connections are often quite obvious and don’t need a thorough analysis to determine. Figure 8.28 shows a number of locations and the connections between them. These connections are derived from the connections between the nodes that are found in those locations. As just discussed, connections between nodes are identified by analyzing the messages sent between the components deployed on those nodes. Figure 8.28 also shows the actors present at each location. (It is a coincidence that the same actor appears in only one location in the figure; it is quite possible for the same actor to be present in several locations.)

Task: Validate Architecture | 251

Task: Validate Architecture PURPOSE The purpose of this task is to validate that the architecture supports the requirements as currently stated. ROLES Application Architect (secondary), Data Architect (secondary), Infrastructure Architect (secondary), Lead Architect, Project Manager (secondary) INPUTS ◆ All architecture-related work products

OUTPUTS ◆ Architecture Assessment, Change Request, RAID Log

STEPS ◆ Plan validation. ◆ Review architecture. ◆ Document findings. ◆ Assess risks and make recommendations. ROLE OF THE ARCHITECT ◆ Planning and leading the validation. ◆ Documenting the findings. ◆ Noting any risks or issues and identifying appropriate mitigations.

As discussed in the sidebar “Concept: Verification and Validation” earlier in this chapter, validation helps answer the question “Am I building the right system?” In other words, does the system satisfy the stated requirements, or has something else been built? Even though you are validating a logical architecture, it’s still possible to evaluate the architecture against the requirements. You can take several approaches to validate the architecture, and the specific techniques you use at a given point in time may vary depending on where you are in the overall project life cycle and the current state of the architecture. Early in the project, for example, it may be best to validate the architecture simply by presenting the architecture to the key stakeholders. Later in the project, you may perform a more rigorous and systematic walk-through of the architecture. As you will see in Chapter 9, “Creating the Physical Architecture,” validation of the physical architecture may also consider characteristics of the executing system. In validating the architecture in this task, you focus not only on the technical aspects of the architecture, but also on the context within which the

252 | Chapter 8 Creating the Logical Architecture

architecture exists, including the requirements from which the architecture has been derived as well as the realities of delivery based on the architecture that has been defined. In these respects, this task encompasses a broad set of considerations: ■

Understanding the broader business context of the architecture. What are the key requirements and commitments that have been made to the stakeholders? What are the organizational aspects to the project that must be understood?

■

Assessing whether the proposed architecture is fit for purpose, given the requirements. Here, you assess the technical aspects of the architecture. Does the architectural solution satisfy the requirements at the current level of elaboration in the project?

■

Determining the ability to deliver. The architecture has a major bearing on what skills are required to develop the system, as well as what is required for the development and test environment. The idealized view of what is required needs to be balanced with what is realistically achievable. This particular consideration emphasizes the close relationship between the architect and Project Manager.

■

Identifying and assessing technical risks. What risks are outstanding, and are they being formally managed? What is the potential effect on the project if these risks become issues? How can the risks be mitigated and contained?

In validating the architecture, sometimes it is useful to take a few key use cases and walk through them to ensure that the architecture supports the use cases. The sidebar “Concept: Scenario-Based Validation” discusses one such approach to this form of validation. Validation can take many forms, ranging from a presentation to the relevant personnel by the architect (or architecture team) through to an exercise that spans several days. The very general steps outlined in this task are intended to cover this broad spectrum. The level of formality is dependent on many factors, of course, including the complexity of the solution, where the project is in terms of the overall project life cycle, and the number of stakeholders involved. The Validate Architecture task focuses on those stakeholders that are internal to the project, such as the Project Manager, Developers, and Testers. The Review Architecture with Stakeholders task, on the other hand, focuses on external stakeholders that are not part of the development team, such as the Application Owner and end users.

Task: Validate Architecture | 253

Concept: Scenario-Based Validation To divide and conquer the task of validating the architecture, often it is useful to consider a set of key scenarios that are used to walk through the architecture and that allow the architect to demonstrate the architecture in action—in terms, for example, of the decisions that have been made, the elements that comprise the architecture and their collaboration, and the qualities that the architecture exhibits. A well-known scenario-based approach is the Architecture Tradeoff Analysis Method (ATAM) from the SEI (Clements 2002), as well as its predecessor, the Software Architecture Analysis Method (SAAM) (Clements 2002). The ATAM considers a set of scenarios in which each scenario focuses on either the functionality offered by the system or the qualities exhibited by the system. In either case, this approach affords the architect the opportunity to convey the architecture in the context of each scenario. The ATAM encompasses the tasks Validate Architecture and Review Architecture with Stakeholders, which are described elsewhere in this chapter. One aspect of the ATAM is architecture evaluation, which follows a series of steps: 1. Present the ATAM. The approach is described, and any questions regarding the evaluation process are answered. 2. Present the business drivers. The business motivation for the development effort and key architectural drivers are described. This step often is performed by someone from the business, the customer, or the project manager. 3. Present the architecture. The architect describes the architecture and how it addresses the business drivers. This step typically is performed by considering the various views that describe the architecture. 4. Identify the architectural approaches. In this step, the architectural approaches taken are determined, typically by asking questions of the architect. The approaches are often described in terms of high-level architecture decisions, such as the selection of particular architectural styles and significant elements. 5. Generate the quality attribute utility tree. The key system qualities are determined, specified in terms of scenarios, and prioritized. The scenarios refine any rather vague qualities, such as, performance into more Continued

254 | Chapter 8 Creating the Logical Architecture

specific scenarios that can be measured, resulting in a utility tree. The main purpose of this step is to ensure that the relevant set of scenarios used to validate the architecture is selected. “In effect, the utility tree tells the evaluation team where to probe the architecture” (Clements 2002). 6. Analyze the architectural approaches. The evaluation team determines the applicability of the architectural approaches taken in terms of satisfying the business drivers previously described for each of the prioritized scenarios. Any risks are noted. 7. Brainstorm and prioritize scenarios. Whereas previous steps consider the more technical scenarios against which the architecture should be evaluated, this step considers the bigger picture and invites all stakeholders to contribute scenarios by which the architecture should be evaluated. 8. Analyze the architectural approaches. This step is the equivalent of step 6 but takes any new scenarios into account. 9. Present the results. The information from the ATAM is summarized and presented to the stakeholders.

Step: Plan Validation Validation of the architecture should be planned appropriately, because it involves identifying the key personnel to participate in the validation, scheduling any meetings required, and preparing and distributing materials (the inputs to this task) before any meeting. The validation is a team effort, and the Lead Architect and Project Manager should both be involved in this step.

Step: Review Architecture The architect presents the architecture to the internal stakeholders and answers any questions. The presentation typically commences with a statement of the business drivers for the solution; then the architect presents the architecture. External stakeholders are considered in the Review Architecture with Stakeholders task. In particular, the internal stakeholders will be interested in seeing the big picture of how the architecture addresses the system requirements—the primary objective of validating the architecture. In this respect, the architect typically highlights the high-priority requirements (functional and non-functional) and indicates how each requirement is addressed in terms of the architecture being presented. It is important to show how elements of the architecture can be traced back to the requirements by using some form of traceability matrix.

Task: Validate Architecture | 255

One important aspect of reviewing the architecture is ensuring that all the requirements, as originally stated by the stakeholders, have been dealt with. This is where having some form of traceability—linking architectural elements back to requirements—comes into its own. Well-defined traceability allows reviewers to trace from the architecture back to the requirements to see how each requirement has been satisfied. While reviewing the architecture, it is useful to have a checklist available to ensure that the right questions are asked and nothing is missed. Appropriate checklists, aligned with the architecture description framework introduced in Chapter 4, “Documenting a Software Architecture,” are provided in Appendix B, “Viewpoint Catalog.” These checklists also help architects prepare for this task, because the checklists remind you of the questions that need to be answered in the review.

Step: Document Findings As the presentation proceeds, various items may not have been addressed adequately in the architecture, or questions may remain unanswered. All such comments should be recorded to ensure that they’re addressed, and all such findings are documented in the Architecture Assessment work product. If it becomes apparent that the architecture cannot be validated against the stated performance requirements because the requirements are not described adequately, the finding might be as shown in Table 8.7.

Step: Assess Risks and Make Recommendations After documenting all findings, the next step is deciding what risks are associated with each finding. It is important that risks clearly state the potential impact on the delivery of the project. As well as stating the risks, it is helpful to quantify the risks according to the likelihood of their actually occurrence and the potential impact on the project if the risks actually occur. For each risk, you should also make some statement or recommendation regarding risk mitigation, as shown in Table 8.8, by doing one of the following things: ■

Removing the risk from the project by changing the solution

■

Containing or reducing the risk by adding estimation contingency, mitigation tasks, excess capacity, or other measures to reduce the risk

■

Accepting the risk without changing anything but possibly providing an alternative plan or approach if the risk materializes

Risks identified in the Architecture Assessment also should have an entry in the RAID Log to ensure that they get tracked by the project. Issues may be

256 | Chapter 8 Creating the Logical Architecture

Table 8.7 Example Architecture Validation Finding Finding

The performance requirements are not specific enough to be measured. They are considered incomplete and ambiguous.

Table 8.8 Example Architecture Assessment Finding with Risk and Mitigation Added Finding Risk Probability Mitigation

The performance requirements are not specific enough to be measured. They are considered incomplete and ambiguous. From a performance perspective, the system will not deliver against the expectations of the various stakeholders. High Impact High Review all stakeholder requests with a view to refining the performance requirements on the system. Contact the relevant stakeholders if necessary. Review and refine the architecture based on the refined performance requirements.

identified during the assessment and these issues should also be tracked in the project RAID Log. This task may also result in one or more Change Requests being raised against work products that have been examined.

Task: Update Software Architecture Document PURPOSE The purpose of this task is to document the architecturally significant elements in the Software Architecture Document. ROLE Lead Architect INPUTS ◆ Architecture Assessment, Architecture Decisions, Architecture Overview, Architecture Proof-of-Concept, Data Model, Deployment Model, Functional Model STEP ◆ Update software architecture document. ROLE OF THE ARCHITECT ◆ The architect is responsible for this task.

OUTPUT ◆ Software Architecture Document

Task: Update Software Architecture Document | 257

Step: Update Software Architecture Document In this step, the architect updates the relevant views in the Software Architecture Document. The outline of the Software Architecture Document is discussed in Chapter 4, “Documenting a Software Architecture.” In terms of that structure, the various sections are populated from the content of the work products that have been created, as shown in Table 8.9. Just as the requirements view is populated from the various requirements-related work products, you can populate the functional, deployment, and validation views from the

Table 8.9 Alignment of Sections in the Software Architecture Document and Work Products Section

Work Products

Overview of the Architecture Architecture Decisions Requirements View Functional View

Architecture Overview Architecture Decisions See Chapter 7, “Defining the Requirements” Architecture Decisions Architecture Overview Data Model Functional Model Architecture Decisions Architecture Overview Deployment Model Architecture Assessment Architecture Proof-of-Concept Review Record RAID Log This view is cross-cutting and potentially includes elements from all work products. This view is cross-cutting and potentially includes elements from all work products. This view is cross-cutting and potentially includes elements from all work products. This view is cross-cutting and potentially includes elements from all work products. This view is cross-cutting and potentially includes elements from all work products. This view is cross-cutting and potentially includes elements from all work products.

Deployment View

Validation View

Application View Infrastructure View Systems Management View Availability View Performance View Security View

258 | Chapter 8 Creating the Logical Architecture

various architecture-related work products that are output from the tasks described in this chapter. You can also populate the cross-cutting views that are part of the architecture description framework too. When populating the Software Architecture Document, it is important to remember that a difference exists between the architecture definition as defined in various (detailed) architecture work products and the architecture definition as defined in the Software Architecture Document. The purpose of the Software Architecture Document is to provide a vehicle for bringing together all the relevant architecture-related information in one place for the purpose of communicating and reviewing the architecture (and the document sometimes is referred to as a deliverable as a result). Therefore, the document often is a subset of all the information available in all the work products.

Task: Review Architecture with Stakeholders PURPOSE The purpose of this task is to baseline the logical architecture work products and obtain stakeholder agreement that the architecture, at its current level of elaboration, addresses the defined requirements. ROLES Application Architect (secondary), Data Architect (secondary), Infrastructure Architect (secondary), Lead Architect, Stakeholder INPUTS ◆ Software Architecture Document, other work products as required

OUTPUTS ◆ Change Request, RAID Log, Review Record

STEPS ◆ Baseline work products. ◆ Assemble work products. ◆ Review work products. ROLE OF THE ARCHITECT ◆ Ensuring that the correct work products have been baselined. ◆ Leading the review. ◆ Answering questions and providing clarifying remarks as the review proceeds.

Task: Review Architecture with Stakeholders | 259

The purpose of reviewing the architecture with the stakeholders is to ensure that their concerns have been addressed or will be addressed. The logical architecture may not yet address all concerns (some concerns may not be addressed until the physical architecture is defined), but it should be a major step on the way to doing so. Architecture reviews are architectural testing, a safety net for the architect, planned and conducted in line with a risk-based testing strategy. (Buschmann 2009)

We recommend that before performing the review, you formally baseline the architecture and put it under change control so that from now on, all changes in requirements that affect the architecture can be controlled against this baseline. Whether baselining takes place before or after the review is a matter of some debate. Our preference, however, is to baseline first and handle review comments under change control. This method prevents the vicious circle of being unable to baseline the architecture because the review has highlighted problems, and addressing the problems results in an architecture that needs to be re-reviewed. Much has been written on performing architecture reviews, but one of the most definitive sources is the Software Architecture Review and Assessment (SARA) Report (SARA 2002).

Step: Baseline Work Products Baselining work products very simply consists of selecting the current set that represents the architecture (which are the ones output from this activity) and ensuring that the set is stored in a configuration management system with suitable version numbers applied. Then you need to publicize this set of work products as being the baseline so that it can be referred to for all follow-up activities, such as performing detailed design or defining the physical architecture (which we describe in Chapter 9, “Creating the Physical Architecture”).

Step: Assemble Work Products The primary input to the architecture review is the Software Architecture Document. All other work products may be made available for reference purposes during the review, however, including the requirements work products from which the architecture has been derived. As discussed in the previous task, the Software Architecture Document is populated from the various architecture-related work products, and these work products may also be included in the review.

260 | Chapter 8 Creating the Logical Architecture

Step: Review Work Products In this step, you review the architecture work products. This review may be no more than walking through the content of the Software Architecture Document, with the supporting work products available for reference if needed. Any problems discovered are documented in Change Requests. When the review is complete, you briefly capture the results of the review, including any action items, in a Review Record. Anything that needs to be raised as a project issue should be tracked in the project RAID Log. The review itself, depending on the architecture under review, may last from a few hours to a few days (or longer). Reviews typically examine the many aspects of the architecture in a similar vein to the verification performed, including clarification of the goals of the architecture (in line with the stated requirements), agreement on priorities, examination of the trade-offs made (such as flexibility versus performance), and consideration of the risks. This review serves as a quality gate for an iteration that ensures that the logical architecture is stable enough to support subsequent tasks, such as the detailed design of the logical architecture, the creation of an outline test plan, or the population of a project plan. As a result, it is important that the relevant parties participate in the review, including the Project Manager, Testers, and Developers, for example. In addition, the Application Owner will be interested in getting an overview of the architecture and an understanding of how it will meet the key strategic requirements, and users will need assurance that the key business requirements have been met.

Summary Defining a logical architecture is a critical part of the overall software development process that, if performed well, results in a more robust and understandable architecture, with a clear separation of concerns and a balanced division of responsibility between system elements. Defining the logical architecture is also a stepping stone that helps you move from the system requirements to the physical architecture. The Create Logical Architecture activity discussed in this chapter leads into the Create Logical Detailed Design activity (discussed in Chapter 1, “Introduction”), which fleshes out any remaining detail that may be required at a logical level, such as the detail of a particular business rule. In the next chapter, we describe how to use the logical architecture (and logical detailed design) to derive a physical architecture that directly supports subsequent development activities.

Chapter 9 Creating the Physical Architecture

In this chapter, we move from the logical architecture discussed in Chapter 8, “Creating the Logical Architecture,” to the creation of the corresponding physical architecture. Unlike its logical counterpart, the physical architecture acknowledges all the products and technologies that will be used for detailed physical design and, ultimately, coding. As described in Chapter 4, “Documenting a Software Architecture,” a model moves through discrete levels of realization during its life from an initial model whose content is very conceptual to a model whose content is detailed enough to be used as the basis for implementation. In this chapter, we show how the two key models used to describe the architecture of a system—the Functional Model and the Deployment Model—move from containing purely logical (or technology-independent) elements to containing physical (or technology-specific) elements. In this chapter, we describe each of the tasks that produce the physical architecture that realizes the requirements defined in Chapter 7, “Defining the Requirements,” and that evolves the logical architecture defined in Chapter 8. We assume that several work products are input to, and output from, the Create Physical Architecture activity, as shown in Figure 9.1. As you can see from this figure, consideration of the physical architecture involves both requirements and the logical architecture work products.

261

262 | Chapter 9 Creating the Physical Architecture

Output Work Products Input Work Products Architecture Assessment Business Entity Model

Architecture Assessment Architecture Decisions

Business Rules

Architecture Decisions Architecture Overview

Enterprise Architecture Principles

Architecture Overview Architecture Proof-of-Concept

Existing IT Environment

Architecture Proof-of-Concept Change Request

Functional Requirements

Glossary

Change Request

Data Model

Create Physical Architecture

Data Model

Deployment Model Non-Functional Requirements

Deployment Model

Prioritized Requirements List

Functional Model

RAID Log

Review Record

System Context

Software Architecture Document

Functional Model

RAID Log

Review Record

Software Architecture Document

Logical Architecture Physical Architecture Figure 9.1 Input and Output Work Products of the Create Physical Architecture Activity

Moving from Logical to Physical Architecture | 263

Moving from Logical to Physical Architecture Because the logical architecture is one of your primary inputs, when moving from the logical to physical architecture, you should understand what this input entails. As well as considering the requirements on the system, you must consider the various elements defined in the logical architecture, a diagram from which is shown in Figure 9.2. This figure contains both functional and deployment elements and shows many of the items that you need to consider in moving from the logical to physical architecture, including components, locations, nodes, node connections, and deployment units. Subsystems, component interfaces, operations, and various relationships are not shown to simplify the diagram. Each of these elements is discussed later in this chapter. In moving from logical to physical architecture, you make several choices:

■

Technology. This choice includes the platforms that will be used to define the execution environment, such as the Java Platform Enterprise Edition (Java EE) or Microsoft .NET, as well as any programming languages used to implement any components.

■

Products. This choice includes products that support the implementation and execution of any components, such as application servers and database servers, as well as hardware selection. Refer to the sidebar “Concept: Product” for a definition of what is meant by product in this context.

■

Reusable assets. Software assets (as discussed in Chapter 5, “Reusable Architecture Assets”) include packaged applications, existing components, and any legacy applications. You may also select hardware that is available from the existing IT environment.

■

Custom development. You may decide, for various reasons, that certain components should be custom built. Custom-built components provide the ultimate in flexibility because they are completely under your control. Such components usually target a specific set of capabilities and may be a cheaper option than purchasing a product if you need only a fraction of the capability that the product provides. In some cases, you may also build custom hardware.

Content Management Components

«deploy»

Content Management Server

Security Server

«deploy»

Security Components

Tour Booking Server

Integration Server

«deploy»

Integration Components «manifest»

«deploy»

«deploy»

«deploy»

«Boundary» CRM System Boundary

CRM Server

«manifest» «manifest» Tour Booking UI Components «manifest» «Boundary» Tour Booker Boundary

Tour Booking Control Components

Tour Booking Entity Components «manifest»

«manifest»

«Entity» Tour Booking Manager

«Control» Book Tour Controller

«manifest»

«manifest»

«manifest»

Figure 9.2 Subset of the Logical Architecture

«Entity» Tour Manager

«Entity» Tour Rules

«Entity» Transaction Log

«Boundary» Payment Engine Boundary

«Boundary» Reservation System Boundary

264 | Chapter 9 Creating the Physical Architecture

«Location» Central Office

Applying the Process | 265

Concept: Product Moving from the logical to physical architecture requires you to make decisions regarding technologies and products. We use the term product to represent something that is sourced from outside the organization, as opposed to something that is developed in-house. A product may represent software or hardware. A software product may be a complete application or part of an application (such as a configurable package or component). A commercial product (sometimes referred to as a commercial-off-the-shelf, or COTS, product) is one that is acquired through sale, lease, or license and includes licensed open-source products. From the perspective of a software development project, a commercial product requires you to consider product procurement.

Applying the Process As described in Chapter 3, “Method Fundamentals,” the architecture discipline follows the profile shown in Figure 9.3. The tasks associated with defining the physical architecture can start in an iteration of the Inception phase, when you may decide to base your solution on a set of existing software and hardware assets, for example. You place greater emphasis on these tasks in the Elaboration phase, when you concentrate on architecting the major (or, as we often call them, architecturally significant) elements of the system. As you move into the iterations of the Construction phase, physical-architecture tasks taper off as the focus shifts to completing the implementation, based on the architecture that has been defined thus far. We may give the impression that there is a clean separation of logical and physical architecture and that they are always performed in a simple sequence.

Inception

Elaboration

Incep Incep #1 #n

Elab #1

Phases Construction

Transition

Architecture Elab #n

Const #1

Const #2

Const #n

Iterations Figure 9.3 Physical Architecture and Iterative Development

Tran #1

Tran #n

266 | Chapter 9 Creating the Physical Architecture

You should remember, however, that an architecture is derived both top-down and bottom-up. Although you can derive the physical architecture from the logical architecture, some physical elements may be givens (and specified as constraints on the solution, for example) and you can model them straight away at a physical level without first considering the logical elements (although you may choose to represent the physical elements in any logical model in an abstract form). One thing you should avoid, however, is mixing logical and physical concepts in the same model or diagram. Mixing these concepts can lead to confusion about what elements have been addressed at a physical level and may skew any effort estimates for the completion of the architecture work. Mixing logical and physical elements in a single model or diagram is a form of view overloading (Rozanski 2005) and generally should be avoided. In this book, therefore, we always show logical and physical concepts in separate diagrams.

Creating the Physical Architecture: Activity Overview The creation of the physical architecture is simply a particular focus of the architecture tasks, so it should be no surprise therefore that the tasks themselves are exactly the same as those used to define the logical architecture, as shown in Figure 9.4. The only difference is the emphasis on the physical, rather than logical, aspects of the system under development. Following is a summary of these tasks, with a focus on the creation of the physical architecture: ■

The purpose of the Survey Architecture Assets task is to identify reusable architecture assets that can be applied to the system under development. You base your survey on the requirements and the logical architecture that has been defined.

■

The purpose of the Define Architecture Overview task is to identify and describe the major elements of the system under development. The physical architecture reflects the selection of key technologies, products, and reusable assets.

■

The purpose of the Document Architecture Decisions task is to capture the key decisions made in shaping the architecture and the rationale behind them. The emphasis in creating the physical architecture is on decisions related to the selection of technologies, products, and reusable assets.

Creating the Physical Architecture: Activity Overview | 267

An Iteration of the Create Physical Architecture Activity

Survey Architecture Assets

Define Architecture Overview

Document Architecture Decisions

Outline Functional Outline Deployment Elements Elements Verify Architecture Detail Functional Elements

Build Architecture Proof-of-Concept

Detail Deployment Elements

Validate Architecture

Update Software Review Architecture Architecture Document with Stakeholders

Figure 9.4 Overview of the Create Physical Architecture Activity

268 | Chapter 9 Creating the Physical Architecture ■

The purpose of the Outline Functional Elements task is to identify the major functional elements (subsystems and components) of the system under development. The focus is on how the functional elements are realized by products, reusable assets, and custom software elements.

■

The purpose of the Outline Deployment Elements task is to identify the locations across which the system under development will be deployed and the nodes within each location. The focus is on identifying physical computer platforms and other hardware devices, such as routers and firewalls.

■

The purpose of the Verify Architecture task is to verify that the architecture work products are consistent and to ensure that any concerns that cut across the architecture work products (a quality such as performance, for example) have been addressed consistently. This task is performed with respect to the elements that comprise the physical architecture.

■

The purpose of the Build Architecture Proof-of-Concept task is to synthesize at least one solution (which may simply be conceptual) that satisfies the architecturally significant requirements (or the required subset of these requirements) to determine whether such a solution, as envisaged by the architect, exists. In terms of the physical architecture, you accommodate the technologies, products, and reusable assets that have been selected.

■

The purpose of the Detail Functional Elements task is to refine the functional elements to the point that they can be handed off to detailed design. You ensure the presence of enough detail describing the physical architecture to make this handoff possible.

■

The purpose of the Detail Deployment Elements task is to refine the deployment elements to the point that they can be handed off to detailed design. Again, you ensure the presence of enough detail describing the physical architecture to make this handoff possible.

■

The purpose of the Validate Architecture task is to validate that the system as a whole is going to support the various stakeholder requests.

■

The purpose of the Update Software Architecture Document task is to document the architecturally significant elements in the Software Architecture Document. The various views are updated to reflect the physical aspects of the architecture.

■

The purpose of the Review Architecture with Stakeholders task is to obtain stakeholder agreement that the architecture, at its current level of elaboration, addresses the defined requirements. This task clearly means gaining agreement that the physical architecture is sufficient.

Task: Survey Architecture Assets | 269

Table 9.1 Elements Considered in the Outline and Detail Tasks Element

Outline

Detail

Functional

Subsystem Component Operation Location Node

Interface Mapping to data Operation signature Deployment unit Connection

Deployment

Because this chapter essentially repeats the tasks that we defined in Chapter 8, “Creating the Logical Architecture,” albeit focusing on physical rather than logical elements, we do not include the entire set of task descriptions in this chapter. Therefore, the reader should assume that all roles, work products, and steps are the same unless we say otherwise. As we discuss each task in this chapter, we refer to any logical elements that may have been created and that are at your disposal. In Chapter 8, you saw that the tasks that focus on functional elements and deployment elements are divided into outline tasks and detail tasks. We said that the outline tasks focus on those elements that are most significant to the architecture and that would be the responsibility of the Lead Architect on the project. The detail tasks are focused on the less-significant elements and are the responsibility of the architect with the relevant focus—such as the Application Architect, Infrastructure Architect, or Data Architect. Table 9.1 summarizes the physical elements considered in this chapter.

Task: Survey Architecture Assets When creating the logical architecture, you focus on assets that help you define the basic structures and interactions of architectural elements. When creating the physical architecture, you look for physical assets that help you realize the logical level structures and any interactions between logical elements. In this respect, the logical architecture acts as a set of requirements and constraints on the physical assets you might choose to realize your architecture. As mentioned in Chapter 8, “Creating the Logical Architecture,” this task is typically performed several times in the course of an iteration, because the reuse of architecture assets is always at the forefront of an architect’s mind at

270 | Chapter 9 Creating the Physical Architecture

various points during the creation of the physical architecture. This reuse reflects the many types of reusable assets that may be considered, ranging from a technology-specific reference architecture to a technology-specific design pattern. As a simple example, suppose that you have decided that the YourTour system will have a separate content management subsystem, the requirements for which will be analyzed and captured as responsibilities of the relevant functional element. For now, you are assigning a single Content Management component to the Content Management subsystem. That assignment may change later if you decide that you need to decompose the subsystem further or to source parts of it from different vendors. (The database may be separate from the content management workflow, for example.) The need for a content management solution was identified in both the logical Architecture Overview as well as the logical Functional Model. Furthermore, you will have determined the non-functional requirements on this component. Table 9.2 summarizes the characteristics of this component. Based on the description of the Content Management component, you would look for one or more existing assets that satisfy as many of these responsibilities and qualities as possible and draw up a list of potential candidate assets. Clearly, if no suitable asset can be found, you may look to a commercially available software product that you could use for this component. If no suitable candidates are found, you would need to consider building your own component. It’s important to remember that the Survey Architecture Assets task considers both software and hardware. Therefore, you may also consider those assets identified from the Existing IT Environment work product—including existing systems and infrastructure—that can be reused.

Task: Define Architecture Overview The purpose of this task is to identify and describe the major elements of the system under development that reflect any technology, product, and reusable asset selections that have been made. While you are realizing the Functional Model and Deployment Model in terms of technology-specific elements, it may be useful to reflect these elements in an Architecture Overview of the physical architecture. As for its logical counterpart, this Architecture Overview provides an initial sketch of the envisaged physical architecture. Figure 9.5 shows the Architecture Overview that represents physical elements of the YourTour system, in which (as you will see) a decision has been

Task: Define Architecture Overview | 271

Table 9.2 Component Description for the Content Management Component Component Name

Content Management

Description

Used to create, edit, search, and publish various kinds of digital media, including text files, video files, audio files, and any other kind of web content; also used for storing and versioning the content. This component also supports the ability to identify content management roles for users of the YourTour system as well as the ability to assign roles to the management of different content types. To support different user roles for the creation, update, and deletion of content. To support the ability to assign roles to different types of content. To support a workflow for the creation of content. To support workflow between different roles creating content. To support multiple versions of all content types. To support separation of content semantics from the way that the content is rendered. To support content capture from external sources (including scanning and from the web). To support the publishing of content in various sources (including HTML, XML, and PDF). The system will support people with visual, hearing, motor, or cognitive impairments in accordance with the YourTour organization standards. The system will be 99.9% available for functions requiring secure access (such as booking a tour). The system will be 99% available for all other functions (such as the ability to browse tours). Backup and maintenance operations will not require system shutdown. The system will use industry-standard web protocols for interoperability. The YourTour system will be made available through Internetenabled devices, such as web browser and personal digital assistants (PDAs).

Responsibilities

Non-functional requirements relevant to this component

made to base the architecture on Java EE technologies. (The use of Java EE is not shown explicitly in the figure, which shows only deployment elements.). As you can see from this figure, the updated Architecture Overview is influenced by the logical architecture but now shows physical nodes, rather than logical subsystems.

272 | Chapter 9 Creating the Physical Architecture

Outside World

Demilitarized Zone (DMZ)

Internal Network

CRM System

Tour Organizer

Customer

Web Server

Tour Booking Server

Integration Server

Sales Clerk

MyPay Payment Engine

MyReservation Reservation System Content Directory and Management Security Server Server

Figure 9.5 Physical Architecture Overview for YourTour

The connectivity shown in Figure 9.5 entails specific security considerations. The figure also includes firewalls to indicate the proposed security zones for the YourTour system. The placement of such firewalls follows the application of a standard pattern (IBM 2009) for systems that are accessed from the web, with an initial firewall protecting the system as a whole and another firewall providing additional security for elements that reside in the internal network. When creating the Architecture Overview representing the physical architecture, you should refer to the requirements that have driven the logical architecture, as well as the Architecture Overview representing the logical architecture. Although the logical architecture provides a first approximation of the architecture required, it may not take all the requirements into account— specifically, constraints that mandate the use of particular technologies or products. The Architecture Overview representing the physical architecture, on the other hand, does acknowledge such constraints, which is why you see specific references to the MyPay payment engine and the MyReservation reservation system in Figure 9.5; these elements are constraints on the solution that have been specified. Specifically addressing the non-functional requirements in the physical architecture is discussed in the sidebar “Concept: Addressing NonFunctional Requirements.”

Task: Document Architecture Decisions | 273

Concept: Addressing Non-Functional Requirements One of the major factors affecting the physical architecture is the approach taken to address non-functional requirements (both qualities and constraints). Although the architect takes certain steps to address these requirements in the logical architecture, such requirements are addressed more explicitly and fully in the physical architecture. In particular, many approaches take a rather idealized approach to deriving the logical architecture, wherein networks are infinitely fast; computers never fail; and processing power, disk space, and memory are infinite. You cannot escape such considerations when defining the physical architecture, however. Any “optimal” architecture that you may have described is brought back to reality quickly as you consider the physical considerations of the architecture in its environment.

The Architecture Overview is meant to be just that: an overview of the proposed architecture for communicating with various stakeholders. It is not meant to be a rigorous specification of the architecture from which a system could be built. This is the purpose of the more-detailed Functional Model and Deployment Model, which we focus on in subsequent tasks in this chapter.

Task: Document Architecture Decisions When considering the physical architecture, the architect makes decisions regarding the selection of particular technologies, products, reusable assets, and the like. In particular, the architect makes buy-versus-build decisions (which are discussed in more detail in the Outline Functional Elements task later in this chapter). It is important that the decisions be captured adequately to reflect the options that were considered and the rationale for deciding which option was selected. When making such decisions, you have several useful inputs. The RAID Log helps you focus on those areas where decisions need to be made. The architecture models (that is, the Data Model, Deployment Model, and Functional Model work products) ensure that any decision is made in the context of the evolving architecture. The Architecture Assessment and Architecture Proof-of-Concept work products are sources of quantitative information for selecting the right option and actually arriving at a decision.

274 | Chapter 9 Creating the Physical Architecture

Task: Outline Functional Elements This task focuses on realizing the logical subsystems and components by identifying their physical counterparts.

Mapping Logical Functional Elements to Physical Functional Elements This task focuses on identifying the subsystems and components that will comprise the physical architecture by ensuring that the logical subsystems and components that have been identified are realized appropriately. In Chapter 8, “Creating the Logical Architecture,” a subsystem is defined as a set of related components. That definition holds true for the physical architecture too, where a physical subsystem represents a set of related physical components. The mapping of logical subsystems to physical subsystems is normally fairly straightforward, and typically one-to-one. However, we may create additional subsystems that reflect technology-specific considerations. For example, we may identify a set of physical components that do not map one-to-one with their logical counterparts, and it would make sense to create additional subsystems within which these components reside. A physical subsystem could also represent a product which, although made up of several loosely coupled components, typically bundles all these components together. If you had chosen to procure a customer relationship management (CRM) subsystem rather than reuse an existing CRM system, for example, you might find that it consists of separate components for contact management, billing, order management, and so on (elements that you had considered separately) sold together as a single integrated subsystem. In terms of components, the realization of a logical component by a physical component is not always one-to-one, and all the following mappings are possible: ■

One-to-one. You can realize a logical component by using a single physical component if the responsibilities assigned to the logical component can be satisfied completely by one physical component. The Content Management component of the YourTour application may be mapped completely to a product, for example.

■

One-to-many. You can realize a logical component by using more than one physical component if, for example, you cannot realize that component exactly with a product or packaged application and have to part-buy and part-build components. In this case, you may have to separate responsi-

Task: Outline Functional Elements | 275

bilities across more than one physical component and provide a way of communicating among these components. ■

Many-to-one. You can realize many logical components by using a single physical component if you find that, for example, you can address the performance requirements only if you combine two logical components into a single physical component.

The preceding examples are specific examples of when to map, split, or aggregate when moving from logical components to physical components. A more complete checklist of things to consider is provided in the sidebar “Checklist: Mapping Logical Components to Physical Components.”

Checklist: Mapping Logical Components to Physical Components Consider a one-to-one mapping between a logical component and a physical component when: ■

A single physical component can support all the responsibilities of the corresponding logical component, using an appropriate implementation technology without breaking any of the principles of coupling, cohesion, or granularity that you use when assigning responsibilities to components.

■

A single physical component can support any non-functional requirements without the need for either a one-to-many or a many-to-one mapping.

Consider a one-to-many mapping between a logical component and physical components when: ■

Many physical components are required to realize the logical component. The physical components may be a combination of several products and custom built components.

■

Many physical components are required to support different service-level characteristics that have been assigned to the logical component. In the case of YourTour, for example, the ability to book a tour probably is needed 24 hours a day, but canceling a tour usually is required only during a normal working day, as this task probably requires additional confirmation and checking from a booking clerk. Continued

276 | Chapter 9 Creating the Physical Architecture

■

Many physical components are required to accommodate a particular architectural pattern that has been selected and that requires the responsibilities assigned to a logical component to be realized in multiple physical components.

Consider a many-to-one mapping between logical components and a physical component when: ■

A single physical component, such as a product, encapsulates the responsibilities assigned to several logical components.

■

A single physical component supports a service-level characteristic required of several logical components. Business rules that were spread across multiple logical components may need to be maintained in one place and may be brought together in a single rules-engine component, for example.

■

A single physical component that realizes several logical components is required to accommodate a particular architectural pattern that has been selected.

As far as possible, the logical architecture tries to ensure that components are independent of technology; the logical architecture can therefore be implemented with different technologies and products. In practice, when choosing technologies and products to realize the logical architecture, you must remember that each technology has its own idiosyncrasies, which means that you have to do some work to interpret these differences to ensure an unambiguous specification of the components so that they can be further detailed and implemented. Then the physical architecture becomes a blueprint for designers and developers to follow. A simple example is consideration of the implementation of interfaces in a programming language. You may have put a great deal of effort into specifying interfaces at a logical level to help yourself make better-informed decisions when selecting physical elements. Also, you may have a one-to-one mapping between logical and physical elements and may want to retain the interfaces as best you can in the physical architecture. Although interfaces are supported explicitly in some programming languages, such as Java and C#, they are not supported explicitly in languages such as C++, C, and COBOL, so you would need to devise a scheme to support interfaces in these languages.

Task: Outline Functional Elements | 277

Another area that warrants consideration is how any technology provides exception handling, transaction handling, persistence, integration, and the like. Such areas often represent architectural mechanisms, which are among the types of assets discussed in Chapter 5, “Reusable Architecture Assets.”

Identifying Physical Functional Elements Following is an obvious sequence in which you can identify physical subsystems and components: 1. Survey the complete set of logical subsystems and components contained in the Functional Model, and for each, decide whether it will be realized with an available asset or product, or whether it needs to be built. 2. For each component that is to be realized with an asset or product, liaise with the Project Manager to initiate the procurement process to buy that product. 3. For each subsystem or component that is to be built, decide on the implementation technology, and provide enough guidance to ensure that detailed design and implementation of the component can proceed smoothly. Here, we use the term buy to mean procuring anything that already exists, including any of the types of assets discussed in Chapter 5, “Reusable Architecture Assets,” and products from commercial software or hardware vendors. The asset may already exist in the organization (that is, it was developed for another project or as part of a corporate reuse program). Guidance on whether to buy or build varies from organization to organization as well as project to project. In deciding whether to buy or build, it is worth reviewing the checklist in the sidebar “Checklist: Buy versus Build Decisions.” We strongly recommend that the architect be involved in procurement decisions, especially where the requirements are complex and several alternatives must be considered. It is important that the overall technical integrity of the system under development be maintained; the architect has the big-picture view of what this system should be, so the architect is the person best placed to be involved in this process and ensure this integrity. When several options are available, it is worth recording these options and the rationale for the final selection in the Architecture Decision work product. Remember that when you are considering these options, it is important to look at both non-functional and functional criteria. A product or asset may appear to satisfy all your functional requirements but may be woefully inadequate when it comes to qualities such as performance and availability, especially if the product or asset is immature or relatively new to the market.

278 | Chapter 9 Creating the Physical Architecture

Checklist: Buy versus Build Decisions The following questions can be applied when trying to make “buy versus build” decisions. In this checklist, the term product typically refers to something from outside the organization, but we use the same term in this checklist to refer to reusable assets inside the organization, because you need to ask many of the same questions when reusing assets that have been produced by another team or business unit. ■

■

■

■

■ ■ ■

■

■

■

■

■

■

Does a corporate-wide policy favor buy versus build (or the other way around)? In the event that no products exist that completely provide the required functionality, is it worth considering changing the requirements so that a product can be reused? If an existing product requires a lot of customization before it can be used, would it be better to custom-build the solution instead? Is the required component leading edge or unique in the sense that no comparable products exist or, if they do, are likely to be unstable or immature? Is the product vendor financially sound? What support options are available from the vendor? How are problems raised and escalated with the vendor, and what service-level agreements (SLAs) are offered (such as turnaround times for problem fixes)? Are any financial implications related to any ongoing maintenance costs of using an existing product (including upgrades)? Have maintenance costs been factored into the decision and the total cost of ownership (TCO) calculated? Does the product vendor have an acceptable policy regarding migration that allows, for example, data to be migrated with minimal disruption to ongoing operations? Does integration of any product require specialist skills that are hard to come by? Is customization of any product particularly onerous and time-consuming, which could lead to schedule slippage? Is any product required dependent on other products or platforms, and have these products or platforms been factored into the decision-making process?

Task: Outline Functional Elements | 279

■

■ ■ ■ ■ ■

Is the product at the correct version number to be compatible with other products that may be used? (Vendors often issue new versions of products that may make the products at least temporarily incompatible with other products—either their own or those from other vendors.) Does any product have credible references of previous (and successful) use? Does the vendor have a long-term road map for the product? Is the vendor credible and aligned with where you want to go as a user? Are the product release timelines acceptable? Are any suitable cost-free options available, such as open-source software that isn’t licensed? (Although this class of software may be perceived as being too risky for an enterprise to build mission-critical systems, it may have been built by a dedicated online community of developers and may even be of higher quality than commercial software. For a certain class of system, this route can be very favorable. When using open-source software, you should be aware that even though the license may be free, you will have ongoing support costs.)

In conclusion, most IT systems are a combination of off-the-shelf products and assets and custom-built elements. Ensuring that all these elements work together, while satisfying the system’s requirements, is clearly the responsibility of the architect.

Procuring Products After you decide which components need to be procured, you probably need to follow some kind of procurement process to ensure that the products are selected in the proper way, as discussed in the sidebar “Guideline: Product Selection.” The reusable assets you seek to procure may align with the architectural layers if you have used a layering strategy based on reuse. In particular, you can separate the following: ■ ■

Business-specific elements, such as a CRM system or enterprise resource planning (ERP) system. Business-independent elements, such as security packages (lightweight directory-access protocol servers and public key infrastructure software, for example), systems management software, relational database management systems, application servers, transaction processing monitors, and system software (operating systems, for example).

280 | Chapter 9 Creating the Physical Architecture

Guideline: Product Selection Following is a simple technique for selecting software products: 1. Review the criteria for product selection. Most organizations have a list of preferred vendors as well as criteria for product selection. If an Enterprise Architecture exists, that architecture almost certainly includes policies that also guide the selection of products. You should review the criteria to ensure that rules and policies are met. 2. Identify the criteria that will be used to perform an evaluation of candidate products, some of which may be considered to be mandatory (resulting in a failure if not met) and some of which are simply desirable. 3. Determine how the criteria will be scored, which may be as a binary value (the candidate either does or does not meet the criterion), a fixed value (from a set of possible values, such as “very good,” “good,” “average,” or “poor,” for example), or a range of values (any number between 0 and 10, for example). Also consider whether a weighting factor should be applied to some criteria, as not every factor will be equal when you determine the suitability of the product for the system under development. 4. Identify a candidate list of products that may meet the evaluation criteria defined. Clearly, this step may require a considerable amount of research, including requests to vendors to present their products, as well as visits to sites where the products are already being used (reference sites). 5. Perform the actual evaluation by assessing each candidate and recording the assessment against the criteria. In some circumstances, it may be necessary to create prototypes to assess the relative merits of competing vendor products. These prototypes may be built by the architecture team or by the vendors themselves.

Accommodating Technology-Specific Patterns An excellent resource to have on hand when moving to a particular technology is a set of technology-specific patterns. Many vendors produce patterns that describe how to use their products, which may include elements based on open standards. IBM (IBM 2009), Sun (Sun 2009), and Microsoft (Microsoft 2009) all provide advice and guidance on their websites for this purpose. These patterns can be used to see how particular components might be implemented. Sun, for example, produces a set of Java EE blueprints (Sun 2009) that show how Java EE constructs can be applied.

Task: Outline Functional Elements | 281

The following examples use Java EE to highlight certain principles. We provide a summary of Java EE in the sidebar “An Overview of the Java Platform, Enterprise Edition (Java EE).”

An Overview of the Java Platform, Enterprise Edition (Java EE) Figure 9.6 summarizes some of the key technologies used in a typical Java EE application, aligned by architectural tier. This figure contains the following elements: ■

A markup language (such as HTML or XML). The markup language is rendered on a client device (such as a web browser).

■

Java Servlets (servlets). A servlet defines how a request from the client is processed and how a response is generated. Servlets execute in a web container (described later in this sidebar).

Client

Server Presentation Tier

Business Tier

Data Tier JDBC

Client Device

HTTP HTTPS HTML, XML

Web Server

EJB Server

Web Container

EJB Container

JSP

JPA

Relational Database

Relational Database

JAX-WS

Web Service

JMS

Message Queue

JCA

External System

EJB Servlet

Figure 9.6 Java EE Overview

Continued

282 | Chapter 9 Creating the Physical Architecture

■

JavaServer Pages (JSPs). A JSP is a text document that, like a servlet, describes how a request is processed and a response generated. JSPs provide an alternative to servlets when generation of statements in a markup language (such as HTML) is required. JSPs execute in a web container. The JavaServer Faces (JSF) framework builds on JSP technology.

■

Enterprise JavaBeans (EJBs). An EJB is responsible for implementing an aspect of the business logic of a Java EE application and for storing, where relevant, persistent data. EJBs execute in an EJB container.

■

Java DataBase Connectivity (JDBC). JDBC provides programmatic access to a relational database.

■

Java Persistence API (JPA). JPA supports persistence of data through an object-to-relational mapping, allowing persistent objects to be treated as plain old Java objects (PoJos). This is achieved through Java annotations that declare the persistent fields of an object and that in essence provide a mapping between a field of the object and a field in a database table. An annotation is metadata that declares some intent for the platform to add some functionality via injection at run-time.

■

Java API for XML Web Services (JAX-WS). JAX-WS provides support for SOAP/XML-based web services.

■

Java Message Service (JMS). JMS provides a standard interface to reliable asynchronous messaging implementations (such as IBM’s WebSphere MQ).

■

Java EE Connector Architecture (JCA). One of the common requirements of an enterprise application is to connect to external resources. Some of these resources may be external applications accessed via a vendor-specific protocol. JCA provides a standard means for providing resource adapters (more commonly known as connectors).

Containers Central to the J2EE platform is the concept of a container. A container provides run-time support for application components (such as JSPs, servlets, and EJBs) that execute within it. An EJB container provides component life-cycle management (the container creates and removes application components as required), transaction management, security, and persistence support to the EJBs that execute within it, for example. EJB Interfaces A client’s access to an EJB is provided through interfaces. A client never interacts directly with the EJB implementation, as the Java EE platform maps the

Task: Outline Functional Elements | 283

methods of the interface to the equivalent methods of the EJB implementation. The EJB interface can be declared for local (co-located) or remote (distributed) access. Session, Entity, and Message-Driven EJBs EJBs come in three distinct flavors: session beans, entity beans, and messagedriven beans. Session beans, as the name suggests, are beans whose state is valid in the context of a user session. The Java EE platform specifies two types of session beans: stateless session beans and stateful session beans. A stateless session bean is intended to be very lightweight in that it maintains no conversational state whatsoever. Stateless session beans are often used as controllers that coordinate a series of interactions between other EJBs but don’t actually maintain any state of their own. A stateful session bean, on the other hand, does maintain in-memory state between one invocation and the next within the context of the user session. A shopping cart, for example, could be implemented as a stateful session bean. Entity beans represent coarse-grained elements that manage long-lived state; therefore, they are provided support for persistence. Examples of entity beans are Customer, Order, and Product. An entity bean may use the JDBC API, but may also use the EJB3/JPA APIs if an object-to-relational mapping managed by the platform is required. In addition to session beans and entity beans, the Java EE platform specifies message-driven beans. Message-driven beans are designed to support asynchronous communication. A client sending messages to message-driven beans does not block waiting for a response after sending a message. For all types of EJBs, annotations can be provided that allow the EJB container to manage the EJB appropriately. In addition, annotations allow the automatic generation of a web service wrapper for the EJB.

In addition to deciding among the various patterns available, you need to decide how, given the selected technologies, elements in the logical architecture are mapped to elements in the physical architecture. Following are some simple rules based on the selection of the Java EE platform: ■

A boundary component that represents an interface with a person will be implemented using JSPs and servlets.

■

A boundary component that represents an interface with an external system will be implemented as a session EJB and use JMS to provide connectivity.

284 | Chapter 9 Creating the Physical Architecture ■

A control component will be implemented as a session EJB.

■

An entity component will be implemented as an entity EJB.

Putting this all together, Figure 9.7 provides an example of a technologyspecific pattern using the YourTour Book Tour Controller logical component. In this figure, the Book Tour Controller provides and requires various interfaces. The logical architecture infers that the Book Tour Controller is stateless, in that any request passed to it is simply passed on to the appropriate required interface. In moving from the logical to physical architecture, the Sun Java EE pattern session façade has been chosen. The session façade pattern “defines a higherlevel business component that contains and centralizes complex interactions between lower-level business components” (Sun 2009). Figure 9.8 shows the structure of this pattern. As you can see, the session façade is implemented as a session EJB and manages relationships between one or more BusinessObjects. Each BusinessObject is instantiated as either a session bean or an entity bean. When implementing

«interface» ITourBookingControl «interface» ITourControl

select tour ( ) add tour participant ( ) add tour participant options ( ) book tour ( )

get tours ( )

«provides»

«provides»

«Control» Book Tour Controller

«requires» «interface» ITour get tours ( )

«requires» «interface» IPayment provide payment details ( )

«requires» «interface» ITourBooking create tour booking ( ) add tour participant ( ) add tour participant options ( )

«requires» «interface» IPaymentEngine process payment ( )

Figure 9.7 Component Specification Diagram for the Book Tour Controller

«requires» «interface» IReservationSystem make reservations ( )

Task: Outline Functional Elements | 285

«SessionEJB» SessionFacade

Client 1

*

BusinessObject

accesses 1

1..*

«EntityEJB» BusinessEntity

«SessionEJB» BusinessSession

Figure 9.8 Session Façade Java EE Pattern

the session façade pattern, you need to make several architectural decisions, such as the following: ■

Should the session façade be a stateful or a stateless session bean? This decision depends on the interface provided by the session façade. A scenario that needs only one method call to complete a given service is nonconversational and so can be implemented with a stateless session bean. If the scenario requires multiple method calls to complete, however, the service is conversational, which means that some state must be saved between each method invocation. In this scenario, a stateful session bean would be used to implement the session façade.

■

How should the business object be implemented? The choices given by the pattern are that the business object can be a session bean or an entity bean. Session beans typically provide a business service that does not maintain any persistent data, whereas entity beans do maintain persistent data.

Figure 9.9 shows how the session façade pattern has been used to realize the Book Tour Controller component. The BookTourController façade provides a single interface for accessing all information related to a tour booking, including tour participants, their preferred options, and payment information related to the booking. The façade is a stateless session bean because it maintains no

286 | Chapter 9 Creating the Physical Architecture

«SessionEJB» BookTourController

«SessionEJB» TourManager

«SessionEJB» TourBookingManager

«SessionEJB» ReservationSystem

«SessionEJB» PaymentEngine

Figure 9.9 Tour Booking Manager Realized as a Session Façade

state between method invocations. This session façade wraps several session EJBs, all acting as business objects in the pattern: ■

A TourManager session EJB, which manages tour information

■

A TourBookingManager session EJB, which manages tour booking information

■

A ReservationSystem session EJB, which acts as an interface to the reservation system

■

A PaymentEngine session EJB, which acts as an interface to the payment engine

To describe the characteristics of the physical elements more completely, you may create a set of requirements realizations based on physical elements to ensure that the relevant responsibilities are assigned to them. As discussed in Chapter 8, “Creating the Logical Architecture,” you typically achieve this goal by producing one or more sequence diagrams to show how components interact to realize the requirements. See the sidebar “Concept: Requirements Realizations in the Physical Architecture” for a brief discussion of the merits of creating these types of diagram for the physical architecture.

Concept: Requirements Realizations in the Physical Architecture In Chapter 8, “Creating the Logical Architecture,” we introduce the concept of a requirements realization. This concept allows you to express explicitly how a given requirement (functional or non-functional) is realized in terms of solution elements. In that chapter, we show how requirements are realized in

Task: Outline Functional Elements | 287

terms of logical elements. You can use the same approach to show how requirements are realized in terms of physical elements. The extent to which you perform this task in the physical architecture depends on several factors, however. If you have chosen not to create a logical architecture (for reasons described in Chapter 8), you cannot imply any realization of requirements by tracing the physical elements to the logical elements from which they are derived and which in turn trace to the requirements they realize. In this case, you may choose to perform a relatively extensive analysis of how requirements are realized by physical elements. At the other extreme, if you have performed an extensive analysis of how requirements are realized by logical elements, you may not explicitly show the realization of any requirements by physical elements, because we can imply this by tracing physical elements to those logical elements that do realize the requirements. The most common approach lies somewhere between the two options: You realize a key set of requirements in terms of logical elements but also selectively show how certain requirements are realized in terms of physical elements.

Figure 9.10 shows a sequence diagram containing components from the physical architecture that realize the main flow of the Book Tour use case. In creating such diagrams, we are defining operations on the target EJBs. In addition, we could have created a similar diagram showing a use-case flow of events realized in terms of interactions between user interface elements, such as JSP pages. In Figure 9.10: ■

The client calls the session façade, BookTourController, to get a list of tours. The BookTourController calls the TourManager EJB to get a list of tours.

■

The client calls the BookTourController to select a tour. The BookTourController calls the TourBookingManager EJB to create a new tour booking.

■

The client calls the BookTourController to add tour participants. The BookTourController calls the TourBookingManager EJB to add the tour participants to the booking.

■

The client calls the BookTourController to add tour participant details. The BookTourController calls the TourBookingManager EJB to add the options for each tour participant.

:BookTourController

:TourManager

:TourBookingManager

1: getTours 1.1: getTours

2: selectTour 2.1: createTourBooking

loop [0,*]

1: addTourParticipant 1.1: addTourParticipant

loop

1: addTourParticipantOptions

[0,*]

1.1: addTourParticipantOptions

3: bookTour 3.1: savePaymentDetails

3.2: processPayment 3.3: placeReservations

Figure 9.10 Participants in the Main Flow of the Book Tour Use Case

:PaymentEngine

:ReservationSystem

288 | Chapter 9 Creating the Physical Architecture

:Client

Task: Outline Deployment Elements | 289 ■

The client calls the BookTourController to book the tour. The BookTourController calls the TourBookingManager session EJB to record the payment details associated with the tour booking. Then the BookTourController calls PaymentEngine session EJB to make the payment with the payment system. Finally, the BookTourController calls the ReservationSystem session EJB to place the reservations by using the reservation system.

Task: Outline Deployment Elements This task focuses on identifying the physical deployment elements in terms of technologies, products, and custom-built elements. This task is concerned with the following: ■

Overall hardware configurations that address the required service-level characteristics, such as fail-over, scalability, and security.

■

Specifications of the hardware required, such as processors (based on their speed), disk configurations, and network bandwidth and latency.

■

Specifications of the software required (such as operating-system software), together with required versions and any detailed configurations.

■

Product selection of hardware and software for computers and the networks that connect them.

Mapping Logical Deployment Elements to Physical Deployment Elements The mapping of logical locations to physical locations is simply a case of identifying the number of physical locations in the solution. For example, a “branch office” logical location may be mapped to physical locations of “New York branch office” and “Tokyo branch office.” You may not always have such a straightforward one-to-one mapping of logical nodes to physical nodes, however. As for the functional elements, the transition from the logical to the physical architecture may result in splitting or aggregating nodes for various reasons: ■

One-to-one. You can realize a logical node by using a single physical node if the specification of the logical node can be satisfied completely by one physical node.

■

One-to-many. A single logical node may need to be split across multiple physical nodes to meet performance, availability, or other non-functional requirements. Clearly, this has implications not only for the deployment elements, but also for the functional elements (which may themselves need to be split to accommodate the physical distribution).

290 | Chapter 9 Creating the Physical Architecture ■

Many-to-one. Logical nodes may end up as being partitions on physical nodes rather than separate processing units; a physical node may satisfy the needs of more than one logical node. Consolidation of more than one logical node into a single physical node may also be required when, for example, a packaged application has been selected that is deployed to a single physical node (to provide tighter coupling but improved performance and management, for example) whose capabilities were originally architected as residing on separate nodes.

Identifying Physical Deployment Elements Taking into account the general guidance in the preceding sections, you can develop the physical deployment elements as follows: 1. For each logical location, define how many physical instances of this location there will be and where, geographically, these locations will be placed. 2. For each node assigned to the logical location being considered, create a corresponding physical node (bearing in mind the need to split or aggregate nodes, as described in the preceding section). 3. Tag the node with an alignment to a specific hardware product (assuming that nodes are procured and not built).Where no obvious alignment exists, simply list candidates, and identify the preferred option based on the requirements (especially non-functional requirements).This may result in multiple nodes residing at a single location, where each node represents a candidate hardware product. 4. Size the physical nodes by reviewing the non-functional requirements and—based on required throughput, availability, scalability, and so on— coming up with suitably sized platforms (that is, platforms with a suitable number of instances, amount of disk space, processor speed, and so on). On a large, distributed system, this task is a significant one in its own right and may involve doing detailed performance modeling, possibly aided by building a further Architecture Proof-of-Concept to support the sizing estimates. Figure 9.11 shows the level of detail you would expect after following the preceding steps. The figure shows the Central Office location of the YourTour system, which physically resides in London, and shows the servers, workstations, and other devices together with their physical attributes. In particular,

Task: Outline Deployment Elements | 291

«Location» London Central Office

Disk Array

Admin Client

Mfr = Sun Model = Fire X4140 Disk = 1Tb

CPU = 1x1.2GHz Model = Dimension Memory = 2Gb Mfr = Dell Disk = 160Mb

Web Server CPU = 1x1.2GHz Model = p310 Memory = 1Gb Mfr = IBM

Content Management Server CPU = 1x1.2GHz Model = p310 Memory = 1Gb Mfr = IBM

Tour Booking Server CPU = 2x1.2GHz Model = p320 Memory = 4Gb Mfr = IBM

Database Server CPU = 2x1.2GHz Model = p320 Memory = 2Gb Mfr = IBM

Security Server CPU = 1x1.2GHz Model = p310 Memory = 1Gb Mfr = IBM

Integration Server CPU = 2x1.2GHz Model = p320 Memory = 2Gb Mfr = IBM

Figure 9.11 The Central Office Location in the Physical Deployment Model

you see the addition of a database server with an associated disk array for storing any YourTour persistent data. We have also shown the likely connections that will be needed between the nodes. These connections will be confirmed and updated as necessary when deploying the physical components onto the nodes in the task Detail Deployment Elements. Connections from the Admin Client are not shown, as there is a connection to all other nodes in this figure (with the exception of the Disk Array, which is a device).

292 | Chapter 9 Creating the Physical Architecture

Admin Client «Location» London Central Office

1

5

CPU = 1x1.2GHz Model = Dimension Memory = 2Gb Mfr = Dell Disk = 160Mb

Figure 9.12 Representing the Number of Nodes at a Given Location

It’s also possible to show the number of nodes required at each location within a Unified Modeling Language (UML) model by creating a composition aggregation relationship between the location and the nodes it contains. Then this relationship can show the multiplicity of the relationship. Figure 9.12 shows that the London Central Office location has five Admin Client nodes. This information is clearly important in procuring hardware—the topic of the next section.

Procuring Hardware The logical Deployment Model acts as a specification for the deployment elements that are needed to realize the system under development. Unlike the case with functional elements, it is much more likely that items needed to realize the deployment aspects of the system will be bought rather than built. Unless the system under development is very specialized, it is highly unlikely that anything other than off-the-shelf hardware will be used to realize the physical node descriptions specified in the physical architecture. Having decided which hardware elements need to be bought (procured), you probably need to follow some kind of procurement process to ensure that the hardware is selected in the proper way, as discussed in the sidebar “Guideline: Product Selection” earlier in this chapter. This guidance is most relevant when a choice of hardware is available, with many options supporting the same hardware specification.

Task: Verify Architecture As stated previously when we considered the logical architecture in Chapter 8, “Creating the Logical Architecture,” the Functional Model and Deployment Model usually are developed by different roles, and the two models inevitably become misaligned to some extent. The purpose of this task is to ensure that

Task: Build Architecture Proof-of-Concept | 293

the architecture is defined consistently across these work products, and they have, together, addressed all of the requirements. As stated in Chapter 8, “Creating the Logical Architecture,” verification helps you answer the question “Am I building the product right?” In other words, have you followed the method and conformed to any development standards? The secondary purpose of this task is to ensure that all decisions, as captured in the Architecture Decisions work product and possibly quantified by data obtained from any Architecture Proof-of-Concept (discussed next), are reflected in the architecture models.

Task: Build Architecture Proof-of-Concept After you make the key decisions about the specific technologies to be used in the architecture, it often makes sense to prove the architecture through the creation of an Architecture Proof-of-Concept. Then you can use information gleaned from building and executing this proof-of-concept to refine the architecture. The sidebar “Checklist: When to Create an Architecture Proof-of-Concept” provides some examples of when a proof-of-concept may be required.

Checklist: When to Create an Architecture Proof-of-Concept An Architecture Proof-of-Concept should be considered when any of the following statements hold true: ■

Are some functional requirements only partially addressed and require further proving?

■

Is performance or any of the other required system qualities likely to be an issue, and do detailed metrics proving that the system is likely to meet these qualities need to be established?

■

Are some components considered to be high risk or leading edge in what they are required to do and, therefore, need to be proved?

■

Are products being used that need to interface with other products or existing systems, and do these interfaces need to be proved?

■

Do products being used have an existing user interface that you need to show to end users to verify that their needs are satisfied?

■

Are products or packages being used that require complex customization or configurations? (Some products can be configured in many ways, which can affect the performance or availability of the product.)

294 | Chapter 9 Creating the Physical Architecture

The context and scope of the Architecture Proof-of-Concept are usually decided by reviewing the various architecture models, which will highlight one or more areas of concern from the above list. You should also examine the project RAID Log to help determine which areas of technical risk have been identified and ensure that the proof-of-concept focuses on addressing these areas where necessary and applicable.

Task: Detail Functional Elements As for the Outline Functional Elements task, each technology has its own idiosyncrasies that influence the detailing of the functional elements defined in terms of interfaces and operation signatures. You know, for example, that you access the EJB implementations through a business interface rather than directly (and that the Java EE environment will inject the right code into the application to make this access possible). In this task, you take these idiosyncrasies into account while providing enough information to allow designers and developers to build the system. Then the physical architecture becomes a blueprint for designers and developers to follow. The execution of this task follows, exactly, the description given for detailing functional elements in the logical architecture, as discussed in Chapter 8, “Creating the Logical Architecture.” In practice, especially with standard technologies such as Java EE and .NET, often it is sufficient simply to associate a technology-specific pattern with the element concerned in terms of providing a detailed-enough specification to support detailed design or coding. Consider the BookTourController shown in Figure 9.13, which shows the operations that have been assigned to it based on the realization of all the use-case flows in which it participates. You know that the BookTourController is a stateless session EJB. You may also stipulate, in a pattern, that all EJBs be fronted by a JavaBean class that pro-

«SessionEJB» BookTourController getTours ( ) selectTour ( ) addTourParticipant ( ) addTourParticipantOptions ( ) bookTour ( )

Figure 9.13 Operations on the BookTourController Session EJB

Task: Detail Functional Elements | 295

vides simplified access to EJBs. Rather than specify this JavaBean class, you can simply state the pattern once and imply these elements without ever expressing them explicitly in your models. This approach can apply to other elements too, which can be useful because then you can keep your models as simple as possible (and not clutter them with unnecessary detail) without losing any useful detail. You can add further detail by providing the operations signatures as well as preconditions and postconditions. Detailing the signatures in this way in the physical architecture ensures that the components are defined unambiguously in terms of their interface. This means you can hand the components over to the developers to implement, safe in the knowledge that (provided that the interface is complied with) the component will be implemented as intended. Figure 9.14 shows the same BookTourController session EJB together with the Java classes that are used as parameter and return types. Again, you would look to the logical architecture to get a sense of the information that needs to be passed in each operation but also apply any technology-specific considerations when specifying these elements in your physical architecture. As you did for the logical architecture, it is in the detailing of the Functional Model that you make the connection between components (and their

addTourParticipant precondition { If the number of participants will exceed the maximum capacity for the tour associated with the booking Then the participant is not added to the booking and the operation returns false Else The participant is added to the booking and the operation returns true } «SessionEJB» BookTourController getTours ( ) : Tour [*] selectTour ( tour : Tour ) : TourBooking addTourParticipant ( booking : TourBooking, participant : TourParticipant ) addTourParticipantOptions ( participant : TourParticipant, options : TourParticipantOption [1..*] ) bookTour ( tour : TourBooking )

«JavaClass» Tour

«JavaClass» TourBooking

«JavaClass» TourParticipant

«JavaClass» TourParticipantOption

Figure 9.14 Parameter Types on Operations of the BookTourController Session EJB

296 | Chapter 9 Creating the Physical Architecture

interfaces) in the Functional Model and elements in the Data Model (although this time, the Data Model is considered in terms of physical tables). Clearly, you have identified elements that are persistent (in a Java EE environment, this is data managed by the entity EJBs or JPA objects). A subset of the persistent elements is shown in Figure 9.15, which uses a UML profile to describe the structure of a relational database (where each class represents a database table, certain attributes are stereotyped as being a primary key, and a foreign key is implied by a role name on an association). The structure of the database reflects the structure of any persistent classes and is influenced by the business types identified in the logical architecture, as well as the Business Entity Model. Although not shown in Figure 9.15, it is also possible to explicitly show a relationship between a database table and any persistent classes that use this table.

«Table» Address «primaryKey» reference line1 line2 city state zipcode country

«Table» Tour «primaryKey» reference name capacity public : Boolean description margin

«Table» TourBooking

- tour_reference 1

*

«primaryKey» reference 1

- tourbooking_reference

1 1

* «Table» TourParticipant «primaryKey» reference firstName lastName dateOfBirth passportNumber

- tourparticipant_reference 1

1

- contactDetails

«Table» ContactDetails «primaryKey» reference phone fax email

Figure 9.15 Extract from the Physical Data Model

Task: Detail Deployment Elements Detailing deployment elements is concerned primarily with identifying the deployment units that associate the physical components with the physical nodes and the connections that must exist between nodes to support the interactions between the physical components.

Task: Detail Deployment Elements | 297

Having identified the physical components and specified them to the level where they can be procured or built, you can consider where these components are deployed physically. This task considers the following: ■

For custom-built components, determining how these components will be packaged in such a way that they can be deployed to the relevant physical nodes by identifying suitable deployment units.

■

For products that have been selected, reviewing the product documentation and working out how the products are to be deployed alongside the system under development. For any customizable components (such as packaged applications) that have been selected, you also need to ensure that all configuration options and any customizations that need to be made are specified.

Table 9.3 shows the mapping of a subset of the physical components to deployment units for the YourTour application. This mapping is a reflection of the deployment units identified in the logical architecture but takes technology considerations into account, as well as the fact that these physical components need to be deployed on different servers, as shown in Figure 9.16. JSPs and servlets are deployed in a WAR file, whereas EJBs are deployed in a JAR file on the Java EE platform, for example. As well as assigning components to deployment units, you can assign the deployment units to the relevant nodes. Figure 9.16 depicts a subset of the updated Deployment Model for the YourTour Central Office location, showing the placement of the tourBookingUIComponents.war and tourBookingEntities .jar deployment units. Any connections are added or refined as a result of the interactions that take place among the components deployed on each of the nodes.

Table 9.3 Mapping Components to Deployment Units Component

Component Type

Deployment Unit (DU)

DU Type

TourManager TourBookingManager BookTourController ReservationSystem PaymentEngine CRMSystem TourBookerInterface

Entity EJB Entity EJB Session EJB Session EJB Session EJB Session EJB JSPs

tourBookingEntities.jar tourBookingEntities.jar tourBookingControllers.jar integrationComponents.jar integrationComponents.jar integrationComponents.jar tourBookingUIComponents.war

JAR JAR JAR JAR JAR JAR WAR

298 | Chapter 9 Creating the Physical Architecture

«Location» London Central Office Web Server

Tour Booking Server

«deploy»

tourBookingUIComponents.war

«manifest»

«ServerPage» BookTour.jsp

«manifest»

«ServerPage» Tour.jsp

«deploy»

tourBookingEntities.jar

«manifest»

«SessionEJB» TourBookingManager

«manifest»

«SessionEJB» TourManager

Figure 9.16 Components Assigned to Servers (Subset) in the London Central Office

Although diagrams such as that shown in Figure 9.16 are good for showing summary information of deployments, you can capture only so much detail in such diagrams. In most real-world scenarios, you are likely to need additional supporting information, such as that shown in Table 9.4. This detailed physical

Table 9.4 Component Mapping for the Tour Booking Server Node Node: Tour Booking Server CPU: 2x2.1GHz Model: p320 Memory: 4GB Manufacturer: IBM Component

Version

TourManager TourBookingManager Solaris IBM WebSphere Application Server

V1.0.0 V1.0.0 V9.0.0.3 V7.1.1

Task: Detail Deployment Elements | 299

specification of the node shows all components deployed to it, including technical elements such as the middleware and operating system. Remember that at this stage the detailed physical design has still not been done; the architect is simply providing guidance to ensure that the detailed physical design will be done within necessary constraints (to ensure the integrity of the architecture). Planning early how the system will be packaged and deployed is particularly important for large, complex, distributed systems, which may have many different elements to be deployed. When packaging the software into appropriate deployment units, you should consider the following: ■

The linkage with any configuration management and change-control processes and systems. The deployment units must reflect the right versions of the various components and products they contain. On a related note, you should consider dependencies among the different software elements, especially where common libraries are needed that may come from different vendors.

■

The physical mechanism by which the software will be shipped and installed (such as providing access over the Internet, shipping disks, or sending someone out to install the software physically).

■

Considerations involving internationalization and various locale-specific data and resources that must be made available.

■

The various testing environments that must be supported and the software configuration needs for each environment. Most systems require at least unit, integration, system, and acceptance testing to be performed, and each system may well require a different environment in which to perform that testing. How software will be deployed in these environments and how it will be promoted between environments is very much the concern of the architect.

The architect should also be conscious of certain operational concerns that need to be accommodated after the software has been deployed, because these concerns can affect the physical architecture. The architect should consider the following: ■

The mechanism by which any new system is populated with data. The architect needs to focus not only on how new data gets put into the system (users, products, customers, and so on), but also on how existing data gets migrated from the system that is being replaced (if this is the case). Data migration is the name given to the process of loading data from an existing system onto the new system. In a large, complex development, this

300 | Chapter 9 Creating the Physical Architecture

process may be a complete project itself, requiring the analysis of existing data, the cleansing of that data to remove errors and duplications, and the development of a strategy for how existing data will be moved (a “bigbang” approach in which data is moved wholesale just before cutover to the new system, for example, or a phased approach in which data is moved a piece at a time). Data migration might also introduce new subsystems and components into the architecture, such as an Extract, Transform, and Load (ETL) subsystem or file-transfer components. ■

Constraints involved in scheduling updates to existing systems, especially if those systems are live and need to be running around the clock.

During this task, you also refine the number of each type of physical node required by considering some of the required service-level characteristics involving performance, availability, and scalability. High or continuous availability may be achieved only by ensuring duplication of some nodes, for example, so that if one node fails, another can be switched in. Similarly, scalability requirements may demand the use of multiple processors (referred to as vertical scalability) or multiple nodes (referred to as horizontal scalability), and such considerations add to the more detailed specification of the deployment nodes as a result. Based on the connections between nodes (and locations) defined in the physical architecture, you can also determine how these connections will be realized using either the existing network or new network devices such as local- or wide-area networks, routers, bridges, and so on. This task entails sizing the traffic across those connections that result from implementing the new system to ensure that sufficient capacity is available, so that that the network does not become a bottleneck and adversely affect performance.

Task: Validate Architecture Validating the physical architecture builds on the task of the same name performed during the specification of the logical architecture and addresses the question, “Am I building the right system using the set of technologies and products that have been selected?” In other words, will the system meet the stated requirements and, therefore, meet stakeholders’ expectations? The steps that you carry out in performing the validation are the same as those described for the corresponding task in defining the logical architecture. The criteria being addressed are different, however, or at least have a different focus. The criteria to consider when performing an architecture validation at the physical level are similar to those for the logical-level architecture; appropriate checklists are provided in Appendix B, “Viewpoint Catalog.”

Task: Review Architecture with Stakeholders | 301

When you are validating the architecture, all the models built so far (that is, the Functional Model, Deployment Model, and Data Model) will be validated against known requirements. In addition, key decisions documented in the Architecture Decisions work product (and supported by the Architecture Proof-of-Concept) will be used during the validation together with the Architecture Overview work product.

Task: Update Software Architecture Document The Software Architecture Document is updated to reflect the physical architecture that has been defined. As we mention earlier in this book, the purpose of the Software Architecture Document is to provide a vehicle for summarizing all the relevant architecture-related information in one place for the purpose of communicating and reviewing the architecture. This document usually is a subset of all the information available in the referenced work products. The challenge you face in updating the Software Architecture Document to include the physical architecture is deciding whether to extend any existing document or to break a potentially large document into several separate documents that together comprise the Software Architecture Document work product. This separation can be achieved in several ways. You could separate based on logical versus physical architecture or by architectural view, for example. The main reasons for bringing together the architecture work products in one overarching work product (the Software Architecture Document) is to allow the work done to date to be communicated to all team members and also reviewed by stakeholders so that they can sign off. With respect to stakeholder signoff, most projects of any significant size have one or more authorization-to-proceed (AtP) points, which need to be passed successfully before the release of further funding or resources. To satisfy the input to an AtP, the significant work products that are to be reviewed as part of that AtP usually need to be baselined at an agreed level. This is one of the primary reasons for creating the Software Architecture Document, which serves as a point-in-time view of the architecture that stakeholders can review and agree on.

Task: Review Architecture with Stakeholders This task is almost identical to the equivalent task described in Chapter 8, “Creating the Logical Architecture,” although it is performed with respect to the

302 | Chapter 9 Creating the Physical Architecture

physical architecture. In this task, you first baseline the physical architecture work products and then review the Software Architecture Document and supporting architecture work products with the key stakeholders. Any problems discovered are documented in Change Requests. When the review is complete, you briefly capture the results of the review, including any action items, in a Review Record. This review serves as a quality gate and ensures that the physical architecture is stable enough to support tasks that depend on it. As a result, it is important that the relevant parties participate in the review—the Project Manager, Testers, and Developers, for example.

Summary Developing software architecture is an iterative process. The architect must continuously refine, verify, and validate the architecture and also gain agreement with stakeholders who have interests in the system under development. Furthermore, as information is gathered and requirements are better understood, the architect is able to move from a conceptual view of the architecture to a more physical view. In this chapter, we have shown how you can refine and elaborate on the elements in the logical architecture by applying the same process pattern to create a physical architecture that clearly identifies the technologies, products, assets, and custom-built elements used to design and build the system. Chapter 10, “Beyond the Basics,” examines other aspects of a software development project, as well as the particular challenges of architecting in complex environments.

Chapter 10 Beyond the Basics

The process discussed in Chapters 7 through 9 focuses on describing the essential tasks performed in a typical software development project, with emphasis on the role of the architect. The context for this description is a relatively straightforward tour booking system. In this chapter, we examine other aspects of a software development project and, in particular, the involvement of the architect with respect to other aspects of software development not discussed so far, such as test, configuration management, change management, and the development environment. In addition, even though the case study exemplifies various architectural challenges, such as addressing system qualities and considering integration and packaged applications, additional complexities may also warrant consideration. These complexities include accommodation of large systems, large teams whose work must be coordinated, and a distributed development team—all of which are considered in this chapter.

The Architect and the Project Team As the technical lead for the project, the architect has an influence on many aspects of a software development project. We discuss the involvement of the architect in the requirements discipline in Chapter 7, “Defining the Requirements.” In Chapter 8, “Creating the Logical Architecture,” and Chapter 9, “Creating the Physical Architecture,” we focus on the core architecting tasks in which the architect is involved. 303

304 | Chapter 10 Beyond the Basics

The purpose of this section is to examine other aspects of a software development project and, in particular, the involvement of the architect with respect to other disciplines and, therefore, with other roles on the team. [A discipline is a] primary categorization mechanism for organizing tasks that define a major “area of concern” and/or cooperation of work effort. (OpenUP 2008)

The Architect and Requirements The role of the architect with respect to requirements is discussed in detail in Chapter 7, “Defining the Requirements.” In that chapter, you see that the architect has a varied set of responsibilities with respect to requirements, as summarized in Figure 10.1. The most significant contributions made by the architect are to ensure that the more technical users of the system (such as the System Administrator) are considered, to ensure that the more technical requirements (especially non-functional requirements such as qualities and constraints) are captured and detailed appropriately, and to assist with the prioritization of requests and the resulting requirements.

The Architect and Development The purpose of the development discipline is to perform detailed design tasks, to define the organization of the implementation, to implement the detailed design elements, to unit-test the implementation, to integrate the work of individual developers, and ultimately to produce an executable system.

Ensure that technical users are considered Ensure that external systems are considered

Software Architect

Ensure that non-functional requirements in particular are emphasized Articulate the implications of a requirement on the solution

Business Analyst

Prioritize requirements

Figure 10.1 The Role of the Architect with Respect to Requirements

The Architect and the Project Team | 305

Clearly, the architecture is input to the detailed design activities, because it identifies the major components of the system and their interfaces, as discussed in some detail in Chapter 9, “Creating the Physical Architecture,” including the identification of deployment units such as the executable work products. The architect’s influence does not end there, however. As shown in Figure 10.2, the architect is also responsible for the architecturally significant aspects of the implementation such as the implementation structures that will be used to organize the source code. A well-structured implementation supports concurrent development, whereby different elements of the system can be implemented in parallel by different developers (or teams of developers). The architect is also responsible for identifying any development-related standards, guidelines, and reusable assets. Another consideration for the architect with regard to implementation is the sequence in which the various elements of the implementation are integrated to provide the delivered system. Again, the architecture provides an excellent guide in terms of integration and testing. It should be possible to create the system as a succession of builds that are individually integrated and tested, for example. While such considerations may appear to be rather detailed, an architect avoids such details at their peril, as discussed in the sidebar “Pitfall: Avoiding the Technical Details.” As well as providing specific input on certain technical matters relating to development, architects are also responsible for the technical outcome as a whole, and they apply themselves accordingly. This situation is true of all disciplines and the development discipline in particular. Rather than involving themselves only in those areas for which they are responsible, architects typically work closely alongside project team members to guide and mentor them

Identify elements to be designed and implemented Identify significant implementation structures (e.g., code organization) Software Architect

Influence sequence in which elements are implemented and integrated

Developer

Ensure that architecture decisions and standards are complied with

Figure 10.2 The Role of the Architect with Respect to Development

306 | Chapter 10 Beyond the Basics

Pitfall: Avoiding the Technical Details In Chapter 2, “Architecture, Architect, Architecting,” we say that it is important for the architect to have technology knowledge, design skills, and a level of programming skills. Although architects may focus primarily on the significant elements of the architecture, on occasion they need to get involved in the details in terms of the detailed design and coding. A particular pitfall for architects is always handing off the details to others, considering such details to be outside their concern. Such architects lose the respect of their teammates and tend to get a bad reputation with many negative characterizations, such as being hand-wavers, being remote from the project in their ivory tower, or being able to talk the talk but not walk the walk. Good architects get their hands dirty and, when required to, get deeply involved in the technical details.

in their work. In particular, the architect ensures that any architecture decisions and standards are complied with.

The Architect and Test The purpose of the test discipline is to find and document defects in software quality, to advise about perceived software quality, and to validate that the system functions as designed and as required. Complementing the unit testing performed in the development discipline, the test discipline focuses on the integrated units provided by the developers and the system as a whole. In particular, the test discipline considers integration testing, system testing, and acceptance testing. Integration testing, as its name suggests, focuses on testing the work of several developers as an integrated whole. System testing focuses on testing the entire system and validating the end-to-end functioning of the system. Acceptance testing typically is the final test action before the software is deployed in production. The goal of acceptance testing is to verify that end users can use the software to execute the functionality of the system. The architect’s participation in the test discipline is shown in Figure 10.3. The architect ensures that the architecture is testable and, more informally, tested. From the perspective of testability, the architect ensures that the system can be assessed with respect to the defined functional and non-functional requirements. In terms of non-functional requirements, the architect must ensure that run-time qualities can be assessed and, depending on the constraint defined, any constraints assessed. If a requirement states that all communica-

The Architect and the Project Team | 307

Ensure that the architecture is “testable”

Software Architect

Ensure that the architecture is tested (especially significant elements,including relevant qualities and constraints)

Tester

Figure 10.3 The Role of the Architect with Respect to Test

tion between the system and external systems be encrypted, for example, there must be some way of capturing the information being passed from the system to the external systems so that the encryption can be assessed. In addition, it is in the best interest of the architect to ensure that the system under development has been tested thoroughly, because the quality of the resulting system is largely their responsibility, as they are the technical lead on the project. As such, architects often work with the test team to ensure that the more challenging requirements on the system result in a corresponding emphasis on the testing activities. Because the architect contributes to the prioritizing of requirements (and, therefore, to the requirements considered within a given iteration) and identifying the solution elements that satisfy the requirements, the architect is in a good position to identify those areas of the system that should be tested at any point in time. The architect also works with the test team to determine whether any opportunities exist for optimizing the creation of test harnesses (and test data).

The Architect and Project Management The purpose of the project management discipline is to provide a framework for managing the project; to provide practical guidelines for planning, staffing, executing, and monitoring the project; and to provide a framework for managing risk. As mentioned in Chapter 2, “Architecture, Architect, Architecting,” the architect supports the planning process in terms of scheduling, work allocation, cost analysis, risk management, and skills acquisition, as shown in Figure 10.4. In Chapter 2, we conclude that much of the support provided is because the architecture identifies the significant components in the system and the relationships between them, and then uses this information appropriately. Although there is a separation between a person and a role in the process described in this book (whereby the same person can play many roles), a particular pitfall is for the same person to take on the role of architect and Project

308 | Chapter 10 Beyond the Basics

Provide input into scheduling Provide input into work allocation Provide input into costing Software Architect

Identify risks and their mitigation

Project Manager

Identify skills required and their acquisition

Figure 10.4 The Role of the Architect with Respect to Project Management

Manager, as discussed in the sidebar “Pitfall: The Architect and Project Manager Are the Same Person.”

The Architect and Configuration Management The purpose of the configuration management discipline is to identify and manage elements that should be placed under configuration management control. Many elements need to be accommodated: documents, models, source code, executable code, project plans, test scripts, and so on. These elements are versioned individually and also assigned to one or more configurations, where a configuration defines a particular version of a system or part of a system. Elements may be entire work products (if a single file represents the entire work product) or parts of a work product (if a file represents part of a work product, such as a use-case specification representing part of the Functional Requirements work product). A necessary element of a configuration management strategy is appropriate tooling that supports a repository of all elements (and, therefore, of the project work products). The tooling is used throughout the project life cycle and contains both current and historical versions of the elements. A good configuration management tool also provides measurements based on the information it holds, such as the rate of change of elements (which may provide an indication of stability and may be of particular interest to the architect). The repository structure often is a reflection of both the work products that are defined for the project and, for certain elements, the architecture that has been defined (when storing models or code, for example). This alignment makes it easier for team members to identify where to place their work in the version control system. Therefore, the architect ensures that appropriate structures are

The Architect and the Project Team | 309

Pitfall: The Architect and Project Manager Are the Same Person The role of the architect and the role of the Project Manager are both significant and often time-consuming. These two roles also have very different focuses. A project in which a single person plays both roles is rarely successful, because there is always a bias toward one role or the other. As a result, one of these roles is performed inadequately. The beneficial interplay that always occurs between architect and Project Manager is also missing, although it may go on in the person’s head!

defined, as shown in Figure 10.5. Failing to perform this alignment is discussed in the sidebar “Pitfall: Configuration Management Ignores the Architecture.” This structuring should also minimize the need to compare and merge changes as practitioners work on the various elements concurrently. In addition to defining the structure of the elements in the configuration management repository, the architect helps define the approach to changing elements stored in the repository. It may be decided that only one person at a time can work on a source-code file, for example. In this case, the file in question is locked when it is checked out, meaning that others can get a copy of the file but cannot change it. If you decide that two or more practitioners can work on the same file concurrently, it will be necessary to compare and merge changes when each practitioner checks his or her changes into the repository. Configuration management also has a close relationship with any build-andrelease mechanisms in place. Such mechanisms automate the steps for compiling, testing, and packaging software for distribution. Each step will result in files being accessed from the configuration management system so that, for example, the final executable system is constructed from the correct versions of the constituent parts.

Influence the structure of any configuration management repository Software Architect

Structure elements to support concurrent work

Configuration Manager

Figure 10.5 The Role of the Architect with Respect to Configuration Management

310 | Chapter 10 Beyond the Basics

Pitfall: Configuration Management Ignores the Architecture Development teams can get themselves into real trouble if they pay insufficient attention to the configuration management strategy. This situation can occur when a team does not appreciate the relationship between architecture and configuration management. The main symptom is that a system is built that does not reflect the changes that have been made in the project work products. This situation may occur when files are stored in the wrong place in the configuration management repository because the structure is not well defined. Old versions of elements (which are stored in the correct repository location) are then used by practitioners in preference to the most recent versions (which are stored in the wrong repository location). Another reason is that changes in files are lost as different practitioners fail to compare and merge their changes correctly when too many practitioners are allowed to work on the same files at the same time. This situation typically is the result of inadequate consideration of what information is stored in what files and how the files are likely to be accessed by practitioners in doing their work. Both of these challenges can be influenced by the architect, who is able to make informed decisions regarding the files being stored and the access that will be required. The architect in particular wants to encourage as much concurrent work as possible while ensuring that a simple configuration management repository structure is in place, with associated policies.

The Architect and Change Management Another discipline closely related to configuration management is change management. The purpose of the change management discipline is to restrict and audit changes to work products. In particular, a change management discipline includes consideration of the organization elements required (such as a changecontrol board) to assess the cost, schedule, and impact of a change in an existing system. It also includes the ability to track changes in work products, which serves as a history and rationale of changes made in the software. Finally, the change management discipline is concerned with measuring the current state of the product based on the type, number, rate, and severity of defects found and fixed during the course of product development. Given this scope, an important benefit of architecting is that it supports impact analysis, allowing architects to reason about the impact of making a change before it is undertaken, as shown in Figure 10.6. An architecture identi-

The Architect and the Project Team | 311

Software Architect

Identify the impact of making any changes in terms of elements affected, cost, and risk

Change Manager

Figure 10.6 The Role of the Architect with Respect to Change Management

fies the major architectural elements and their interactions, the dependencies between elements, and the traceability from these elements to the requirements that they realize. A change in a requirement can be analyzed in terms of the impact on the elements that collaborate to realize this requirement, for example. Similarly, the impact of changing a given element can be analyzed in terms of the other elements that depend on it. Such an analysis can also greatly assist in determining the cost of a change and the risk associated with making the change. This information is used when the change-control board (in which the architect participates) prioritizes the change.

The Architect and the Development Environment The purpose of the development environment discipline is to provide a software development environment that will support the development team. The environment itself comprises several elements and, in larger organizations, may have a department or team that is dedicated to providing this environment. This team may even include the role of a development environment architect (Eeles 2008). The elements of a development environment include a method or process that describes how the members of the development team should work together, tools to automate aspects of the method, materials for enabling team members in particular skills, and infrastructure to support the method, tools, and enablement. In addition, the environment may include the organization that supports the environment, such as a dedicated support department, as well as guidance on how a project adopts the environment. The architect is involved in several of these elements, as shown in Figure 10.7. The architect is responsible, for example, for defining any architecture standards or guidelines that the team should use (including any standard for documenting the architecture) that are part of the method. In general terms, a standard is something that must be adhered to and, from an architecture-related perspective, could encompass technology standards (such as Java Enterprise Edition [EE] standards), development standards (such as design or

312 | Chapter 10 Beyond the Basics

Define architecture standards and guidelines Identify tools to support any architecture standards Software Architect

Consider required integrations between tools Ensure that infrastructure is available to implement and test the system

Development Environment Architect

Figure 10.7 The Role of the Architect with Respect to the Development Environment

programming standards), and so on. A guideline, on the other hand, provides prescriptive guidance on how to undertake one or more activities (such as how to identify architecturally significant solution elements from the system requirements). The architect also provides input on any tools selected, because these tools need to support the development standards that the architect has mandated. If the architect has stipulated that Unified Modeling Language (UML) will be used for documenting the architecture and detailed design, for example, a suitable UML modeling tool is required. Similarly, if the implementation technology is Java-based, appropriate Java tooling is required. In addition, the architect ensures appropriate integration between the tools, such as the ability to transform from UML to Java code (in the example given), and vice versa, if these transformations are considered to be desirable. This thinking, of course, can be applied to other technology stacks, such as .NET. The architect also ensures that an appropriate infrastructure is in place to support not only the development tooling, but also the execution and test of the system under consideration.

The Architect and Business Analysis The architect may want to undertake business analysis to gain an understanding of current problems in the organization and identify areas of potential improvement. This improvement may be provided through the implementation of applications that automate aspects of the business. Such automation may address problems such as poor performance or excessive human error, for example. Business analysis may also be undertaken to ensure that customers, end users, and developers have a common understanding of the structure of the tar-

The Architect and External Influences | 313

get organization. This understanding may be communicated as precise definitions of roles, responsibilities, and interactions between elements of the organization. This understanding often takes the form of a Target Operating Model (TOM ) or organizational blueprint. Business analysis can also be undertaken when deriving requirements on applications that are built to support the organization. A particular application may be required to interoperate with other applications (that automate other aspects of the business), for example, and may be accessed by certain roles within the organization (that might result in a requirement to access the application through certain devices, such as a cell phone for mobile users). On a closely related note, business analysis is also undertaken when a perspective that spans individual applications is required and business alignment is valuable. An excellent example is the identification of common business tasks and entities that ultimately leads to the identification of businessrelevant services in a service-oriented architecture (SOA). Such services may support the execution of several business processes and are reused within several applications. The outputs from business analysis is discussed, to some extent, in Chapter 7, “Defining the Requirements,” where we consider the use of the Business Process Model, Business Entity Model, and Business Rules work products. These work products are used to derive the system requirements needed to support the target organization. In some situations, such work products are not readily available. Understanding the broader context within which the system exists can be of great value, however, so the only option is for the development team that is delivering the system to perform some amount of business analysis. This is why we include this discipline in this discussion. All the business analysis work products influence the work of the architect either directly or indirectly. These work products influence the system requirements and therefore indirectly influence the work of the architect. The architect also appreciates the broader context within which the system must operate, however, and refers to the business analysis work products, if they exist.

The Architect and External Influences The architecture of an IT system, which is the focus of this book, is not developed in isolation. Several external influences guide its definition and must be taken into account if the system is to meet all its requirements and address the stakeholder concerns. In particular, four external influences nearly always need

314 | Chapter 10 Beyond the Basics

to be considered in the context of the project that is responsible for developing a system (including its architecture). These external influences are ■

Enterprise architecture

■

Design authority

■

Infrastructure provider

■

Application maintenance provider

These influences and their relationships to the development project and the associated system are shown in Figure 10.8 and described in the sections that follow. Both enterprise architect and enterprise architecture are included. The relationships shown in Figure 10.8 are ■

Enterprise architect, design authority, infrastructure provider, and application maintenance provider are all kinds of stakeholders.

■

Enterprise architects create an enterprise architecture.

■

An enterprise architecture provides guidance for a development project.

■

A design authority governs the development project.

■

A development project develops a system.

Stakeholder

Enterprise Architect

Design Authority

Infrastructure Provider

Application Maintenance Provider

*

- creates

- interprets

Enterprise Architecture

- governs * - provides guidance for

- runs

*

Development Project

- maintains System

- develops

Figure 10.8 External Influences on the IT System Architecture

The Architect and External Influences | 315 ■

A design authority interprets the policies and principles laid down by the enterprise architecture.

■

An infrastructure provider runs the deployed system when the development project is complete.

■

An application maintenance provider maintains the system after it has been deployed.

Enterprise Architecture According to The Open Group Architecture Framework (TOGAF), the primary reason for developing enterprise architecture is To support the business by providing the fundamental technology and process structure for an IT strategy. This in turn makes IT a responsive asset for a successful modern business strategy. (TOGAF 2009)

Although there is no industry-wide agreement on exactly what enterprise architecture is, most descriptions seem to agree that it should cover these four areas: ■

Business architecture. This area includes the strategies, goals, policies, key business processes, and organizational aspects (roles and organizational structures) of the business.

■

Information architecture. This area includes the key information assets of the organization, including logical and physical data models, resources, and metadata.

■

Application architecture. This area includes inventories and logical and physical models that describe the application software and interfaces, and how they support the business processes of the organization.

■

Technology architecture. This area describes the physical hardware needed to support the deployment of the applications and data. It typically also includes middleware, database software, communications, transaction processing, operating systems, and programming languages.

This book is not about enterprise architecture, but it recognizes that when an organization has defined such an architecture, systems that are built need to comply with the areas that the enterprise architecture covers. Several work products that we introduce in earlier chapters may be in the domain of the

316 | Chapter 10 Beyond the Basics

enterprise architecture and act as inputs into the tasks in the architecting process we describe in Chapters 7 through 9. ■

Enterprise Architecture Principles. We envisage these principles as covering one or more of the four architecture areas just described and see it as the role of the design authority to ensure that the project team developing the system complies with those principles.

■

Business Entity Model. This work product defines the main business entities in the enterprise as part of the information architecture. Architects use a subset of this work product to define the logical Data Model.

■

Business Process Model. This work product defines the key business processes that form the business architecture.

■

Business Rules. This work product defines the key business rules that govern how the business operates and is also part of the business architecture.

■

Existing IT Environment. This work product may be developed by the enterprise architect as part of the application and technology architecture. It is a catalog of parts that describes the current IT systems.

Design Authority The design authority is responsible for the overall technical integrity of the system and provides the necessary governance that links the IT system under development to the enterprise architecture goals, strategies, and principles, thus ensuring that the system will meet the requirements. One of the key reasons for having a separate design authority overseeing the development of a system is to reduce the risk of cost overruns or failure to meet the requirements or schedule. A design authority can take various forms, depending on the size and complexity of the system: ■

For a small system, the design authority may be just the Lead Architect. The system is small enough that it can be understood by one person, who can ensure the overall technical integrity is being maintained.

■

For a system of medium complexity, the design authority may be a dedicated architect with one or more specialist architects reporting to him or her on a part-time basis.

■

For a large and complex system, the design authority may consist of a fulltime team of architects with a design authority lead and various specialist roles reporting to the team.

The Architect and External Influences | 317

The responsibilities of the design authority are many and varied, but most design authorities assume at least the following responsibilities: ■

Define and run the various controls that are needed to ensure that the architecture is developed consistently and supports the requirements.

■

Ensure compliance with all mandated internal and external standards and regulatory controls.

■

Ensure that an effective development process (and tooling) is in place and is being followed.

■

Be accountable to the various stakeholders that have concerns and interests in the system, and act as the interface between the technical team developing and building the system and the stakeholders.

Design authorities sometimes are incorrectly called technical design authorities. In the authors’ opinion, however, a design authority should be a mixture of business and technical roles, so to prevent confusion, the term technical probably should not be used. The work products discussed in the process described in this book, which are relevant to the design authority, are ■

The Enterprise Architecture Principles developed by the enterprise architects that need to be complied with

■

The Architecture Decisions to which the design authority contributes

■

The Architecture Assessment that is produced as the result of performing an architecture validation (one of the key ways of ensuring compliance with internal and external standards)

Infrastructure Provider When a system has been developed, it needs to be operated on a suitable infrastructure (that is, on computer platforms, networks, and other hardware). The organization providing this infrastructure may or may not be part of the organization for which the system was built. In the era of cloud computing, the infrastructure provider often is external to the organization that uses the system. To know what it needs to do to run and operate the system, the infrastructure provider needs to be involved in the development process as a key stakeholder. The infrastructure provider provides input into the Non-Functional Requirements (since the provider needs to convey what is and isn’t possible)

318 | Chapter 10 Beyond the Basics

and is involved in developing the Deployment Model, which is the primary work product that describes the infrastructure to be built. The provider is involved in any architecture reviews and has an interest in the Architecture Assessment work product that is the result of performing an architecture validation.

Application Maintenance Provider Just as the infrastructure provider may be an external provider, so may the people who maintain the application after the system has been developed and deployed, particularly when economies of scale can be obtained by having multiple applications maintained by dedicated maintenance staff. More likely, however, applications are maintained remotely in regions that have lower labor costs and that can provide dedicated maintenance teams around the clock. The application maintenance provider clearly needs to understand the details of the applications to be maintained, so it needs to provide its requirements early in the development of the system. These requirements usually focus on particular qualities that need to be achieved, such as maintainability, portability, and manageability, because they may indicate constraints on what is possible or, alternatively, want early indicators of skills and resources that they may need to acquire. As such, the application maintenance provider usually is one of the stakeholders providing input into the Non-Functional Requirements work product. This provider also is interested in the Functional Model and Data Model in particular, as these models provide high-level descriptions of the applications and data that need to be maintained.

Architecting Complex Systems In Chapters 7 through 9, we have looked at the approach that an architect might take in architecting a relatively straightforward system for a mediumscale project—that is, one that has between 10 and 100 people working on it. In this section, we look at some of the challenges of architecting complex systems, such as those that involve systems of systems with more than 100 people typically being involved in the development. Figure 10.9 shows a summary of such complexities and the best practices that are used to address them. These characteristics are not necessarily independent, of course. A system that has a large number of functions to be developed is also likely to need a large number of people to develop those functions. Separating the various chal-

Architecting Complex Systems | 319

Many distinct functions are being developed Many people are involved in development

Ensure the architecture is componentized appropriately

The system is highly distributed

Establish and govern architecture standards

The development team is distributed Operational qualities are extremely challenging

Ensure that qualities drive the architecture definition

There is a system of systems

Formally describe the architecture as a “system of systems”

Figure 10.9 Challenges of Complex Systems and Associated Best Practices

lenges, however, allows us to describe each challenge in the following sections. For each challenge, we discuss the following: ■

Why the characteristic is considered to be a property of a complex system

■

Any additional considerations that should be made when developing the architecture of such a system

■

The effect on the architecture tasks that allow the architect to develop the architecture for such a system

Many Distinct Functions Are Being Developed A system that is large in scope is not necessarily complex. The system may have many screens to create or many transactions to be described, for example. If all these elements follow a common pattern, the challenge is simply one of manpower, not of complexity. If such patterns are not readily visible, however, the system is deemed to be complex due to its sheer size. This situation has ripple effects in all aspects of the development effort, from requirements to architecture to coding to test.

320 | Chapter 10 Beyond the Basics

In terms of the architecture and the tasks performed by the architect, separation of concerns is a sensible approach to managing such complexity. This topic is discussed in the sidebar “Best Practice: Ensure That the Architecture Is Componentized Appropriately.”

Many People Are Involved in Development Many metrics can be used to measure the size of a system. One metric that is sure to indicate system complexity is the number of resources (people) required to develop the system. The complexity arises not through the sheer amount of work to be performed, but through the communication that is required among the people. Such communication channels sometimes break

Best Practice: Ensure That the Architecture Is Componentized Appropriately Appropriate chunking or componentization of the architecture can help you address many challenges of complex systems. In preceding chapters, we discuss several techniques that fall into the category of componentization: ■

Consideration of the architecture at both a logical and physical level. A logical architecture in particular can provide a set of high-level abstractions that allows you to reason about the complexity.

■

Consideration of a layered architecture. Different elements of the architecture reside in different layers, which can help you by providing suitable homes for the architectural elements.

■

Consideration of subsystems. Separation of the architecture into subsystems, with each subsystem comprising a cohesive set of elements, can help you focus on the bigger picture without getting bogged down in the detail.

■

Consideration of coupling and cohesion heuristics when identifying components. Separation of the architecture into components (in the most general sense) that have a cohesive set of responsibilities and welldefined interfaces, and that are reused throughout the architecture, can also help you manage complexity. These heuristics apply equally to deployment elements in accommodating a highly distributed system.

These techniques translate into distinct practices and tasks performed by the architect.

Architecting Complex Systems | 321

down, such as when important messages do not propagate to those who need to know. In addition, it is important for the work itself to be coordinated in an appropriate manner and every effort should be made to ensure that everyone is working to plan, delivering the various project work products at the right time and in the right order. When many teams are involved in a project, it is crucial to develop an outline architecture as soon as possible to allow the project to be structured based on a separation of concerns (such as a team per subsystem), because the allocation of resources and work items is influenced by the architecture to some extent. If a packaged application is to be used to implement a major aspect of the system, for example, the sooner this situation is identified, the better, because a significant portion of the effort (and therefore resources) may need to focus on customizing this packaged application, and this task may require particular skills to be available at a particular time. Again, this situation can benefit from an appropriate separation of concerns, as discussed in the preceding sidebar, “Best Practice: Ensure That the Architecture Is Componentized Appropriately.” In addition, to ensure the integrity of the architecture, it is wise to establish architecture standards for the development and to ensure that these standards are adopted through appropriate governance, as described in the sidebar “Best Practice: Establish and Govern Architecture Standards.”

Best Practice: Establish and Govern Architecture Standards To ensure the integrity of the architecture across the team (which may be large and distributed), it is important to establish the relevant standards that all team members conform to when designing or developing the solution. Such standards may include architecture and design patterns to be applied, modeling standards, and programming standards. Enforcement of such standards can be governed by a design authority, if one is in place. If the application of a standard results in work products being created in a consistent form (all components must expose one or more interfaces, for example), it may be possible to automate adherence to such standards if supporting development tools are available. A particular industry standard for thinking about automation as a fundamental aspect of the development approach is provided by the Model Driven Architecture (MDA) initiative from the Object Management Group (OMG). MDA defines several concepts, as shown in Figure 10.10. Continued

322 | Chapter 10 Beyond the Basics

CIM to CIM Transformation

Computation Independent Model (CIM) CIM to PIM Transformation

PIM to PIM Transformation

Platform Independent Model (PIM) PIM to PSM Transformation

PSM to PSM Transformation

Platform Specific Model (PSM) PSM to Code Transformation Code

Figure 10.10 MDA Concepts and Terminology

MDA defines several categories of models: ■

Computation Independent Model (CIM). This model defines elements that are independent of the type of solution, whether this solution is software, hardware, or people. Business models fall into this category and include the Business Process Model and Business Entity Model.

■

Platform Independent Model (PIM). This model defines elements that are technology independent. The Functional Requirements, Non-Functional Requirements, logical Functional Model, and logical Deployment Model fall into this category.

■

Platform Specific Model (PSM). This model acknowledges technology. The physical Functional Model and physical Deployment Model fall into this category.

Architecting Complex Systems | 323

■

Code. Although not often considered to be a model, the source code that comprises the system is also an abstraction (it must be converted to machine code before it executes, even if an interpreted language is used, rather than a compiled language).

A transformation is another concept that MDA emphasizes. A transformation defines the rules by which a model is transformed into another and is a good way of enforcing consistency and, therefore, architecture integrity. Figure 10.11 shows an example in which a PIM is transformed into a PSM for Enterprise JavaBeans (EJBs, which represent large-grained solution components), a PSM for SQL (representing the persistent elements in a relational database), and a PSM that describes the rules for mapping from EJBs to SQL (sometimes referred to as an object-to-relational mapping). The PSM defining EJBs can be transformed into code, as can the PSM defining SQL and also the object-to-relational mapping. Each of these transformations may or may not be automated in a tool. Even if a human being performs the transformation manually, however, the concept of a transformation still applies.

Platform Independent Model (PIM)

EJB (PSM)

EJB (Code)

EJB - SQL Mapping (PSM)

EJB - SQL Mapping (Code)

SQL (PSM)

SQL (Code)

Figure 10.11 Transformations from PIM to PSM to Code

324 | Chapter 10 Beyond the Basics

The System Is Highly Distributed The system itself may be deployed across many organizational and geographic boundaries. Such systems have additional complexity associated with them because: ■

There are additional system interfaces to contend with. These interfaces support the distributed nature of the system, where elements of the system must communicate across this distributed environment.

■

There may be additional human interfaces to consider. A given geography may impose particular regional requirements that must be accommodated.

■

There may be additional stakeholders to consider. Additional geographies may require communication with new stakeholders that provide input to the project.

■

Additional operational considerations must be taken into account. Provision of appropriate networking must be considered, and qualities such as performance and availability become harder to meet.

■

Time-zone differences can also provide challenges in terms of timedependent operations. It may not be clear when it would be appropriate to schedule batch runs if an off-peak period is preferred for such actions, for example. Also, it may be appropriate to perform certain operations at the end of the business day (particularly in financial institutions), but the concept of “end of day” is unclear.

■

It may be necessary to segregate business data for both technical and regulatory reasons.

■

Deployment across the distributed environment involves more locations. Each location may have its own nuances that need to be accommodated.

In terms of the architecture, a focus on the deployment aspects of the system can help address some of these challenges. The Deployment Model work product, for example, allows the various deployment elements to be debated, such as locations, nodes, and the connections between them. In addition, the architect models locations in terms of both logical (such as a Store) and physical (such as Orlando store and Tampa store) elements, for example, allowing the consideration of placement of functional elements on deployment elements to be made very early in the process. In addition, architecting highly distributed systems can benefit from an appropriate separation of concerns, as discussed earlier in this chapter in the sidebar “Best Practice: Ensure That the Architecture Is Componentized Appropriately.”

Architecting Complex Systems | 325

The Development Team Is Distributed Complex systems are often developed by teams that are not physically colocated. There are many reasons for this arrangement, including cost reduction through the use of cheaper labor (from a supplier in a different location), and shortened delivery times by allowing development to proceed around the clock (by developers in different geographies and time zones). Although distributed development may indeed help, it also adds to the complexity. Communication between individuals becomes more difficult when different languages, time zones, and cultures are taken into consideration, for example. In addition, appropriate architectural and project governance needs to be in place to ensure that the elements of the system are delivered as required. In particular, it is essential that clear and unambiguous specifications, along with any standards that must be adhered to, be produced and delivered to any remote teams. The deliverables required and acceptance criteria must also be very clearly defined. The architect can help ensure that such an approach is taken. Geographically distributed development can benefit from an appropriate separation of concerns, as discussed in the sidebar “Best Practice: Ensure That the Architecture Is Componentized Appropriately” earlier in this chapter. This separation will allow the system to be subdivided in a manner that effectively supports a level of concurrent development. In addition, for the various teams to work consistently and to ensure the integrity of the architecture, there should be a focus on relevant standards that should be adopted, together with an appropriate and consistent development toolset, as described earlier in this chapter in the sidebar “Best Practice: Establish and Govern Architecture Standards.” Use standards to express architectural concerns that cross geographic boundaries. This technique may extend to organizational boundaries, which can be as severe as distant geographic location. It might even extend to organizations separated only by one floor in a building. Small geographic distances can loom large if the building architecture doesn’t support close interworking. (Coplien 2005)

Another focus when dealing with distributed teams is the manner in which the teams’ work is coordinated and integrated. From a coordination perspective, this task comes down largely to project management, in that the content of the architecture can help guide the project planning. The architecture can also guide the sequence in which independently developed elements of the system are brought together, integrated, and tested as a unit. There may also be a focus on validation and verification tasks to ensure that the distributed teams are both delivering the right thing and delivering the thing right.

326 | Chapter 10 Beyond the Basics

Operational Qualities Are Extremely Challenging A system may need to exhibit operational (run-time) qualities that are extremely challenging. Service levels such as ensuring the system is available 99.999 percent of the time, supporting very rapid response times in a distributed system, or moving large amounts of data around in a sensible time frame are all challenging. Such complex operational environments require the architect to balance the sometimes-conflicting non-functional requirements of, say, achieving high-performance service levels and at the same time delivering on time and to a given budget. As discussed in Chapters 7 through 9, it is critical from the outset to focus actively on the non-functional requirements, on the development of those requirements and on an approach for addressing them. For systems with difficult or challenging non-functional requirements, there is even more reason to focus on them. A life-support machine that does not meet its availability requirements will never see the light of day, for example. Therefore, such requirements can represent the most-challenging requirements of the system under development. As a result, architects often place corresponding emphasis on proving that such qualities have been addressed by creating relevant architecture proofs of concept. The emphasis on such qualities is discussed in the sidebar “Best Practice: Ensure That Qualities Drive the Architecture Definition.” Where a system must address a particularly challenging quality or capability, it is appropriate to select a viewpoint that provides the necessary focus and that is populated using appropriate work products. Some examples of such viewpoints and associated work products are ■

Usability Viewpoint. For systems that have challenging usability requirements, such as user interfaces that may potentially be used by thousands or even millions of users, there may be a complete sub-project that deals with this aspect of the system. If this is the case, then a usability cross-cutting viewpoint may be selected that is populated by specific Usability Requirements and User Interface Model work products.

■

Performance Viewpoint. Where high-performance systems are to be built, the Performance cross-cutting viewpoint described in Chapter 4, “Documenting a Software Architecture,” may be populated by a specific Performance Model work product. Performance models are used to establish whether the system is likely to meet all of its performance requirements by using simulation, measurement, benchmarking, and rules of thumb to validate how the system is likely to perform.

■

Availability Viewpoint. For systems that need to be highly available, the Availability cross-cutting viewpoint described in Chapter 4, “Documenting

Architecting Complex Systems | 327

Best Practice: Ensure That Qualities Drive the Architecture Definition The architecture of a system is not wholly focused on functionality provided by the system; it is equally concerned with the qualities that the executing system exhibits. The architect is responsible for ensuring that these qualities meet or exceed the requirements on the system. Therefore, it is essential for the architect to ensure that such qualities are captured, described, considered, and verified throughout the course of the project.

a Software Architecture,” may be populated by a specific Availability Model. Availability models use various modeling techniques such as reliability graphs and fault trees to establish the likely availability of a system. ■

Security Viewpoint. When security is a particular concern, the Security cross-cutting viewpoint described in Chapter 4, “Documenting a Software Architecture,” may be populated by Security Requirements, Security Architecture, and Security Threat Analysis work products.

There Is a System of Systems Another characteristic of complex systems is that they may be composed of subsystems that are significant enough to be considered systems in their own right. Also, the system for which an architect is responsible may actually be a subsystem of something much larger. Both situations could be true, as shown in Figure 10.12, which shows a system (System C) in context of those systems with which it is related.

System A

System B

System C

System D

System E

System F

System G

Figure 10.12 A System of Systems

328 | Chapter 10 Beyond the Basics

In this figure, System C is a subsystem of System A and has three subsystems of its own: E, F, and G. All the systems in question may be developed within their own projects and have their own architecture. The systems are not completely independent, of course—something that we explore in this section. Acknowledgment of a system-of-systems approach is described in more detail in the sidebar “Best Practice: Formally Describe the Architecture as a System of Systems.”

Best Practice: Formally Describe the Architecture as a System of Systems The decomposition of a system into a number of subsystems is widely recognized and described in the system of interconnected systems architectural pattern (Jacobson 1997). This pattern can be used to describe the relationship between a system and its subsystems. In the pattern, the overall system is referred to as the superordinate system, whereas each of the subsystems is referred to as a subordinate system. An important characteristic of the pattern is that it is recursive, meaning that a subordinate system may also have subsystems of its own and be superordinate in relation to them. The system of interconnected systems pattern can be applied to many initiatives, such as the following: ■

Service-oriented architecture (SOA). In this case, the SOA can itself be considered to be the system (normally at an enterprise-wide or organization-wide level), with each service representing a subsystem within the SOA.

■

Enterprise architecture. As discussed in Chapter 2, “Architecture, Architect, Architecting,” an enterprise architecture considers elements of hardware, software, people, and information with a link to business objectives such as business agility and organizational efficiency. In terms of the pattern, the enterprise represents the overall system, where the elements of the enterprise represent the subsystems.

■

Systems engineering. Similarly, systems engineering is concerned with hardware, software, people, and information. The system as a whole can be decomposed into subsystems that may also contain each of these different types of elements.

■

Strategic reuse. Reusable assets by definition do not exist in isolation (because they are intended to be reused within several contexts). A

Architecting Complex Systems | 329

fundamental premise of any strategic reuse initiative, therefore, is to define the services that each asset provides and any services that the asset requires. These assets and their relationships can be described in terms of a system of systems, where the containing asset represents the system and the reused asset represents a subsystem. This thinking is particularly relevant to the creation of a software product line representing a set of systems that applies to a particular industry segment and that is created from a common set of reusable assets. Software product lines are discussed in detail in Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach (Bosch 2000) and Software Product Lines: Practices and Patterns (Clements 2001). ■

Application integration. Application integration is concerned with developing a solution that includes the integration of several existing systems. Such efforts are driven to a large extent from the bottom up because elements of the solution already exist, but some top-down effort is still required to understand the context within which such existing systems will fit. Often, techniques such as wrapping interfaces to existing software applications are required, together with a good understanding of available middleware technologies that can be used to interact with such applications. With regard to the system of interconnected systems pattern, the integrated enterprise application is considered to be the overall system, and each integrated application is considered to represent a subsystem.

■

Packaged application development. Packaged applications can be considered to be customizable frameworks that allow you to build a family of related applications that support a certain aspect of a business, such as customer relationship management or human resources. These frameworks can be considered at two levels. First, such frameworks often implement a piece of a larger system. In this context, the packaged application (or a piece of the packaged application) represents a subsystem. Second, such frameworks are often large and complex, and thinking of them as systems in their own right can help you understand how the packaged application will be applied in terms of what pieces will be used as is, what pieces will be used after modification or configuration, and what pieces will not be used at all. Indeed, such applications are often split into modules, each having specific application functions that can be considered subsystems in their own right.

330 | Chapter 10 Beyond the Basics

In describing a system of systems, various architectural principles need to be accommodated, a formalism of which can be found in the Model-Driven Systems Development approach from IBM Rational (MDSD 2009), formerly known as RUP for Systems Engineering (RUP SE), which is now part of the Rational Unified Process (RUP 2008). This is the work of Dr. Murray Cantor and others. MDSD specifically supports systems engineering initiatives (but can be applied to other initiatives too), where a system is defined as follows: [A system is] a set of resources that provide services that are used by an enterprise to carry out a business purpose or mission. System components typically consist of hardware, software, data, and workers. (Cantor 2003)

The neat thing about the MDSD approach is the set of techniques for the allocation of system requirements to subsystems (both functional and non-functional), in which a subsystem itself may also comprise software, hardware, people, and data. One of these key techniques, joint realization, is one of the cornerstones of MDSD. This technique shows how both system functional and non-functional requirements are jointly realized across the different types of element that comprise the system, in terms of software, hardware, people, and data. MDSD attempts to tackle, head on, the well-known problems that arise when such elements are considered in isolation. The result of applying the MDSD approach is a set of loosely coupled and highly cohesive subsystems, each with its own set of requirements (functional requirements to be met, qualities to be exhibited, and constraints to be accommodated) that allows each subsystem to be treated as a system in its own right.

Summary This chapter complements earlier chapters by introducing topics not discussed elsewhere in this book—typically, those that are beyond a basic understanding of the role of the architect in a typical software development project. In particular, we examined the involvement of the architect with respect to several software development disciplines not discussed earlier in the book, as well as some additional considerations of the architect when faced with complex systems. This chapter has only scratched the surface of addressing the challenges of complex systems, however. This area is receiving much-deserved attention in the industry.

In Conclusion: A Note from the Authors | 331

In Conclusion: A Note from the Authors As stated at the start of this book, our purpose is to convey a series of practices that can be applied in total or in part to the process of architecting. We’ve tried to build a foundation of essential knowledge that every architect should have and that we’ve gradually built on during the course of this book, concluding with a discussion of more advanced topics that are themselves worthy of a book of their own. However you use the content of this book, and whether you’re an aspiring architect or an advanced practitioner, we hope that your application of the various practices is successful. Finally, remember that even the best of best practices can be improved!

This page intentionally left blank

Appendix A Software Architecture Metamodel

This appendix contains the complete definition of the metamodel of concepts used within this book. The relationships in the metamodel shown in Figure A.1 are ■

A system has an architecture.

■

A system fulfills one or more missions.

■

A system has one or more stakeholders.

■

A system inhabits an environment.

■

An environment influences a system.

■

An architecture is described by an architectural description.

■

An architectural description identifies one or more stakeholders.

■

An architectural description identifies one or more concerns.

■

An architectural description provides a rationale.

■

A stakeholder has one or more concerns.

■

A concern is important to one or more stakeholders.

■

A development project is staffed by a team.

■

A development project follows a development process.

■

A development project develops a system.

■

The development process includes architecting.

■

The team includes an architect. 333

- is staffed by

- follows

Team

Development Process

Architecture Decision

1..*

1..* - justifies

- includes - performs

Architect

- includes

- governs

1..*

Architecting

View

- organized by 1..*

Rationale

1..* - participates in

* - provides

- creates

- results in

Architecture

- consists of 1..*

- participates in - aggregates

- described by 1

Architectural Description

Model 1..*

*

1..* - establishes methods for

- has an - identifies 1..* - is important to Stakeholder 1..* 1..* 1..* - addresses - has

- develops System - influences - fulfills 1..* Mission

- inhabits Environment

Figure A.1 Software Architecture Metamodel

- has 1..*

- identifies 1..* - used to cover Concern 1..* 1..* - addresses

- selects 1..* - conforms to Viewpoint

334 | Appendix A Software Architecture Metamodel

Development Project

Definition of Metamodel Terms | 335 ■

The architect performs architecting.

■

The architect creates an architecture.

■

The architect is a kind of stakeholder.

■

Architecting results in an architecture.

■

Rationale justifies one or more architecture decisions.

■

An architecture decision addresses one or more concerns.

■

An architectural description is organized by one or more views.

■

A view consists of one or more models.

■

A model participates in one or more views.

■

A model participates in one or more architectural descriptions.

■

A view conforms to a viewpoint.

■

An architectural description selects one or more viewpoints.

■

A viewpoint established methods for one or more models.

■

A viewpoint is used to cover one or more concerns.

Definition of Metamodel Terms This section contains a definition of the terms used in the metamodel. architect The person, team, or organization responsible for systems architec-

ture. (IEEE 1471 2000) This term is synonymous with software architect. architecting The activities of dening, documenting, maintaining, improving,

and certifying proper implementation of an architecture. (IEEE 1471 2000) This term is synonymous with software architecting. architectural description A collection of products to document an architecture. (IEEE 1471 2000) architecture The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. (IEEE 1471 2000) architecture decision Conscious design decisions concerning a software system as a whole, or one or more of its core components. These decisions determine the non-functional characteristics and quality factors of the system. (Zimmermann 2008).

336 | Appendix A Software Architecture Metamodel

concern Those interests which pertain to the system’s development, its operation, or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations such as performance, reliability, security, distribution, and evolvability. (IEEE 1471 2000) development process A set of partially ordered steps performed for a given

purpose during system development, such as constructing models or implementing models. (UML 2.0 2003) development project A project is a temporary endeavor undertaken to create a unique product or service. Temporary means that every project has a definite beginning and a definite ending. Unique means that the product or service is different in some distinguishing way from all similar products and services. Projects are often critical components of the performing organizations’ business strategy. (RUP 2008) environment The environment, or context, determines the setting and cir-

cumstances of developmental, operational, political, and other influences upon that system. (IEEE 1471 2000) mission A use or operation for which a system is intended by one or more stakeholders to meet some set of objectives. (IEEE 1471 2000) model Models provide the specific description, or content, of an architecture. For example, a structural view might consist of a set of models of the system structure. The elements of such models might include identifiable system components and their interfaces, and interconnections among those components. (IEEE 1471 2000) rationale A set of reasons or a logical basis for a course of action or a belief. (OED) stakeholder An individual, team, or organization (or classes thereof) with

interests in, or concerns relative to, a system. (IEEE 1471 2000) system [1] [A software system is] A collection of components organized to

accomplish a specic function or set of functions. The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest. A system exists to fulll one or more missions in its environment. (IEEE 1471 2000) [2] An integrated composite that consists of one or more of the processes, hardware, software, facilities, and people, that provides a capability to satisfy a stated need or objective. (IEEE 12207 1995)

Definition of Metamodel Terms | 337

team A small number of people with complementary skills who are commit-

ted to a common purpose, performance goals, and approach for which they hold themselves mutually accountable. (Katzenbach 1993) view A representation of a whole system from the perspective of a related set

of concerns. (IEEE 1471 2000) viewpoint A specification of the conventions for constructing and using a

view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis. (IEEE 1471 2000)

This page intentionally left blank

Appendix B Viewpoint Catalog

This appendix contains a summary of the viewpoints used in this book, which we introduced in Chapter 4, “Documenting a Software Architecture.” In that chapter, we discussed the concepts of basic and cross-cutting viewpoints. [An architectural viewpoint represents] a specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis. (IEEE 1471 2000)

The various viewpoints are shown in Figure B.1, a figure reproduced from Chapter 4. This chapter uses a template to describe each of the viewpoints, which contains the following items: ■ ■

■ ■

■ ■

Description. A brief description of the viewpoint. Stakeholder concerns. The stakeholder concerns that the viewpoint addresses. Stakeholders. The stakeholders addressed by this viewpoint. Work products. The work products that are referenced by a view defined by this viewpoint. Examples. One or more examples. Checklist. One or more questions that can be considered when verifying and validating the architecture or reviewing the architecture with stakeholders. 339

340 | Appendix B Viewpoint Catalog

Basic Viewpoints

Requirements Viewpoint

Functional Viewpoint

Deployment Viewpoint

Validation Viewpoint

Cross-Cutting Viewpoints

Application Viewpoint Infrastructure Viewpoint Systems Management Viewpoint Availability Viewpoint Performance Viewpoint Security Viewpoint

Figure B.1 The Architecture Description Framework

An obvious omission in this template is a detailed discussion of the techniques that you might use when applying the viewpoint. Although some techniques are discussed in the process-related chapters (Chapters 7 through 9), the omission of specific techniques in this appendix is deliberate. Many good books are available that can assist with the details of requirements definition, performance modeling, security management, and the like. In considering this catalog, you should remember that the architecture description standard used in this book can be refined and extended as required. You may see the inclusion of information, concurrency, and other viewpoints if you deem them to be of significance for the system under development, for example.

Stakeholder Summary Each viewpoint in this catalog lists the stakeholders that are addressed by the viewpoint. Table B.1 summarizes the stakeholders considered in this catalog. You can use this summary as a starting point when identifying the stakeholders in the architecture in any given situation. This table also indicates the scope of

Basic Viewpoints | 341

Table B.1 Stakeholder Summary Role

Scope

Primary Responsibility

Application Owner Business Administrator Configuration Manager

External

Commissions (and funds) the system

External

Manages business-related elements of the operational system Defines the structure of the configuration management repository and the elements that reside within it

Developer

Internal

Performs detailed design and implementation of the system

Maintainer

External

Manages the ongoing evolution of the system after it has been deployed

Project Manager

Internal

Supplier

External

Support Personnel System Administrator Tester User

External External

Manages the execution of the development project in terms of planning, staffing, monitoring, and risk management Provides software or hardware elements required in the development or running of the system Provide system support and perform diagnostic functions Manages the operational execution of the system

Internal External

Tests the system to ensure that it is fit for purpose Makes use of the system’s business functionality

Internal

each stakeholder; internal stakeholders are those within the current development team, whereas external stakeholders are not. Although not included in this table, it is assumed that the architect is a stakeholder in all viewpoints.

Basic Viewpoints This section contains descriptions of the basic viewpoints. Requirements Viewpoint Description

This viewpoint is concerned with the system requirements that have shaped the architecture and includes functional requirements, qualities, and constraints. Continued

342 | Appendix B Viewpoint Catalog

Requirements Viewpoint (Continued) Stakeholder Concerns Stakeholders Work Products

Checklist

Architecturally significant functional requirements, required qualities, solution constraints, requirement priorities, and external actors. All stakeholders. Business Entity Model, Business Process Model, Business Rules, Change Request, Enterprise Architecture Principles, Existing IT Environment, Functional Requirements, Glossary, Non-Functional Requirements, Prioritized Requirements List, Stakeholder Requests, System Context, and Vision. Have the requirements been identified and specified to the right level of detail for the purpose of defining the architectural solution? Have non-functional requirements (qualities and constraints) been considered, as well as non-functional requirements?

Functional Viewpoint Description

Stakeholder Concerns

Stakeholders Work Products Checklist

This viewpoint is concerned with those architectural elements that support the functionality (the logic) of the system and includes the structural elements from which the system is built, the relationships among them, and their behavior. System functionality, interfaces to end users and external systems, major structural components, intercomponent relationships and behavior, data structures, data flow, data access, and transaction management. All stakeholders. Architecture Decisions, Architecture Overview, Data Model, and Functional Model. Do functional elements support the stated functional and nonfunctional (qualities and constraints) requirements where relevant? Specific constraints include the cost and schedule associated with the implementation of the functional elements. Are functional elements traceable to the requirements? Do any components exhibit the correct levels of cohesion, coupling, and granularity? Do the interfaces on any components contain a cohesive set of operations that have valid signatures and preconditions and postconditions? Do any subsystems represent cohesive groupings of capability? Do persistent functional elements have corresponding data elements defined?

Basic Viewpoints | 343

Deployment Viewpoint Description

Stakeholder Concerns Stakeholders Work Products Checklist

This viewpoint is concerned with those architectural elements that support the distribution of the system and includes elements such as location, nodes, devices, and the connections among them. System distribution, hardware node (and devices) specification, and network specification. Configuration Manager, Developer, Maintainer, Project Manager, Supplier, Support Personnel, System Administrator, and Tester. Architecture Decisions, Architecture Overview, and Deployment Model. Do deployment elements support the stated functional and non-functional (qualities and constraints) requirements where relevant? Specific constraints include migration from the existing environment, cost, implementation schedule (including any lead time to procure the hardware required), and physical constraints such as available spaces in a data center. Are deployment elements traceable to the requirements? Have all components in the functional view been deployed to nodes in the deployment view? Do connections between nodes and locations exist to support the interactions between functional elements? Have physical deployment elements been defined in sufficient detail, in terms of the numbers of nodes and devices, and their detailed specification? Have all third-party software requirements been identified, such as operating systems, together with any run-time elements that require a software license?

Validation Viewpoint Description

Stakeholder Concerns Stakeholders Work Products

This viewpoint is concerned with assessing whether the system will provide the required functionality, exhibit the required qualities, and accommodate the defined constraints. Architecture fitness for purpose, consideration of solution alternatives, and resolution of technical risks and issues. Application Owner, Project Manager, and Tester. Architecture Assessment, Architecture Proof-of-Concept, RAID Log, and Review Record. Continued

344 | Appendix B Viewpoint Catalog

Validation Viewpoint (Continued) Checklist

Have architecture decisions been adopted in the architecture? Is there appropriate recognition (and inclusion) of reusable assets? Are any third-party elements (such as application packages and infrastructure products) that have been chosen consistent with organizational policies (for example, are the packages or software products and vendors on the preferred vendor/product list?)? Is the architecture consistent with any mandated principles, standards, and guidelines? Has the architecture been validated in a development or test environment that is considered to be equivalent to the production environment? Where possible, have the stated requirements (especially qualities such as performance) been validated in an executable environment? Have alternative solutions been considered? Are technical risks defined and appropriate mitigations identified?

Cross-Cutting Viewpoints This section describes each of the cross-cutting viewpoints.

Application Viewpoint Description

Stakeholder Concerns Stakeholders Work Products Checklist

This viewpoint is concerned with those architectural elements that provide the application-specific behavior of the solution—that is, behavior that the system must provide to meet its business requirements. Application-specific requirements and their realization. Business Administrator, Developer, Maintainer, Supplier, System Administrator, and Tester. This viewpoint is cross-cutting and potentially references all work products. This viewpoint is cross-cutting, and the checklists from all basic viewpoints apply in the context of this viewpoint.

Cross-Cutting Viewpoints | 345

Infrastructure Viewpoint Description

Stakeholder Concerns Stakeholders Work Products Checklist

This viewpoint is concerned with those architectural elements that provide the application-independent behavior of the solution— that is, behavior that the system must provide to support the business purpose of the system. Application-independent requirements and their realization. Developer, Maintainer, Supplier, System Administrator, and Tester. This viewpoint is cross-cutting and potentially references all work products. This viewpoint is cross-cutting, and the checklists from all basic viewpoints apply in the context of this viewpoint.

Systems Management Viewpoint Description

Stakeholder Concerns Stakeholders Work Products Checklist

This viewpoint is concerned with those architecture elements that contribute to the operational running of the system after it has been deployed into production. System startup and shutdown, monitoring and control of the operational system, data backup, data archival, and data restore. Developer, Maintainer, Supplier, System Administrator, and Tester. This viewpoint is cross-cutting and potentially references all work products. This viewpoint is cross-cutting, and the checklists from all basic viewpoints apply in the context of this viewpoint. Have requirements regarding system startup and shutdown, monitoring and control of the operational system, data backup, data archival, and data restore been addressed?

Availability Viewpoint Description

Stakeholder Concerns

This viewpoint is concerned with those architectural elements that allow the system to meet the specified availability requirements. This viewpoint is also concerned with those architectural elements that allow the system to recover from failures (that make the system fully or partially unavailable). Startup and shutdown, qualities of service, and system recovery. Continued

346 | Appendix B Viewpoint Catalog

Availability Viewpoint (Continued) Stakeholders Work Products Checklist

Developer, Maintainer, Supplier, System Administrator, and Tester. This viewpoint is cross-cutting and potentially references all work products. This viewpoint is cross-cutting, and the checklists from all basic viewpoints apply in the context of this viewpoint. Have requirements regarding system startup and shutdown, qualities of service, and system recovery been addressed? Have different qualities of service been considered where relevant?

Performance Viewpoint Description

Stakeholder Concerns Stakeholders Work Products Checklist

This viewpoint is concerned with those architectural elements that allow the system to meet the specified performance requirements (such as response time and throughput). Response time, throughput, and scalability. Developer, Maintainer, Supplier, System Administrator, and Tester. This viewpoint is cross-cutting and potentially references all work products. This viewpoint is cross-cutting, and the checklists from all basic viewpoints apply in the context of this viewpoint. Have requirements regarding response time, throughput, and scalability been identified and addressed?

Security Viewpoint Description

This viewpoint is concerned with those architectural elements that allow the system to meet the specified security requirements, such as authorized access to the system functions and resources. This viewpoint is also concerned with those architectural elements that allow the system to detect, and recover from, failures in the system’s security mechanisms.

View Correspondence | 347

Security Viewpoint (Continued) Stakeholder Concerns Stakeholders Work Products

Security threats, security policies, and threat detection.

Checklist

This viewpoint is cross-cutting, and the checklists from all basic viewpoints apply in the context of this viewpoint. Have requirements regarding security threats, security policies, and threat detection been addressed? Are secure resources identified as such? Have security policies been identified and stated? Has identification of, and recovery from, security breaches been defined?

Developer, Maintainer, Supplier, System Administrator, and Tester. This viewpoint is cross-cutting and potentially references all work products.

View Correspondence Not included in the descriptions of the preceding viewpoints are any relationships between a view defined by a given viewpoint and any other views. The placement of a component on a node is a concern of both a functional view and a deployment view, for example, and you may want all components identified in the functional view to be deployed to nodes in the deployment view. Rather than describe view correspondence in each of the preceding sections, we chose to minimize duplication by providing Table B.2 instead. This table indicates the correspondence between all the views in the architecture description framework. The intention is to allow you to look across the rows for each viewpoint you are adopting to see what correspondence (and, therefore, completeness and consistency) needs to exist.

348 | Appendix B Viewpoint Catalog

Table B.2 View Correspondence Requirements Requirements

Functional

Deployment

Validation

How do functional elements realize the requirements (e.g., order processing components)?

How do deployment elements realize the requirements (e.g., a node that allows a user to place an order)?

How well does the architecture meet the requirements (e.g., an assessment of the solution for placing an order)?

Which deployment elements are functional elements placed on (e.g., the nodes on which order processing components are placed)?

How well do functional elements meet the requirements (e.g., an assessment of order processing components)?

Functional

How do functional elements realize the requirements (e.g., order processing components)?

Deployment

How do deployment elements realize the requirements (e.g., a node that allows a user to place an order)?

Which deployment elements are functional elements placed on (e.g., the nodes on which order processing components are placed)?

Validation

How well does the architecture meet the requirements (e.g., an assessment of the solution for placing an order)?

How well do functional elements meet the requirements (e.g., an assessment of order processing components)?

How well do deployment elements meet the requirements (e.g., an assessment of the nodes required to place an order)?

Application

What are the applicationspecific requirements (e.g., a Place Order use case)?

What are the applicationspecific functional elements (e.g., order processing components)?

What are the applicationspecific deployment elements (e.g., a node that allows a user to place an order)?

How well do deployment elements meet the requirements (e.g., an assessment of the nodes required to place an order)?

How well are the applicationspecific requirements met (e.g., an assessment of the solution for placing an order)?

View Correspondence | 349

Table B.2 View Correspondence (Continued) Requirements

Functional

Deployment

Validation

Infrastructure

What are the applicationindependent requirements (e.g., a constraint to use a particular database)?

What are the applicationindependent functional elements (e.g., a persistency mechanism)?

What are the applicationindependent deployment elements (e.g., a printer)?

How well are the application-independent requirements met (e.g., an assessment of whether a constraint to use a particular database has been accommodated)?

Systems management

What are the systems management requirements (e.g., the system should raise an exception under failure)?

What are the systems management– related functional elements (e.g., components that support error notification)?

What are the systems management– related deployment elements (e.g., nodes to support system administrators)?

How well are the systems management requirements met (e.g., an assessment of the solution for raising an exception after system failure)?

Availability

What are the availability requirements (e.g., the system will be 99.99% available)?

What are the functional elements that influence availability (e.g., components that support offline working)?

What are the deployment elements that influence availability (e.g., nodes to support system failover)?

How well are the availability requirements met (e.g., an assessment of the solution being 99.99% available)?

Performance

What are the performance requirements (e.g., a payment must be processed in less than 5 seconds)?

What are the functional elements that influence performance (e.g., components involved in data compression)?

What are the deployment elements that influence performance (e.g., LAN and WAN connectivity)?

How well are the performance requirements met (e.g., an assessment of the ability to process a payment in less than 5 seconds)?

Security

What are the security requirements (e.g., all users must be authenticated)?

What are the security-related functional elements (e.g., components that provide user authentication)?

What are the security-related deployment elements (e.g., firewalls that prevent unauthorized access)?

How well are the security requirements met (e.g., an assessment of the extent to which users are authenticated)?

This page intentionally left blank

Appendix C Method Summary

This appendix contains a summary of the method referred to in this book. An overview of the fundamental concepts associated with a method is provided in Chapter 3, “Method Fundamentals.”

Roles A role defines the behavior and responsibilities of an individual or a set of individuals working together as a team, within the context of a software development organization. A role is responsible for one or more work products and performs a set of tasks. The roles within the project team (as described in this book) are shown in Figure C.1. Table C.1 provides a summary of the roles within the project team.

351

352 | Appendix C Method Summary

Project Manager Lead Architect Business Analyst

Application Architect

Developer

Infrastructure Architect Data Architect

Tester

Figure C.1 The Project Team

Table C.1 Role Summary Role Name

Description

Owned Work Products

Application Architect

The Application Architect focuses on those elements of a system that automate business processes and meet business needs. This role focuses primarily on satisfying the functionality required by the business, but it is also concerned with how the application-related elements meet the non-functional requirements of the system (qualities and constraints).

Functional Model

Business Analyst

The Business Analyst is responsible for identifying and documenting requirements and analyzing these requirements from a business perspective. The person in this role defines current and future operational scenarios (processes, models, use cases, plans, and solutions) and works with the stakeholders and the architects to ensure proper translation of business requirements into system requirements.

Business Entity Model Business Process Model Business Rules Enterprise Architecture Principles Existing IT Environment Functional Requirements Glossary Non-Functional Requirements Prioritized Requirements List Stakeholder Requests System Context Vision

Roles | 353

Table C.1 Role Summary (Continued) Role Name

Description

Owned Work Products

Data Architect

The Data Architect focuses on the data elements of a system, especially data that is made persistent in an appropriate mechanism, such as a database, a file system, a content management system, or some other storage mechanism. This role defines appropriate data-related properties, such as structure, source, location, integrity, availability, performance, and age.

Data Model

Developer

The Developer is responsible for performing detailed design tasks, defining the organization of the implementation, implementing the detailed design elements, unit-testing the implementation, integrating his or her work with that of other developers, and ultimately producing an executable system.

The Developer does not own any of the work products described in this book.

Infrastructure Architect

The Infrastructure Architect concentrates on those elements of the system that are independent of business functionality, such as a persistence mechanism, hardware, and middleware. Such elements support the execution of the application-related elements. This role focuses on elements that have a significant bearing on the qualities exhibited by the system and, therefore, the extent to which certain non-functional requirements are addressed.

Deployment Model

Lead Architect

The Lead Architect has overall responsibility for the major technical decisions that define the architecture of the system. This role also is responsible for providing rationale for these decisions; balancing the concerns of the various stakeholders; managing technical risks and issues; and ensuring that decisions are effectively communicated, validated, and adhered to.

Architecture Assessment Architecture Decisions Architecture Overview Architecture Proof-of-Concept Software Architecture Document

Project Manager

The Project Manager is responsible for leading the project team that will deliver the solution by applying a range of project management principles, tools, and techniques. The Project Manager has overall responsibility for managing scope, cost, schedule, and contractual deliverables, as well as for the management of issues, risks, and change.

Change Request RAID Log Review Record

Continued

354 | Appendix C Method Summary

Table C.1 Role Summary (Continued) Role Name

Description

Owned Work Products

Tester

The Tester is responsible for finding and documenting defects in software quality, generally advising about perceived software quality, and validating that the system functions as designed and as required. Complementing the unit testing performed in the development discipline, the Tester focuses on the integrated units provided by the developers and the system as a whole.

The Tester does not own any of the work products described in this book.

Work Products A work product is a piece of information or physical entity that is produced and/or used during the execution of the process. Examples of work products include models, plans, code, executables, documents, databases, and so on. The work products used in this book are shown in Table C.2.

Table C.2 Work Product Summary Work Product Name

Description

Owning Role

Architecture Assessment

Records the results of an assessment of the solution architecture performed at various stages during the project life cycle. An assessment identifies issues and risks associated with an architecture, and recommends actions and mitigation strategies to address them.

Lead Architect

Architecture Decisions

Records the significant decisions made in shaping the overall architecture, and describes the rationale used in making the decision, the options considered, and the implications of the decision.

Lead Architect

Architecture Overview

Provides an overview of the significant elements of the architecture, such as major structural elements, important behavior, and significant decisions.

Lead Architect

Architecture Proof-ofConcept

Used to prove and validate key parts of the architecture to reduce project risk. This work product may take the form of a model of a solution using a notation such as Unified Modeling Language (UML), a simulation of a solution, or an executable prototype.

Lead Architect

Work Products | 355

Table C.2 Work Product Summary (Continued) Work Product Name

Description

Owning Role

Business Entity Model

Defines the key concepts in the business domain under consideration.

Business Analyst

Business Process Model

Defines the activities performed by the business and the roles that perform each activity.

Business Analyst

Business Rules

Defines any policies or conditions that must be satisfied by the system under development.

Business Analyst

Change Request

Describes the request for a change to the system. Changes may be significant and may dramatically affect the focus of the iteration.

Project Manager

Data Model

Describes the representation of the data used by the system.

Data Architect

Deployment Model

Shows the configuration of nodes, the communication links between them, and the components that are deployed on them.

Infrastructur e Architect

Enterprise Architecture Principles

Contains rules and guidelines, defined at enterprise level, that inform and guide the way in which architectures will be created.

Lead Architect

Existing IT Environment

Represents the collection of existing elements that comprise the current IT landscape and that may be used by, or constrain, the system under development.

Lead Architect

Functional Model

Describes the software components, including their responsibilities and relationships, and the collaborations of components in delivering the required functionality.

Application Architect

Functional Requirements

Describes the functional requirements of the system under development.

Business Analyst

Glossary

A list of common terms, their meanings, and alternatives used by the business.

Business Analyst

Non-Functional Requirements

Describes the non-functional requirements of the system under development. Non-functional requirements represent system qualities (such as reliability) and constraints.

Business Analyst

Prioritized Requirements List

Captures the priority associated with each requirement.

Business Analyst

RAID Log

Captures the risks, assumptions, issues, and dependencies for the project.

Project Manager Continued

356 | Appendix C Method Summary

Table C.2 Work Product Summary (Continued) Work Product Name

Description

Owning Role

Review Record

Records the major findings of a review, together with the recommended actions for addressing those findings.

Project Manager

Software Architecture Document

Provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. (RUP 2008)

Lead Architect

Stakeholder Requests

Contains requests that a stakeholder may have on the system to be developed. It may also contain references to any standards to which the system must conform (such as regulatory compliance standards or organizational standards).

Business Analyst

System Context

Represents the entire system as a single entity or process and identifies the interfaces between the system and external entities.

Business Analyst

Vision

Defines the stakeholders’ view of the system to be developed and is specified in terms of the stakeholders’ key needs and features. It outlines the envisioned core requirements and may be as simple as a problem statement.

Business Analyst

Figure C.2 shows the alignment of work products and viewpoints.

Activities An activity represents a grouping of tasks. The activities described in Figure C.3 follow the flow described in Chapter 7, “Defining the Requirements,” Chapter 8, “Creating the Logical Architecture,” and Chapter 9, “Creating the Physical Architecture.” In addition, this figure shows the more detailed design activities that would be undertaken within the overall development process, although these activities are not discussed in detail in this book. You should remember that in an iterative development process, each of these activities is executed within a single iteration.

Tasks A task is a unit of work that provides a meaningful result in the context of the project. It has a clear purpose, which usually involves creating or updating artifacts. In the following sections, the various tasks are grouped according to the

Tasks | 357

Requirements Viewpoint Application Viewpoint Infrastructure Viewpoint Systems Management Viewpoint Availability Viewpoint Performance Viewpoint Security Viewpoint

Business Entity Model Business Process Model Business Rules Change Request Enterprise Architecture Principles Existing IT Environment Functional Requirements Glossary Non-Functional Requirements Prioritized Requirements List Stakeholder Requests System Context Vision

Functional Viewpoint Architecture Decisions Architecture Overview Data Model Functional Model

Deployment Viewpoint Architecture Decisions Architecture Overview Deployment Model

Figure C.2 Viewpoints and Work Products

Requirements

Architecture

Development

Define Requirements

Create Logical Architecture

Create Logical Detailed Design

Create Physical Architecture

Create Physical Detailed Design

Figure C.3 Activity Overview

Validation Viewpoint Architecture Assessment Architecture Proof-ofConcept RAID Log Review Record

358 | Appendix C Method Summary

activity to which they belong. Each activity has an overall activity diagram that shows the flow between the tasks, as well as a table that summarizes the steps for each task.

Activity: Define Requirements The flow between the tasks that comprise the Define Requirements activity is shown in Figure C.4 and a summary of each task is given in Table C.3.

Collect Stakeholder Requests

Capture Common Vocabulary

Define System Context

Outline Functional Outline Non-Functional Requirements Requirements

Prioritize Requirements

Detail Functional Requirements

Detail Non-Functional Requirements

Update Software Review Requirements Architecture Document with Stakeholders

Figure C.4 Tasks in the Define Requirements Activity

Tasks | 359

Table C.3 Define Requirements: Task Summary Task Name

Steps

Collect Stakeholder Requests

Identify stakeholders. Collect stakeholder requests. Prioritize stakeholder requests. Identify common terms.

Capture Common Vocabulary Define System Context

Outline Functional Requirements Outline Non-Functional Requirements Prioritize Requirements Detail Functional Requirements

Detail Non-Functional Requirements Update Software Architecture Document Review Requirements with Stakeholders

Identify actors. Identify actor locations. Identify data flows. Identify functional requirements. Outline functional requirements. Identify non-functional requirements. Outline non-functional requirements. Prioritize requirements. Detail use cases (for each use case considered in the current iteration). Detail use-case data fields. Detail system-wide functional requirements. Detail functional requirement scenarios. Detail non-functional requirements (for each non-functional requirement considered in the current iteration). Detail non-functional requirement scenarios. Update software architecture document. Baseline work products. Assemble work products. Review work products.

360 | Appendix C Method Summary

Activity: Create Logical Architecture The flow between the tasks that comprise the Create Logical Architecture activity is shown in Figure C.5 and a summary of each task is given in Table C.4.

Survey Architecture Assets

Outline Functional Elements

Document Architecture Decisions

Define Architecture Overview

Outline Deployment Elements Verify Architecture

Detail Functional Elements

Build Architecture Proof-of-Concept

Detail Deployment Elements

Validate Architecture

Update Software Review Architecture Architecture Document with Stakeholders

Figure C.5 Tasks in the Create Logical Architecture Activity

Tasks | 361

Table C.4 Create Logical Architecture: Task Summary Task Name

Steps

Survey Architecture Assets

Survey architecture assets.

Define Architecture Overview

Define architecture overview.

Document Architecture Decisions

Capture issue or concern. Assess options. Select preferred option. Document decision.

Outline Functional Elements

Identify subsystems. Identify components.

Outline Deployment Elements

Identify locations. Identify nodes.

Verify Architecture

Plan verification. Hold kickoff meeting. Perform individual verification. Hold verification meeting. Perform rework. Perform follow-up

Build Architecture Proof-of-Concept

Create architecture proof-of-concept. Document findings.

Detail Functional Elements

Define component interfaces. Define operations and operation signatures. Define contracts between components.

Detail Deployment Elements

Assign components to nodes. Define connections between nodes. Define connections between locations.

Validate Architecture

Plan validation. Review architecture. Document findings. Assess risks and make recommendations.

Update Software Architecture Document

Update software architecture document.

Review Architecture with Stakeholders

Baseline work products. Assemble work products. Review work products.

362 | Appendix C Method Summary

Activity: Create Physical Architecture The work products are identical to those in the Create Logical Architecture activity and are not repeated here.

Phases [A phase is] a specialized type of activity that represents a significant period in a project normally ending with a decision checkpoint, major milestones, or a set of deliverables. Phases typically have well defined objectives and provide the basis for how the project work will be structured. (OpenUP 2008)

Inception The Inception phase is where the business case for the project is established and concurrence among all stakeholders on the objectives for the project is established. Inception is where the architect focuses on ensuring that the project is both valuable and feasible. Table C.5 presents a summary of the objectives and milestone evaluation criteria for the Inception phase.

Table C.5 Inception Phase Summary Primary Objectives

Milestone Evaluation Criteria

Establish the project’s scope.

Stakeholders concur with the scope definition. Stakeholders concur with the project acceptance criteria. Stakeholders agree that the right set of requirements has been captured, and there is shared understanding of these requirements. All requirements are prioritized. Stakeholders agree that the cost/schedule estimates, priorities, risks, and development process are appropriate.

Establish the project’s acceptance criteria. Identify the features of the system, and select those that are critical.

Estimate the overall cost and schedule for the entire project (and more detailed estimates for the Elaboration phase that wil immediately follow). Estimate potential risks.

Set up the supporting environment for the project (e.g., hardware, software, process, and resources).

All known risks have been recorded and assessed, and a risk mitigation strategy has been determined. The supporting environment is in place.

Phases | 363

Elaboration The Elaboration phase is where the architecture is established to provide a stable foundation for the design and implementation that is performed during the Construction phase. This phase, therefore, is of particular relevance to architects and certainly is where architects expend the majority of their effort. Table C.6 presents a summary of the objectives and milestone evaluation criteria for the Elaboration phase.

Table C.6 Elaboration Phase Summary Primary Objectives

Milestone Evaluation Criteria

Ensure that the architecture, requirements and plans are stable. Establish a baselined architecture. Ensure that the risks are sufficiently mitigated to predictably determine the cost and schedule for the completion of the development. Demonstrate that the baselined architecture will support the requirements of the system at an acceptable cost and within an acceptable time frame.

The product vision, requirements, and baselined architecture are stable. The major risk elements have been addressed and have been credibly resolved. All architecturally significant aspects of the system and selected areas of functionality have been evaluated in an architectural proof-of-concept.

Construction The Construction phase is where the remaining requirements are clarified and development of the system is completed against the baselined architecture established during the Elaboration phase. Between the Elaboration and Construction phases, the focus shifts from understanding the problem and identifying key elements of the solution to developing a deployable product. Table C.7 presents a summary of the objectives and milestone evaluation criteria for the Construction phase.

364 | Appendix C Method Summary

Table C.7 Construction Phase Summary Primary Objectives

Milestone Evaluation Criteria

Achieve useful versions (alpha, beta, and other test releases) in a timely fashion.

The system is developed in line with the expectations specified in the phase plan and iteration plans. All required functionality is incorporated into the system.

Complete the analysis, design, implementation, and testing of all required functionality. Determine whether the system is ready to be deployed.

The system has met all acceptance criteria as tested in the development environment.

Transition The Transition phase is where the architect ensures that the software is available to, and accepted by, its end users. This phase is where the system is deployed into the user’s environment for evaluation and testing. The focus is on fine-tuning the product and on addressing configuration, installation, and usability issues. By the end of the Transition phase, the project should be in a position to be closed out. Table C.8 presents the objective and milestone evaluation criterion for the Transition phase.

Table C.8 Transition Phase Summary Primary Objectives

Milestone Evaluation Criteria

Successfully roll out the system to the delivery channels.

The system has passed the formal acceptance criteria in the deployment environment.

Appendix D Architectural Requirement Checklist

This appendix contains a checklist of potential requirements that have particular architectural significance. Such a checklist can be used when gathering stakeholder requests and when reviewing requirements, for example. There are several classifications of requirement types. One such classification is the FURPS classification (Grady 1992); the acronym stands for functionality, usability, reliability, performance, and supportability. A similar classification is defined in ISO standard 9126 (ISO 9126 2001), where requirements are classified for external and internal quality and for quality in use. In this standard, “external and internal quality characteristics” are functionality, reliability, usability, efficiency, maintainability, and portability. Quality in use characteristics are effectiveness, productivity, safety, and satisfaction. A characterization of various non-functional requirements (qualities in particular) is also given in Software Architecture in Practice, 2nd ed. (Bass 2003), where the authors consider qualities of the system, business qualities, and qualities of the architecture itself. The classification used in this book is based on the FURPS classification, with particular emphasis on non-functional requirements (the URPS in FURPS). In this appendix, we extend this classification to also emphasize constraints as an essential part of the checklist (which some would refer to as FURPS+). You are encouraged to adopt such a checklist, amend as required, and apply it to your own projects.

365

366 | Appendix D Architectural Requirement Checklist

Functional Requirements Functional requirements describe functions that the system should exhibit when used under defined conditions. Functional requirements usually are specific to the system under development, so we don’t include a checklist of all functional requirements that should be considered. Instead, this book advocates use-case modeling as a technique for capturing the majority of functional requirements, based on the needs of the actors that interact with the system. Some functional requirements are not necessarily best captured in use cases and are referred to, in this book, as system-wide functional requirements (in the sense that they are not associated with a particular use case). A requirement to provide a secure system, for example, is a functional requirement that pervades the entire system and is not tied to a particular use case. Table D.1 provides some examples of functional requirements that happen to be systemwide and that often are of particular interest to the architect.

Table D.1 Examples of System-Wide Functional Requirements Requirement

Description

Audit Localization

Provision of the ability to audit the system Provision of localization mechanisms to allow the system to be configured for a particular human language Provision of online help capability Provision of printing capability Provision of reporting capability Provision of security capabilities to protect resources against unauthorized access Provision of systems management capabilities to control the system’s operational characteristics

Online help Printing Reporting Security Systems management

Usability Requirements Usability requirements describe the degree to which the system is understood and used. Table D.2 defines some usability requirements.

Performance Requirements | 367

Table D.2 Examples of Usability Requirements Requirement

Description

Accessibility

The degree to which the system may be exercised via the specified user interface mechanisms The degree to which the system is attractive to the user The degree to which the system may be learned by the user The degree to which the system may be exercised by the user

Aesthetics Learnability Operability

Reliability Requirements Reliability requirements describe the degree to which the system provides a defined level of operational performance. Table D.3 defines some reliability requirements. Table D.3 Examples of Reliability Requirements Requirement

Description

Accuracy

The degree to which the system provides results with the required level of precision The degree to which the system maintains a specified operational state The degree to which the system will reestablish a specified operational state

Availability Recoverability

Performance Requirements Performance requirements describe the degree to which the system provides a defined level of execution performance. Table D.4 defines some performance requirements. Table D.4 Examples of Performance Requirements Requirement

Description

Resource consumption

The degree to which the system uses stated amounts of resource Continued

368 | Appendix D Architectural Requirement Checklist

Table D.4 Examples of Performance Requirements (Continued) Requirement

Description

Speed

The degree to which the system exhibits specific processing times, such as startup, shutdown, and response times The degree to which the system supports specified throughput rates

Throughput

Supportability Requirements Supportability requirements describe the degree to which the system can be supported. Table D.5 defines some supportability requirements.

Table D.5 Examples of Supportability Requirements Requirement

Description

Adaptability Compatibility

The degree to which the system may be adapted to new environments The degree to which the system is compatible with previous or future versions The degree to which the system may be configured The degree to which the system may be extended The degree to which the system is easily installed The degree to which the system interacts with other specified systems The degree to which the system may be modified The degree to which the system may be used to replace another system that serves the same purpose in the same environment, including replacing previous and future versions of the system The degree to which the system can scale in terms of data volumes and numbers of concurrent users The degree to which the system can be validated

Configurability Extensibility Installability Interoperability Maintainability Replaceability

Scalability Testability

Constraints A constraint is a restriction on the degree of freedom we have in providing a solution. (Leffingwell 2000)

In essence, constraints represent restrictions on the solution, in that they restrict the available options.

Constraints | 369

Business Constraints Some of the constraints imposed upon an architect may come from the business. Table D.6 defines some constraints that are related to the business.

Table D.6 Examples of Business Constraints Requirement

Description

Compliance Cost Schedule

The ability to adhere to mandated standards and regulations Constraints on the cost of the solution and its deployment Constraints on the schedule for developing and deploying the solution

Architecture Constraints Various architectural mechanisms may be constrained. Table D.7 defines some constraints that are imposed on the architecture. Many more mechanisms may be at play in any given situation, of course.

Table D.7 Examples of Architecture Constraints Requirement

Description

Collaboration

Constraints on the mechanism for handling collaboration between users Constraints on the mechanism for handling interprocess communication Constraints on the mechanism for managing errors within the system Constraints on the mechanism for handling asynchronous events within the system Constraints on the mechanisms that allow this system to integrate with other systems Constraints on the mechanism for allowing system data to be written to disk Constraints on the mechanism for providing scheduling capability Constraints on the mechanism for providing security capability

Communication Error management Event management Integration Persistence Scheduling Security

Continued

370 | Appendix D Architectural Requirement Checklist

Table D.7 Examples of Architecture Constraints (Continued) Systems management Transaction management Workflow

Constraints on the mechanism for providing systems management capability Constraints on the mechanism for handling transactions Constraints on the mechanism for handling the movement of items of work, typically through an organization

Development Constraints Additional constraints may be imposed on any detailed design and development. Table D.8 defines some constraints that are imposed on the development and run-time environments.

Table D.8 Examples of Development Constraints Requirement

Description

Implementation languages Interface formats Legacy integration Network infrastructure Platform support Resource limits

Constraints on the programming languages to be used

Standards compliance Third-party components

Constraints on the format of any data passed between this system and external systems Constraints on the use of existing components Constraints on the platforms that the system will support Constraints on the platforms that the system will support Constraints imposed by any limits on the use of resources, such as memory and hard disk space Constraints imposed by any standards to which the system must conform Constraints on the use and cost of third-party components

Physical Constraints Table D.9 defines some constraints that are imposed by the physical environment. Such requirements are particularly relevant when the hardware housing the software is itself constrained in some way. Cellular phones, airplanes, and military hardware (such as tanks) all place physical constraints on the comput-

Constraints | 371

ing hardware, for example, and such constraints may themselves impose constraints on the software that executes on this hardware.

Table D.9 Examples of Physical Constraints Requirement

Description

Power consumption Shape Size Weight

Constraints on the power consumed by the system Constraints on the shape of the resulting hardware housing the system Constraints on the size of the hardware housing the system Constraints on the weight of the hardware housing the system

This page intentionally left blank

Glossary

This glossary defines the terms used throughout this book. activity A grouping of tasks. antipattern A commonly occurring pattern or solution that generates decidedly negative consequences. An antipattern may be a pattern in the wrong context. (Brown 1998) application framework The partial implementation of a specific area of an

application. architect The person, team, or organization responsible for systems architec-

ture. (IEEE 1471 2000) This term is synonymous with software architect. architecting The activities of dening, documenting, maintaining, improving,

and certifying proper implementation of an architecture. (IEEE 1471 2000) This term is synonymous with software architecting. architectural description A collection of products to document an architecture. (IEEE 1471 2000) architectural mechanism Common concrete solutions to frequently encoun-

tered problems. They may be patterns of structure, patterns of behavior, or both. (SPEM 2007)

373

374 | Glossary

architectural style A family of systems defined in terms of a pattern of struc-

tural organization. More specifically, an architectural style defines a vocabulary of components and connector types, and a set of constraints on how they can be combined. (Shaw 1996) architecture The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. (IEEE 1471 2000) architecture decision Conscious design decisions concerning a software sys-

tem as a whole, or one or more of its core components. These decisions determine the non-functional characteristics and quality factors of the system. (Zimmermann 2008). business rule A statement that defines or constrains some aspect of the busi-

ness. It is intended to assert business structure or to control or influence the behavior of the business. (Business Rules Group 2000). component A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a type whose conformance is defined by these provided and required interfaces (encompassing both their static as well as dynamic semantics). One component may therefore be substituted by another only if the two are type conformant. (UML 2.2 2009) concern Those interests that pertain to the system’s development, its operation, or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations such as performance, reliability, security, distribution, and evolvability. (IEEE 1471 2000) constraint A restriction on the degree of freedom we have in providing a solu-

tion. (Leffingwell 2000) design authority The role that takes specific responsibility for the overall tech-

nical integrity of the system and provides the necessary governance that links the IT system under development to the enterprise architecture goals, strategies, and principles, thus ensuring the system will meet the requirements. development process A set of partially ordered steps performed for a given

purpose during system development, such as constructing models or implementing models. (UML 2.0 2003) development project A temporary endeavor undertaken to create a unique

product or service. Temporary means that every project has a definite beginning and a definite ending. Unique means that the product or service is differ-

Glossary | 375

ent in some distinguishing way from all similar products and services. Projects are often critical components of the performing organizations’ business strategy. (RUP 2008) discipline A primary categorization mechanism for organizing tasks that

define a major “area of concern” and/or cooperation of work effort. (OpenUP 2008) domain An area of knowledge or activity characterized by a set of concepts

and terminology understood by practitioners in that area. (UML User Guide 1999) enterprise architecture The set of principles, guidelines, policies, models, standards, and processes that, when aligned with business strategy and information requirements, guide the selection, creation, and implementation of solutions that are aligned with future business direction. environment The environment, or context, determines the setting and cir-

cumstances of developmental, operational, political, and other inuences upon that system. (IEEE 1471 2000) functional requirement Descriptions of the behaviors (functions or services) of the [IT] system that support user goals, tasks or activities. (Malan 2001) iteration A short and set duration division of a project. Iterations allow you to demonstrate incremental value and obtain early and continuous feedback. (OpenUP 2008) method A regular and systematic way of accomplishing something; the detailed, logically ordered plans or procedures followed to accomplish a task or attain a goal. (RUP 2008) mission A use or operation for which a system is intended by one or more

stakeholders to meet some set of objectives. (IEEE 1471 2000) model The specific description, or content, of an architecture. For example,

a structural view might consist of a set of models of the system structure. The elements of such models might include identifiable system components and their interfaces, and interconnections among those components. (IEEE 1471 2000) non-functional requirement Requirements that include constraints and qualities. (Malan 2001) packaged application A large-grained commercial off-the-shelf product that provides a significant amount of capability (and reuse), such as a Customer

376 | Glossary

Relationship Management (CRM) application, or an Enterprise Resource Planning (ERP) application. pattern A common solution to a common problem in a given context. (UML

User Guide 1999) phase A specialized type of activity that represents a significant period in a

project normally ending with a decision checkpoint, major milestones, or a set of deliverables. Phases typically have well-defined objectives and provide the basis for how the project work will be structured. (OpenUP 2008) practice An approach to solving one or several commonly occurring problems. Practices are intended as “chunks” of process for adoption, enablement, and configuration. (RUP 2008) process See development process. quality Properties or characteristics of the system that its stakeholders care

about and hence will affect their degree of satisfaction with the system. (Malan 2001) rationale A set of reasons or a logical basis for a course of action or a belief. (OED) reference architecture An architecture associated with a particular domain of interest and typically includes many different architectural patterns, applied in different areas of its structure. reference model An abstract representation of entities, their relationships and

behavior, in a given domain of interest, and which typically forms the conceptual basis for the development of more concrete elements. Examples include a business model, an information model, and a glossary of terms. reusable asset A solution to a recurring problem. A reusable asset is an asset that has been developed with reuse in mind (RAS 2004) role The responsibilities of an individual, or a set of individuals working

together as a team, within the context of a software development organization. A role is responsible for one or more work products and performs a set of tasks. stakeholder An individual, team, or organization (or classes thereof) with

interests in, or concerns relative to, a system. (IEEE 1471 2000) subsystem A set of related components. system [1] A collection of components organized to accomplish a specic func-

tion or set of functions. The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines,

Glossary | 377

product families, whole enterprises, and other aggregations of interest. A system exists to fulll one or more missions in its environment. (IEEE 1471 2000) [2] An integrated composite that consists of one or more of the processes, hardware, software, facilities, and people, that provides a capability to satisfy a stated need or objective. (IEEE 12207 1995) task A unit of work that provides a meaningful result in the context of the project. It has a clear purpose, which usually involves creating or updating work products. All tasks are performed by appropriate roles. team A small number of people with complementary skills who are commit-

ted to a common purpose, performance goals, and approach for which they hold themselves mutually accountable. (Katzenbach 1993) traceability The mechanism by which we trace (identify and measure) from

one set of development elements to another. validation A process that focuses the system as a whole, rather than individual

work products. It is concerned with ensuring that the system satisfies the stated requirements. verification Verification allows us to determine whether the work products,

at the current point in the overall development process, are consistent with the inputs used to create them (such as other work products and any development standards that have been mandated). view A representation of a whole system from the perspective of a related set

of concerns. (IEEE 1471 2000) viewpoint A specification of the conventions for constructing and using a

view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis. (IEEE 1471 2000) viewpoint catalog A collection of viewpoints. work product A piece of information or physical entity that is produced and/

or used during the execution of the process. Examples of work products include models, plans, code, executables, documents, databases, and so on.

This page intentionally left blank

References

Agile Manifesto 2009. “The Agile Manifesto.” www.agilemanifesto.org (accessed April 2, 2009). Ahern 2008. Ahern, Dennis M., Aaron Clouse, and Richard Turner. 2008. CMMI Distilled: A Practical Introduction to Integrated Process Improvement, 3rd ed. Boston: Addison-Wesley. Alexander 1964. Alexander, Christopher. 1964. Notes on the Synthesis of Form. Cambridge, MA: Harvard University Press. Alexander 1977. Alexander, Christopher, Sara Ishikawa, and Murray Silverstein. 1977. A Pattern Language. New York: Oxford University Press. Alexander 1979. Alexander, Christopher. 1979. The Timeless Way of Building. New York: Oxford University Press. Ambler 2000. Ambler, Scott W. 2000. The Unified Process Elaboration Phase. Lawrence, KS: R&D Books. Ambler 2008. Ambler, Scott, and Celso Gonzalez. 2008. “Agile Model-Driven Development.” www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&ac=367 (accessed April 4, 2009). Barbacci 2003. Barbacci, Mario R., Robert Ellison, Anthony J. Lattanze, Judith A. Stafford, Charles B. Weinstock, and William G. Wood. 2003. “Quality Attribute Workshops (QAWs),” 3rd ed. www.sei.cmu.edu/publications/ documents/03.reports/03tr016.html (accessed April 4, 2009).

379

380 | References

Bass 2003. Bass, Len, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice, 2nd ed. Boston: Addison-Wesley. Bittner 2003. Bittner, Kurt, and Ian Spence. 2003. Use Case Modeling. Boston: Addison-Wesley. Booch 2009. Booch, Grady. 2009. “Handbook of Software Architecture,” www.handbookofsoftwarearchitecture.com (accessed April 4, 2009). Bosch 2000. Bosch, Jan. 2000. Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach. Harlow, England: Addison-Wesley. Brown 1998. Brown, William, Raphael Malveau, Hays McCormick and Thomas Mowbray. 1998. AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. New York: John Wiley and Sons. Buschmann 1996. Buschmann, Frank, et al. 1996. Pattern-Oriented Software Architecture: A System of Patterns. Chichester, England: John Wiley and Sons. Buschmann 2009. Buschmann, Frank, and Christa Schwanninger. 2099. “Architecture Reviews.” Frank Presentation at OOP, Munich, Germany, 2009. Business Rules Group 2000. The Business Rules Group. 2000. “Defining Business Rules: What Are They Really?” www.businessrulesgroup.org (accessed April 4, 2009). Cantor 2003. Cantor, Murray. 2003. “Rational Unified Process for Systems Engineering.” The Rational Edge. http://download.boulder.ibm.com/ibmdl/ pub/software/dw/rationaledge/aug03/f_rupse_mc.pdf (accessed April 4, 2009). Cheesman 2001. Cheesman, John, and John Daniels. 2001. UML Components: A Simple Process for Specifying Component-Based Software. Boston: Addison-Wesley. Clements 2001. Clements, Paul, and Linda Northrop. 2001. Software Product Lines: Practices and Patterns. Boston: Addison-Wesley. Clements 2002. Clements, Paul, Rick Kazman, and Mark Klein. 2002. Evaluating Software Architectures: Methods and Case Studies. Boston: AddisonWesley. Clements 2003. Clements, Paul, et al. 2003. Documenting Software Architectures:Views and Beyond. Boston: Addison-Wesley. Cockburn 2000. Cockburn, Alistair. 2000. Writing Effective Use Cases. Boston: Addison-Wesley. Conallen 2003. Conallen, Jim. 2003. Building Web Applications with UML, 2nd ed. Boston: Addison-Wesley.

References | 381

Coplien 2005. Coplien, James, and Neil Harrison. 2005. Organizational Patterns of Agile Software Development. Upper Saddle River, NJ: Prentice Hall. Eeles 2008. Eeles, Peter. 2008. “The Rise of the Development Environment Architect.” The Rational Edge. www.ibm.com/developerworks/rational/ library/edge/08/apr08/eeles/index.html (accessed April 4, 2009). Fagan 1976. Fagan, Michael. 1976. “Design and code inspections to reduce errors in program development.” IBM Systems Journal 15:3;182–211. Fowler 1997. Fowler, Martin. 1997. Analysis Patterns: Reusable Object Models. Menlo Park, CA: Addison-Wesley. Gamma 1995. Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. 1995. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley. Gilb 1988. Gilb, Tom. 1988. Principles of Software Engineering Management. Wokingham, England: Addison-Wesley. Gilb 1993. Gilb, Tom, and Dorothy Graham. 1993. Software Inspection. Wokingham, England: Addison-Wesley. Grady 1992. Grady, Robert B. 1992. Practical Software Metrics for Project Management and Process Improvement. Upper Saddle River, NJ: Prentice Hall. Herzum 2000. Herzum, Peter, and Oliver Sims. 2000. Business Component Factory. New York: John Wiley and Sons. Hofmeister 2000. Hofmeister, Christine, Robert Nord, and Dilip Soni. 2000. Applied Software Architecture. Reading, MA: Addison-Wesley. Hofmeister 2005: Hofmeister, Christine et al. 2005. “Generalizing a Model of Software Architecture Design from Five Industrial Approaches.” Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA5). Washington, DC: IEEE Computer Society. Hopkins 2008. Hopkins, Richard, and Kevin Jenkins. 2008. Eating the IT Elephant: Moving from Greenfield Development to Brownfield. Upper Saddle River, NJ: IBM Press. IAA 2009. IBM. “Insurance Application Architecture.” www-03.ibm.com/ industries/insurance/us/detail/solution/P669447B27619A15.html (accessed April 4, 2009). IBM 2009. “IBM patterns for e-business.” www.ibm.com/developerworks/ patterns/ (accessed April 4, 2009).

382 | References

IEEE 1061 1992. IEEE Computer Society. 1992. Standard for a Software Quality Metrics Methodology. IEEE Std 1061-1992. http://standards.ieee.org/ reading/ieee/std_public/description/se/1061-1992_desc.html (accessed April 4, 2009). IEEE 12207 1995. IEEE Computer Society. 1995. IEEE Standard for Information Technology—Software Life Cycle Processes. IEEE Std 12207-1995. http:// ieeexplore.ieee.org/ISOL/standardstoc.jsp?punumber=5410 (accessed April 4, 2009). IEEE 1471 2000. IEEE Computer Society. 2000. Recommended practice for architectural description of software-intensive systems. IEEE Std 1471-2000. http://standards.ieee.org/reading/ieee/std_public/description/se/14712000_desc.html (accessed April 4, 2009). ISO 9126 2001. International Organization for Standardization/International Electrotechnical Commission. 2001. ISO/IEC 9126-1:2001. Software engineering—Product quality—Part 1: Quality model. www.iso.org/iso/ iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22749 (accessed April 4, 2009). Jacobson 1992. Jacobson, Ivar, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard. 1992. Object-Oriented Software Engineering: A Use Case Driven Approach. Wokingham, England: Addison-Wesley. Jacobson 1997. Jacobson, Ivar, Martin Griss, and Patrik Jonsson. 1997. Software Reuse: Architecture, Process and Organization for Business Success. Harlow, England: Addison-Wesley. Katzenbach 1993. Katzenbach, Jon R., and Douglas K. Smith. 1993. The Wisdom of Teams. Boston: Harvard Business School Press. Kruchten 1995. Kruchten, Philippe. 1995. “The ‘4+1’ View Model of Software Architecture.” IEEE Software 12:6;42–50. Kruchten 1995-2. Kruchten, Philippe. 1995. “Mommy, Where Do Software Architectures Come From?” Proceedings of 1st International Workshop on Architectures for Software Systems, Seattle, 1995. Kruchten 1999. Kruchten, Philippe. 1999. “The Architects: The Software Architecture Team.” Donohoe, Patrick, ed. Proceedings of the First Working IFIP Conference on Software Architecture (WICSA1). Deventer, Netherlands: Kluwer Academic Publishing. Kruchten 2000. Kruchten, Philippe. 2000. The Rational Unified Process: An Introduction, 2nd ed. Reading, ME: Addison-Wesley. Leffingwell 2000. Leffingwell, Dean, and Don Widrig. 2000. Managing Software Requirements: A Unified Approach. Reading, MA: Addison-Wesley.

References | 383

Malan 2001. Malan, Ruth, and Dana Bredemeyer. 2001. “Defining NonFunctional Requirements.” www.bredemeyer.com/pdf_files/ NonFunctReq.PDF (accessed April 4, 2009). Marasco 2004. Marasco, Joe. 2004. “On Politics in Technical Organizations.” The Rational Edge. www.ibm.com/developerworks/rational/library/ 4690.html (accessed April 4, 2009). McGovern 2004. McGovern, James, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo. 2004. A Practical Guide to Enterprise Architecture. Upper Saddle River, NJ: Prentice Hall. MDA 2009. Object Management Group. 2009. “Model Driven Architecture.” www.omg.org/mda/ (accessed April 4, 2009). MDSD 2009. IBM Redbooks. 2009. “Model Driven Systems Development with Rational Products.” www.redbooks.ibm.com/abstracts/sg247368.html (accessed April 4, 2009). Meyer 1997. Meyer, Bertrand. 1997. Object-Oriented Software Construction, 2nd ed. Upper Saddle River, NJ: Prentice-Hall. Microsoft 2009. “Microsoft Patterns and Practices Developer Center.” http:// msdn.microsoft.com/en-gb/practices/default.aspx (accessed April 4, 2009). OED 2009. AskOxford.com. www.askoxford.com (accessed April 4, 2009). OpenUP 2008. Open Unified Process, Version 1.5.0.1. 2008. http:// epf.eclipse.org/wikis/openup/ (accessed April 4, 2009). RAS 2004. Reusable Asset Specification. Object Management Group, Inc. Document number 04-06-06. www.omg.org/cgi-bin/doc?ptc/2004-06-06 (accessed April 4, 2009). Royce 1998. Royce, Walker. 1998. Software Project Management: A Unified Framework. Upper Saddle River, NJ: Addison-Wesley. Royce 2005. Royce, Walker. 2005. “Successful software management style: Steering and balance.” The Rational Edge. www.ibm.com/developerworks/ rational/library/mar05/royce/ (accessed April 4, 2009). Rozanski 2005. Rozanski, Nick, and Eoin Woods. 2005. Software Systems Architecture:Working with Stakeholders Using Viewpoints and Perspectives. Upper Saddle River, NJ: Addison-Wesley. RUP 2008. Rational Unified Process. IBM Rational Software, Version 7.5. www.ibm.com/software/awdtools/rmc (accessed April 4, 2009). SARA 2002. Software Architecture Review and Assessment (SARA) Report, Version 1.0. Henk Obbink, Henk, et al. 2002. http://philippe.kruchten.com/ architecture/SARAv1.pdf (accessed April 4, 2009).

384 | References

Schwaber 2002. Schwaber, Ken, and Mike Beedle. 2002. Agile Software Development with Scrum. Upper Saddle River, NJ: Prentice Hall. SEI 2009. Software Engineering Institute (SEI) Architecture website. www.sei.cmu.edu/architecture (accessed April 4, 2009). Shaw 1996. Shaw, Mary, and David Garlan. 1996. Software Architecture: Perspectives on an Emerging Discipline. Upper Saddle River, NJ: Prentice Hall. SPEM 2007. Software & Systems Process Engineering Metamodel Specification, Version 2.0. Object Management Group, Inc. Document number 07-08-07, October 2007. www.omg.org/technology/documents/formal/spem.htm (accessed April 4, 2009). Stevens 1974. W. P. Stevens, G. J. Myers, L. L. Constantine. 1974. “Structured design.” IBM Systems Journal 13:2;115. Sun 2009. Sun Java BluePrints. http://java.sun.com/blueprints/patterns/ index.html (accessed April 4, 2009). TOGAF 2009. The Open Group Architecture Framework. TOGAF 8.1.1. www.opengroup.org/architecture/togaf8-doc/arch/toc.html (accessed April 4, 2009). Tyree 2005. Tyree, Jeff, and Art Akerman. 2005. “Architecture Decisions: Demystifying Architecture.” IEEE Software 22:2. UML 2.2 2009. UML 2.2 Superstructure Specification. Object Management Group, Inc. Document number 09-02-02, February 2009. www.omg.org/ docs/formal/09-02-02.pdf (accessed April 4, 2009). UML User Guide 1999. Booch, Grady, James Rumbaugh, and Ivar Jacobson. 1999. The Unified Modeling Language User Guide. Reading, MA: Addison-Wesley. von Halle 2001. von Halle, Barbara. 2001. Business Rules Applied. New York: John Wiley and Sons. Warmer 1999. Warmer, Jos, and Anneke Kleppe. 1999. The Object Constraint Language: Precise Modeling with UML. Reading, MA: Addison-Wesley. Wirfs-Brock 1990. Wirfs-Brock, Rebecca, et al. 1990. Designing Object-Oriented Software. Englewood Cliffs, NJ: Prentice Hall. Zachman 1987. Zachman, John. 1987. “A Framework for Information Systems Architecture.” IBM Systems Journal 26:3. Zimmermann 2008. Zimmermann, Olaf, et al. 2008. “Combining Pattern Languages and Reusable Architectural Decision Models into a Comprehensive and Comprehensible Design Method.” Proceedings of 7th IEEE/IFIP Working Conference on Software Architecture. Los Alamitos, CA: IEEE Computer Society.

Index

A Abstraction levels, modeling, 74 Abstractions, 78. See also Views. Acceptance testing, 306 Accessibility perspective, 81 Activities. See also specific activities. definition, 49–50, 356–357 in the development process, 44–45 involved in architecture. See specific activities. Actors checklist of, 144 identifying, 144–146 locations, identifying, 146–147 overlooking, 144 refactoring, 154–155 use cases, 165 ADD (Attribute-Driven Design) method, 182–183 Agile processes, 58–59 Alexander, Christopher, 97 Antipatterns, 97 Application Architect, 47, 113, 352 Application architecture architectural scope, 18 influence on architects, 315 roles related to, 47 Application framework assets, 102–103 Application integration architecting complex systems, 329 case study, 116 Application maintenance provider, influence on architects, 318 Application viewpoint, 344

Architecting accommodating diverse stakeholders, 32–33 complex systems. See Complex systems, architecting. definition, 27, 335 disciplines involved, 30–31 making trade-offs, 33–34 as ongoing activity, 31–32 process metamodel, 28–29 project emphasis, over time, 31–32 reusing assets, 34 science versus art, 30 top-down versus bottom-up, 34–35 Architecting, benefits of addressing system qualities, 34–35 architectural integrity, 38–39 cost estimation, 37–38 impact analysis, 40 managing complexity, 39 performance requirements, 35 in the planning process, 36–38 reducing maintenance costs, 39–40 reusing assets, 39 risk management, 38 scheduling, 37 security requirements, 35 stakeholder consensus, 36 Architects application, 20 business domain knowledge, 23–24 communication skills, 26 data, 20

385

386 | Index Architects, continued decision making, 26 definition, 21, 335 design skills, 24–25 disciplines involved, 30–31 infrastructure, 20 negotiating skills, 27 organizational politics, 26–27 programming skills, 25 software development knowledge, 23 in teams, 22 technical leadership, 21–22 technology knowledge, 24 Architects, external influences application architecture, 315 application maintenance provider, 318 Architecture Assessment, 317 Architecture Decisions, 317 business architecture, 315 Business Entity Model, 316 Business Process Model, 316 Business Rules, 316 design authority, 316–317 enterprise architecture, 315–316 Enterprise Architecture Principles, 316, 317 Existing IT Environments, 316 information architecture, 315 infrastructure providers, 317–318 overview, 313–315 technology architecture, 315 Architects, roles avoiding technical details, 306 business analysis, 312–313 change management, 310–311 configuration management, 308–310 development, 304–306 development environment, 311–312 versus individuals, 22 organizational blueprint, 313 project management, 307–309 requirements, 304 standards versus guidelines, 311–312 testing, 306–307 TOM (Target Operating Model), 313 Architectural integrity, 38–39 mechanism assets, 96 partitioning, 17 patterns, 97 perspectives. See Perspectives. significance, 129 style assets, 95–96 styles, 15–16

Architectural description definition, 335 elements of, 64–65 standards. See IEEE 1471-2000, IEEE Recommended Practice for Architectural Description... Architecture activities involved in. See specific activities. application, 18 constraints, 369–370 data, 18 definition, 335 definitions, 9, 11 versus design, 4 development team structure, 17 documenting. See Documentation. enterprise, 18 environmental influences, 16–17 forms of, 18 hardware, 18 information, 18 infrastructure, 18 logical. See Create Logical Architecture. metamodel diagram, 333–335 physical. See Create Physical Architecture. scope of activities, 18–21 system, 18 Architecture, purpose of balancing stakeholder needs, 14–15 behavioral definition, 12–13 documenting decision rationales, 15 focus on significant elements, 13–14 structural definition, 11–12 Architecture Assessment influence on architects, 317 output of Create Logical Architecture, 181 as work product, 354 Architecture Decisions assets, 100–101 definition, 335 documenting. See Document Architecture Decisions. influence on architects, 317 Outline Deployment Elements, identifying locations, 224 Outline Deployment Elements, identifying nodes, 227 output of Create Logical Architecture, 181 as work product, 354 Architecture description, packaging, 63 Architecture description framework abstractions, 78. See also Views. accessibility perspective, 81 availability perspective, 80

Index | 387 business model perspective, 79 characteristics, 76 detailed representation perspective, 79 development resource perspective, 81 development view, 77 evolution perspective, 80 functioning enterprise perspective, 79 internationalization perspective, 81 levels of realization, 78–79, 85–86 location perspective, 81 logical view, 77 performance perspective, 80 perspectives, 78–79. physical view, 77 process view, 77 regulation perspective, 81 resilience perspective, 80 scalability perspective, 80 scenarios view, 77 scope perspective, 79 security perspective, 80 starting from scratch, 76 system model perspective, 79 technology model perspective, 79 usability perspective, 81 Zachman Framework, 77–79 Architecture description framework, viewpoints application, 83 availability, 83 concurrency, 79 data, 78 deployment, 80, 83 development, 79 functional, 78, 79, 83 information, 79 infrastructure, 83 motivation, 79 network, 78 operational, 80 people, 78 performance, 83 requirements, 83 security, 84 stakeholders, summary of, 81–82 summary of, 83–84 systems management, 83 time, 79 validation, 83 Zachman Framework, 78–79 Architecture discipline, 46 Architecture Overview, 182, 354 Architecture Proof-of-Concept, 182, 354. See also Build Architecture Proof-of-Concept.

Art versus science of architecting, 30 Articulation, asset attribute, 103, 104 Artifact stimulated, in scenarios, 173 Artifacts, definition, 48 Assets consumption, over time, 57 existing, identifying, 6 name attribute, 105 reusing. See Reusing assets; Survey Architecture Assets. type attribute, 105 Asynchronous communication, Java EE, 283 ATAM (Architecture Tradeoff Analysis Method), 253–254 AtP (authorization to proceed) points, 301 Attribute-Driven Design (ADD) method, 182–183 Audience identification, 66 Author, asset attribute, 104 Availability perspective, 80 Availability viewpoint architecting complex systems, 326–327 description, 83, 345–346 B Basic viewpoints, 341–344 Best practices architecture as a system of systems, 328 Capture Common Vocabulary, 143 componentizing architecture, 320 documentation, 64 establishing standards, 321 Outline Non-Functional Requirements, 157 quality-driven architecture definition, 327 reconciling synonyms and homonyms, 143 selecting viewpoints, 110 surveying existing IT environment, 115 tracing solutions to requirements, 214 understanding the environment, 115 Bottom-up architecting, 34–35 Boundary components, 206 Brownfield development, 111 Build Architecture Proof-of-Concept, logical architecture. See also Create Logical Architecture. Architecture Proof-of-Concept, definition, 182 creating the proof of concept, 233–234 documenting findings, 234 purpose, 6–7, 190 task description, 232–233 task inputs, 233–234 Build Architecture Proof-of-Concept, physical architecture, 293–294 Business analysis, architect’s role, 312–313 Business Analyst refactoring actors and use cases, 155 roles and responsibilities, 112, 352

388 | Index Business architecture, influence on architects, 315 Business behavior expected. See Business Process Model. Business constraints, 369 Business domain, asset attribute, 105 Business domain knowledge, architects, 23–24 Business Entity Model case study, 114, 117–118 definition, 125–126 identifying components, 207–208 influence on architects, 316 input to Create Logical Architecture, 181 as work product, 355 Business model perspective, 79 Business policies. See Business Rules. Business Process Model case study, 114 definition, 125–126 influence on architects, 316 as work product, 355 Business Rules categories of, 158 constraints provided by, 122–123 definition, 158 identifying components, 217–219 identifying Non-Functional Requirements, 157 influence on architects, 316 input, 114, 125–126 input to Create Logical Architecture, 181 placement on components, 217–219 representation on components, 217–219 as work product, 355 Buying versus building, physical architecture, 278–279 C Cantor, Murray, 330 Capture Common Vocabulary. See also Glossary. best practices, 143 case study, 117–118 creating a Glossary, 141–143 in the design process, 4–5 different words, same meaning, 143 homonyms, 143 purpose of, 134–135 same words, different meaning, 143 synonyms, 143 task description, 141–142 Case study inputs and outputs, 133. logical architecture. See Create Logical Architecture. physical architecture. See Create Physical Architecture. requirements definition. See Define Requirements.

role of the architect, 133 roles, primary and secondary, 133 task descriptions, 133 Case study, application overview application integration, 116 Business Entity Model, 117–118 business terminology, identifying, 117–118 common challenges, 116 constraints, 116 core functional requirements, 116 development-time qualities, 116 key business concepts, 117–118 physical distribution, 116 reusable assets, 116 run-time qualities, 116 Case study, scope of Application Architect, responsibilities, 113 brownfield versus greenfield development, 111 Business Analyst, responsibilities, 112 Business Entity Model, 114 Business Process Model, 114 Business Rules, 114 Data Architect, responsibilities, 113 Developer, responsibilities, 113 Enterprise Architecture Principles, 114 Existing IT Environment, 114–115 external influences, 113–115 Infrastructure Architect, responsibilities, 113 Lead Architect, responsibilities, 113 overview, 110–111 Project Manager, responsibilities, 112 project team, individual responsibilities, 112–113 Tester, responsibilities, 113 work products, input, 114 Change cases, 152 Change management. See also Impact analysis. architect’s role, 310–311 impact modeling, 75 Change Requests Create Logical Architecture, 182 Define Requirements, 125–127 as work product, 355 Chunking the architecture, 320 CIM (Computation Independent Model), 322 Cohesion, components, 215 Collect Stakeholder Requests checklist of stakeholders, 137 collecting the requests, 138–141 in the design process, 4–5 identifying stakeholders, 136–137 objective measurements, 140 pitfalls, 138–141 prioritizing requests, 141

Index | 389 purpose, 4–5, 134–135 requests versus requirements, 136, 138–139 shopping-cart mentality, 139 talking to the wrong people, 140 task description, 136 technical questionnaires, 139–140 vague requests, 140 Combining patterns, 100 Commercial products, physical architecture, 263 Commercial-off-the-shelf (COTS) products, 101–102, 265 Communication skills, architects, 26 Complete implementation assets, 104 Complex systems, architecting application integration, 329 availability viewpoint, 326–327 broad system distribution, 324 chunking the architecture, 320 componentizing the architecture, 320 crossing organizational boundaries, 324 decomposing into subsystems, 328–329 enterprise architecture, 328 establishing standards, 321–323 geographically distributed teams, 325 many people involved, 320–323 multiple distinct functions, 319–320 operational quality challenges, 326–327 overview, 318–319 packaged application development, 329 performance viewpoint, 326 recursion, 328 security viewpoint, 327 SOA (service-oriented architecture), 328 software product lines, 329 strategic reuse, 328–329 subordinate systems, 328 superordinate systems, 328 system, definition, 330 systems engineering, 328 systems of systems, 327–330 usability viewpoint, 326 viewpoints, selecting, 326–327 Complexity, managing benefits of architecting, 39 with viewpoints, 71–72 Component identification, Outline Functional Elements from Business Entity Model, 207–208 from Business Rules, 217–219 from Functional Requirements, 208–212 from Non-Functional Requirements, 212–217 overview, 206 from Prioritized Requirements List, 208–212 quality metrics, 215

requirement realizations, 214 size of function, 215 strength of associations, 215 traceability, 212, 214 use cases, examples, 209, 211, 213 use cases, UML sequence diagram, 213 Component library assets, 103 Componentizing the architecture, 320 Components as assets, 103 boundary, 206 control, 206–207 data, 207 Define Architecture Overview, 197 definition, 10 description, example, 271 Detail Deployment Elements, 245–246, 248 entity, 207 execution components, 206–207 logical architecture, 204–207 placing Business Rules, 217–219 presentation, 206 representing Business Rules, 217–219 UML representations, 207 Components, Detail Functional Elements contracts, defining, 242 interfaces, defining, 235–237 interfaces, definition, 235–236 operation names, specifying, 237 provided interfaces, 235 required interfaces, 235 signature names, specifying, 237 specification diagram, 239 specification diagrams, 237 use case, UML sequence diagram, 238 Components, Outline Functional Elements allocating to subsystems, 211–212 characteristics of, 206 cohesion, 215 coupling, 215 definition, 204 granularity, 215 Computation Independent Model (CIM), 322 Concerns, definition, 336 Concerns addressed, asset attribute, 104 Concurrency viewpoint, 79 Configuration management, architect’s role, 308–310 Constraints application overview, 116 Business Rules, 122–123 case study, 116, 122–123 client Vision, 122–123 on Non-Functional Requirements, 130

390 | Index Constraints, continued OCL (Object Constraint Language), 243 Vision, 122–123 Constraints, on requirements architecture, 369–370 business, 369 definition, 368 development, 370 physical, 370–371 Construction phase, 55–57, 363–364 Contained artifacts, asset attribute, 104 Containers, Java EE, 282 Context. See Environment; Scenarios; Use cases. Contracts, components, 242 Control components, 206–207 Conversational state, data flow, 239 Conway’s Law, 17 Core functional requirements, 116 Correspondence views, 87 Cost estimation, benefits of architecting, 37–38 of maintenance, reducing, 39–40 COTS (commercial-off-the-shelf) products, 101–102, 265 Coupling, components, 215 Create Logical Architecture activity overview, 188–191, 360. See also specific activities. ADD (Attribute-Driven Design) method, 182–183 architectural overview. See Define Architecture Overview. Architecture Assessment, 181 Architecture Decisions, 181, 202–203. See also Document Architecture Decisions; Update Software Architecture Document. Architecture Overview, 182 Architecture Proof-of-Concept, 182. See also Build Architecture Proof-of-Concept. Build Architecture Proof-of-Concept, 6–7 Business Entity Model, 181 Business Rules, 181 Change Requests, 182 Create Logical Detailed Design, 3 Data Model, 182 Define Architecture Overview, 6 deployment elements. See Detail Deployment Elements; Outline Deployment Elements. Deployment Model, 182, 183 description, 3 Detail Functional Elements, 6–7 Document Architecture Decisions, 6. See also Architecture Decisions.

documenting decisions. See Document Architecture Decisions. documenting findings. See Update Software Architecture Document. Enterprise Architecture Principles, 181 Existing IT Environments, 181 flow diagrams, 6, 189 functional elements. See Detail Functional Elements; Functional Requirements; Outline Functional Elements. Functional Model, 182, 183 Glossary, 181 inputs/outputs, 180–182 as an investment, 186–187 logical architecture versus physical, 179 Non-Functional Requirements, 181, 182–183 Outline Functional Elements, 6–7 outline tasks versus detail tasks, 191 proof of concept. See Build Architecture Proof-of-Concept. RAID Logs, 181–182 from requirements to solutions, 182–185 reusing assets. See Survey Architecture Assets. Review Architecture with Stakeholders, 6–7 Review Records, 182 reviewing results with stakeholders. See Review Architecture with Stakeholders. rightsizing, 185–186 RUP (Rational Unified Process), 184 S4V (Siemen’s 4 Views) method, 184 Software Architecture Document, 182 Survey Architecture Assets, 6 system context. See Define System Context; System Context. tactics, 185 task summary, 361 tasks involved, 6 traceability, 186–187 Update Software Architecture Document, 6–7 validating results. See Validate Architecture; Verify Architecture. verifying results. See Validate Architecture; Verify Architecture. Create Logical Architecture, components boundary components, 206 characteristics of, 206 control components, 206–207 data components, 207 definition, 204 entity components, 207 execution components, 206–207 identifying, 206

Index | 391 presentation components, 206 UML representations, 207 Create Logical Architecture, process overview Build Architecture Proof-of-Concept, 6–7 Create Logical Detailed Design, 3 Define Architecture Overview, 6 description, 3 Detail Deployment Elements, 6–7 Detail Functional Elements, 6–7 Document Architecture Decisions, 6 flow chart, 6 Outline Deployment Elements, 6 Outline Functional Elements, 6–7 Review Architecture with Stakeholders, 6–7 Survey Architecture Assets, 6 tasks involved, 6 Update Software Architecture Document, 6–7 Validate Architecture, 6–7 Verify Architecture, 6 Create Logical Detailed Design, 3 Create Physical Architecture activity overview, 266–269, 362. See also specific activities. Build Architecture Proof-of-Concept, 293–294 commercial products, 265 component description, example, 271 COTS (commercial-off-the-shelf) products, 265 Create Physical Detailed Design, 3, 7 custom development, 263 Define Architecture Overview, 270–273 description, 3 Detail Functional Elements, 294–296 Document Architecture Decisions, 273 documenting architectural decisions, 301 flow diagrams, 264, 267, 272 inputs and outputs, 262 iterative development, 265–266 mixing logical and physical concepts, 266 Non-Functional Requirements, 273 operations signatures, 295 physical architecture versus logical, 179 postconditions, 295 preconditions, 295 products, choosing, 263 reusing assets, 263, 269–270 Review Architecture with Stakeholders, 301–302 software products, 265 stakeholder signoff, 301 Survey Architecture Assets, 269–270 system elements, identifying and describing, 270–273 task summary, 362

tasks involved, 7 technological platform, choosing, 263 transition from logical architecture, 263–265 Update Software Architecture Document, 301 Validate Architecture, 267–268, 300–301 Verify Architecture, 267–268, 292–293 view overloading, 266 Create Physical Architecture, Detail Deployment Elements data migration, 299–300 horizontal scalability, 300 mapping components to deployment units, 297–299 overview, 296 post-deployment concerns, 299–300 scalability, 300 software packaging, 299 vertical scalability, 300 Create Physical Architecture, Outline Deployment Elements hardware procurement, 292 many-to-one mapping, 290 mapping logical elements to physical, 289–290 one-to-many mapping, 289 one-to-one mapping, 289 physical elements, identifying, 290–292 Create Physical Architecture, Outline Functional Elements buying versus building, 278–279 Java EE, 281–283 many-to-one mapping, 275–276 mapping logical elements to physical, 274–276 one-to-many mapping, 274–275 one-to-one mapping, 274, 275 physical elements, identifying, 277, 279 product procurement, 279–280 requirements realization, 286–287 software products, selecting, 280 technology independence, 276–277 technology-specific patterns, 280–289 Create Physical Architecture, process overview Create Physical Detailed Design, 3, 7 description, 3 tasks involved, 7 Create Physical Detailed Design, 3, 7 Cross-cutting viewpoints, 68–70, 79–81, 344–347 Custom development, physical architecture, 263 D Data Architect, roles and responsibilities description, 353 software and information, 20 system data elements, 47, 113

392 | Index Data architecture, 18, 47 Data components, 207 Data flows conversational state, 239 identifying, 147–149 persisted data, 240 transient data, 239 use cases, 170 Data migration, 299–300 Data Models, 182, 355 Data viewpoint, 78 Decision making, by architects, 26 Declaring victory too soon, 55 Decomposing systems into subsystems, 328–329 Define Architecture Overview, logical architecture. See also Create Logical Architecture. components, 197 defining the overview, 195–199 Enterprise Architecture Principles, 195–196 flow diagram, 196 layers, 198–199 notational styles, 195 purpose, 6, 188 subsystems, 197 task description, 194 tiers, 198–199 Define Architecture Overview, physical architecture, 270–273 Define Requirements activities, overview, 134–135, 358–359. See also specific activities. architectural significance, 129 Business Entity Model, 125–126 Business Process Model, 125–126 Business Rules, 125–126 Capture Common Vocabulary, 4–5 Change Requests, 125–127 description, 3 documenting requirements, 131–132 Enterprise Architecture Principles, 126–127 Existing IT Environments, 126–127 flow chart, 5 functional requirements. See Detail Functional Requirements; Functional Requirements; Outline Functional Requirements. Glossary, 126–127 inputs, 125–127 iterative development, 132–133 non-functional requirements. See Detail Non-Functional Requirements; Non-Functional Requirements; Outline Non-Functional Requirements. outlining requirements. See Outline Functional Requirements; Outline Non-Functional Requirements.

outputs, 126–128 Prioritize Requirements, 4–5 Prioritized Requirements List, 126–127 prioritizing requirements. See Prioritize Requirements. RAID Log, 126–127 refining requirements, 133 relationship to architecture, 128–129 requirements management, 132–133 Review Records, 126–127 Software Architecture Document, 126–127 Stakeholder Requests, 126, 128, 157 stakeholder requests, collecting. See Collect Stakeholder Requests. stakeholder review. See Review Requirements with Stakeholders. system context. See Define System Context; System Context. task summary, 359 tasks involved, 5 Update Software Architecture Document, 5, 134–135, 174 user terminology. See Capture Common Vocabulary. Vision, 126–127 Define Requirements, process overview. See also Define System Context. Capture Common Vocabulary, 4–5 Collect Stakeholder Requests, 4–5 description, 3 Detail Functional Requirements, 5 Detail Non-Functional Requirements, 5 flow chart, 5 Outline Functional Requirements, 4–5 Outline Non-Functional Requirements, 4–5 Prioritize Requirements, 4–5 Review Requirements with Stakeholders, 5 tasks involved, 5 Update Software Architecture Document, 5 Define System Context in the design process, 4–5 identifying actor locations, 146–147 identifying data flows, 147–149 identifying Non-Functional Requirements, 157 purpose of, 134–135 sample diagram, 145 task description, 143–144 Define System Context, actors checklist of, 144 identifying, 144–146 refactoring, 154–155 Definitions. See Glossary; specific terms. Deliverables, definition, 48

Index | 393 Deployment. See also Detail Deployment Elements; Outline Deployment Elements. elements, 6–7 logical deployment units, 248 view, 68–70, 85 viewpoint Deployment Model, 182, 183, 355 Design authority, influence on architects, 316–317 Design patterns, 97 Design skills, architects, 24–25 Detail Deployment Elements, logical architecture. See also Create Logical Architecture; Outline Deployment Elements. purpose, 6–7, 190 task description, 245 Detail Deployment Elements, logical architecture components assigning to nodes, 245–246 logical deployment units, 248 Detail Deployment Elements, logical architecture location connection definitions, 250 Detail Deployment Elements, logical architecture nodes assigning components to, 245–246, 247 connections between, defining, 246, 249 deployment units, 246, 248 links to components, 246 Detail Deployment Elements, physical architecture data migration, 299–300 horizontal scalability, 300 mapping components to deployment units, 297–299 overview, 296 post-deployment concerns, 299–300 scalability, 300 software packaging, 299 vertical scalability, 300 Detail Functional Elements, logical architecture. See also Create Logical Architecture; Outline Functional Elements. interface responsibility diagram, 240–242 interfaces, mapping to business types, 240–242 logical Data Model, 240 postconditions, 242–244 preconditions, 242–244 purpose, 6–7, 190 task description, 234–235 Detail Functional Elements, logical architecture components contracts, defining, 242 interfaces, defining, 235–237 interfaces, definition, 235–236 operation names, specifying, 237 provided interfaces, 235

required interfaces, 235 signature names, specifying, 237 specification diagram, 239 specification diagrams, 237 use case, UML sequence diagram, 238 Detail Functional Elements, logical architecture data flows conversational state, 239 persisted data, 240 transient data, 239 Detail Functional Elements, physical architecture, 294–296 Detail Functional Requirements. See also Functional Requirements; Outline Functional Requirements. in the design process, 5 input from Outline Functional Requirements, 165–169 purpose of, 134–135 scenarios, 170–171 system-wide, 170 task description, 164–165 Detail Functional Requirements, use cases actors, 165 context, 166 data flows, 170 detailed data items, 170 event flows, alternative, 165, 168 event flows, main, 165, 168 event flows, required information, 167–168 input from Define System Context, 170 postconditions, 166, 169 preconditions, 166, 169 special requirements, 165, 168–169 Detail Non-Functional Requirements in the design process, 5 Glossary, consistency, 172 purpose of, 134–135 scenarios, parts of, 172–173 SMART (specific, measurable, achievable, realistic, time-based), criteria, 172 task description, 171 Detail tasks versus outline tasks, 191 Detailed data items, use cases, 170 Detailed design. See also Create Logical Architecture; Create Physical Architecture. Create Logical Detailed Design, 3 Create Physical Detailed Design, 3, 7 Detailed representation perspective, 79 Developer, roles and responsibilities, 113, 353 Development architect’s role, 304–306 constraints, 370 discipline, 46

394 | Index Development, continued discipline, asset attribute, 105 environment, architect’s role, 311–312 method, asset attribute, 105 method assets, 94–95 phase, asset attribute, 105 process, definition, 336 projects, definition, 336 resource perspective, 81 scope, asset attribute, 105 view, 77 viewpoint, 79 Development-time assets, 92, 93 Development-time qualities, 116 Diagrams with models and views, 72–73 views as, 70–71 Disciplines. See also specific disciplines. definition, 45 summary of, 46 Document Architecture Decisions, logical architecture. See also Create Logical Architecture; Software Architecture Document; Update Software Architecture Document. capturing issues or problems, 201 document decisions, 202–203 options, assessing, 201–202 options, selecting, 202 purpose, 6, 190 RAID Logs, 201 task description, 200–201 Document Architecture Decisions, physical architecture, 273. See also Architecture description framework; Create Physical Architecture; Software Architecture Document; Update Software Architecture Document. Documentation. See also Architecture description framework; Document Architecture Decisions; Modeling; Software Architecture Document; Update Software Architecture Document; Viewpoints; Views. agile processes, 59 architectural decisions, 6–7. See also Document Architecture Decisions; Software Architecture Document; Update Software Architecture Document. architecture description, packaging, 63 benefits of, 61–62 best practices, 64 decision rationales, 15 Functional Requirements, case study, 131–132 importance of, 17–18 minimal but sufficient, 64 process description, 62–64

role of architecture, 15 Software Architecture Document, creating, 63–64 stakeholders, identifying, 63 work products, creating, 63 Document-driven versus results-driven architecture, 160–161 Domain, 24. See also Business domain. E EJB interfaces, 282–283 EJBs (Enterprise JavaBeans), 282–283 Elaboration phase, 55–57, 363 Enterprise, system element, 19–20 Enterprise architecture architecting complex systems, 328 influence on architects, 315–316 scope of activities, 18 Enterprise Architecture Principles case study, 126–127 Define Architecture Overview, 195–196 description, 114 identifying Non-Functional Requirements, 157 influence on architects, 316, 317 input to Create Logical Architecture, 181 Outline Deployment Elements, identifying locations, 224 Survey Architecture Assets, 193–194 as work product, 355 Entity beans, 283 Entity components, 207 Environment architectural influences, 16–17 definition, 10, 336 geographical partitioning, 17 IT, surveying existing, 115 in scenarios, 173 understanding, 115 Error detection, modeling, 75 Event flows, in use cases alternative, 165, 168 main, 165, 168 required information, 167–168 Event-based architecture assets, 95–96 Evolution perspective, 80 Execution components, 206–207 Existing applications, reusing, 101 Existing IT Environments case study, 114–115, 126–127 influence on architects, 316 input to Create Logical Architecture, 181 Outline Deployment Elements, identifying locations, 224 Outline Deployment Elements, identifying nodes, 226 as work product, 355

Index | 395 External influences, on architects application architecture, 315 application maintenance provider, 318 Architecture Assessment, 317 Architecture Decisions, 317 business architecture, 315 Business Entity Model, 316 Business Process Model, 316 Business Rules, 316 design authority, 316–317 enterprise architecture, 315–316 Enterprise Architecture Principles, 316, 317 Existing IT Environments, 316 information architecture, 315 infrastructure providers, 317–318 overview, 313–315 technology architecture, 315 External influences, overview, 113–115 External interactions, identifying. See Define System Context. F Features, proposing, 121–122 Framework. See Application framework. Functional, usability, reliability, performance, supportability (FURPS), 365 Functional elements, 6–7 Functional Model non-functional requirements, influence of, 183 Outline Deployment Elements, identifying nodes, 226 output of Create Logical Architecture, 182 as work product, 355 Functional Requirements. See also Non-Functional Requirements. definition, 130 description, 366 details. See Detail Functional Requirements. documenting, 131–132 identifying components, 208–212 input to Create Logical Architecture, 181 Outline Deployment Elements, identifying nodes, 226 outlining. See Outline Functional Requirements. output work product, 126–127 Prioritize Requirements, 161 from requirements to solutions, 182–183 roles related to, 46–47 system-wide, 131 use-case models, 132 as work product, 355 Functional view intersecting, 68–69 related work products, 84–85

Functional viewpoint description, 83, 342 purpose of, 63 Rozanski and Woods, 79 Zachman Framework, 78 Functioning enterprise perspective, 79 FURPS (functional, usability, reliability, performance, supportability), 365 G Geographical partitioning, 17 Geographically distributed teams, complex systems, 325 Glossary (architectural terms), 28, 335–337 Glossary (business domain) capturing, 4–5. See also Capture Common Vocabulary. consistency, 172 creating, 141–143 different words, same meaning, 143 homonyms, 143 input to Create Logical Architecture, 181 output, 126–127 Prioritize Requirements, 161 same words, different meaning, 143 synonyms, 143 as work product, 355 Granularity asset attribute, 103, 105 components, 215 Greenfield development, 111 Guidelines versus standards, 311–312. See also Standards. H Hardware. See also Create Physical Architecture. architecture, 18 system element, 19, 20 Horizontal scalability, 300 I IBM Rational, 184 Idioms (programming patterns), 97 IEEE 1471-2000, IEEE Recommended Practice for Architectural Description... architect, definition, 21 architecting, definition, 27 architecting, process metamodel, 28–29 architectural description, elements of, 64–65 architecture, definition, 9 documentation, key concepts, 64–65 environment, definition, 10 mission, definition, 10 stakeholder, definition, 10 systems, definition, 10

396 | Index IEEE 12207-1995, IEEE Standard for Information Technology, 18 Impact analysis, benefits of architecting, 40. See also Change management. Inception phase, 55–57, 362 Industry vertical models, 193 Information, system element, 19, 20 Information architecture, 18, 315. See also Documentation. Information viewpoint, 79 Infrastructure Architects description, 353 hardware responsibilities, 20 roles and responsibilities, 47, 113 Infrastructure architecture, 18, 47 Infrastructure providers, influence on architects, 317–318 Infrastructure viewpoint, 83, 345 Integration testing, 306 Interface responsibility diagrams, 240–242 Interfaces, Detail Functional Elements defining, 235–237 definition, 235–236 mapping to business types, 240–242 operation names, specifying, 237 provided interfaces, 235 required interfaces, 235 signature names, specifying, 237 Internationalization perspective, 81 Intersecting views. See Cross-cutting viewpoints; Views, intersecting. IT environment, surveying existing, 115 Iterative processes agile development, 59 characteristics of, 54 Construction phase, 55–57 declaring victory too soon, 55 definition, 44, 52–53 Elaboration phase, 55–57 Inception phase, 55–57 milestones, 54 OpenUP phases, 55–58 phases, 54 resource consumption, over time, 57 Sprints, 59 stability, over time, 56 Transition phase, 55–58 versus waterfall, 58 J Java EE asynchronous communication, 283 containers, 282 EJB interfaces, 282–283

EJBs (Enterprise JavaBeans), 282–283 entity beans, 283 Java servlets, 281 JAX-WS (Java API for XML Web Services), 282 JCA (Java EE Connector Architecture), 282 JDBC (Java DataBase Connectivity), 282 JMS (Java Message Service), 282 JPA (Java Persistence API), 282 JSPs (Java Server Pages), 282 markup language, 281 message-driven beans, 283 Outline Functional Elements, physical architecture, 281–283 overview, 281 session beans, 283 stateful session beans, 283 stateless session beans, 283 Java servlets, 281 JAX-WS (Java API for XML Web Services), 282 JCA (Java EE Connector Architecture), 282 JDBC (Java DataBase Connectivity), 282 JMS (Java Message Service), 282 JPA (Java Persistence API), 282 JSPs (Java Server Pages), 282 K Key business concepts, 117–118 Kruchten, Philippe, 76–77 L Layers, Define Architecture Overview, 198–199 Lead Architect description, 353 roles and responsibilities, 47, 113 Legacy applications, reusing, 101 Level of ceremony, 49 Levels of abstraction, modeling, 74 Levels of realization. See also Perspectives. definition, 73 versus levels of abstraction, 74 logical versus physical, 85–86 modeling, 73–74, 85–86 Zachman Framework, 78–79 Location perspective, 81 Locations, defining connections between, 250 Logical architecture, 3. See also Create Logical Architecture. Logical Data Model, 240 Logical deployment units, 248 Logical versus physical architecture, 179 elements, modeling, 74 levels of realization, 85–86 Logical view, 77

Index | 397 M Maintenance cost reduction, benefits of architecting, 39–40 Managing complexity. See Complex systems, architecting; Complexity, managing. Mapping components to deployment units, 297–299 Mapping logical elements to physical, 274–276, 289–290 Markup language, Java EE, 281 MDSD (Model-Driven Systems Development). See RUP SE (Rational Unified Process for Systems Engineering). Message-driven beans, 283 Method content. See also Roles; Work products. activities, 49–50 definition, 45 rightsizing, 108 tasks, 50, 51 Method processes. See also Agile processes; Iterative processes. definition, 45 types of, 50. See also specific types. waterfall, 51–52, 58 Methods. See also Disciplines. activities, 45 application architecture, 47 data architecture, 47 functional requirements, 46–47 infrastructure architecture, 47 iterations, 44 key concept relationships, 44 phases, 44 SPEM standard, 43–44 tasks, 45 who, what, how, and when, 44 Meyer, Bertrand, 242 Milestones, 54 Mission, definition, 10, 336 Mockups. See Modeling. Model, definition, 336 Model-Driven Systems Development (MDSD). See RUP SE (Rational Unified Process for Systems Engineering). Modeling. See also Architecture description framework; Documentation. abstraction levels, 74 analyzing change impact, 75 benefits of, 75 CIM (Computation Independent Model), 322 definition, 72 early error detection, 75 evaluating options, 75 levels of abstraction, 74 levels of realization, 73–74, 85–86. See also Perspectives; Zachman Framework.

logical versus physical elements, 74 multiple aspects of, 73–74 PIM (Platform-Independent Model), 322 in project planning, 75 PSM (Platform-Specific Model), 322 refining, 73–74 sharing across views, 72 source code, 323 with views and diagrams, 72–73 Motivation viewpoint, 79 N Negotiating skills, architects, 27 Network viewpoint, 78 Nodes assigning components to, 245–246, 247 connections between, defining, 246, 249 deployment units, 246, 248 links to components, 246 Non-Functional Requirements. See also Functional Requirements. definition, 130 details. See Detail Non-Functional Requirements. documenting, 131–132 identifying components, 212–217 input to Create Logical Architecture, 181 Outline Deployment Elements, identifying locations, 224–225 Outline Deployment Elements, identifying nodes, 226 outlining. See Outline Non-Functional Requirements. output work product, 126–127 physical architecture, 273 Prioritize Requirements, 161 from requirements to solutions, 182–183 as work product, 355 Non-negotiable requirements, 152 Notational styles, Define Architecture Overview, 195 O OCL (Object Constraint Language), 243 Online resources. See Web sites. OpenUP, 45–46, 55–58 Operation names, specifying, 237 Operational quality challenges, complex systems, 326–327 Operational viewpoint, 80 Operations signatures, physical architecture, 295 Organizational blueprints, 313 Organizational boundaries, complex systems, 324 Organizational politics, influence on architects, 26–27 Outcomes, definition, 48

398 | Index Outline Deployment Elements, logical architecture. See also Create Logical Architecture; Detail Deployment Elements. in the design process, 6 identifying locations, 224–225 identifying nodes, 226–227 purpose, 190 software engineering versus systems engineering, 223–224 task description, 222–223 Outline Deployment Elements, physical architecture hardware procurement, 292 many-to-one mapping, 290 mapping logical elements to physical, 289–290 one-to-many mapping, 289 one-to-one mapping, 289 physical elements, identifying, 290–292 Outline Functional Elements, component identification from Business Entity Model, 207–208 from Business Rules, 217–219 from Functional Requirements, 208–212 from Non-Functional Requirements, 212–217 overview, 206 from Prioritized Requirements List, 208–212 use cases, examples, 209, 211, 213 use cases, UML sequence diagram, 213 Outline Functional Elements, components allocating to subsystems, 211–212 characteristics of, 206 cohesion, 215 coupling, 215 definition, 204 granularity, 215 quality metrics, 215 requirement realizations, 214 size of function, 215 strength of associations, 215 traceability, 212, 214 Outline Functional Elements, logical architecture. See also Create Logical Architecture; Detail Functional Elements. naming, 204 purpose, 6–7, 190 subsystems, identifying, 205 task description, 204 Outline Functional Elements, physical architecture. See also Create Physical Architecture. buying versus building, 278–279 Java EE, 281–283 many-to-one mapping, 275–276 mapping logical elements to physical, 274–276 one-to-many mapping, 274–275 one-to-one mapping, 274, 275

physical elements, identifying, 277, 279 product procurement, 279–280 requirements realization, 286–287 software products, selecting, 280 technology independence, 276–277 technology-specific patterns, 280–289 Outline Functional Requirements. See also Detail Functional Requirements; Functional Requirements. change cases, 152 creating the outline, 153–155 Functional Requirements, descriptions, 153in the design process, 4–5 identifying Functional Requirements, 150–152 non-negotiable requirements, 152 pitfalls, 152 potential changes, 152 purpose of, 134–135 refactoring actors, 154–155 refactoring use cases, 154–155 task description, 149–150 use case model, 151 use cases, 150–152 Outline Non-Functional Requirements. See also Detail Non-Functional Requirements; Non-Functional Requirements. best practices, 157 creating the outline, 158–160 in the design process, 4–5 example, 159 identifying Non-Functional Requirements, 157–158 purpose of, 134–135 stating what is not required, 160 task description, 156 Outline tasks versus detail tasks, 191 P Packaged applications developing systems, 329 reusing, 101–102 Partial implementation assets, 104 Partitioning, 17 Pattern languages, 100 Patterns. See also Reusing assets. antipatterns, 97 architectural, 97 behavioral representation, 99 combining, 100 common contents, 98 defining software elements, 98 definition, 96 design, 97 programming (idioms), 97 reusing software elements. See Reusing assets.

Index | 399 structural representation, 99 transforming inputs to outputs, 100 UML modeling, 99–100 visual representation, 98–100 People viewpoint, 78 Performance perspective, 80 Performance requirements, 35, 367–368 Performance view, 68–69 Performance viewpoint, 83, 326, 346 Persisted data, data flow, 240 Perspectives. See also Levels of realization. accessibility, 81 availability, 80 business model, 79 definition, 68 detailed representation, 79 development resource, 81 evolution, 80 functioning enterprise, 79 internationalization, 81 location, 81 performance, 80 regulation, 81 resilience, 80 Rozanski and Woods, 79 scalability, 80 scope, 79 security, 80 system model, 79 technology model, 79 usability, 81 Zachman Framework, 78–79 Phases Construction, 363–364 definition, 54, 362 in the development process, 44 Elaboration, 363 Inception, 362 Transition, 363–364 Physical architecture, in the design process, 3. See also Create Physical Architecture. constraints, 370–371 distribution, 116 elements, identifying, 277, 279, 290–292 view, 77 PIM (Platform-Independent Model), 322 Pipes-and-filters architecture assets, 96 Pitfalls architects bog down in technical details, 306 architectural influence on team structure, 17 assuming requirements are equal, 144 combining architect and project manager, 309

configuration management ignores the architect, 310 declaring victory too soon, 55 misconceptions about the team, 23 overlooking actors or stakeholders, 144 requests are not measurable, 140 shopping-cart mentality, 139 talking to the wrong people, 140 technical questionnaires, 139–140 treating requests as requirements, 138–139 unequal treatment of hardware and software, 223 vague requests, 140 Planning process, benefits of architecting, 36–38 Policies of the business. See Business Rules. Postconditions definition, 166 Detail Functional Elements, 242–244 physical architecture, 295 use cases, 166, 169 Potential changes, 152 Practice, 2, 108 Preconditions definition, 166 Detail Functional Elements, 242–244 physical architecture, 295 use cases, 166, 169 Prerequisites, asset attribute, 105 Presentation components, 206 Primary roles, 47–48 Prioritize Requirements in the design process, 4–5 Functional Requirements, 161 Glossary, 161 Non-Functional Requirements, 161 pitfalls, 164 prioritization process, 161–164 Prioritized Requirements List, 162 purpose of, 134–135 RAID Logs, 161–162 results-driven versus document-driven, 160–161 Stakeholder Requests, 161 stakeholder requests, 141 task description, 160–161 unequal requirements, 164 use cases, 162–163 Vision document, 161 Prioritized Requirements List identifying components, 208–212 output of Define Requirements, 126–127 Prioritize Requirements, 162 as work product, 355 Problem statement, 118 Process description, documenting, 62–64

400 | Index Process elements, rightsizing, 108 Process view, 77 Product procurement, 279–280 Products, choosing for physical architecture, 263 Programming patterns (idioms), 97 Programming skills, architects, 25 Project emphasis, change over time, 31–32 Project management architect’s role, 307–308 description, 46 Project Managers combining with architects, 309 description, 353 roles and responsibilities, 47, 112 Project planning, modeling, 75 Project teams architectural influences on structure of, 17 case study, 112–113 definition, 22, 337 geographical distribution, 325 Project teams, responsibilities Application Architect, 113 Business Analyst, 112 Data Architect, 113 Developer, 113 Infrastructure Architect, 113 Lead Architect, 113 Project Manager, 112 Tester, 113 Proof-of-concept. See Build Architecture Proof-ofConcept. Prototypes. See Modeling. Provided interfaces, 235 PSM (Platform-Specific Model), 322 Q Qualities in Non-Functional Requirements, 130 overview, 122 Quality attributes, 131 metrics for components, 215 of software, 131 Questionnaires, collecting stakeholder requests, 139–140 R RAID Logs Document Architecture Decisions, 201 output from Create Logical Architecture, 181–182 output of Define Requirements, 126–127 Prioritize Requirements, 161–162 as work product, 355

RAS (Reusable Asset Specification), 106 RAS repository service, 106 Rational Unified Process (RUP), 184 Rational Unified Process for Systems Engineering (RUP SE), 19 Rationale, definition, 336 Recursion, complex systems, 328 Refactoring, 154–155. See also Refining. Reference architecture assets, 94 Reference model assets, 96 Refining. See also Refactoring. models, 73–74 requirements, 133 views. See Levels of realization. Regulation perspective, 81 Related assets, asset attribute, 105 Reliability requirements, 367 Requests versus requirements, 136, 138–139 Required interfaces, 235 Requirements. See also Functional Requirements. architect’s role, 304 defining. See Define Requirements. discipline, 46 FURPS (functional, usability, reliability, performance, supportability), 365 managing, 132–133 performance, 367–368 realizations, 214, 286–287 reliability, 367 versus requests, 136 supportability, 368 transforming to solutions, 182–185 types of, 365 usability, 366–367 view, 68–69, 84–85 viewpoint, 67–68, 83, 341–342 Requirements, constraints architecture, 369–370 business, 369 definition, 368 development, 370 physical, 370–371 Resilience perspective, 80 Resources. See Assets. Response, in scenarios, 173 Response measure, in scenarios, 173 Results-driven versus document-driven architecture, 160–161 Reusable Asset Specification (RAS), 106 Reusing assets. See also Existing IT Environments; Survey Architecture Assets. during architecting, 34 benefits of architecting, 39

Index | 401 case study, 116 physical architecture, 265, 269–270 RAS (Reusable Asset Specification), 106 RAS repository service, 106 sources for, 89–90 Reusing assets, a metamodel development-time assets, 92, 93 diagram, 91 run-time assets, 92–93 Reusing assets, asset attributes articulation, 103, 104 asset name, 105 asset type, 105 author, 104 brownfield development, 105 business domain, 105 complete implementation, 104 concerns addressed, 104 contained artifacts, 104 context-sensitive, 105 current state, 105 development discipline, 105 development method, 105 development phase, 105 development scope, 105 granularity, 103, 105 partial implementation, 104 prerequisites, 105 related assets, 105 specification, 103 technical domain, 105 use instructions, 105 variability, 105 version number, 105 Reusing assets, asset types. See also Patterns. application framework, 102–103 architectural mechanisms, 96 architectural styles, 95–96 architecture decisions, 100–101 client-server architecture, 95 component libraries, 103 components, 103 COTS (commercial-off-the-shelf) products, 101–102 development method, 94–95 event-based architecture, 95–96 existing applications, 101 legacy applications, 101 packaged applications, 101–102 pipes-and-filters architecture, 96 reference architecture, 94 reference models, 96 SaaS (Software as a Service), 102 viewpoint catalogs, 95

Review Architecture with Stakeholders, logical architecture. See also Create Logical Architecture. assembling work products, 259 baseline work products, 259 purpose, 190 reviewing, 260 SARA (Software Architecture Review and Assessment) Report, 259 task description, 258–259 Review Architecture with Stakeholders, physical architecture, 301–302. See also Create Physical Architecture. Review Records, 126–127, 182, 356 Review Requirements with Stakeholders assembling work products, 176 baseline work products, 175–176 in the design process, 5 purpose of, 134–135 reviewing work products, 176 task description, 175 Rightsizing Create Logical Architecture, 185–186 examples, 109 method content, 108 process elements, 108 Risk management, 38, 255–256 Roles Application Architect, 47, 352 architects. See Architects, roles. assigning individuals to, 47 Business Analyst, 46–47, 352 Data Architect, 47, 353 definition, 46–47 Developer, 353 versus individuals, 22, 47 Infrastructure Architect, 47, 353 Lead Architect, 47, 353 primary, 47–48 Project Manager, 47, 353 responsibilities of, 46–47 secondary, 47–48 Tester, 354 Rozanski, Nick, 68, 79–81 Run-time assets, 92–93 Run-time qualities, 116 RUP (Rational Unified Process), 184 RUP SE (Rational Unified Process for Systems Engineering), 19 S S4V (Siemen’s 4 Views) method, 184 SaaS (Software as a Service), 102

402 | Index SARA (Software Architecture Review and Assessment) Report, 259 Scalability, 300 Scalability perspective, 80 Scenario-based architecture validation, 253–254 Scenarios. See also Use cases. artifact stimulated, 173 Detail Functional Requirements, 170–171 environment, 173 parts of, 172–173 response, 173 response measure, 173 source of the stimulus, 173 stimulus, 173 Scenarios view, 77 Scheduling, benefits of architecting, 37 Science versus art of architecting, 30 Scope of architectural activities, 18–21 Scope perspective, 79 Scrum, definition, 59 Secondary roles, 47–48 Security perspective, 80 Security requirements, benefits of architecting, 35 Security view, 69–70 Security viewpoint, 84, 327, 346–347 Selic, Bran, 31–32 Separation, Trace, Externalize, Position (STEP) principles, 219 Service-oriented architecture (SOA), 328 Session beans, 283 Sharing models across views, 72 Shopping-cart mentality, 139 Siemen’s 4 Views (S4V) method, 184 Signature names, specifying, 237 SMART (specific, measurable, achievable, realistic, time-based), criteria, 172 SOA (service-oriented architecture), 328 Software architecting. See Architecting. architects. See Architects. architecture. See Architecture. development knowledge, architects, 23 development methods. See Methods. packaging for deployment, 299 product lines, complex systems, 329 products, physical architecture, 263, 280 requirements, defining. See Define Requirements. system element, 19, 20 Software and Systems Project Engineering Metamodel Specification (SPEM), 43–44, 48–49 Software Architecture Document. See also Documentation. creating, 63–64 outline for, 87–88

output of Create Logical Architecture, 182 output of Define Requirements, 126–127 purpose of, 87 updating, 5–7 as work product, 356 Software Architecture Review and Assessment (SARA) Report, 259 Software as a Service (SaaS), 102 Software engineering versus systems engineering, 223–224 Source code, as model, 323 Source of the stimulus, in scenarios, 173 Special requirements for use cases, 165, 168–169 Specific, measurable, achievable, realistic, time-based (SMART), criteria, 172 Specification assets, 103 SPEM (Software and Systems Project Engineering Metamodel Specification), 43–44, 48–49 Sprint Backlog, 59 Sprints, 59. See also Iterative processes. Stability, over time, 56 Stakeholder Requests collecting. See Collect Stakeholder Requests. identifying Non-Functional Requirements, 157 output of Define Requirements, 126, 128 Prioritize Requirements, 161 as work product, 356 Stakeholders accommodating diversity, 32–33 building consensus, 36 case study, summary of, 119–120 collecting requests from, 4–5 communication through viewpoints, 72 definition, 10, 119, 336 identifying, 63, 136–137 needs, addressing, 118 needs, balancing, 14–15 requests, collecting. See Collect Stakeholder Requests. reviewing architecture with. See Review Architecture with Stakeholders. reviewing requirements with. See Review Requirements with Stakeholders. signoff on physical architecture, 301 types of, summary, 340–341 view of the new system. See Vision. viewpoints, summary of, 81–82 Standards. See also IEEE. architecting complex systems, 321–323 CIM (Computation Independent Model), 322 for complex systems, 321–323 enforcing consistency, 323 establishing, 321–323 MDA (Model Driven Architecture), 321–323

Index | 403 models, 322–323 OMG (Object Management Group), 321–323 PIM (Platform-Independent Model), 322 PSM (Platform-Specific Model), 322 SPEM (Software and Systems Project Engineering Metamodel Specification), 43–44, 48–49 transformations, 323 Standards versus guidelines, 311–312 Stateful session beans, 283 Stateless session beans, 283 Status meetings, agile processes. See Scrum. Stevens, W. P., 215 Stimulus, in scenarios, 173 Strategic design, 4 Strategic reuse, complex systems, 328–329 Stroustrup, Bjarne, 1 Subordinate systems, complex systems, 328 Subsystems, 197, 211–212 Superordinate systems, complex systems, 328 Supportability requirements, 368 Survey Architecture Assets, logical architecture. See also Create Logical Architecture; Reusing assets. Enterprise Architecture Principles, 193–194 industry vertical models, 193 purpose of, 6, 188 reusing assets, 192–194 surveying the assets, 192–194 task description, 192 Survey Architecture Assets, physical architecture, 269–270. See also Create Physical Architecture; Reusing assets. System Context input to Create Logical Architecture, 181 Outline Deployment Elements, identifying locations, 225 output from Define Requirements, 126, 128 as work product, 356 System model perspective, 79 System qualities, benefits of architecting, 34–35 System testing, 306 Systems architecture. See Architecture. complex. See Complex systems, architecting. constraints. See Constraints. decomposing into subsystems, 328–329 distribution, complex systems, 324 elements, identifying and describing. See Create Logical Architecture; Create Physical Architecture; Functional Requirements; Non-Functional Requirements. elements of, 19–20 physical architecture, identifying and describing elements, 270–273 software intensive, 20

subordinate, 328 subsystems, 197, 211–212 superordinate, 328 of systems, 327–330 Systems, definitions IEEE 1471-2000, IEEE Recommended Practice for Architectural Description..., 10, 336 IEEE 12207-1995, IEEE Standard for Information Technology, 18 RUP SE (Rational Unified Process for Systems Engineering), 19 systems of systems, 330 Systems engineering architecting complex systems, 328 versus software engineering, 223–224 Systems management viewpoint, 83, 345 System-wide Functional Requirements, 131, 170 T Tactical design, 4 Tactics, Create Logical Architecture, 185 Talking to the wrong people, 140 Target Operating Model (TOM), 313 Tasks. See also specific tasks. definition, 50, 51, 356, 358 in the development process, 44–45 Teams. See Project teams. Technical details, avoiding, 306 Technical domain, asset attribute, 105 Technical leadership, architects, 21–22 Technological knowledge, architects, 24 Technological platform, choosing, 263 Technology architecture, influence on architects, 315 Technology independence, 276–277 Technology model perspective, 79 Technology-specific patterns, 280–289 Templates for views, 66–67 Terminology. See Capture Common Vocabulary; Glossary. Test discipline, 46 Testers, 113, 354 Testing acceptance, 306 architect’s role, 306–307 integration, 306 system, 306 Tiers, 198–199 Time viewpoint, 79 TOM (Target Operating Model), 313 Top-down architecting, 34–35 Traceability components, 212, 214 Create Logical Architecture, 186–187 Trade-offs during architecting, 33–34

404 | Index Transient data, data flow, 239 Transition phase, 55–58, 363–364 U UML (unified modeling language), examples component, definition, 10 component diagram, 12 sequence diagram, 13 UML (unified modeling language), modeling patterns, 99–100 Update Software Architecture Document. See also Document Architecture Decisions; Documentation; Software Architecture Document. aligning document sections with work products, 257 Create Logical Architecture, 6–7 Create Physical Architecture, 301 Define Requirements, 5, 134–135, 174 purpose, 190 purpose of, 134–135 task description, 174, 256 updating the document, 174, 257–258 Usability perspective, 81 Usability requirements, 366–367 Usability viewpoint, complex systems, 326 Use case models, 151 Use cases. See also Scenarios. actors, 165 context, 166 data flows, 170 detailed data items, 170 identifying Functional Requirements, 150–152 input from Define System Context, 170 postconditions, 166, 169 preconditions, 166, 169 Prioritize Requirements, 162–163 refactoring, 155 special requirements, 165, 168–169 Use cases, event flows alternative, 165, 168 main, 165, 168 required information, 167–168 Use instructions, asset attribute, 105 Users’ needs, addressing, 118 V Validate Architecture, logical architecture. See also Create Logical Architecture; Verify Architecture. ATAM (Architecture Tradeoff Analysis Method), 253–254 considerations, 252 documenting findings, 255 planning for validation, 254 purpose, 6–7, 190 reviewing architecture, 254–255 risk assessment and recommendations, 255–256

scenario-based validation, 253–254 task description, 251–252 Validate Architecture, physical architecture, 267–268, 300–301. See also Create Physical Architecture. Validation view intersecting, 69–70 related work products, 85 Validation viewpoint, 67–68, 83, 343–344 Variability, asset attribute, 105 Verify Architecture, logical architecture. See also Create Logical Architecture; Validate Architecture. follow-up, 232 individual verifications, 231 kickoff meeting, 231 plan verification, 230 purpose, 6, 190 rework, 231 task description, 228–230 verification meeting, 231 verification versus validation, 229 Verify Architecture, physical architecture, 267–268, 292–293. See also Create Physical Architecture; Validate Architecture. Version number, asset attribute, 105 Vertical scalability, 300 Viewpoint application, 83 Viewpoint catalogs application viewpoint, 344 architecture description framework, 340 availability viewpoint, 345–346 basic viewpoints, 341–344 cross-cutting viewpoints, 344–347 definition, 67, 95 deployment viewpoint, 343 functional viewpoint, 342 infrastructure viewpoint, 345 performance viewpoint, 346 requirements viewpoint, 341–342 reusing assets, 95 security viewpoint, 346–347 selecting viewpoints, 76 stakeholder summary, 340–341 systems management viewpoint, 345 validation viewpoint, 343–344 view correspondence, 347–349 Viewpoints. See also Architecture description framework; Documentation; Views. architectural perspectives, 68 audience identification, 66 availability, 326–327 basic types, 67–68 benefits of, 71–72 characteristics, 66–67 in complex systems, 326–327

Index | 405 cross-cutting, 68–70, 79–81 definition, 66, 337 deployment, 62, 63, 67 focusing on system subsets, 71–72 functional, 62, 63, 67 intersecting. See Cross-cutting viewpoints. managing complexity, 71–72 multipurpose, 66 performance, 326 requirements, 67–68 security, 327 selecting, 63, 67, 110 selecting, best practices, 110 stakeholder communications, 72 a templates for views, 66–67 usability, 326 validation, 67–68 and work products, 357 Views. See also Abstraction; Architecture description framework; Documentation; Viewpoints. benefits of, 71–72 correspondence, 87, 347–349 creating from viewpoints, 66–67 definition, 66, 337 deployment, 85 as diagrams, 70–71 focusing on system subsets, 71–72 functional, 84–85 managing complexity, 71–72 with models and diagrams, 72–73 overloading, 266 refining. See Levels of realization. related work products, 84–85 requirements, 84–85 stakeholder communications, 72 Views, intersectingvalidation, 85 deployment, 68–70 functional, 68–69 performance, 68–69 requirements, 68–69 security, 69–70 validation, 69–70 Vision business behavior expected. See Business Process Model. business policies, adhering to. See Business Rules. Business Rules, 122–123 constraints, 122–123 Define Requirements, 126–127 features proposed, 121–122 functionality, determining, 120–122 identifying Non-Functional Requirements, 157 problem statement, 118 qualities, 122

stakeholder needs, addressing, 118–120 user needs, addressing, 118 as work product, 356 Vision document, 161 Vocabulary. See Glossary. W Waterfall process, 51–52, 58 Web sites, companion to this book, xxi Woods, Eoin, 68 Work products. See also specific work products. artifacts, 48 case study, input, 114 creating, 63 definition, 48 deliverables, 48 level of ceremony, 49 outcomes, 48 ownership, 49 related viewpoints, 84–85, 357 types of, 48 Work products, descriptions of Architecture Assessment, 354 Architecture Decisions, 354 Architecture Overview, 354 Architecture Proof-Of-Concept, 354 Business Entity Model, 355 Business Process Model, 355 Business Rules, 355 Change Requests, 355 Data Models, 355 Deployment Model, 355 Enterprise Architecture Principles, 355 Existing IT Environments, 355 Functional Model, 355 Functional Requirements, 355 Glossary, 355 Non-Functional Requirements, 355 Prioritized Requirements List, 355 RAID Logs, 355 Review Record, 356 Software Architecture Document, 356 Stakeholder Requests, 356 System Context, 356 Vision, 356 Workers, system element, 19, 20 Y YourTour. See Case study. Z Zachman, John, 77–79 Zachman Framework, 77–79. See also Levels of realization.

FREE Online Edition

Your purchase of The Process of Software Architecting includes access to a free online edition for 45 days through the Safari Books Online subscription service. Nearly every Addison-Wesley Professional book is available online through Safari Books Online, along with more than 5,000 other technical books and videos from publishers such as Cisco Press, Exam Cram, IBM Press, O’Reilly, Prentice Hall, Que, and Sams.

SAFARI BOOKS ONLINE allows you to search for a specific answer, cut and paste code, download chapters, and stay current with emerging technologies.

Activate your FREE Online Edition at www.informit.com/safarifree STEP 1: Enter the coupon code: JHVIZAA. STEP 2: New Safari users, complete the brief registration form. Safari subscribers, just log in.

If you have difficulty registering on Safari or accessing the online edition, please e-mail [email protected]