Thinking Architecturally
•
1 like•550 views
Presented by Nate Schutta at the Fedex Cloud-Native Conference in Pittsburgh on July 12th, 2019.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Thinking Architecturally
Similar to Thinking Architecturally (20)
More from VMware Tanzu
More from VMware Tanzu (20)
Recently uploaded
Recently uploaded (20)
Thinking Architecturally
- 1. Nathaniel T. Schutta @ntschutta ntschutta.io Thinking Architecturally
- 6. Constantly.
- 7. Feature not a bug.
- 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.
- 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…
- 31. Often *very* strong opinions.
- 32. Maybe we fear old things?
- 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.
- 45. Bleeding edge… means you will bleed!
- 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?
- 61. Block out Friday afternoon. Tuesday over lunch. Whatever fits.
- 63. Take 15-30 minutes in the morning to peruse the tech news.
- 64. Before the day gets away from you…
- 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?
- 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*?
- 84. Remember Google’s 20% time?
- 85. Fallen out of favor in some circles…
- 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?
- 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.
- 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...
- 154. How does it stack up to alternatives?
- 156. Options across the top.
- 157. Criteria down the left.
- 158. Criteria can be weighted.
- 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.
- 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.
- 205. What if our architectures expected to change?
- 207. — Building Evolutionary Architectures An evolutionary architecture supports guided, incremental change across multiple dimensions.
- 208. Some architectures are more evolvable than others…
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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