Tweet
Tweet

Slide 1

Slide 1 text

There is no such thing as future-proof architecture! Here is how to prepare for it. Eberhard Wolff Head of Architecture https://swaglab.rocks/

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Real World Story

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Why You Must Work in Iterations Requirements change. Impact architecture

Slide 12

Slide 12 text

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…

Slide 13

Slide 13 text

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.

Slide 14

Slide 14 text

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!

Slide 15

Slide 15 text

How Much Architecture Should We Start With?

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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?

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

YAGNI

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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.

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Trying to be Future Proof: Bad Idea?

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

End

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Being emotionally invested in your architecture is a bad idea!

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

Build the Highest Stack Possible

Slide 42

Slide 42 text

Structure

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Future-proof Structure •Hypothesis: We cannot predict changes •Hypothesis: Some changes require fundamental adjustments to the structure •How can systems be future proof then???

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

Order Process Invoicing Process Better Shipping

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

Technologies

Slide 53

Slide 53 text

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?

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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?

Slide 57

Slide 57 text

Conclusion

Slide 58

Slide 58 text

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.

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

No content

Slide 62

Slide 62 text

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