Lean architecture: for agile software development

378 Pages·2011·2.379 MB·English

by  Coplien, James O.;Bjørnvig, Gertrud

Lean Architecture for
Agile Software
Development
James Coplien
Gertrud Bjørnvig
A John Wiley and Sons, Ltd, Publication
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.
Reprinted with corrections December 2010
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
Dedication
To Trygve Mikkjel Heyerdahl Reenskaug, also a grandfather
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
Contents
AbouttheAuthors xii
Preface xiii
1 Introduction 1
1.1 TheTouchstones:LeanandAgile 1
1.2 LeanArchitectureandAgileFeatureDevelopment 4
1.3 AgileProduction 7
1.3.1 AgileBuildsonLean 7
1.3.2 TheScopeofAgileSystems 8
1.3.3 AgileandDCI 9
1.4 TheBookinaVerySmallNutshell 10
1.5 LeanandAgile:ContrastingandComplementary 11
1.5.1 TheLeanSecret 14
1.6 LostPractices 14
1.6.1 Architecture 15
1.6.2 HandlingDependenciesbetweenRequirements 15
1.6.3 FoundationsforUsability 16
1.6.4 Documentation 16
CodeDoesNotStandAlone 17
Capturingthe‘‘Why’’ 19
1.6.5 CommonSense,Thinking,andCaring 19
1.7 WhatthisBookisNotAbout 21
1.8 Agile,Lean–Oh,Yeah,andScrumandMethodologiesandSuch 22
1.9 HistoryandSuch 24
2 AgileProductioninaNutshell 27
2.1 EngagetheStakeholders 27
2.2 DefinetheProblem 29
2.3 FocusingonWhattheSystemIs:TheFoundationsofForm 30
2.4 FocusingonWhattheSystemDoes:TheSystemLifeblood 32
2.5 DesignandCode 33
2.6 Countdown:3,2,1... 34
v
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
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
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