Volatility decomposition
There are many ways to design software. According to the author Juval Löwy, using volatility-based decomposition is the perferred strategy, as he talks about in his series of #Righting software.
But make no misstake. This is no “silver bullet”. As Löwy puts it, “You cannot add value without sweating” (Allure of the free lunch#), and doing volatility decomposition requires you to toil and sweat a lot.
Primary goal: Encapsulate change.
Surviving a hand-grenade of changes
Imagine your system. If you were to hand a live and fused grenade to one of its components, what will happen to the rest of the system?
Given you’ve designed by #Functional decomposition, the result will most probably be that the component explodes, and fragments of the explosion shatters across the entire system, damaging seemingly unrelated components.
Now a perfectly designed system that was designed by volatility-based decomposition can be compared to a set of vaults. You toss a grenade into one of the vaults (components) and the component is destroyed, but the shrapnel is contained by the walls of the vault.
The grenade in this case are changes.
This is what you want to achieve with volatility-based decomposition. You want to encapsulate change.
Where to start
Before you do anything, you must bein with Finding the nature of your buisness#.
Continue with Finding a system’s volatilities#.
Complete the overall design by Finding a system’s components#, based on the volatilities from step 2.
How to get good
The answer is obvious: practice, practice, practice!
But there are some good tips and tricks you can read on about Getting good at volatility decomposition#.
Issues with volatility-based decomposition
There are plenty, and all originates from the fact that it’s more difficult and requires more sweating than #Functional decomposition.
Universal rule
One of the favorite aspects of volatility-based decomposition, according to Juval Löwy, is that these rules and principles work universally when designing.
There’s no small footnote specifying that this “Does not apply to software” (Designing software vs hardware).
Everything is designed through volatility decomposition, because while it’s the difficult route, it is also the only resilient one.
References
- J. Löwy (January 27, 2021), “Righting Software - System Design” [Workshop], NDC London 2021.
