The following method of decomposing a system I learned back in 2013 while being employed at my previous employer and I saw the immense benefits it had on the organization, it is called volatility based decomposition, it is way to break a system up into components that can absorb change and result in a stable system. One of our architects at the organization went on the IDesign master class and implemented this method at the organization with massive success. This is my breakdown and explanation of how it works, It builds on SOLID principles and can be viewed as the opposite of functional decomposition. For those that want to learn more detail ,go to YouTube and search for Juval Lowey or purchase his Righting Software book.

Download the power point containing the slides and images for volatility based decomposition here.

Advantages:

• Encapsulates the use case. One use case will not affect another. No bugs due to someone working in another part of the system.
• The design encapsulates change. (Absorbs changes in requirements easily).
• Implementing variations of use cases / requirements are quick to do.
• Each component can be isolated and tested.
• Troubleshooting of performance issues are easy due to the components based design.
• Speed of delivery goes up as the system matures and more components are build that can be re-used.
• Cloud cost can be managed as the only load baring components can be isolated and scaled.
• Attempts to control the amount of traffic to and from the client.
• As the development order of components and the dependencies are known upfront it can be used for accurate project planning and costing.
• Results in a very stable system.

Disadvantages

• The decomposition is not easy or quick.
• Requires a skilled architect.
• Takes longer to implement.
• Development cost is high.
• Requires developers to follow a implementation pattern.
• Slow to deliver any features in the beginning.
• Requires service contracts to be documented. Documentation will not only need to cover the inputs and outputs but also the internal behavior of the services.

Who should use volatility based decomposition?

Volatility based decomposition should be used for applications that:

• Has requirements that change often.
• Will be maintained for many years even decades.
• Where the system is dependent on 3rd parties or sub systems.
• The development time is open ended.
• Requires a level of security between the front end and the back end.
• Requires the ability to isolate use cases.

In this example I will show how to do a Volatility based decomposition.

Client requirements.

A system design always start with user requirement. Below are some user stories that I made up from which I will do a system design.

1. As a end user I need to be to register myself on a android or IOS mobile device. Part of the registration will allow me to subscribe to receiving text message alerts about future events. I should be able to login and browse for music events at various locations and make a booking to attend it. My only payment option will be to use Paypal.
2. As a employee I need to login to web based system so that I can load, add, update and delete music events. End users should receive a text message when additional music events get added at a later date.

if you have a BA then the system requirements will be mapped out in a document for you and you should receive a use case diagram.

Use case diagram.

For the architect this is the document where it all begins. If you don’t have a BA or did not receive a document like this you will have to draw it up yourself and have it validated by the client. And always remember requirements always change. It is important to ask many questions at this level and don’t start a design until you are comfortable that the use case is complete.

Use case and Volatility based decomposition

• Identify the core use cases of the business.
  These are use cases without which the company can not do business at all.
  
• Identify the core services.
  Core use cases are the activities that a business can not afford to go down or fail. It needs to be up 99.9% of the time and often also will bare most of the load.
  • Break / group these use cases into services. Ideally you do not want more than one core use case in a service. If one core service fail the rest must be unaffected.
  • Name the services as close to the core use case as possible.

Use cases by themselves are volatile as they will change with time and therefor they should be encapsulated. Do no spread a use case over more than one service.

• Identify 3rd party providers.
  Why code something if a 3rd party provider can provide the functionality.
  
• Identify non core use-cases and their services.
  These are use cases that can go down for 4hrs in a day and the business can function without it for that period of time. Often companies will swear that all their use cases are critical but in reality they are not, in those situations the architect will have to use his own judgement.
  I Identified only one non core use case from the use case diagram.
  • Music Events Maintenance or Administration.
• Build a static view.
  Next you build a static view. Showing the layout of the components. As architect you can start to make technology decisions here. I have decided that we will be using MySQL for this example.I have decided to give each of the core services its own database.
  • Because the Music Events DB has admin and potentially high read operation on it I have decided;
    • For reliability all admin operations will be applied only be done to the master database.
    • The Master will sync to the Slave DB’s.
    • For high availability all read operation will be done only via the slave DB’s.
• Identify the volatilities.This is a very important step and probably the most difficult to get right. Volatilities are things in the requirements that could potentially change. These are often the things clients swear will never change but then they do. There is no real method that can be followed to identify these items but a good way to find them is to look for any concrete decisions very similar to hard coding values.I Identified the following volatilities.Login – The requirements does not cover how a client will login. Also does no cover if a custom login method will need to be written or if a 3rd party identity provider will need to be used.
  • Type of Events – Chances are that the system will have to deal with other types of events in the future other than just music.
  • Ways to browse events by – At the moment users can browse by location but they might need to browse by date or artist in the future.
  • Payment gateway – Right now the client has identified that PayPal is the only pay method. This is very likely to change.
  • Communication type – At the moment the client requires that we send text messages but this might change to include email in the future.
  • Unknown notification types – When communication is sent – Right now we will only notify users of future events but we might require users to be notified if a booking was successful as well.
  • Changing Resource – Resources and subsystems can potentially change and therefor we will need to encapsulate the resources access.

 

• Adjust the design to cater for volatilities.
  • Login – Decided to use Identity Provider.
  • Type of Events – Adjust the design to use Events instead of MusicEvents. Make sure to encapsulate in a service.
  • Ways to browse events by – Make sure the Browse by variations are encapsulated in a service.
  • Payment gateway – Introduce a new client, Payment Gateway to encapsulate this change. The reason for this being a new client is because the communication will mostly happen client side.
  • Communication type – Introduce a communication service to encapsulate this volatility.
  • Unknown notification types – Introduce a message bus. New Communication service to listen for events. This will allow us to handle the change of notifications.
  • Resource encapsulation – Encapsulate the access to each resources or subsystem. This allows the developer to hide the technology used for accessing the resources from the consumer. If change occur in the resources the change will be contained.

One can stop at this level and you would have a pretty robust design but it is possible to take it further by analyzing each service for further volatilities within the use case. Beware of gold plating from this point onward, it is easy to add unneeded complexity.

I am not going to cover the further volatility steps in detail but the next items to identify per use case are; Engines and Utilities. These are the re-usable components between the use cases. Read more about them under the topic Building blocks of an application

Call Chain

The next step of the architect is to take one of the use case activities and map it out over the static view to create a call chain diagram. As the architect you will have to consider the interaction mode and protocol. Synchronous or Asynchronous. Http, Tcp or Service Bus.

The call chain diagram shows:

• which components participate in a use case.
• what calls are used.
• which calls need to be synchronous and asynchronous.

To simplify the diagram I will be replacing the different types of clients with a block called client.

From this diagram you can see there is a single call to the service. Compare this to functional decomposition. Some of the magic here is in the implementation.

As in the functional decomposition I added the 2nd call to make a booking. What you can observe from this call is that the there are more components at play and this is to encapsulate the volitilities as to limit the change when a change in requirements happened.

Summary

Volatility based decomposition is much harder to do and takes time to decompose and implement but the result is an application that is stable and handles the changes in requirements with ease. In the next article I will continue and show how this design allow the Microservices to control the UI.