If you’ve ever talked with anyone in construction you may have heard the saying that concrete is guaranteed to do two things. It’s guaranteed to get hard, and its guaranteed to crack.

Software systems have a similar guarantee. They are guaranteed to get constructed the first time only once, and they are guaranteed to change. Okay, so maybe that is a rather pitiful analogy, albeit a true one.

As a Software Engineer, what important lesson should we gleam from this employment perpetuating realization? We know whatever system we have built or we are in the process of supporting is very likely to continue to be modified in the future. Are the systems we are building or extending designed for change?

A very typical, if not uniformly followed approach to system design is to decompose a system functionally. Our user stories (or Functional Requirements Specification document) indicate we have features A, B, and C. So, we create an A component, a B component, and a C component that implements those features. Now A relies on both component B and C for it to function properly and likewise B relies on C. A few weeks into the development of these components the Product Owner stops by and informs us that feature A needs to change just a bit. We overlooked 17 input values that must be incorporated. After a few frustrating moments we pull ourselves together and start reviewing the rework necessary to accommodate this late breaking change. All 3 components, the client, and the data model need to change. It’s not all bad news though, we can salvage about 35% of the work completed so far. That means we just have to add the new functionality for the new 17 input values and refactor 65% of components A, B, and C to handle the new requirements. Sound familiar? Ever been there? Perhaps in the past week or month?

Wouldn’t it be nice if we knew of a way to design our systems that embraced change? A way that resonates with the change and doesn’t cause the preverbal domino effect. What if we approach it in such a way that the design is entirely focused on encapsulating areas of change?

The good news it this has been done for over a decade by the IDesign.net architects. They refer to this approach as “Volatility based decomposition”. Using this methodology, we compose features by the integration of components that collectively satisfy the underlying use case. As a starting point the system is decomposed along two axes of volatility.

  1. At the same customer over time
  2. At the same time across customers

Considering the A, B, and C features, what could change across customers? What could change over time for a given customer? Designing components that encapsulate these areas of volatility will enable us to produce these feature by integrating these components. Therefore, when a change does occur we have essentially only one place to make it.

Here’s a video of Juval Lowy from IDesign explaining this approach in much more detail.

Related Posts


  1. One other point I would like to add is this (With reference to axes of volatility analogy)

    Design for change could be better accomplished by stepping into the shoes of the customer and his business in the current and near future changes of business environment. This way our system is designed for possible change at the outset. Atleast when the change happens we are not surprised by it.

  2. That’s a very good point Satish. Volatility is definitely dependent on the business needs, the environment, and even the infrastructure of the organization or product. Taking into account what changes each key stakeholder (CEO, CTO, CIO, VP of Sales, VP of Marketing, VP of Product, etc.) will have now or in the future is essential to ensuring your design meets these needs.

    Jim Kudirka

Leave a Reply

Your email address will not be published. Required fields are marked *