$30 off During Our Annual Pro Sale. View Details »

No Future-Proof Architecture

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.

Eberhard Wolff

October 11, 2022
Tweet

More Decks by Eberhard Wolff

Other Decks in Technology

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 [email protected]
    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