by Russ Miles & Sylvain Hellegouarch (Simplicity Itself), 10th February, 2016
I was just introduced to this wonderful talk by Richard Cook on systems resilience by my good friend, Sylvain Hellegouarch
Richard's main point seems to be that the fundamental battle any software delivery and operation team faces is made of three, often implicit, boundaries:
In the early 2000s, it was acknowledged that the initial view was only a partial understanding of the system’s input and so agile methodologies were gradually defined. The aim here was to iterate as often as you can so as to correct your path early.
Although a foot in the direction, this did not pan out as well as one could have hoped for. Indeed, changes could be introduced during the life of the project, but they still could take a long time to be delivered into production. This was the Elephant in the Standup effect; where your software becomes grossly in conflict with reality over time.
It's time for this to change. Right now the process can absorb incoming changes but the software, something you might hope would be wonderfully malleable, resists these changes.
If we don't architect and design to thrive on change then we are destined to build systems that will be perceved to be holding the business back.
We need to fix the software design and architecture, not just the process. This is at the heart of Antifragile Software as enabled by microservices.
Richard's main point seems to be that the fundamental battle any software delivery and operation team faces is made of three, often implicit, boundaries:
- Responding to economic need to avoid failure: Adding or updating features, supporting different expectations...
- Coping with workload: Teams need to feel confident and at ease they can deliver. If they feel overloaded, they either collapse or go to sleep mode
- Enduring the stress of reality in time: Will the software support the load? Will it fail? What will happen then? Can we mitigate against this? The problem lies in the view that systems can be planned and control from the initial pool of information, a la the Plato story from my own talks! This has led to waterfall methodologies - research and plan enough so your software will be formally designed.
In the early 2000s, it was acknowledged that the initial view was only a partial understanding of the system’s input and so agile methodologies were gradually defined. The aim here was to iterate as often as you can so as to correct your path early.
Although a foot in the direction, this did not pan out as well as one could have hoped for. Indeed, changes could be introduced during the life of the project, but they still could take a long time to be delivered into production. This was the Elephant in the Standup effect; where your software becomes grossly in conflict with reality over time.
It's time for this to change. Right now the process can absorb incoming changes but the software, something you might hope would be wonderfully malleable, resists these changes.
If we don't architect and design to thrive on change then we are destined to build systems that will be perceved to be holding the business back.
We need to fix the software design and architecture, not just the process. This is at the heart of Antifragile Software as enabled by microservices.
RSS Feed
