Design It!: From Programmer to Software Architect

324 Pages·2016·6.19 MB·English

by  Michael Keeling

This book covers the essentials of design and software architecture that all devel­
opment teams need to know. It is definitely going on the recommended reading
list for all my teams and anyone we bring on board!
► J0rn 01mheim
Leading Advisor Software Architecture, Statoil ASA
What sets Design It! apart for me is its fresh perspective—that the technical un­
dertaking of building software is an intensely social activity. Michael manages to
uniquely fuse the mechanics of software architecture together with the chemistry
of design thinking. You’ll learn to move from architecture viewpoints into design
mindsets and from managing architecture life cycles into telling architecture sto­
ries. This is a must-have reference book on modem software architecting.
> Amine Chigani
Chief Architect, GE Digital
This book is timely, valuable, accessible, and excellent. It is a clear, informed,
and practical guide to the principles and practice of software architecture, for the
aspiring architect as well as the established practitioner who wants to deepen
and refresh his or her skills. Michael Keeling takes the reader on a clear and re-
sults-oriented journey, from the fundamentals of the field to the state of the art.
► Eoin Woods
CTO of Endava, editor of IEEE Software's Pragmatic Architect column, and
author of Software Systems Architecture
Invaluable for growing your career and your team! The perfect balance between
design theory and practical activities.
> Joseph Kramer
Software Engineering Manager, IBM
Design It!
From Programmer to Software Architect
Michael Keeling
The Pragmatic Bookshelf
Raleigh, North Carolina
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 Pragmatic
Programmers, LLC was aware of a trademark claim, the designations have been printed in
initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer,
Pragmatic Programming, Pragmatic Bookshelf, PragProg and the linking g device are trade­
marks of The Pragmatic Programmers, LLC.
Every precaution was taken in the preparation of this book. However, the publisher assumes
no responsibility for errors or omissions, or for damages that may result from the use of
information (including program listings) contained herein.
Our Pragmatic books, screencasts, and audio books can help you and your team create
better software and have more fun. Visit us at https://pragprog.com.
The team that produced this book includes:
Publisher: Andy Hunt
VP of Operations: Janet Furlow
Development Editor: Susannah Davidson Pfalzer
Indexing: Potomac Indexing, LLC
Copy Editor: Liz Welch
Layout: Gilson Graphics
For sales, volume licensing, and support, please contact [email protected].
For international rights, please contact [email protected].
Copyright © 2017 The Pragmatic Programmers, LLC.
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,
without the prior consent of the publisher.
Printed in the United States of America.
ISBN-13:978-1-68050-209-1
Printed on acid-free paper.
Book version: PI .0—October 2017
Contents
Acknowledgments...............................................................................................xi
Foreword...........................................................................................................xiii
Welcome!...............................................................................................................
Part I — Introducing Software Architecture
1. Become a Software Architect..............................................................................3
What Software Architects Do 3
What Is Software Architecture? 7
Become an Architect for Your Team 11
Build Amazing Software 12
Case Study: Project Lionheart 14
Next Up 14
2. Design Thinking Fundamentals.........................................................................15
The Four Principles of Design Thinking 15
Adopt a Design Mindset 18
Think, Do, Check 21
Next Up 24
Part II — Architecture Design Fundamentals
3. Devise a Design Strategy...................................................................................27
Find a Design That Satisfices 27
Decide How Much to Design Up Front 29
Let Risk Be Your Guide 32
Create a Design Plan 36
Project Lionheart: The Story So Far... 38
Next Up 38
Contents • vi
39
4. Empathize with Stakeholders.................................................
39
Talk to the Right People
41
Create a Stakeholder Map
43
Discover the Business Goals
46
Project Lionheart: The Stoiy So Far...
47
Next Up
49
5. Dig for Architecturally Significant Requirements .
49
Limit Design Options with Constraints
51
Define the Quality Attributes
56
Look for Classes of Functional Requirements
58
Find Out What Else Influences the Architecture
59
Dig for the Information You Need
60
Build an ASR Workbook
62
Project Lionheart: The Story So Far...
62
Next Up
63
6. Choose an Architecture (Before It Chooses You) .
63
Diverge to See Options, Converge to Decide
66
Accept Constraints
68
Promote Desired Quality Attributes
73
Assign Functional Responsibilities to Elements
75
Design for Change
77
Project Lionheart: The Story So Far...
77
Next Up
79
7. Create a Foundation with Patterns
79
What Is an Architecture Pattern?
80
Layers Pattern
82
Ports and Adapters Pattern
84
Pipe-and-Ftlter Pattern
86
Service-Oriented Architecture Pattern
88
Publish-Subscribe Pattern 90
Shared-Data Pattern 92
Multi-Tier Pattern
93
Center of Competence Pattern
95
Open Source Contribution Pattern 96
Big Ball of Mud Pattern 96
Discover New Patterns
Project Lionheart: The Story So Far...
Next Up
Contents • vii
8. Manage Complexity with Meaningful Models..................................................99
Reason About the Architecture 99
Design the Meta-Model 101
Build Models into the Code 107
Project Lionheart: The Story So Far... 111
Next Up 112
9. Host an Architecture Design Studio.................................................................113
Plan an Architecture Design Studio 113
Choose Appropriate Design Activities 119
Invite the Right Participants 120
Manage the Group 122
Work with Remote Teams 124
Project Lionheart: The Story So Far... 126
Next Up 126
10. Visualize Design Decisions........................................................................129
Show the Architecture from Different Views 129
Draw Fantastic Diagrams 136
Project Lionheart: The Story So Far... 141
Next Up 142
11. Describe the Architecture..........................................................................143
Tell the Whole Story 143
Match the Description Method to the Situation 145
Respect Your Audience 149
Organize Views around Stakeholders' Concerns 152
Explain the Rationale for Your Decisions 155
Project Lionheart: The Story So Far... 156
Next Up 157
12. Give the Architecture a Report Card . . . . 159
Evaluate to Learn 159
Test the Design 160
Host an Evaluation Workshop 166
Evaluate Early, Evaluate Often, Evaluate Continuously 171
Project Lionheart: The Story So Far... 175
Next Up 176
13. Empower the Architects on Your Team . 177
Promote Architectural Thinking 177
Facilitate Decision Making and Foster Skills Growth 179
Contents • viii
179
Create Opportunities for Safe Practice
181
Delegate Design Authority
185
Design Architecture Together
186
Project Lionheart: The Epic Conclusion
187
Next Up
Part III — The Architect's Toolbox
191
14. Activities to Understand the Problem
192
Activity 1. Choose One Thing
195
Activity 2. Empathy Map
199
Activity 3. Goal-Question-Metric (GQM) Workshop
202
Activity 4. Interview Stakeholders
205
Activity 5. List Assumptions
207
Activity 6. Quality Attribute Web
210
Activity 7. Mini-Quality Attribute Workshop
215
Activity 8. Point-of-View Mad Lib
219
Activity 9. Response Measure Straw Man
221
Activity 10. Stakeholder Map
225
15. Activities to Explore Potential Solutions ■
226
Activity 11. Personify the Architecture
228
Activity 12. Architecture Flipbook
232
Activity 13. Component Responsibility Collaborator Cards
236
Activity 14. Concept Map
239
Activity 15. Divide and Conquer
244
Activity 16. Event Storming
249
Activity 17. Group Posters
252
Activity 18. Round-Robin Design
255
Activity 19. Whiteboard Jam
259
16. Activities to Make the Design Tangible . 260
Activity 20. Architecture Decision Records
263
Activity 21. Architecture Haiku
265
Activity 22. Context Diagram
267
Activity 23. Greatest Hits Reading List
269
Activity 24. Inception Deck 272
Activity 25. Modular Decomposition Diagram 274
Activity 26. Paths Not Taken 276
Activity 27. Prototype to Learn or Decide
Contents • ix
Activity 28. Sequence Diagram 278
Activity 29. System Metaphor 281
17. Activities to Evaluate Design Options..........................................................285
Activity 30. Architecture Briefing 286
Activity 31. Code Review 289
Activity 32. Decision Matrix 292
Activity 33. Observe Behavior 295
Activity 34. Question-Comment-Concem 298
Activity 35. Risk Storming 301
Activity 36. Sanity Check 304
Activity 37. Scenario Walkthrough 307
Activity 38. Sketch and Compare 311
Al. Community Contributor Bios....................................................................315
Bibliography...............................................................................................317
Index..........................................................................................................321
Acknowledgments
The most memorable moment for me writing this book was when my wife and
five-year-old son helped me figure out how to organize Chapters 1 and 2. One
Saturday morning, Marie asked probing questions and listened to me talk
things out while Owen, sharpie in hand, helped me write ideas on sticky notes
and move them around our kitchen window for over an hour. You are both
amazing. Thank you for your love and patience.
Deadlines do indeed make a strange whooshing sound as they pass. The best
deadline, and the only one I didn’t let slip while writing this book, was Finn.
Welcome to the world!
Mom, Dad, Ryan—this book was only possible thanks to your support and
encouragement throughout my life. Chris and Russ, thank you for helping
me find the time to write (and for the lasagna). Leia, thanks for listening.
I’ve been fortunate to learn from, collaborate with, and hang out with many
smart software architects and designers who greatly influenced my thinking,
including David Garlan, Mary Shaw, George Fairbanks, Len Bass, Rebecca
Wirfs-Brock, Simon Brown, Ariadna Font, Matt Bass, Tony Lattanze, Dave
Root, and Ipek Ozkaya.
I had an army of technical reviewers who, through their pointed feedback,
made this book significantly better. Those reviewers are David Bock, Will
Chaparro, Javier Collado, Fabrizio Cucci, George Fairbanks, Kevin Gisi,
Thijmen de Gooijer, Rod Hilton, Michael Hunter, Maurice Kelly, Joe Kramer,
Nick McGinness, Ryan Moore, Daivid Morgan, Emanuele Origgi, Ipek Ozkaya,
Will Price, Antonio Gomes Rodrigues, Jesse Rosalia, Tibor Simic, Stephen
Wolff, Eoin Woods, Peter W A Wood, and Colin Yates. Thank you to everyone
at IBM Pittsburgh for being willing guinea pigs for many of the design methods.
Susannah Pfalzer, the most amazing editor a first-time author could ask for,
thank you for shepherding me through the writing and publishing process.
Andy and Dave, thanks for giving me a chance to try to improve the way we
build software.
Foreword
When I picked up the final draft of this book, at first I was surprised to see
that it was missing any mention of Agile software development. Michael and
I have been chatting about this book for years now, and I thought I knew
what the book was about and why it must be written: software architecture
ideas, as traditionally described, have been hard to use in Agile processes,
but Michael has figured out how to do just that. So how could “Agile" not be
on eveiy page of the book?
Michael is a modern Prometheus, fascinated by technology and determined
to tame it for all of humanity. He is a true believer in the benefits of Agile and
an expert in software architecture. I know of no one else who was walking
the walk as an Agile team leader during the day while mentoring Carnegie
Mellon software architecture students at night. I know him best through our
involvement in the SATURN software architecture conference, where he has
brought ideas and thought leaders from the Agile community to rub elbows
with the architecture community. He has been looking for the best of both
worlds, a mixture of Agile and architecture that is not oil and water.
There have been other attempts to reconcile the differences, but they have
all been limited. Early attempts tried to shoehorn Agile into the implementation
phase of a waterfall process. Others implicitly assumed there was still a
“corner office architect” making the important decisions. Almost all of them
were based in theory rather than reporting on what they had successfully
applied and were written by an author in one camp trying to pull in ideas
from the other.
This book is a different, better synthesis of Agile and architecture, which is
why the word “Agile” is not on every page. It starts with a deep) understanding
and appreciation for Agile values and describes design techniques that are
compatible. Michael has invented or adapted many of the techniques himself,
but it thrills me to see that he’s also plucked the best ideas from conferences
over the past few years, techniques that are not yet in any other book. If you