Reviewing Architectures. Nathaniel T.

Transcription

1 Reviewing Architectures Nathaniel T.

2 At it s core, our job is pretty straightforward.

3 We educate.

4 We communicate.

5 If you can t communicate

6 You can t tell the story.

7 You can t be an effective architect.

8 Part of telling the story, is critiquing the story.

9 Did we do a good job telling the story?

10 How can we tell the story better?

11 Type of reviews.

12 There are any number of reasons for a review.

13 Some happen more frequently than others.

14 Some are higher ceremony.

15 Others are less formal.

16 Governance.

17 Are we following our standards and best practices?

18 Are we building the right thing?

19 Are we leveraging existing capabilities?

20 These reviews may seem like red tape.

21 And they can be!

22 Done right though

23 Can be very educational.

24 None of us knows it all.

25 Sorry to burst your bubble.

26 More eyes, more opportunities.

27 I worked on something like this a few years ago

28 We ran into issues with that, talk to Steve.

29 Sanity check.

30 We can be myopic.

31 Buried in the weeds.

32 Another set of eyes never hurts.

33 Cheaper to find issues early.

34 Also a great way of socializing projects.

35 Greater awareness.

36 Back fill, pitch in.

37 This isn t a blame fest.

38 Don t get personal!

39 Don t take criticism personally!

40 It isn t about you, it s about the architecture.

41 the only way to make something great is to recognize that it might not be great yet. Your goal is to find the best solution, not to measure your personal self-worth by it. Jonas Downey

42 Adequate lead time is a must.

43 Didn t have time to review it?

44 Don t come. But apologize.

45 Have a moderator.

46 Keep the trains moving.

47 Take notes, circulate minutes, follow up.

48 Follow up is key!

49 Retrospective.

50 These can be hard

51 Many are loathe to do it.

52 Or at least do it well

53 Excellent opportunity.

54 Requires introspection.

55 Mistakes were made but not by me?

56 What went well?

57 What went wrong?

58 What can we do better?

59 Shouldn t be blame-storming!

60 Did we miss requirements?

61 Did we miss a key quality attribute?

62 Were our assumptions wrong?

63 You know what they say about assumptions

64 Do we need to change the process?

65 How do we avoid this issue in the future?

66 Do we need to educate?

67 Socialize the lessons.

68 Find the positives.

69 Incorporate the positives into the process.

70 Fix and tweak.

71 Same things coming up again and again?

72 Fix it already!

73 Or just admit we don t care about that

74 Vendor products.

75 We certainly don t build everything.

76 We will incorporate vendor products.

77 How do we evaluate them?

78 You won t get the source code!

79 Marketing material is just that.

80 Not the unvarnished truth.

81 Proof of concept.

82 Only way to really know.

83 Identify what you need to understand, test accordingly.

84 Key use cases, concerns.

85 What criteria should we use to judge the product?

86 Hello world may not tell you enough.

87 But you probably won t have time for everything.

88 And don t rely on the vendor to perform the PoC!

89 Identify risks.

90 What is the impact? What is the likelihood?

91 Huge impact but unlikely? Medium impact, very likely?

92 Our job is to shed light on the risks.

93 Others typically decide what to do about it.

94 Be prepared for politics.

95 Many are chosen for non technical reasons.

96 Magic quadrant

97 CIO used to work there

98 Not much you can do about that.

99 Another layer of indirection!

100 Don t overthink it.

101 It ll drive you nuts.

102 Understand the context.

103 Doesn t mean you have to agree with it.

104 Mergers and acquisitions.

105 Business decisions do not exist in a vacuum.

106 Guarantee there s a technology impact.

107 Business can change direction in a 3 hour meeting.

108 But the tech rarely can adapt that quickly.

109 Rare for technologists to be part of M&A

110 Until it s too late.

111 But ideally there should be some sanity check!

112 Be ready to dig.

113 Software archaeology.

114 Are the technology stacks compatible?

115 Probably not.

116 Heterogeneous environment is the norm.

117 We probably can t *stop* the merger.

118 But we better figure out how to make it work.

119 Identify the current state.

120 How many systems are we talking about?

121 Can they run standalone? For how long?

122 What does that cost us?

123 Are there any regulations we need to be aware of?

124 Especially important across countries.

125 Don t assume laws are all the same everywhere!

126 What are the key architectural patterns?

127 What is our ideal end state?

128 How do we get there?

129 Identify the transitional states.

130 Don t skimp on the intermediate architecture.

131 They may last longer than you d like!

132 Be prepared for politics.

133 We re X, everything should be X, X is better

134 Is that really the best approach?

135 Can you afford to convert everything?

136 Evaluate systems.

137 What do they do well? What do they do poorly?

138 Expect non-technical criteria to dominate

139 For better or worse.

140 It s cheaper to convert 3,000 people to this

141 You sure about that?

142 Be prepared to tell the story.

143 Don t overthink it.

144 It ll drive you nuts.

145 Understand the context.

146 Doesn t mean you have to agree with it.

147 What types of reviews have you been a part of?

148 Preparing for reviews.

149 As a reviewer

150 You need to prepare.

151 Do your homework!

152 There are a host of questions to consider.

153 What are we reviewing?

154 Blueprint? Candidate? As implemented?

155 Vendor application?

156 Why are we reviewing it?

157 Review gate?

158 Merger?

159 Did we buy something new?

160 Are we having project issues? Any ility issues?

161 Is this a new application?

162 Existing?

163 Is this a strategic solution?

164 Tactical?

165 Is this a transitional state?

166 If so, for how long?

167 What happens if we need more time?

168 Does this solution make sense?

169 Is the architecture appropriate?

170 Are there any additional considerations?

171 At the end of the day, it boils down to this:

172 Did we do a good job telling the story?

173 If not, what do we have to add to tell the story?

174 As the reviewee

175 Have I identified all the stakeholders?

176 Have I answered questions raised by reviewers?

177 Is there anything else I need to tell the story?

178 Another diagram?

179 Bit of prose?

180 Have I had a peer look it over?

181 Are we ready?

182 Are things still in flux?

183 Highly recommend having a peer give it a once over.

184 Set it down for a day or two.

185 Come back to it.

186 What do you see differently now?

187 Is it clear? Concise?

188 Make every line, every diagram prove itself.

189 Don t take criticism personally!

190 It s not about you, it s about the architecture.

191 A sample process.

192 Cost/complexity/risk of the app dictates steps.

193 Early on, perform an initiation review.

194 Identify risks.

195 Shed light on them.

196 Summarize the project.

197 What are we doing? Why?

198 Give us the context!

199 Some questions for presenting architect.

200 Does it follow applicable standards/best practices?

201 Does it follow applicable enterprise standards?

202 Did we identify all the stakeholders?

203 Is it aligned to our project roadmaps?

204 Is this strategic?

205 Does it affect multiple projects?

206 Have we identified them?

207 Are we using our strategic tools/frameworks etc.?

208 Are we up to date on vendor versions?

209 Are we leveraging existing components?

210 Does this solution require stand alone infrastructure?

211 What kind of data does the project have?

212 Is that data transmitted outside the company?

213 Answers feed into a red/yellow/green score.

214 Which can be overridden (with a very good reason).

215 Have a stock architecture document.

216 Bits and pieces are added as the project matures.

217 Pretty straightforward.

218 Project overview.

219 Architectural assumptions, risks, constraints.

220 List of stakeholders and their key concerns.

221 Infrastructure capacity.

222 Set of diagrams.

223 Have a small number of required, most optional.

224 Depends on where we re at in the lifecycle too.

225 Possible required diagrams:

226 Context diagram.

227 Component diagram.

228 Conceptual data model.

229 High level, not normalized.

230 Deployment diagram.

231 Sequence diagram.

232 Logical data model.

233 Business terms, normal form.

234 Physical data model.

235 Implementation details.

236 From less detail to more.

237 Attribute Conceptual Logical Physical Entity Name X X Relationships X X Attributes X Primary Keys X X Foreign Keys X X Table Names Column Names Data Types X X X

238 Everything else could be optional.

239 If it helps to tell the story

240 Security touch point.

241 Disaster recovery.

242 Etc.

243 Once the document is done, review it.

244 Project architect works with coordinator.

245 Identify who should review it.

246 Generally 2-3 assigned.

247 Depends on the project.

248 What expertise do we want reviewing it?

249 Security? Mobile? Integration? Infrastructure?

250 Schedule reviews 2-3 weeks out.

251 Generally 30 minutes is enough time.

252 Accept the meeting? You re accountable.

253 Reviewers post questions about the architecture.

254 Project architect responds.

255 During the meeting, walk through the architecture.

256 Any additional questions?

257 Are the reviewers satisfied?

258 Expect a fair amount of discussion.

259 Did you think of this?

260 What happens if X?

261 At the end, vote on the red/yellow/green score.

262 Green? Good to go!

263 Yellow or red?

264 Senior architects should get involved.

265 Identify why it isn t green.

266 How do we get to green?

267 Is there anything that you need to escalate?

268 Largely about awareness.

269 This shouldn t be a static thing!

270 Work in progress!

271 What is working? What should you adjust?

272 Other things to think about

273 Formalizing quality attributes

274 Identify them, validate them.

275 Architectural decisions.

276 They happen!

277 How do we document them?

278 Title/ID.

279 What is the problem?

280 List assumptions and constraints.

281 What are the options?

282 List the pros and cons of each alternative.

283 Which one did you chose?

284 Why?

285 Consider a time capsule.

286 Screen cast or podcast of what you did and why.

287 Prevent Monday morning quarterbacking

288 Or just why did we do this?

289 Consider an internal class on how you do it.

290 Walk through the models you re expected to create.

291 Don t dictate a specific tool.

292 Though some projects may have a standard.

293 Use what works!

294 Track how many projects score red/yellow/green.

295 Document path to green.

296 Follow up!

297 Constructive criticism.

298 It can be hard to criticize.

299 It can be harder to be criticized.

300 Remember - it isn t personal.

301 Well, it shouldn't be.

302 None of us is perfect.

303 It s all about building better applications.

304 the only way to make something great is to recognize that it might not be great yet. Your goal is to find the best solution, not to measure your personal self-worth by it. Jonas Downey

305 We re all on the same team!

306 It s about the architecture, not the architect.

307 No snark.

308 No sarcasm.

309 Ask helpful questions.

310 How does the app handle expected data growth?

311 Is X a concern for this solution?

312 Share your experiences.

313 My project ran into

314 When you get to X, ping me and I ll help with

315 Etc.

316 Don t make proclamations!

317 This won t scale.

318 Really? Based on what?

319 Does that apply here?

320 Try to sandwich criticism with compliments.

321 Really concerned?

322 Talk to the architect.

323 Don t ambush them!

324 No one wins there

325 Remember, reviews are a chance to educate.

326 Every single one of us is doing the absolute best we can given our state of consciousness. Deepak Chopra

327 Before you get on your high horse

328 Do you have all the context?

329 Are there mitigating circumstances?

330 Some background you don t have?

331 There may be constraints.

332 Keep it to the architecture.

333 Stay grounded.

334 Back it up.

335 Remember, it s all about the story.

336 Did we tell it well?

337 How can we tell it better?

338 An important part of improving is reviewing.

339 We don t get better in a vacuum.

340 Effective reviews are vital to a healthy practice.

341 Prepare, be professional.

342 Learn from each other.

343 Keep improving!

344 Good luck!

345 Thanks! I'm a Software Architect, Now What? Nathaniel T.