[Note: This post is part of a larger series of posts on software architecture and project design. I’m starting with this one because the idea of volatility based decomposition is so important to the process.]
The challenge to adopting volatility based decomposition is largely one of mindset.
The system level architecture is designed upfront so the network of dependent activities can be created against the architecture. Along with the non-software related activities, these activities are used to form the project plan.
Some think you cannot create the architecture upfront because there is “too much that is unknowable.” The mindset in development today is that you must “build it and they will come.”
The conventional mindset associates architecture with the solution space.
The unconventional mindset associates architecture with the problem space.
The problem space is the business and its volatility. The areas of business volatility are areas of business complexity. The volatilities contain all of the nuance. For our solutions to be anti-fragile we build architectures that encapsulate the volatile areas of the problem space, the business volatility.
Functional decomposition is done against a proposed solution. Volatility based decomposition is done against the business. This represents a fundamentally different way of decomposing the architecture.
Some of the differences are outlined in this figure:
Volatility based decomposition is uncomfortable because it’s not how we were trained. Developers are comfortable with functional decomposition.
We naturally think like Ikea instructions: Step 1, Step 2, Step 3, done.
We are taught to think like this and it is deeply ingrained in our culture. We prefer step-by-step navigation rather than reading maps. Step-by-step thinking has it’s place. If making a cake from a box, or putting together an Ikea set, it’s best to just follow the directions (such as they are).
Making a cake and an Ikea set are specific solutions to problems with many solutions. The cake mix and the pre-built furniture do not offer the user any flexibility. Once you purchase the chocolate cake mix, you cannot get a vanilla cake. Once you buy the three shelf unit you cannot have 6 drawers. You are locked into the chosen solution.
Parnas called functional decomposition “conventional decomposition.” When you code using conventional decomposition you are building a single solution. When you architect with functional decomposition you are designing against a single solution, and as a result, the structure of your code represents just one possible solution. The user is given the unit with three shelves whether it’s a good fit or not.
The software architect should strive for solutions that solve a wide array of problems. That allow for some volatility in the way business is done. They should strive for architectures that are resistant or adaptable to change.
Parnas called volatility based decomposition “unconventional decomposition” because it’s use is so rare — it is unconventional. Yet he readily offers the reader an example. The difference between conventional and unconventional is largely mindset.
If we want decide at the last responsible moment between vanilla and chocolate there are many ways to do so. We must recognize and plan for that volatility. The package could offer flavor packages allowing the baker to mix in “vanilla” or “chocolate” or both! We could make cupcakes and offer both flavors allowing the decision to be made at “run-time.”
Ikea offers many sets of shelves and drawers that are “stackable” allowing one to build up units addressing a common volatility. What is key, is understanding which attributes of the business (in this case baking cakes or storing stuff) are volatile.
What is key is having an unconventional mindset.
