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.
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