Table Of ContentSoftware Architecture for Developers
Technical leadership by coding, coaching, collaboration,
architecture sketching and just enough up front design
Simon Brown
Thisbookisforsaleathttp://leanpub.com/software-architecture-for-developers
Thisversionwaspublishedon2014-05-12
ThisisaLeanpubbook.LeanpubempowersauthorsandpublisherswiththeLeanPublishing
process.LeanPublishingistheactofpublishinganin-progressebookusinglightweighttools
andmanyiterationstogetreaderfeedback,pivotuntilyouhavetherightbookandbuild
tractiononceyoudo.
©2012-2014SimonBrown
Tweet This Book!
PleasehelpSimonBrownbyspreadingthewordaboutthisbookonTwitter!
Thesuggestedhashtagforthisbookis#sa4d.
Findoutwhatotherpeoplearesayingaboutthebookbyclickingonthislinktosearchforthis
hashtagonTwitter:
https://twitter.com/search?q=#sa4d
ForKirstie,MatthewandOliver
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Aboutthebook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Abouttheauthor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Softwarearchitecturetraining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
I What is software architecture? . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1 Whatisarchitecture? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Typesofarchitecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Whatissoftwarearchitecture? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Whatisagilesoftwarearchitecture?. . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5 Architecturevsdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6 Issoftwarearchitectureimportant? . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7 Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
II The software architecture role . . . . . . . . . . . . . . . . . . . . . . . . . 17
8 Thesoftwarearchitecturerole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9 Shouldsoftwarearchitectscode? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10 Softwarearchitectsshouldbemasterbuilders . . . . . . . . . . . . . . . . . . . . . 26
11 Fromdevelopertoarchitect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12 BroadeningtheT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
13 Softskills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
14 Softwaredevelopmentisnotarelaysport . . . . . . . . . . . . . . . . . . . . . . . 38
15 Softwarearchitectureintroducescontrol? . . . . . . . . . . . . . . . . . . . . . . . 40
CONTENTS
16 Mindthegap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
17 Wherearethesoftwarearchitectsoftomorrow? . . . . . . . . . . . . . . . . . . . 45
18 Everybodyisanarchitect,exceptwhenthey’renot . . . . . . . . . . . . . . . . . . 47
19 Softwarearchitectureasaconsultant . . . . . . . . . . . . . . . . . . . . . . . . . . 49
20 Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
III Designing software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
21 Architecturaldrivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
22 QualityAttributes(non-functionalrequirements) . . . . . . . . . . . . . . . . . . . 55
23 Workingwithnon-functionalrequirements . . . . . . . . . . . . . . . . . . . . . . 59
24 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
25 Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
26 Technologyisnotanimplementationdetail . . . . . . . . . . . . . . . . . . . . . . 67
27 Morelayers=morecomplexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
28 Collaborativedesigncanhelpandhinder . . . . . . . . . . . . . . . . . . . . . . . . 72
29 Softwarearchitectureisaplatformforconversation . . . . . . . . . . . . . . . . . 73
30 SharePointprojectsneedsoftwarearchitecturetoo . . . . . . . . . . . . . . . . . . 75
31 Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
IV Visualising software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
32 Wehaveafailuretocommunicate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
33 Theneedforsketches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
34 Ineffectivesketches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
35 C4:context,containers,componentsandclasses . . . . . . . . . . . . . . . . . . . . 98
36 Contextdiagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
37 Containerdiagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
38 Componentdiagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
39 Technologychoicesincludedoromitted? . . . . . . . . . . . . . . . . . . . . . . . . 116
CONTENTS
40 Wouldyoucodeitthatway? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
41 Softwarearchitecturevscode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
42 Youdon’tneedaUMLtool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
43 Effectivesketches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
44 C4-FAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
45 Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
V Documenting software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
46 Thecodedoesn’ttellthewholestory . . . . . . . . . . . . . . . . . . . . . . . . . . 141
47 Softwaredocumentationasaguidebook . . . . . . . . . . . . . . . . . . . . . . . . 144
48 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
49 FunctionalOverview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
50 QualityAttributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
51 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
52 Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
53 SoftwareArchitecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
54 ExternalInterfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
55 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
56 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
57 InfrastructureArchitecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
58 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
59 OperationandSupport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
60 DecisionLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
61 Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
VI Software architecture in the development life cycle . . . . . . . . . . 175
62 Theconflictbetweenagileandarchitecture-mythorreality? . . . . . . . . . . . . 176
63 Quantifyingrisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
CONTENTS
64 Risk-storming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
65 Justenoughupfrontdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
66 Introducingsoftwarearchitecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
67 Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
VII Appendix A: Financial Risk System . . . . . . . . . . . . . . . . . . . . . 197
68 FinancialRiskSystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
VIII Appendix B: Software Guidebook for techtribes.je . . . . . . . . . . 201
Preface
TheITindustryiseithertakinggiantleapsaheadorit’sindeepturmoil.Ontheonehandwe’re
pushing forward, reinventing the way that we build software and striving for craftsmanship at
everyturn.Ontheotherthough,we’recontinuallyforgettingthegoodofthepastandsoftware
teamsarestillscrewinguponanalarminglyregularbasis.
Software architecture plays a pivotal role in the delivery of successful software yet it’s frustrat-
inglyneglectedbymanyteams.Whetherperformedbyonepersonorsharedamongsttheteam,
the software architecture role exists on even the most agile of teams yet the balance of up front
andevolutionarythinkingoftenreflectsaspirationratherthanreality.
Software architecture has a bad reputation
I tend to get one of two responses if I introduce myself as a software architect. Either people
think it’s really cool and want to know more or they give me a look that says “I want to
talk to somebody that actually writes software, not a box drawing hand-waver”. The software
architecture role has a bad reputation within the IT industry and it’s not hard to see where this
hascomefrom.
The thought of “software architecture” conjures up visions of ivory tower architects doing big
design up front and handing over huge UML (Unified Modeling Language) models or 200 page
MicrosoftWorddocumentstoanunsuspectingdevelopmentteamasiftheywerethesecondleg
of a relay race. And that’s assuming the architect actually gets involved in designing software
of course. Many people seem to think that creating a Microsoft PowerPoint presentation with
a slide containing a big box labelled “Enterprise Service Bus” is software design. Oh, and we
mustn’t forget the obligatory narrative about “ROI” (return on investment) and “TCO” (total
costofownership)thatwillundoubtedlyaccompanythepresentation.
Many organisations have an interesting take on software development as a whole too. For
example, they’ve seen the potential cost savings that offshoring can bring and therefore see
the coding part of the software development process as being something of a commodity. The
result tends to be that local developers are pushed into the “higher value” software architecture
jobswithanexpectationthatallcodingwillbeundertakenbysomebodyelse.Inmanycasesthis
onlyexaggeratesthedisconnectbetweensoftwarearchitectureandsoftwaredevelopment,with
people often being pushed into a role that they are not prepared for. These same organisations
oftentendtoseesoftwarearchitectureasarankratherthanarole too.
Agile aspirations
“Agile” might be over ten years old, but it’s still the shiny new kid in town and many software
teams have aspirations of “becoming agile”. Agile undoubtedly has a number of benefits but it
Preface ii
isn’t necessarily the silver bullet that everybody wants you to believe it is. As with everything
in the IT industry, there’s a large degree of evangelism and hype surrounding it. Start a new
software project today and it’s all about self-organising teams, automated acceptance testing,
continuous delivery, retrospectives, Kanban boards, emergent design and a whole host of other
buzzwords that you’ve probably heard of. This is fantastic but often teams tend to throw the
baby out with the bath water in their haste to adopt all of these cool practices. “Non-functional
requirements”notsoundingcoolisn’tareasontoneglectthem.
What’s all this old-fashioned software architecture stuff anyway? Many software teams seem
to think that they don’t need software architects, throwing around terms like “self-organising
team”, “YAGNI” (you aren’t going to need it), “evolutionary architecture” and “last responsible
moment” instead. If they do need an architect, they’ll probably be on the lookout for an “agile
architect”.I’mnotentirelysurewhatthistermactuallymeans,butIassumethatithassomething
to do with using post-it notes instead of UML or doing TDD (test-driven development) instead
of drawing pictures. That is, assuming they get past the notion of only using a very high level
systemmetaphoranddon’tuse“emergentdesign”asanexcuseforfoolishlyhopingforthebest.
So you think you’re an architect?
It also turns out there are a number of people in the industry claiming to be software architects
whereas they’re actually doing something else entirely. I can forgive people misrepresenting
themselves as an “Enterprise Architect” when they’re actually doing hands-on software archi-
tecturewithinalargeenterprise.Theterminologyinourindustryis oftenconfusingafterall.
But what about those people that tend to exaggerate the truth about the role they play on
softwareteams?Suchirresponsiblearchitectsareusuallytaskedwithbeingthetechnicalleader
yet fail to cover the basics. I’ve seen public facing websites go into a user acceptance testing
environment with a number of basic security problems, a lack of basic performance testing,
basic functionality problems, broken hyperlinks and a complete lack of documentation. And
that was just my external viewof the software,who knows what the code looked like.If you’re
undertaking the software architecture role and you’re delivering stuff like this, you’re doing it
wrong.Thisisn’t softwarearchitecture,it’salsofoolishlyhopingforthebest.
The frustrated architect
Admittedly not all software teams are like this but what I’ve presented here isn’t a “straw
man” either. Unfortunately many organisations do actually work this way so the reputation
thatsoftwarearchitecturehasshouldn’tcomeasanysurprise.
If we really do want to succeed as an industry, we need to get over our fascination with shiny
newthingsandstartingaskingsomequestions.Doesagileneedarchitectureordoesarchitecture
actually need agile? Have we forgotten more about good software design than we’ve learnt in
recent years? Is foolishly hoping for the best sufficient for the demanding software systems
we’re building today? Does any of this matter if we’re not fostering the software architects of
tomorrow?Howdowemovefromfrustrationtoserenity?
