Why a legacy IT ops model stops working (and how to optimise it)
There’s been a years-long digital transformation journey, and agile has taken off in the organisation. Products and the software to deliver them are now managed in single units. So why is central IT stressed and struggling to keep up?
There’s a simple answer – a legacy IT ops model stops working at a certain stage of the digital maturity curve.
Here, we look at why that happens and how to fix it.
Why a legacy IT ops model doesn’t deliver for agile.
Digital business needs require a new IT approach – because you end up with misalignment between product teams and central IT.
What a ‘built for agile’ IT support model looks like.
To eliminate that friction, you need to redefine what teams are responsible for, how they’re measured and staffed and what service levels should be. The aim is to end up with centralised capabilities supported by an automation platform so IT can scale to meet all product team needs.
Platform engineering team.
Its scope should extend beyond tickets and availability to areas like providing self-service automation, lifecycle management and cost optimisation. We generally recommend the team be split into 4 pillars: landing zone, database, FinOps, Kubernetes, VM Ops.
Central automation platform.
This sits between IT and agile product teams, enabling a high degree of business self-service.
Automation in IT operations.
This frees up capacity and includes automating provisioning, change management, change configuration and scheduled operations.
How to move to a ‘built for agile’ support model.
Your overarching strategy should cover 3 elements
1. Organisation.
- Tightly scope teams so it’s clear who has responsibility for key areas in the ‘new normal’
- Align KPIs and funding models to support the mission as you plan digital change management and service transition
- Make automation part of service/role descriptions for teams and suppliers
2. Leadership.
- Give infra teams a ‘Bezos Mandate’ – to maximise automation, IT must ensure interoperability with Infrastructure as Code
- Drive reorganisation by setting up new teams and expanding the mission of existing teams
- Reframe the vendor strategy to push suppliers in the new direction
3. Tech.
- Create a platform engineering team whose mission is to enable maximum reuse of other IT teams’ existing automation
- Implement a central automation platform that reduces costs, encourages re-use and is non-intrusive for infra teams
- Move away from reactive + tickets to automated, roadmapped, proactive and responsive platform IT
Start with a 3-phase scoping process:
Phase 1
Phase 2
Phase 3
Phase 1
Create a spec charter for each team that defines:
- Target scope – mission, funding model, KPIs/metrics
- Target size and roles
- Support model interfaces
- Technologies owned/supported by the team
- Services hours and SLA
Phase 2
For each team, map
if you’re going to:
- Buy from a partner (partially or fully)
- Expand the existing team scope/size
- Create a new internal team
Phase 3
Build a timeline, roadmap
and business case:
- Get it approved
- Start to change
Want help designing a ‘built for agile’ IT support model?
1 in 3 IT leaders say their teams are struggling to support the needs of their organisation. But there’s no need to keep struggling. Get in touch to discuss how our transformation and automation experts can help.
