How can Multi-Speed Architecture accelerate reliability and delivery flow?
In this article, Steve Smith explains why Policy Rules should be based on Continuous Delivery predictors, the importance of a loosely-coupled architecture, and how architectural Policy Rules can benefit Continuous Delivery and reliability
This is Part 4 of the Continuous Delivery and Multi-Speeding series
Policy Rules are not inherently bad. Some policies should be established across all demand groups, to drive Continuous Delivery adoption:
- Software management should be based on Work In Progress (WIP) limits to reduce batch sizes, visual displays, and production feedback
- Development should involve comprehensive version control, a loosely-coupled architecture, Trunk Based Development, and Continuous Integration
- Testing should include developer-driven automated tests, tester-driven exploratory testing, and self-service test data
These practices have been validated in Accelerate as statistically significant predictors of Continuous Delivery. A loosely-coupled architecture is the most important, with Dr. Forsgren et al stating “high performance is possible with all kinds of systems, provided that systems – and the teams that build and maintain them – are loosely coupled”. Team and application architectures aligned with Conway’s Law enable applications to be deployed and tested independently, even as the number of teams and applications in an organisation increases.
The reliability level of an application cannot exceed the lowest reliability level of its hard dependencies. In particular, the reliability of an application in a lower demand group may be limited by an on-premise runtime environment. Therefore, a Policy Rule should be introduced to reduce coupling between applications, particularly those in different demand groups.
Data should be stored in the same demand group as its consumers, with an asynchronous push if it continues to be mastered in a lower demand group. Interactions between applications should be protected with stability patterns such as Circuit Breakers and Bulkheads. This will allow teams to shift from Optimising For Robustness to Optimising For Resilience, and achieve new levels of reliability.
Example – MediaTech
At MediaTech, there is a commitment to re-architecting video game dataflows. An asynchronous data push is built from videogames-data to a new videogames-details service, which transforms the data format and stores it in a cloud-based database. When this is used by videogames-ui, a reliability level of 99.9% is achieved. Reducing requests into the MediaTech data centre also improves videogames-ui latency and videogames-data responsiveness.
Replacing rules with guidelines
Reducing coupling between applications in different demand groups also allows for context-free Policy Rules to be replaced with context-rich Policy Guidelines. Re-designing a policy previously inherited from a lower demand group can eliminate constraints in a high demand group, and result in dramatic improvements in delivery flow. A Policy Rule that all applications must do End-To-End Testing can be replaced with a Policy Guideline that high demand applications do Contract Testing, while lower demand applications continue to do End-To-End Testing. Such a Policy Guideline could be revisited later on for lower demand applications unable to meet their own throughput target.
At MediaTech, the End-To-End Testing between videogames-ui and videogames-data is stopped. Website Services teams take on more testing responsibilities, with Contract Testing used for the videogames-data asychronous data push. Eliminating testing handoffs increases videogames-ui throughput to every 10 days, but weekly deployments remain unattainable due to operational handoffs.
This is part 4 of the Continuous Delivery and Multi-Speeding series
- Continuous Delivery and Multi-Speeding
- The Bimodal delusion
- Multi-Speed IT
- Multi-Speed Architecture
- Multi-Speed Operations
Thanks to Thierry de Pauw for reviewing this series.