No Future-Proof Architecture

Architecture: This is supposed to be the stable element! And choosing the right architecture ensures that the software can be developed and maintained in the future! What initially appears to make sense often in reality turns out to be the first step toward an architectural failure. Unfortunately, when requirements, insights, or technologies change, the architecture must change as well. How can it then be future-proof? This presentation shows how the paradox can be resolved, and maybe not future-proof architecture - but long-term project success.

Transcript

1. There is no such thing as future-proof architecture! Here is how to prepare for it. Eberhard Wolff Head of Architecture https://swaglab.rocks/
2. What is Software Architecture? •Martin Fowler •Software architecture = Important and hard to change decisions Photo: Webysther Nunes
3. Consequences •Architecture important •Architecture hard to change •Ideally: No need to change!! •Make architecture “future-proof” •Note: Fowler did not suggest that.
4. My Take •Trying to build future-proof architecture: very bad idea •Don’t do it.
5. Real World Story
6. A True Story •Plan at start: Migrate the system module-by-module •Prototype to validate migration. •Prototype quite expensive.
7. A True Story: The Start •Project start •Learn more about the domain •Migration by module makes it impossible …to improve support for business.
8. A True Story: Result •There were other issues, too. •Project cancelled …and considered a failure.
9. Intuitive Lesson Learned •Do more research up front! •Be more restrict in approving projects! •Require a future-proof architecture! •IMHO this is wrong.
10. Why You Must Work in Iterations These [domain] models are never perfect; they evolve. Eric Evans
11. Why You Must Work in Iterations Requirements change. Impact architecture
12. Why You Must Work in Iterations Actually, we all learn how to architect! My approach to architecture changes. That is why we do talk, go to conferences…
13. The Real Lesson Learned •You will always learn about the domain! •Requirements change. •We learn how to architect. •I.e. there will always be something to improve. •Always - not just at the start.
14. Recommended Lesson Learned •Hypothesis: Not changing the architecture when we need to is our core problem. •Be prepared to change the architecture. •Be careful with proofing the architecture! •But: don’t be intentionally stupid!
15. How Much Architecture Should We Start With?
16. Domain Prototyping •No technology at the start •Easy to iterate •Introduce server / database only if needed.
17. Domain Prototyping •Nothing to work with except for domain logic. •Introduce technologies when you really need them …based on more information
18. Domain Prototyping (German) https://software-architektur.tv/2022/09/16/folge134.html
19. Last Responsible Moment •Domain prototyping is quite radical. •Needs courage. •What is the last responsible moment for each decision? •How much do you have to decide at the beginning?
20. Last Responsible Moment •What is the last responsible moment for the migration strategy in the example? •How risk-adverse are you?
21. YAGNI
22. YAGNI •You Ain‘t Gonna Need It! •I.e. do not add functionality until deemed necessary. •XP (eXtreme Programming) principle
23. Why YAGNI Was Needed •Anti BDUF brain washing •Big Design Upfront •There is no way to predict what is really needed! •So a sophisticated BDUF is a bad idea
24. Why YAGNI Might Be Bad •It makes no sense to ignore information. •So: Really ignore a potential requirement? •Is YAGNI too radical?
25. Goal: Peak Project Goal Future- proof Architecture Successful migration to a great, all modularized system.
26. Architecture IMHO What is the next step? How can we implement the current requirements and approach the goal e.g. a better modularization? How do we overcome the next obstacles? Current requirements Don’t ignore Focus Goal: Peak Project Goal Successful migration to a great, all modularized system.
27. Reality Architecture Too often: Magic In particular for migrations. What value will you generate in the next months?
28. Trying to be Future Proof: Bad Idea?
29. Hypothesis •It is not the initial architecture that causes problems •It is that we did not adjust it in time
30. Aim: “Future-proof Architecture” •Lots of thought •Lots of effort •Attempts to be future-proof
31. Change “Future-proof Architecture” Should be possible to put this in the future- proof architecture. Let’s see… Here is a change…
32. End
33. Aim: Iterative Architecture •Let’s build an architecture for the first step! •Let’s see how far it takes us!
34. Change Iterative Architecture Does it invalidate the architecture? No Here is a change… Let me put it in there.
35. Change Iterative Architecture Does it invalidate the architecture? Yes Here is a change… Let me change the architecture.
36. Prototype •Would a prototype make you stick to the architecture? •You might be too (emotionally) invested. •Admitting that you wasted money: hard.
37. Being emotionally invested in your architecture is a bad idea!
38. Concept to be Future Proof: Don’t Try to be Future Proof
39. Result •Architecture based on historic mistakes. •Architecture supports current needs well. •I.e. architecture makes business sense •Architecture probably not aesthetical.
41. Build the Highest Stack Possible
42. Structure
43. Structure •Structure: important part of architecture •Goal: Make the systems easy to change
44. Is This a Great Structure? Data Fetching Service Business Logic Data Service Write Workflow Service UI Aggregation Service API Gateway
45. Future-proof Structure •Hypothesis: We cannot predict changes •Hypothesis: Some changes require fundamental adjustments to the structure •How can systems be future proof then???
46. Domain-driven Design (DDD) •Let the domain drive the design! •I.e. built software specific for the domain! •Not generic •Hypothesis: will support changes in the domain best •No unneeded flexibility
47. Is This a Great Structure? Data Fetching Service Business Logic Data Service Write Workflow Service UI Aggregation Service API Gateway
48. What DDD Means •Can you tell which domain the architecture is for? •Can you use the architecture for a self-driving car or a video game? •My experience: Technical architecture much too common
49. Would you rather show / discuss something technical or business-related if asked for the architecture?
50. Order Process Invoicing Process Better Shipping
51. Concept to be Future Proof: Let the Domain Drive the Design
52. Technologies
53. Technology: Means to an End •What is the business value of modern technologies? •Easy to change / maintain? •Might impact qualities. •E.g. no security updates anymore?
54. Future-proof Technologies •Software development has a constant stream of new technologies •Old technologies might have known security issues •So: Prepare for technology changes! •I.e. technology-independent code
55. Prepare for Technology Changes? •How often do you change the technology? •New technologies also influence logic e.g. mobile
56. Prepare for Technology Changes? •Most consulting gigs: change technology and logic •Logic badly structure and hard to maintain •Do you want to keep the code? And use a new technology?
57. Conclusion
58. Conclusion •We cannot build “future-proof” architectures. •Future-proof is about adjusting to change. •Aiming at “future-proof” might lead to avoiding needed adjustments. •Avoiding needed adjustments leads to a mess.
59. Conclusion •Let the domain drive the design! •Get used to the limited lifespan of technologies!
60. https://software-architektur.tv/2022/10/28/folge140.html
62. Send email to WeAreDevs2023@ewolff.com Slides + Sample Microservices Book DE / EN + Sample Practical Microservices DE/EN + Sample of Continuous Delivery Book DE Powered by Amazon Lambda & Microservices EMail address logged for 14 days, wrong addressed emails handled manually