The document discusses strategies for introducing architectural changes. It recommends starting by identifying stakeholders and understanding personal benefits, risks, and changes. It then discusses moving from monolithic to microservices architectures and taming terminology. The document suggests using analogies to explain changes and determining how refactoring will influence core business processes. It stresses the importance of automated tests and documentation to convince others and overcome fears of uncertainty. It provides tips for removing unused code by measuring impact and checking for dependencies.

1. Source: geek and poke

2. Architecture for
Rookies

4. Change in thinking
Tame the terminology
Convince to change
Automated tests & documentation
Conquer the fear

5. Before we start…

6. Do you know who
you will talk to?

7. Do you know who you will
talk to?
• Any personal benefits?
• Any risks?
• Any changes?

8. Do you know who you will
talk to?
• Any personal benefits?
• Any risks?
• Any changes?

9. Do you know who you will
talk to?
• Any personal benefits?
• Any risks?
• Any changes?

10. Change in thinking

11. Architecture

13. ‘Box arrow box arrow cylinder architecture’
@tedneward

14. Monoliths…

15. Monoliths…
… microservices?

16. Source: geek and poke

17. Dependancies

18. Source: geek and poke

19. Tame the
terminology

20. WHY?
WHAT? WHO?

21. WHY?
WHAT? WHO?

22. WHY?
WHAT? WHO?

23. WHY?
WHAT? WHO?

24. Use analogies!

25. What is the business
question I need answer
for?

26. IntegrationData mapping
Dictionaries Frequency
Collisions
Event based
vs. scheduled
Failure strategy
… other

27. System A
System B

28. System A
System B

29. Convince to change
…refactoring

30. What is core
business process?

31. How refactoring will
influence it?

32. How does the new feature influence
the key business process?

33. How refactoring will
influence it?

34. ∞ ÷ 2 ≈ ∞

36. Automated tests

37. Documentation
…it’s outdated just after you
finish it

38. Source: geek and poke

39. Conquer the fear

40. Delete the code!
(unused part of the app)

41. Source: geek and poke

42. Uncertainty causes
fear

43. Uncertainty causes
fear
…let’s measure upfront

44. Uncertainty causes
fear
…and use automatic tests!

45. How?
• Identify what you can possibly ‘delete’
• Measure use of the part that you want to
remove
• Check dependancies
• Hide the part you want to remove and… wait
• Remove

46. How?
• Identify what you can possibly ‘delete’
• Measure use of the part that you want to
remove
• Check dependancies
• Hide the part you want to remove and… wait
• Remove

47. How?
• Identify what you can possibly ‘delete’
• Measure use of the part that you want to
remove
• Check dependancies
• Hide the part you want to remove and… wait
• Remove

48. How?
• Identify what you can possibly ‘delete’
• Measure use of the part that you want to
remove
• Check dependancies
• Hide the part you want to remove and… wait
• Remove

49. How?
• Identify what you can possibly ‘delete’
• Measure use of the part that you want to
remove
• Check dependancies
• Hide the part you want to remove and… wait
• Remove

50. Query response time
Current
2s
Response loading on page
Max number of rows
0,5s
5
After Refactoring
40-60% less
20% more
30% less
WHY?
WHAT? WHO?
Wrap up

51. Questions