Lean Architecture for Agile Software Development James Coplien Gertrud Bjørnvig A John Wiley and Sons, Ltd, Publicatio n www.it-ebooks.info www.it-ebooks.info Lean Architecture for Agile Software Development James Coplien Gertrud Bjørnvig A John Wiley and Sons, Ltd, Publicatio n www.it-ebooks.info This edition first published 2010  2010 James Coplien and Gertrud Bjørnvig Registered office John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom For details of our global editorial offices, for customer services and for information about how to apply for permission to reuse the copyright material in this book please see our website at www.wiley.com. The right of the author to be identified as the author of this work has been asserted in accordance with the Copyright, Designs and Patents Act 1988. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by the UK Copyright, Designs and Patents Act 1988, without the prior permission of the publisher. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners. The publisher is not associated with any product or vendor mentioned in this book. This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold on the understanding that the publisher is not engaged in rendering professional services. If professional advice or other expert assistance is required, the services of a competent professional should be sought. Quotes from The Clock of the Long Now: Time and Responsibility – The Ideas Behind the World’s Slowest Computer are Copyright  2000 Stewart Brand. Reprinted by permission of Basic Books, a member of the Perseus Books Group. A catalogue record for this book is available from the British Library. ISBN 978-0-470-68420-7 Typeset in 11/13 Palatino by Laserwords Private Limited, Chennai, India. Printed in Great Britain by TJ International, Padstow, Cornwall www.it-ebooks.info Dedication To Trygve Mikkjel Heyerdahl Reenskaug, also a grandfather www.it-ebooks.info Publisher’s Acknowledgments Some of the people who helped bring this book to market include the following: Editorial and Production VP Consumer and Technology Publishing Director: Michelle Leete Associate Director – Book Content Management: Martin Tribe Associate Publisher: Chris Webb Executive Commissioning Editor: Birgit Gruber Assistant Editor: Colleen Goldring Publishing Assistant: Ellie Scott Project Editor: Juliet Booker Content Editor: Nicole Burnett Copy Editor: Richard Walshe Marketing: Senior Marketing Manager: Louise Breinholt Marketing Executive: Kate Batchelor Composition Services: Compositor: Laserwords Private Limited, Chennai, India Proof Reader: Alex Grey Indexer: Annette Musker www.it-ebooks.info Contents About the Authors xii Preface xiii 1 Introduction 1 1.1 The Touchstones: Lean and Agile 1 1.2 Lean Architecture and Agile Feature Development 4 1.3 Agile Production 7 1.3.1 Agile Builds on Lean 7 1.3.2 The Scope of Agile Systems 8 1.3.3 Agile and DCI 9 1.4 The Book in a Very Small Nutshell 10 1.5 Lean and Agile: Contrasting and Complementary 11 1.5.1 The Lean Secret 14 1.6 Lost Practices 14 1.6.1 Architecture 15 1.6.2 Handling Dependencies between Requirements 15 1.6.3 Foundations for Usability 16 1.6.4 Documentation 16 Code Does Not Stand Alone 17 Capturing the ‘‘Why’’ 19 1.6.5 Common Sense, Thinking, and Caring 19 1.7 What this Book is Not About 21 1.8 Agile, Lean – Oh, Yeah, and Scrum and Methodologies and Such 22 1.9 History and Such 24 2 Agile Production in a Nutshell 27 2.1 Engage the Stakeholders 27 2.2 Define the Problem 29 2.3 Focusing on What the System Is:TheFoundationsofForm 30 2.4 Focusing on What the System Does: The System Lifeblood 32 2.5 Design and Code 33 2.6 Countdown:3,2,1 34 v www.it-ebooks.info vi Contents 3 Stakeholder Engagement 35 3.1 The Value Stream 35 3.1.1 End Users and Other Stakeholders as Value Stream Anchors 36 3.1.2 Architecture in the Value Stream 37 3.1.3 The Lean Secret 38 3.2 The Key Stakeholders 41 3.2.1 End Users 43 Psyching Out the End Users 44 Don’t Forget Behavior 46 The End User Landscape 47 3.2.2 The Business 47 A Special Note for Managers 48 3.2.3 Customers 50 As Contrasted with End Users 50 ‘‘Customers’’ in the Value Stream 52 3.2.4 Domain Experts 52 No Ivory Tower Architects 53 Experts in Both Problem and Solution Domains 54 3.2.5 Developers and Testers 55 3.3 Process Elements of Stakeholder Engagement 57 3.3.1 Getting Started 58 3.3.2 Customer Engagement 60 3.4 The Network of Stakeholders: Trimming Wasted Time 61 3.4.1 Stovepipe Versus Swarm 61 3.4.2 The First Thing You Build 64 3.4.3 Keep the Team Together 65 3.5 No Quick Fixes, but Some Hope 66 4 Problem Definition 67 4.1 What’s Agile about Problem Definitions? 68 4.2 What’s Lean about Problem Definitions? 68 4.3 Good and Bad Problem Definitions 70 4.4 Problems and Solutions 72 4.5 The Process Around Problem Definitions 73 4.5.1 Value the Hunt Over the Prize 73 4.5.2 Problem Ownership 74 4.5.3 Creeping Featurism 75 4.6 Problem Definitions, Goals, Charters, Visions, and Objectives 76 4.7 Documentation? 77 5 What the System Is, Part 1: Lean Architecture 79 5.1 Some Surprises about Architecture 80 5.1.1 What’s Lean about This? 82 Deliberation and ‘‘Pull’’ 83 Failure-Proof Constraints or Poka-Yoke 83 The Lean Mantras of Conservation, Consistency, and Focus 84 5.1.2 What’s Agile about Architecture? 84 It’s All About Individuals and Interactions 84 www.it-ebooks.info Contents vii Past Excesses 85 Dispelling a Couple of Agile Myths 86 5.2 The First Design Step: Partitioning 88 5.2.1 The First Partition: Domain Form Versus Behavioral Form 89 5.2.2 The Second Partitioning: Conway’s Law 90 5.2.3 The Real Complexity of Partitioning 93 5.2.4 Dimensions of Complexity 94 5.2.5 Domains: A Particularly Interesting Partitioning 94 5.2.6 Back to Dimensions of Complexity 96 5.2.7 Architecture and Culture 100 5.2.8 Wrap-Up on Conway’s Law 100 5.3 The Second Design Step: Selecting a Design Style 100 5.3.1 Contrasting Structuring with Partitioning 102 5.3.2 The Fundamentals of Style: Commonality and Variation 104 5.3.3 Starting with Tacit Commonality and Variation 105 5.3.4 Commonality, Variation, and Scope 108 5.3.5 Making Commonalities and Variations Explicit 111 Commonality Categories 112 Next Steps 114 5.3.6 The Most Common Style: Object Orientation 114 Just What is Object Orientation? 115 5.3.7 Other Styles within the Von Neumann World 117 5.3.8 Domain-Specific Languages and Application Generators 120 The State of the Art in DSLs 121 DSLs’ Place in Architecture 121 5.3.9 Codified Forms: Pattern Languages 122 5.3.10 Third-Party Software and Other Paradigms 124 5.4 Documentation? 127 5.4.1 The Domain Dictionary 128 5.4.2 Architecture Carryover 128 5.5 History and Such 129 6 What the System Is, Part 2: Coding It Up 131 6.1 The Third Step: The Rough Framing of the Code 131 6.1.1 Abstract Base Classes 133 6.1.2 Pre-Conditions, Post-Conditions, and Assertions 137 Static Cling 142 6.1.3 Algorithmic Scaling: The Other Side of Static Assertions 144 6.1.4 Form Versus Accessible Services 146 6.1.5 Scaffolding 147 6.1.6 Testing the Architecture 149 Usability Testing 149 Architecture Testing 149 6.2 Relationships in Architecture 153 6.2.1 Kinds of Relationship 153 6.2.2 Testing the Relationships 155 6.3 Not Your Old Professor’s OO 155 6.4 How much Architecture? 159 www.it-ebooks.info viii Contents 6.4.1 Balancing BUFD and YAGNI 159 6.4.2 One Size Does Not Fit All 160 6.4.3 When Are You Done? 160 6.5 Documentation? 162 6.6 History and Such 163 7 What the System Does: System Functionality 165 7.1 What the System Does 166 7.1.1 User Stories: A Beginning 166 7.1.2 Enabling Specifications and Use Cases 167 7.1.3 Helping Developers, Too 169 7.1.4 Your Mileage may Vary 170 7.2 Who is Going to Use Our Software? 171 7.2.1 User Profiles 171 7.2.2 Personas 171 7.2.3 User Profiles or Personas? 172 7.2.4 User Roles and Terminology 173 7.3 What do the Users Want to Use Our Software for? 173 7.3.1 Feature Lists 173 7.3.2 Dataflow Diagrams 174 7.3.3 Personas and Scenarios 174 7.3.4 Narratives 174 7.3.5 Behavior-Driven Development 175 7.3.6 Now that We’re Warmed Up 175 Prototypes 176 Towards Foundations for Decisions 176 Known and Unknown Unknowns 176 Use Cases as a Decision Framework 177 7.4 Why Does the User Want to Use Our Software? 177 7.5 Consolidation of What the System Does 178 7.5.1 The Helicopter View 181 Habits: The Developer View and the User View 182 Trimming the Scope 185 7.5.2 Setting the Stage 186 7.5.3 Play the Sunny Day Scenario 187 Business Rules 191 7.5.4 Add the Interesting Stuff 193 7.5.5 Use Cases to Roles 200 Roles from the Use Case 201 Bridging the Gap between the Business and the Programmer 202 7.6 Recap 203 7.6.1 Support the User’s Workflow 203 7.6.2 Support Testing Close to Development 203 7.6.3 Support Efficient Decision-Making about Functionality 204 7.6.4 Support Emerging Requirements 204 7.6.5 Support Release Planning 204 7.6.6 Support Sufficient Input to the Architecture 205 7.6.7 Support the Team’s Understanding of What to Develop 205 www.it-ebooks.info [...]... interactions second Neither Lean nor Agile alone make architecture look easy However, architecture needn’t be intrinsically hard Lean and Agile together illuminate architecture s value Lean brings careful up-front planning and ‘‘everybody, all together, from early on’’ to the table, and Agile teaches or reminds us about feedback Together they illuminate architecture s value: Lean, for how architecture can reduce... solid software architecture www.it-ebooks.info 3 4 Chapter 1 Another key Lean principle is to focus on long-term results (Liker 2004, pp 71–84) Lean architecture is about doing what’s important now that will keep you in the game for the long term It is nonetheless important to contrast the Lean approach with traditional approaches such as ‘‘investing for the future.’’ Traditional software architecture. .. items on the left more (Beck et al 2001) 1.3.1 Agile Builds on Lean Just as with the ‘‘all hands on deck’’ approach of Lean, Agile development also embraces close person-to-person contact, particularly with the clients Unlike the tendencies of Lean, or much of today’s software architecture, our vision of Agile production plans for change Lean architecture provides a context, a vocabulary, and productive... entails a bit of both, but regarding architecture only as an emergent view of the system substantially slows the decision process Software isn’t soft, and architectures aren’t very malleable once developers start filling in the general form with the structure of running code Lean architecture moves beyond structure to form Good form is Lean, and that helps the system be Agile Lean is about complicated things;... about a Lean approach to domain architecture that lays a foundation for Agile software change The planning values of Lean do not conflict with the inspect-and-adapt principles of Agile: allocated to the proper development activities, each supports the other in the broader framework of development We’ll revisit that contrast in a little while (Section 1.4), but first, let’s investigate each of Lean Architecture. .. Agile Production in more detail 1.2 Lean Architecture and Agile Feature Development The Agile Manifesto (Beck et al 2001) defines the principles that underlie the Agile vision, and the Toyota Way (Liker 2004) defines the Lean www.it-ebooks.info Introduction vision This book offers a vision of architecture in an organization that embraces these two sets of ideals The Lean perspective focuses on how we... differ from the classic, heavyweight architectural practices that dominated object-oriented development in the 1980s? We summarize the differences in Table 1-1 Table 1-1 What is Lean Architecture? Lean Architecture Classic Software Architecture Defers engineering Includes engineering Gives the craftsman ‘‘wiggle room’’ for change Tries to limit large changes as ‘‘dangerous’’ (fear change?) Defers implementation... and function rather than an architecture based on structure Classic software architecture sometimes rushes into implementation to force code reuse to happen or standards to prevail Lean architecture also adopts the perspective that standards are valuable, but again: at the level of form, protocols, and APIs, rather than their implementation Some classic approaches to software architecture too often depend... et al 1991) coined the term Lean for the management culture popularized by the Japanese auto industry, and which can be traced back to Toyota where it is called The Toyota Way In vernacular English, minimal is an obvious synonym for Lean, but to link lean to minimalism alone is misleading 1 www.it-ebooks.info 2 Chapter 1 Lean s primary focus is the enterprise value stream Lean grabs the consumer world... that most people hold to be fundamental to Agile The Lean notion of value streams starting with end users recalls individual and interactions as well as customer focus The Lean notion of reduced waste goes hand-in-hand with Agile’s view of documentation It is not about Lean versus Agile and neither about building Lean on top of Agile nor Agile on top of Lean Each one is a valuable perspective into the . Is, Part 1: Lean Architecture 79 5.1 Some Surprises about Architecture 80 5.1.1 What’s Lean about This? 82 Deliberation and ‘‘Pull’’ 83 Failure-Proof Constraints or Poka-Yoke 83 The Lean Mantras. xiii 1 Introduction 1 1.1 The Touchstones: Lean and Agile 1 1.2 Lean Architecture and Agile Feature Development 4 1.3 Agile Production 7 1.3.1 Agile Builds on Lean 7 1.3.2 The Scope of Agile Systems. Lean Architecture for Agile Software Development James Coplien Gertrud Bjørnvig A John Wiley and Sons, Ltd, Publicatio n www.it-ebooks.info www.it-ebooks.info Lean Architecture