I wanted to collect some useful resources on software architecture, centering around Volatility-Based Decomposition.
Quick Summary of Volatility-Based Decomposition
Much if not most of today’s software industry relies on functional decomposition: if you can break a problem down into a flowchart of functions, you would now go off and design out each box of the flowchart as its own modular unit. And what you would find is that when the requirements change (possibly before the first release), you would have to re-design to accommodate the changes.
With Volatility-Based Decomposition you look for ways to identify areas where change can come (typically across customers, or over time) and focus on encapsulating these first. Then when things change, you are ready for it: less to change, less interface breakage, less opportunity for regression issues, etc.
The Software Project Hierarchy of Needs — Juval Löwy demonstrates parallels between Abraham Maslow’s Hierarchy of Needs and the realm of software. IDesign’s courses are intended to help people master the various levels of the pyramid: Project Design Master Class for the lower levels, Architect’s Master Class for the middle levels, and the upper level, focused on technology, is addressed with the WCF Master Class, though of course other technologies could implement a good architecture (how well you can do so is a separate matter).
Escaping Appland — Michael “Monty” Montgomery speaks to microservice architectures as opposed to the pervasive dead-end that is app-centric development.
Webcasts and Videos on Software Architecture
The Zen of Architecture — A webcast from Juval Löwy of IDesign, in which he discusses volatility-based decomposition. He also discusses it in this earlier webcast entitled Volatility-Based Decomposition. Bear in mind that both are just tiny hour-long pieces, as compared with IDesign’s intense week-long courses.
Agile Architecture Part 1 – Allen Holub and Agile Architecture Part 2 – Allen Holub — Allen Holub talks about some of the better Agile approaches to software architecture. Whether or not you agree with his overall opinions on Agile (such as the customer-in-the-room approach), he does a great job of covering the SOLID principles in code (with Java and C# examples).
When you listen to the IDesign webcasts, it may seem as though no one else is doing volatility-based decomposition, but a few visionaries in the industry adopted it (or something similar) beforehand.
Predecessors and Relatives to Volatility-Based Decomposition
In 1972 David Parnas, while at Carnegie-Mellon University, wrote a paper called “On the Criteria To Be Used in Decomposing Systems into Modules” for the ACM. He discusses a concept he calls information hiding (what we now refer to as encapsulation) and concludes:
“…it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.”
The emphasis is mine: by likely to change he means what we call volatility. Hence, even in 1972 this style of design had been recognized, but for whatever reason most of industry (and academia) missed it.
Two decades later, in 1994 Robert Martin wrote an article entitled Stability in which he talks in similar terms to Löwy, discussing volatility and stability as they relate to dependency and responsibility, and he defines the Stable Dependencies Principle (SDP):
The dependencies between packages should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than it is.
Similarly, the IDesign Method stipulates that the upper layers of architecture are increasingly volatile.
By 2012 Robert Martin developed Clean Architecture, which incorporates ideas from several others including Ivar Jacobson’s BCE (1992), Alistair Cockburn’s Hexagonal Architecture (aka “Ports-and-Adapters”) from 2005, Steve Freeman’s and Nat Pryce’s Growing Object-Oriented Software (2009), Jeffrey Palermo’s Onion Architecture (2008), and James Coplien’s DCI (Data, context, and interaction) (2010, book here).
The layers from Clean Architecture are similar to those presented in the IDesign Method. Subjectively I find the Method to be more elegant, and almost familiar, in that it defines certain layers in a top-down view, although it differs from the familiar in terms of how you determine the content of those layers: by volatility-based decomposition rather than functional decomposition.
This section has some information on Project Design. Project Design (as taught in the Project Design Master Class) should not be confused with Project Management. The two are related but Project Design is a means to quantify risk, account for it, produce solid estimates, identify potential staffing levels, logistically plan out multiple options for implementation, and present these to management.
Webcasts on Project Design
I personally recommend watching the 2nd, as it is newer.
A Modular Approach to Development — Another webcast from Juval Löwy which covers some of the project management issues. He talks about the importance of planning around the critical path, identifying how well a project is behaving compared with the project plan, and both how to react, and how not to react, to often-occurring scenarios.
Software Project Design — In this intense webcast Juval Löwy shares his approach software project design, along with his unique insight for delivering software on schedule and budget.