Recently I wrote about Multi-Speed IT, a more flexible approach in which we create a calibrated lifecycle model for a team introducing a mix of elements across the spectrum from Conservative to Nimble to meet the business need—at the business’s chosen level of risk and chosen rate of change.
Let’s unpack what that means. When we consider the need for several different rates of change in the organization, it is usually driven by the need to maintain legacy systems. These systems were never engineered for the agility delivered by newer systems, so we have to balance our technical debt and our brave new world simultaneously.
When thinkers talk about this concept, for example Gartner’s concept of “bi-modal,” they are looking at the Requirement-to-Deploy value stream, as the IT4IT model puts it. IT4IT is a new standard information model from the OpenGroup, describing four value streams: Strategy-to-Portfolio, Requirement-to-Deploy, Request-to-Fulfil, and Detect-to-Correct. Or more simply, they are looking at Build not Run.
That Requirement-to-Deploy lifecycle is the pressure point in the clash of cultures between Conservative and Nimble; it is where the gears crunch as the different cadences of Agile and Waterfall meet.
“Ultimately all systems trickle down to central IT to own as ‘legacy’ using a default maintenance lifecycle.”
— Rob England, The IT Skeptic
Different Change Lifecycles
Adopting a multi-speed approach to change will have implications across our entire operating model, but the really important area is the change lifecycle (value stream), and—as discussed in my last article—the need to have multiple, different lifecycles according to the situation.
Let me be clear here: I'm talking about types of changes, categories of change. I'm not suggesting that for each individual instance of change, someone gets to choose the process to follow.
Fitting the lifecycle to the type of change might mean:
- All changes to the SAP General ledger use change lifecycle C1, a centralized waterfall workflow. Risk and impact assessment is done by Change Management.
- Changes to the public Web site via the Content Management System can be done using lifecycle N3, which requires minimal signoffs …
- … unless they are rated as high business impact, which requires lifecycle N2, in which the change is scheduled centrally by Change Management and stakeholders throughout the company are informed of the upcoming change.
- Changes to the code behind the public Web site require lifecycle N1, an automated DevOps process. Developers do their own risk and impact assessment. No central change scheduling is required.
One Lifecycle That Rules Them All
Much of the attention with nimble, “liberation” ideas is on the scrambling haste to meet immediate needs, but sometimes we need to pause to think about the future of these new information systems. The lifecycles themselves have lifecycles.
Consider this story, and reflect on whether it describes a likely reality:
SystemX starts life as a new, unusual, experimental project. Special circumstances justify doing development in a new way. The business has a high appetite for change and the emphasis is on agility, probing a new space to learn what works and responding quickly to feedback. The SystemX team operates and supports the system: They’re an Agile DevOps shop.
After an initial rush, the process settles down, and changes are standardized and automated.
A regular cadence of releases is adopted, gradually slowing to one release a month.
The SystemX team finds support too distracting. Level 1 support is transferred to the central Service Desk.
The SystemX team starts losing people to other projects, so the fix backlog is looked at only at the end of each sprint. However, the system is an important one now, and high-severity problems need to be addressed quickly. Level 2 support is moved to the generic Applications Maintenance team to diagnose problems.
The team is cut further. They no longer have the resources to operate the infrastructure, so central IT Operations takes over. The servers are moved off Amazon into the private corporate cloud. Some of the team’s DevOps automation is broken in the process, but releases are so seldom that it doesn’t get fixed.
After a year, the system is stable and has become part of business as usual. What remains of the SystemX team is disbanded. The code is handed over to the generic Applications Maintenance team as just another system to support. They change it when needed using their conventional conservative change cycle and tools.
That's at least four different change lifecycles through the lifetime of the system.
My assertion is that the lifecycle design needs to change over time, and that ultimately all systems trickle down to central IT to own as legacy using a default maintenance lifecycle.
Which leads us to the question of dealing with legacy environments (and thinking) within a DevOps approach. As systems are handed over to central support and maintenance, only some of the cool lifecycle automation infrastructure will survive. The tools will “regress to the mean.” On the other hand, people aren’t stupid. The central groups will see the capabilities of these systems and want to adopt as much of it as possible, driving greater uptake of DevOps within the wider organization.
Dealing with legacy environments is “The Hard Problem” of DevOps right now. Clever organizations are solving it with a number of tactics, such as:
- Service-oriented architectures to abstract the legacy systems as micro-services
- Duplication of data inside and outside legacy systems
- Only automating selected parts of the lifecycle, especially testing
- Adapting legacy processes to facilitate DevOps, e.g. the use of Standard Change for automated changes
- Educating new teams in the operational requirements of the legacy environments
… and more ideas are emerging every day.
An organization needs the flexibility to provide and support differing lifecycles and differing support arrangements over time, with a high probability that systems will end up generically owned and supported as “legacy” one day. As these systems become absorbed into “the mother-ship”, they will carry with them the new high-agility “liberation” ideas and gradually drive cultural change of the organization as a whole.