- Page 1 and 2: Software Architecture for Developer
- Page 3: Jersey
- Page 7 and 8: A developer-friendly guide to softw
- Page 9 and 10: What is software architecture?
- Page 11 and 12: Designing software
- Page 13 and 14: Documenting software
- Page 15 and 16: What is software architecture?
- Page 17 and 18: What is “architecture”?
- Page 19 and 20: As a verb... Vision The process of
- Page 21 and 22: Enterprise Architecture Structure a
- Page 23 and 24: What is design? All architecture is
- Page 25 and 26: Web Application Significant Another
- Page 27 and 28: Is software architecture important?
- Page 29 and 30: No defined structure, inconsistent
- Page 31 and 32: Shared vision of WTF?!
- Page 33 and 34: What is software architecture? Arch
- Page 35 and 36: Seeing the big picture
- Page 37 and 38: Software architect as team leader P
- Page 39 and 40: Project Manager, Software Architect
- Page 41 and 42: The software architecture role is d
- Page 43 and 44: Surely we must be able That’s ***
- Page 45 and 46: Abstract Specific Sometimes you nee
- Page 47 and 48: Software architecture is a post-tec
- Page 49 and 50: Learn how to step back and see the
- Page 51 and 52: The low-level details are important
- Page 53 and 54: Is that how we are going to build i
- Page 55 and 56:
Should software architects write co
- Page 57 and 58:
Software architects must be master
- Page 59 and 60:
Software architecture is about tech
- Page 61 and 62:
Leadership Communication Influencin
- Page 63 and 64:
Talking with Tech Leads From Novice
- Page 65 and 66:
Be proactive and lead by example
- Page 67 and 68:
Architectural Drivers Understanding
- Page 69 and 70:
Software architecture introduces co
- Page 71 and 72:
1. Agree on some things 2. Put some
- Page 73 and 74:
Sits in an ivory tower Architect Fo
- Page 75 and 76:
Most importantly, rockstar engineer
- Page 77 and 78:
Implementing the role
- Page 79 and 80:
Generalising Specialist Generalisin
- Page 81 and 82:
Generalising Specialist Generalist
- Page 83 and 84:
How can I write code when I have se
- Page 85 and 86:
Every software development team nee
- Page 87 and 88:
The role Responsibility 1 Responsib
- Page 89 and 90:
The software architecture role It
- Page 91 and 92:
Requirements
- Page 93 and 94:
How many elephants did you see at t
- Page 95 and 96:
Quality Attributes Performance Scal
- Page 97 and 98:
Understand how to refine them What
- Page 99 and 100:
Understand how to challenge them Ar
- Page 101 and 102:
Learn about and understand the (oft
- Page 103 and 104:
Software lives in the real world, a
- Page 105 and 106:
Scope Small scope = low cost and sh
- Page 107 and 108:
People & skills (e.g. team size, le
- Page 109 and 110:
Beware that constraints can drive t
- Page 111 and 112:
Understand what the constraints are
- Page 113 and 114:
Principles are the things you want
- Page 115 and 116:
Architectural layering, no business
- Page 117 and 118:
Designing software
- Page 119 and 120:
How do you design software? (techni
- Page 121 and 122:
Questions Will we receive all of th
- Page 123 and 124:
Don’t blindly focus on the code;
- Page 125 and 126:
Communicating design
- Page 127 and 128:
What’s been challenging about the
- Page 129:
Review the diagrams 3 things we lik
- Page 132 and 133:
9 out of 10 people don’t use UML
- Page 134 and 135:
In my experience, software teams ar
- Page 136 and 137:
Moving fast requires good communica
- Page 140 and 141:
Are these effective sketches?
- Page 142 and 143:
Boxes & No Lines
- Page 144 and 145:
Stormtroopers
- Page 146 and 147:
Generically True
- Page 148 and 149:
Deployment vs Execution Context
- Page 150 and 151:
Homeless Old C# Object (HOCO)
- Page 152 and 153:
Should have used a whiteboard
- Page 154 and 155:
Effective sketches
- Page 156 and 157:
Collaborative design (e.g. pair arc
- Page 159 and 160:
Titles Short and meaningful, number
- Page 161 and 162:
The C4 model
- Page 163 and 164:
Do the names of those views make se
- Page 165 and 166:
Software System iner file system, e
- Page 167 and 168:
System Context The system plus user
- Page 169 and 170:
C4++ Enterprise context User interf
- Page 171 and 172:
Diagrams are maps that help a team
- Page 173 and 174:
A common set of abstractions is mor
- Page 175 and 176:
Context •What are we building?
- Page 177 and 178:
Components •What components/ serv
- Page 179 and 180:
I do use UML (activity, class, sequ
- Page 181 and 182:
Software architecture vs code
- Page 183 and 184:
Does your code reflect the abstract
- Page 185 and 186:
Controller A Presentation layer Con
- Page 187 and 188:
Controller A Controller B Feature S
- Page 189 and 190:
https://github.com/techtribesje/tec
- Page 191 and 192:
Controller A Controller B Feature S
- Page 193 and 194:
“In the early days of computing w
- Page 195 and 196:
Instead of blindly unit testing eve
- Page 197 and 198:
System Tests UI, API, functional an
- Page 199 and 200:
Software architecture as code
- Page 201 and 202:
Diagramming tools see packages and
- Page 203 and 204:
Spring PetClinic https://github.com
- Page 205 and 206:
What are the architecturally signif
- Page 207 and 208:
A component diagram, based upon the
- Page 209 and 210:
Is the architecture in the code?
- Page 211 and 212:
Context People Security groups/role
- Page 213 and 214:
Components People Security groups/r
- Page 215:
Create an architecture description
- Page 220 and 221:
Structurizr Simple, versionable, up
- Page 222 and 223:
Spring PetClinic - Containers
- Page 224 and 225:
A model as code provides opportunit
- Page 226 and 227:
Software architecture really is for
- Page 228 and 229:
The C4 sketches are a great way to
- Page 230 and 231:
Architecture sketching assists with
- Page 232 and 233:
Architecture sketches are not compr
- Page 234 and 235:
Leave your sketches on the wall
- Page 236 and 237:
Communicating design Agree upon a c
- Page 238 and 239:
Working software over comprehensive
- Page 240 and 241:
Should software be documented?
- Page 242 and 243:
The code doesn’t tell the whole s
- Page 244 and 245:
The bus factor (it’s not just abo
- Page 246 and 247:
Context What is this all about? Fun
- Page 248 and 249:
Software Architecture Document Maps
- Page 250 and 251:
An example software guidebook for t
- Page 252 and 253:
Functional Overview Functional Over
- Page 254 and 255:
Constraints System must be deployed
- Page 256 and 257:
Software Architecture Software Arch
- Page 258 and 259:
Code
- Page 260 and 261:
Infrastructure Architecture
- Page 262 and 263:
Operation and Support
- Page 264 and 265:
How much of the document is up to d
- Page 266 and 267:
Product vs project
- Page 268 and 269:
Documenting software The code doesn
- Page 270 and 271:
Software architecture in the softwa
- Page 272 and 273:
The software architecture role shou
- Page 274 and 275:
The “Waterfall” Model Requireme
- Page 276 and 277:
Agile (e.g. Scrum) Skills Sprint 1
- Page 278 and 279:
Agile is about moving fast, embraci
- Page 280 and 281:
What does “agility” mean?
- Page 282 and 283:
Agility is relative and time-based
- Page 284 and 285:
A good architecture enables agility
- Page 286 and 287:
Agility is a quality attribute
- Page 288 and 289:
Think about how to align the softwa
- Page 290 and 291:
Firm foundations
- Page 292 and 293:
“just enough”
- Page 294 and 295:
Analysis or coding?
- Page 296 and 297:
New project checklist Complex non-f
- Page 298 and 299:
Web tier Middle tier Database tier
- Page 300 and 301:
An example timeline from “Beyond
- Page 302 and 303:
Probability Low (1) Medium (2) High
- Page 304 and 305:
Like estimates, risks are subjectiv
- Page 306 and 307:
Risk-storming A collaborative and v
- Page 308 and 309:
What are the risks of your solution
- Page 310 and 311:
Does your architecture work? (write
- Page 312 and 313:
1. Current Situation abuse and frau
- Page 314 and 315:
The software architecture role and
- Page 316 and 317:
The process of software architectin
- Page 318 and 319:
Sketches for early and quick up fro
- Page 320 and 321:
A quick summary...
- Page 322 and 323:
Abstract Specific Sometimes you nee
- Page 324 and 325:
Software System iner ion server, st
- Page 326 and 327:
The C4 sketches are a great way to
- Page 328 and 329:
The code doesn’t tell the whole s
- Page 330 and 331:
Documentation should describe what
- Page 332 and 333:
Just enough up front design to crea
- Page 334 and 335:
There’s a common misconception th
- Page 336 and 337:
Software architecture needs to be m
- Page 338 and 339:
Define the software architecture ro
- Page 340 and 341:
Talk about software architecture in
- Page 342 and 343:
I know we need architecture, but ho
- Page 344 and 345:
Present the facts, risks and soluti
- Page 346:
Do whatever works for you simon.bro