This document discusses strategies for software architects to stay up to date with changing technologies while maintaining stability and delivering business value. It recommends developing a routine for keeping up with news, evaluating new technologies through community involvement and hands-on trials before adopting them. It also stresses the importance of establishing principles, guardrails and fitness functions to guide teams' decisions and ensure the architecture continues to meet its goals as things change incrementally over time.

1. Nathaniel T. Schutta
@ntschutta
ntschutta.io
Thinking Architecturally

2. https://content.pivotal.io/
ebooks/thinking-architecturally

3. Architecting is hard…

4. Many competing agendas.

5. Technology changes.

6. Constantly.

7. Feature not a bug.

8. Keeps things interesting…

9. We want to avoid legacy platforms.

10. But we can’t change
things every few months.

11. “Our app has 4 different
UI frameworks…”

12. Developers kept chasing
the new hotness.

13. How do we avoid that?

14. How do we evaluate new technology?

15. I have no idea what language/
framework/platform is “next”.

16. No one does.

17. But I can guarantee you this much:

18. It will be different than
what we use today.

19. Five years from now we will be using
something that isn’t invented yet.

20. Chasing the new thing.

21. Technology changes.

22. Constantly.

23. Tempting to always
chase the “new hotness”.

24. Bleeding edge.

25. It’s fun!

26. Part of being in this industry.

27. Our understanding constantly evolves.

29. Let’s be honest…

30. Developers have opinions!

31. Often *very* strong opinions.

32. Maybe we fear old things?

34. Predictable hype cycle.

35. https://mobile.twitter.com/cote/status/963481741171265537

36. How do we know where
not to use a technology?

37. Trial and error.

38. Developers tend to get bored quickly.

40. Learning keeps it fresh.

41. But we have to deliver business value.

42. Can’t do that if we’re
always experimenting.

43. Have to commit at some point.

44. Develop some expertise.

45. Bleeding edge…
means you will bleed!

46. https://mobile.twitter.com/joeerl/status/930774515512201216

47. Pioneers…the ones with
arrows in their backs.

48. What is your strategy?

49. How do we avoid dead platforms?

50. Without constantly changing direction?

51. Strategy.

52. Hope is not a strategy!

53. But it is what rebellions are built on.

54. We need to be deliberate.

55. There are a lot of bits out there...

56. New languages, techniques, approaches.

57. How do you keep up?

58. Blogs? Books? Twitter?
Podcasts? Conferences?

60. Develop a routine.

61. Block out Friday afternoon.
Tuesday over lunch. Whatever fits.

62. Consider “morning coffee”.

63. Take 15-30 minutes in the
morning to peruse the tech news.

64. Before the day gets away from you…

65. Attention is precious.

66. — Seth Godin
“Attention is a bit like real estate, in
that they're not making any more of
it. Unlike real estate, though, it
keeps going up in value.”
http://sethgodin.typepad.com/seths_blog/2011/07/
paying-attention-to-the-attention-economy.html

67. Don’t waste it.

68. Be selective.

69. Can’t read it all.

70. http://www.npr.org/blogs/monkeysee/2011/04/21/135508305/the-sad-
beautiful-fact-that-were-all-going-to-miss-almost-everything
In fact, you’ll miss almost everything.

71. We cannot adopt every new thing.

72. How do we know where
to invest our time?

73. Hacker’s Radar?
http://www.paulgraham.com/javacover.html

74. “I have a hunch that [Java] won't be
a very successful language.”

75. Never written a line of Java,
glanced at some books.

76. Need more than just a hunch.

77. “Judging Covers” can
be a useful filter.

78. But beware bias.

79. Where is the community?

81. Are you skating to
where the puck *was*?

82. Technology Radar.
https://www.thoughtworks.com/radar

84. Remember Google’s 20% time?

85. Fallen out of favor in some circles…

86. Innovation Fridays.

87. Could you carve out Friday afternoons?

88. How about Tuesday Tech Talks?

89. Architectural Briefings.
https://github.com/stuarthalloway/presentations/wiki/Architectural-Briefings

90. One person does some
research, presents to the team.

91. And no, you don’t need to be
an architect to present!

92. Why should we use X?

93. What do you need to know
to answer the “why”?

94. What do you need to
know in order to use X?

95. Keep it short - 45 minutes.

96. Not a how to.

97. Beyond the initial documentation.

98. These are participatory events!

99. Attendees should be taking notes.

100. Asking questions.

101. Using their own experiences.

102. Do you agree? Why or why not?

103. By the way, you are up next week…

104. Pass the briefing filter?

105. Hands on time.

106. Workshop it.

107. Couple of hours.

108. A few exercises.

109. Focus on how to, simple setup.

110. Pass the hands on filter?

111. Time to trial it in the organization.

112. Real project work that is a good fit.

113. Probably not a “bet the
company” project though!

114. The new hotness is not our
only concern though.

115. Need to stay current on the things
we are using day in day out.

121. Oops.

122. Don’t think you’re a target?

125. — Justin Smith
At high velocity, the three Rs starve
attacks of the resources they need to
grow. It’s a complete 180-degree change
from the traditional careful aversion to
change to mitigate risk. Go fast to stay
safer — in other words, speed reduces risk.

126. What is your patching strategy?

127. What version of X are you on?

128. Some organizations have
a policy of N or N-1.

129. Do they measure it? Do they enforce it?

130. What needs to change in
your culture to stay at N?

131. What hurts more? Changing
your patching strategy?

132. Or being on the receiving end of the
latest “largest hack ever”?

133. Pros and Cons.

134. Every technical choice
involves tradeoffs.

135. — Susan J. Fowler
Production-Ready Microservices
When we find ourselves presented
with technology that promises to
offer us drastic improvements, we
need to look for the trade-offs.

136. Essence of design.

137. To paraphrase Harry Truman…

138. Give me a one handed technologist.

139. Should we use React or Angular?

140. Should we refactor to microservices?

141. Should we be on prem
or public cloud?

142. https://twitter.com/KentBeck/status/596007846887628801

143. In many cases?

144. && ! ||

145. Balancing those opposing forces
is the art of architecture.

146. No tech is perfect, don’t pretend it is.

147. Acknowledge the negatives.

148. What do you like about it?

149. What don’t you like about it?

150. What would you add?

151. What would you remove?

152. King of Java for a day...

153. https://mobile.twitter.com/kelseyhightower/status/963428093292457984

154. How does it stack up to alternatives?

155. The spreadsheet approach.

156. Options across the top.

157. Criteria down the left.

158. Criteria can be weighted.

159. Harvey balls.
http://en.wikipedia.org/wiki/Harvey_Balls

160. !"#$%

161. How closely does does it
map to the criteria?

162. Very effective...

163. Angular React
Documentation
% $
Community
% $
Committer diversity
% %
Codebase
% %
Testability
% %
Update history
$ $
Maturity
% $

164. Angular React
Stability
% $
Extensibility
% %
Support
% %
Training
% %
Hiring
% $
Corporate fit ? ?
Usage
% %

165. What criteria should you use?

166. How should they be weighted?

167. Up to you.

168. You can tip the scales…

169. Usually backfires.

170. Establish principles.

171. We can’t be everywhere…

172. We can’t be involved
with every decision.

173. We can establish principles.

174. Guard rails.

175. Guide posts.

176. North stars.

177. Create the environment within
which our projects can thrive.

178. But how do we know if projects
are following our principles?

179. Fitness functions.

180. We’re all familiar with the
second law of thermodynamics…

181. Otherwise known as a
teenagers bedroom.

182. The universe really
wants to be disordered.

183. Software is not immune from this!

184. We go through the thoughtful effort
to establish an architecture…

185. How do we maintain it?

186. We can’t spend every minute of
every day on every project.

187. How do we ensure teams
continue to make good decisions?

188. We cannot predict the future.

189. That’s not entirely true.

190. One constant - change.

191. Architecture is often defined as the
decisions that are hard to change.

192. Or the decisions we wish we got right.

193. But we *know* things will change!

194. Isn’t this approach anti agile?

195. Contributing factor to the “we’re agile,
we don’t have architects” theory.

196. You definitely have people making
architectural decisions!

197. Sure hope they are
making good ones…

198. You’ll know in a year or two.

199. “Our app has 4 different
UI frameworks…”

200. 🤔

201. What do we do about that?

202. Maybe we should change
our assumptions.

203. https://mobile.twitter.com/martinfowler/status/949323421619548161

205. What if our architectures
expected to change?

206. http://evolutionaryarchitecture.com

207. — Building Evolutionary Architectures
An evolutionary architecture
supports guided, incremental
change across multiple dimensions.

208. Some architectures are more
evolvable than others…

209. http://evolutionaryarchitecture.com

210. Components are deployed,
features are enabled via toggles.

211. Allows us to change incrementally.

212. Also perform hypothesis
driven development!

213. But how do we ensure the
architecture still meets our needs?

214. How do we know if a solution
violates part of the architecture?

215. Fitness functions!

216. Concept comes from
evolutionary computing.

217. Is this mutation a success?

218. Are we closer to or
further from our goal?

219. For architecture, it is all
about protecting the ilities.

220. And balancing the tradeoffs.

221. We want to capture and preserve the
key architectural characteristics.

222. First, we need to identify those key
measures for project success.

223. Service Level Indicators if you will.

224. What can we measure?

225. Sometimes we let what we can
measure dictate too much…

226. Just because we can measure it
doesn’t mean it matters!

227. Lines of code anyone?

228. Once we have our metrics,
we can set some goals.

229. Service Level Objectives.

230. SLO !== SLA!

231. Now we can create a fitness function!

232. Basically, a set of tests we execute
to validate our architecture.

233. How close does this particular
design get us to our objectives?

234. Ideally, all automated. But we may
need some manual verifications.

235. For example…

236. All service calls must
respond within 100 ms.

237. Cyclomatic complexity
shall not exceed X.

238. Hard failure of an application
will spin up a new instance.

239. https://github.com/Netflix/SimianArmy

240. Chaos Engineering.
https://medium.com/production-ready/chaos-monkey-for-fun-and-profit-87e2f343db31

241. Fitness functions remind us what is
important in our architecture.

242. Informs our thinking about tradeoffs.

243. Different categories of fitness functions.

244. Atomic vs. Holistic.

245. Some characteristics must be tested
in isolation…others cannot.

246. Holistic fitness functions
test combined features.

247. We can’t test every
possible combination!

248. Must be selective, driven by the value
of the architectural characteristic.

249. Triggered vs. Continual.

250. Must consider frequency of execution.

251. Fitness functions can be triggered by
something - checkin, QA pass…

252. Continual tests are just that.

253. Monitoring Driven Development!
http://benjiweber.co.uk/blog/2015/03/02/monitoring-check-smells/

254. Static vs. Dynamic.

255. Static tests have a fixed result -
they either pass or they fail.

256. Nearly any test based on a metric.

257. Other fitness functions have a
shifting definition of success.

258. Generally defined within a
range of acceptable outcomes.

259. Automated vs. Manual.

260. Automation is good!

261. Ideally most of our fitness functions
will live in our deployment pipeline.

262. Not everything is amenable
to automation though…

263. Legal.

264. Existing projects.

265. Temporal fitness functions.

266. Essentially a reminder.

267. Check for an upgrade of library X.

268. Break upon upgrade tests.

269. Clearly we want to identify fitness
functions as early as we can.

270. The discussion about the tradeoffs is
invaluable to our understanding.

271. Help us prioritize features.

272. May lead us to break a system up
to isolate certain features.

273. We can’t know everything up front.

274. Fitness functions will emerge
as the system changes.

275. But we should strive to identify as
many as we can up front.

276. We can also classify fitness functions.

277. Key - critical decisions.

278. Relevant - considered but unlikely
to influence the architecture.

279. Not Relevant - won’t
impact our decisions.

280. Can still be very useful to identify
the non relevant dimensions!

281. Keep fitness functions visible!

282. Need to review the fitness functions.

283. Are they still relevant?

284. Are there new dimensions
we need to track?

285. Are there better ways of measuring/
testing our current fitness functions?

286. Aim for at least an annual review.

287. Architecting is hard…

288. We have a lot to juggle!

289. Important that we thing strategically.

290. We can’t afford
Resume Driven Design.

291. Good luck!

292. Questions?

293. Nathaniel T. Schutta
@ntschutta
ntschutta.io
Thanks!
I’m a Software
Architect,
Now What?
with Nate Shutta
Modeling for
Software
Architects
with Nate Shutta
Presentation
Patterns
with Neal Ford & Nate Schutta