Enabling Innovation: The Importance of Software Architecture
--
A system without clear architecture is destined to become a legacy system after enough changes in the requirements over time.
Once upon a time, there was a Product Requirement Document..
It had a lot of nice clear requirements that described a product and fulfilled all the wishes of the customers.
The product was expected to grow over time, with more requirements and features. The expectations after some time looked like this:
Feature requests kept coming and the system was growing and changing. After yet another feature request the team owning this product realized that in reality the codebase and architecture, possibly even the product itself ended up looking more like this:
In order to enable innovation we need to take into consideration not just the present but the future. The challenge is not coming up with Architecture and System design, which should only take a few days, but finding the core use cases and identifying areas of volatility.
Volatility — Liability to change rapidly and unpredictably.
To be able to identify those areas first we need to capture required behaviour, not functionality. You might be wondering “What’s the difference?” required behaviour describes how a user would interact with the system — use cases — while functionality is how the system behaves.
“If you think good architecture is expensive, try bad architecture” — Brian Foote and Joseph Yoder
The iDesign method
Volatility-based decomposition is the bases of the iDesign method, a method that can help engineers build Architecture and encapsulate change in their design. It involves a few key steps. The first is identifying the core use cases. Most systems have 2 to 5 of them, not more.
For example, humans have one core use-case — Survive.
To identify core use cases you can think of how you would describe the product in an elevator pitch.
Volatility
There are two axes of volatility, in other words, two sources of change, for a product. It is either the same customer over time (new functionality being needed over time for a product) or different customers at the same time (different customers have different use cases for the same system — for example, there are a lot of different use cases for a workflow system, every company has different workflows and expectations when it comes to implementation).
Example of volatility
Imagine a house and the things that might change regarding that house with the same “user” (Axis 1). Here’s a list of things we could consider:
- Rearrange furniture 🛋
- Change appliances — New TV 📺
- Appearance — Paint rooms 🖌
- Occupants — Guests, kids, etc. 👨👩👦👦
- Utilities — No more dial-up internet 🌐
Looking at Axis 2, so a different user but at the same time:
- Structure of the house 🏠
Other houses might have a different structure but they are still a house - Neighbours 👨👩👧
If we copy the same house to another city, it’s not the same house anymore - City 🏙
Different city different regulations/taxes etc.
The likelihood of these changes is very low for the same house.
Important note, there is no component for cooking or kitchen.
In a volatility-based decomposition, the required behaviour is accomplished by an interaction between the various encapsulated areas of volatility. — Righting Software — Juval Löwy
Cooking is an interaction between the occupants of the house, appliances, and utilities.
Solution VS Requirement
Is Cooking a requirement for a house?
No… Then what is it?
Cooking is a possible solution for the requirement of feeding the people in the house. You can satisfy the feeding requirement by ordering pizza or taking the family out for dinner as well.
But now back to software
Example of Areas of Volatility in our Antivirus module
Our internal antivirus solution has two core use cases, detect viruses and audit files. We want to scan files uploaded into our system and allow users to audit the files that have been flagged.
- Volatility Axis 1:
- Where are the files coming from
- Is the scope only uploaded files or also downloaded
- How do we scan files
- Where do we store the information about the scans
- How do we approve/deny files - Volatility Axis 2:
- What kind of files are we scanning
- How to expose information about the state of the files
Why do we do all this?
Would you build a house like we build Software?
Key takeaways
- Investing time and effort in architecture is the best way to ensure we build for the future
- We need to keep ever-changing requirements in mind when we are designing a system
- To be truly agile we need more than just practices, we need to plan for change
- Is software different from any other engineering discipline and if not why don’t we hold ourselves to the same standards?
