What is Multi-Speed IT?
In this article, Steve Smith explains how Multi-Speed IT provides the means to drive a Continuous Delivery programme with incremental investments, according to product demand.
This is Part 3 of the Continuous Delivery and Multi-Speeding series
Multi-Speed is a more sophisticated method of IT transformation. Multi-Speed means investing in groups of technology value streams, according to their product demand. While Bimodal favours an architectural division of applications and limitations on Continuous Delivery, Multi-Speed recommends a product division based on Cost of Delay and gradual investments in Continuous Delivery across an IT estate.
A technology value stream is a sequence of activities that converts product ideas into value-adding changes. A demand group is a set of applications in one or more technology value streams, with a shared throughput target that must be met for Continuous Delivery to be achieved. There may also be individual reliability targets for applications within a group, based on their criticality levels.
An IT department should have at least three demand groups representing high, medium, and low throughput targets. This links to Dr. Nicole Forsgren’s research in The Role of Continuous Delivery in IT and Organizational Performance, and Simon Wardley’s Pioneers, Settlers, and Town Planners model in The Only Structure You’ll Ever Need. Additional demand groups representing very high and very low throughput targets may emerge over time. Talented, motivated people are needed to implement Continuous Delivery within the unique context of each demand group.
Multi-Speed creates a Continuous Delivery investment language. Demand groups make it easier to prioritise which applications are in a state of Discontinuous Delivery, and need urgent improvement. The aim is to incrementally invest until Continuous Delivery is achieved for all applications in a demand group. An application might exceed its throughput target, but it would only move between demand groups if market disruption or upstream dependents cause product demand to surge. A rip and replace migration would likely be required, as each demand group will have its own practices, processes, and tools.
A high or medium demand group should contain a single technology value stream. This means all applications with similar demand undergo the same activities and tasks. This reduces cognitive load for teams, and ensures all applications will benefit from a single flow efficiency gain. A low demand group is more likely to have multiple technology value streams, especially if some of its applications are part of a legacy estate.
Example – MediaTech
Assume MediaTech adopts Multi-Speed for its IT transformation. There is a concerted effort to assess technology value streams, and forecast product demand. As a result, the following demand groups are created:
videogames-ui is in the sole Website Services technology value stream, while videogames-data is in one of the Heritage Applications technology value streams.
A demand group will have a policy set which determines its practices, processes, and tools. Inspired by Cynefin, a policy can be a:
- Policy Fix: single group, such as heightened permissions for teams in a specific group
- Policy Rule: multi-group single implementation, such as mandatory use of a central incident management system for all groups
- Policy Guideline: multi-group multi-implementation, such as mandatory test automation with different techniques in each group
A policy will shape one or more activities and tasks within a technology value stream. Each demand group should have a minimal set of policies, as Little’s Law dictates the higher the throughput target, the fewer activities and tasks must exist. Furthermore, applying the Theory Of Constraints to Continuous Delivery shows throughput in a technology value stream will likely be constrained by the impact of a single policy on a single activity.
At MediaTech, the Multi-Speed lens shows videogames-data is in a state of Continuous Delivery while videogames-ui is in Discontinuous Delivery. This is due to the inheritance of End-To-End Testing, CAB meetings, and central production support policies from Heritage Apps, which has lower product demand and a very different context.
Policy Rules should be treated with caution, as they ignore the context and throughput target of a particular demand group. A Policy Rule can easily constrain throughput in a high demand group when it is inherited from a lower demand group. Activities such as End-To-End Testing, CAB meetings, and central production support incur handoffs and delays that cannot be tolerated as product demand increases.
This is part 3 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.