Enterprises are wrestling with the conflicting needs to chase competitiveness in a world of endlessly changing technology, whilst still remaining mindful and careful. In IT we are caught in the same bind. I have written about this squeeze before in "To Protect and Serve".
This year I'm looking at solutions: how IT can deal with the dichotomy with Multi-Speed IT. By embracing Agile, DevOps, BYOD and other "liberation" approaches, and integrating them into our ITSM, risk, and governance practices, we can create an IT environment with a better chance of responding at the speed of business, whatever the business chooses that speed to be. This article proposes a nuanced approach to two-speed IT, where each lifecycle implementation is a blend of the two "speeds".
http://www.itskeptic.org/content/multi-speed-it
The concept of two-speed or bi-modal IT
Some example development lifecycles
A story of four lifecycles as a project evolves
How only half the world can be standardised, and how to deal with the rest
Applying this idea to creating lifecycles: some are standard, others bespoke
Trust and empowerment. Moving Change Management from control to facilitation
What this means for the operating model
Governance, risk, and the enterprise
How many in the room even understand this analogy?
Lifecycles are the core of this – I think
The essential story here is one of liberation
Liberation approaches
Agile, DevOps, BYOD…
Forgive me if this doesnt fit your mental model
My characterisation
A system starts life as new, unusual, experimental. the team have special circumstances that justify doing change in some new way.
The business has a high appetite for risk, because they want agility as they explore a new space, probing it to learn what works and responding quickly when they do.
Trusted and senior staff develop the lifecycle they require, with a free hand so long as they stay within the policy.
The lifecycle is a highly nimble one with rapid unconstrained changes.
The team operate and support the system.
After an initial period, the system stabilises and settles down to known kinds of changes.
These get standardised so they can be automated, and a regular cadence of change is adopted after the users get change fatigue from the wild early days.
The team find support too distracting from development, and Level 1 is transferred to the central Service Desk.
The team becomes a Level 2 and 3 resolver group, as well as iterative developers.
The team goes through a cost-cutting event and a number of staff are moved out. They no longer have the resources to operate the infrastructure and databases themselves, even though the servers are in the cloud. They persuade central IT Operations to take them on. the servers are moved off Amazon into the private corporate cloud and the central database team start doing maintenance.
After a year or two, the system is stable, it has become part of business as usual, is changing much less.
The business loses interest in funding it, the development team is disbanded except for one developer, and it needs to be operated and supported.
The code then goes through all the stages of a traditional waterfall release to production and is handed over to the core Applications Maintenance team as just another system to support.
They change it when needed using their conventional conservative change cycle.
That's four different change lifecycles through the lifetime of the system.
Ultimately all systems trickle down to central IT to own as "legacy".
Given enough time it all ends up in a conservative operations lifecycle
There are as many lifecycle stories as you want to tell
No one size or two sizes fits all
A lifecycle of lifecycles
A meta-lifecycle
The concept of two-speed or bi-modal IT
Some example development lifecycles
A story of four lifecycles as a project evolves
How only half the world can be standardised, and how to deal with the rest
Applying this idea to creating lifecycles: some are standard, others bespoke
Trust and empowerment. Moving Change Management from control to facilitation
What this means for the operating model
Governance, risk, and the enterprise