Devoxx Belgium 2025 - Making significant Software Architecture decisions

Making significant Software Architecture decisions - presented at Devoxx Belgium 2025.

1. [email protected]
Making significant software architecture decisions
Bert Jan Schrijver
@bjschrijver.dev

2. Bert Jan Schrijver
L e t ’ s m e e t
@bjschrijver.dev

3. Let’s talk about software.

4. What is software architecture?

5. Software architecture == making decisions

6. It depends.Source: https://static.wikia.nocookie.net/matrix/images/f/fb/Architect.png/revision/latest?cb=20110515094801

7. On what?!!

8. •”We’ve always done it like this”
•“We don’t want to do depend on <x>”
•“We need to be future proof”
•Because the product owner wants it
•Because the architect wants it
Bad (reasons for) architecture decisions

9. Source: https://7216-presscdn-0-76-pagely.netdna-ssl.com/wp-content/uploads/2011/12/confused-man-single-good-men.jpg So how do you make architecture decisions?

10. It depends.Source: https://static.wikia.nocookie.net/matrix/images/f/fb/Architect.png/revision/latest?cb=20110515094801

11. On what?!!

12. •Start with the 5 W’s
•Why are we even here as architects?
•To enable one or more teams to build something
•Why?
•To help a business reach their goals
•Why?
•Because that’s why we even have a job !
➡ Every architecture decision has a business component
Input for architecture decisionsBackground source: GR Stocks on Unsplash

13. •Requirements
•Functional
•Non-functional / quality attributes
•(Business) constraints
•Which of these impact our architecture the most?
•But: we can never fully fulfil them all
•So we always need to consider
trade-offs between requirements & constraints
Input for architecture decisionsSource: https://medium.com/@jeffwhelpley/the-problem-with-shared-code-124a20fc3d3b

14. Quality attributes (non functionals)
•Also known as “the ilities”
•Which quality attributes do you now?
•Performance, security, availability, reliability
•In general: ISO 25010

15. ISO 25010

16. Which requirements or constraints
are the most important?

17. It depends.Source: https://static.wikia.nocookie.net/matrix/images/f/fb/Architect.png/revision/latest?cb=20110515094801

18. On what?!!

19. On your business.
But how do you prioritise?

20. Trade-off analysis for software architectureSource: https://images.unsplash.com/photo-1515611926865-4fcb1c2ce28d?ixlib=rb-4.0.3&dl=kelly-sikkema-kxtB2TFBF2g-unsplash.jpg&q=80&fm=jpg&crop=entropy&cs=tinysrgb
•Gather requirements,
quality attributes & constraints
•Select potential solutions
•Discover and weigh trade-offs
•Pick the best fitting solution
•Document decision
•Validate afterwards
Described in “Software Architecture:
The Hard Parts” by Ford, Richards et al

21. Source: https://images.unsplash.com/photo-1515611926865-4fcb1c2ce28d?ixlib=rb-4.0.3&dl=kelly-sikkema-kxtB2TFBF2g-unsplash.jpg&q=80&fm=jpg&crop=entropy&cs=tinysrgb What is a trade-off?Source: Michael Carducci’s presentation “A Model for Holistic Software Architecture” at Dev2Next, Colorado, october 2025

22. •Security vs. usability
•Configurability vs. maintainability
•Availability vs. cost
•Performance vs. cost
•Performance vs. maintainability
•Runtime configuration vs. robustness
Examples of trade-offsBackground source: DALL·E

23. Every architecture decision is a trade-off

24. 24
Trade-off analysis example

25. Example: tradeoff analysisSource: Neal Ford - Modern Trade-off Analysis for Software Architecture - DDD Europe

26. Example: tradeoff analysisSource: Neal Ford - Modern Trade-off Analysis for Software Architecture - DDD Europe

27. Example: tradeoff analysisSource: Neal Ford - Modern Trade-off Analysis for Software Architecture - DDD Europe

28. It depends.Source: https://static.wikia.nocookie.net/matrix/images/f/fb/Architect.png/revision/latest?cb=20110515094801

29. On what?!!

30. Example: tradeoff analysisSource: Neal Ford - Modern Trade-off Analysis for Software Architecture - DDD Europe

31. Which requirements
and tradeoffs
should you consider?

32. •Relevant quality attributes
•See ISO 25010
Technical factorsSource: http://www.nasa.gov/images/content/218652main_STOCC_FS_img_lg.jpg

33. •Developer experience
•Learning curve
•Tool & IDE support
•Documentation &
support
•Integration with current
landscape
•Conway’s law
Organisational factors
•Adoption, popularity &
expertise:
•own team
•industry
•Long-term viability
(Active development,
community & ecosystem)

34. Business factorsBackground source: DALL·E
•Cost
•Infrastructure
•Licenses
•Support
•Engineers
•TCO
•Time-to-market
•Migration cost vs
benefits after
migration
•Productivity
•Regulatory reqs, legal,
IP risk
•Exit strategy

35. How to figure out which tradeoffs matter?
•Talk to business / stakeholders
•Force them to choose / prioritise
•Ride the architect elevator
•(Gregor Hohpe - https://architectelevator.com/)
•Figure out what matters to them

36. When not to compromise?
When risking irreversible damage
to your business.Photo: Dave Lehl

37. Documenting
architecture decisions

38. •Project documentation vs system
documentation
•What happens when you don’t document?
Documenting architecture decisions

39. •Describes:
•Title
•Context
•Status
•Decision
•Options considered
•Consequences
Architecture decision record (ADR)

40. •Write ADR’s for "architecturally significant"
decisions
•Store them in a central place (Git, for example)
•ADRs are immutable!
•Encourage others to read (& write) ADR’s
•Templates & tools:
•https://adr.github.io
•https://github.com/npryce/adr-tools
•https://github.com/thomvaill/log4brains
Working with ADRs

41. Validating your architecture

42. •Once development starts, how do you know the
system stays in conformance with the architecture?
•This is where Fitness functions come in
•Coined by Rebecca Parsons
•Defined as:
An architectural fitness function provides an objective
integrity assessment of some architectural
characteristic(s).
Validating your architecture

43. •Examples of Fitness function evaluation:
•“We have 17 violations of <x> which is within our
tolerable range of up to 20 violations. So we're good
for now. Let's talk about changing the tolerable range
to allow only 10 violations for the next iteration”
•“We found two unwanted dependencies between the
modules. We must remove these dependencies.”
Architectural fitness functions

44. •Automating Fitness functions:
•ArchUnit tests
•Load tests
•Alerts on metrics / monitoring
•.. and more
•A failing fitness function is a conversation starter
with the development team ( -Neal Ford)
Architectural fitness functions

45. Summary

46. •Gather requirements & constraints
•Brainstorm for possible solutions
•Consider technical, organisational and business
factors
•Discover and weigh trade-offs
•Pick the best fitting solution
•Document the decision (via ADR’s)
•Validate afterwards (via Fitness functions)
Significant software architecture decisions

47. How to make architecture decisions?
It depends.

48. On the informed
trade-offs you make.Source: https://images.unsplash.com/photo-1515611926865-4fcb1c2ce28d?ixlib=rb-4.0.3&dl=kelly-sikkema-kxtB2TFBF2g-unsplash.jpg&q=80&fm=jpg&crop=entropy&cs=tinysrgb

49. Source: https://cdn2.vox-cdn.com/thumbor/J9OqPYS7FgI9fjGhnF7AFh8foVY=/148x0:1768x1080/1280x854/cdn0.vox-cdn.com/uploads/chorus_image/image/46147742/cute-success-kid-1920x1080.0.0.jpg THAT’S IT.
NOW GO KICK SOME ASS!

50. Questions?
@bjschrijver.dev

51. Thanks for your time.
Don’t forget to rate this talk!
All pictures belong
to their respective
authors
@bjschrijver.dev
meetup.com/isaqb-nl