Developers

Recommendations

Info

Technical leadership
Architectural Drivers Understanding the goals; capturing, refining and challenging the requirements and constraints Designing Software Creating the technical strategy, vision and roadmap Technical Risks Identifying, mitigating and owning the technical risks to ensure that the architecture “works” Architecture Evolution Continuous technical leadership and ownership of the architecture throughout the software Coding Involvement in the hands-on elements of the Quality Assurance Introduction and adherence to standards, guidelines, principles The software architecture role
Page 1 and 2:
Software Architecture for Developer
Page 3 and 4:
Jersey
Page 5 and 6:
I help software teams understand so
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: Be proactive and lead by example
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
show all

Developers

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?