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/
   

   View Slide

2. What is Software Architecture?
   •Martin Fowler
   •Software architecture =
   Important
   and hard to change decisions
   Photo: Webysther Nunes
   

   View Slide

3. Consequences
   •Architecture important
   •Architecture hard to change
   •Ideally: No need to change!!
   •Make architecture “future-proof”
   •Note: Fowler did not suggest that.
   

   View Slide

4. My Take
   •Trying to build future-proof architecture:
   very bad idea
   •Don’t do it.
   

   View Slide

5. Real World Story
   

   View Slide

6. A True Story
   •Plan at start:
   Migrate the system module-by-module
   •Prototype to validate migration.
   •Prototype quite expensive.
   

   View Slide

7. A True Story: The Start
   •Project start
   •Learn more about the domain
   •Migration by module makes it impossible
   …to improve support for business.
   

   View Slide

8. A True Story: Result
   •There were other issues, too.
   •Project cancelled
   …and considered a failure.
   

   View Slide

9. Intuitive Lesson Learned
   •Do more research up front!
   •Be more restrict in approving projects!
   •Require a future-proof architecture!
   •IMHO this is wrong.
   

   View Slide

10. Why You Must Work in Iterations
    These [domain] models are never perfect; they evolve.
    Eric Evans
    

    View Slide

11. Why You Must Work in Iterations
    Requirements change. Impact architecture
    

    View Slide

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…
    

    View Slide

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.
    

    View Slide

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!
    

    View Slide

15. How Much Architecture
    Should We Start With?
    

    View Slide

16. Domain Prototyping
    •No technology at the start
    •Easy to iterate
    •Introduce server / database only if needed.
    

    View Slide

17. Domain Prototyping
    •Nothing to work with except for domain logic.
    •Introduce technologies when you really need them
    …based on more information
    

    View Slide

18. Domain Prototyping (German)
    https://software-architektur.tv/2022/09/16/folge134.html
    

    View Slide

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?
    

    View Slide

20. Last Responsible Moment
    •What is the last responsible moment for the migration
    strategy in the example?
    •How risk-adverse are you?
    

    View Slide

21. YAGNI
    

    View Slide

22. YAGNI
    •You Ain‘t Gonna Need It!
    •I.e. do not add functionality until deemed necessary.
    •XP (eXtreme Programming) principle
    

    View Slide

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
    

    View Slide

24. Why YAGNI Might Be Bad
    •It makes no sense to ignore information.
    •So: Really ignore a potential requirement?
    •Is YAGNI too radical?
    

    View Slide

25. Goal: Peak
    Project Goal
    Future-
    proof
    Architecture
    Successful migration
    to a great,
    all modularized system.
    

    View Slide

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.
    

    View Slide

27. Reality
    Architecture
    Too often:
    Magic
    In particular for migrations.
    What value will you generate in the next months?
    

    View Slide

28. Trying to be Future Proof:
    Bad Idea?
    

    View Slide

29. Hypothesis
    •It is not the initial architecture that causes problems
    •It is that we did not adjust it in time
    

    View Slide

30. Aim: “Future-proof Architecture”
    •Lots of thought
    •Lots of effort
    •Attempts to be future-proof
    

    View Slide

31. Change “Future-proof Architecture”
    Should be possible to
    put this in the future-
    proof architecture.
    Let’s see…
    Here is a change…
    

    View Slide

32. End
    

    View Slide

33. Aim: Iterative Architecture
    •Let’s build an architecture for the first
    step!
    •Let’s see how far it takes us!
    

    View Slide

34. Change Iterative Architecture
    Does it invalidate the
    architecture?
    No
    Here is a change…
    Let me put it in there.
    

    View Slide

35. Change Iterative Architecture
    Does it invalidate the
    architecture?
    Yes
    Here is a change…
    Let me change the
    architecture.
    

    View Slide

36. Prototype
    •Would a prototype make you stick to the
    architecture?
    •You might be too (emotionally) invested.
    •Admitting that you wasted money: hard.
    

    View Slide

37. Being emotionally invested in
    your architecture is a bad
    idea!
    

    View Slide

38. Concept to be Future Proof:
    Don’t Try to be Future Proof
    

    View Slide

39. Result
    •Architecture based on historic mistakes.
    •Architecture supports current needs well.
    •I.e. architecture makes business sense
    •Architecture probably not aesthetical.
    

    View Slide

40. View Slide

41. Build the Highest Stack Possible
    

    View Slide

42. Structure
    

    View Slide

43. Structure
    •Structure: important part of architecture
    •Goal: Make the systems easy to change
    

    View Slide

44. Is This a Great Structure?
    Data
    Fetching
    Service
    Business Logic Data
    Service
    Write Workflow
    Service
    UI Aggregation
    Service
    API Gateway
    

    View Slide

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

    View Slide

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
    

    View Slide

47. Is This a Great Structure?
    Data
    Fetching
    Service
    Business Logic Data
    Service
    Write Workflow
    Service
    UI Aggregation
    Service
    API Gateway
    

    View Slide

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
    

    View Slide

49. Would you rather show /
    discuss something technical or
    business-related if asked for
    the architecture?
    

    View Slide

50. Order Process
    Invoicing
    Process
    Better
    Shipping
    

    View Slide

51. Concept to be Future Proof:
    Let the Domain Drive the
    Design
    

    View Slide

52. Technologies
    

    View Slide

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?
    

    View Slide

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
    

    View Slide

55. Prepare for Technology Changes?
    •How often do you change the technology?
    •New technologies also influence logic e.g. mobile
    

    View Slide

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?
    

    View Slide

57. Conclusion
    

    View Slide

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.
    

    View Slide

59. Conclusion
    •Let the domain drive the design!
    •Get used to the limited lifespan of technologies!
    

    View Slide

60. https://software-architektur.tv/2022/10/28/folge140.html
    

    View Slide

61. View Slide

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
    

    View Slide