DevOps and ITIL: Continuous Delivery doesn’t stop at software

DevOps. The next saviour of the world. A combination of agile delivery and super-effective provisioning scripts with a sprinkling of software-defined (virtual) infrastructure.

Whilst ITIL v3 and 2011 seem (on the surface at least) to support a waterfall approach, it’s imperative to step back and think for a second.

The concept of identifying a need for change to your service portfolio hasn’t altered. It still relies on identifying demand and building a decent relationship with your customers.

You still need to design it, and you’ll still need to operate it and continually improve it.

The biggest difference here is your transition strategy, transition design and the execution of transition. If you have waterfall style release policies and service validation practices then these won’t be capable of dealing with DevOps style Continuous Deliveries out the box. Sure, you can slice and dice your delivery packages down into smaller and smaller pieces, but this is still going to be at odds with the kinds of flexibility DevOps promises.

So let’s step back to Service Strategy and Service Design. In a traditional waterfall approach, an example of a high level transition plan is:

 

Delivery Contents
Delivery 1 (June)
  • Functional requirements a, b & c.
  • Pair of DB servers, single application server, single web server, no loadbalancer.
  • Non-functional requirements x,y,z meeting 75% of targets.
  • Documents 1,2 & 3.
  • Ops briefing at t-3 weeks.
  • ELS to +5 days
Delivery 2 (Nov)
  • additional functional requirements d, e & f.
  • Additional webserver with loadbalancer.
  • Non-functional requirements x,y,z meeting 90% of targets.
  • Documents 4,5 & 6.
  • Full training plan from t- 5 weeks
  • ELS to +15 days

 

These are packages. Discrete units. Similar to this site’s logo (which may need to change now!). You have built entire releases comprising some software components, some hardware, some documents, some knowledge transfer into a bundle. And this works really well for big deliveries, and even slicing these up into smaller 2-3 week deliveries is possible albeit with some overhead.

But what about daily? What about the developers with testers sat next to them checking in quality tested code on a daily basis to an automated build server, having it integrated, auto test packs run and then pushed to production? How are you going to slice release packages across multiple developers cutting code for variable prioritised lists of business requirements?

Packages now become unwieldy. You need a different transition strategy, and a different transition design, and you need to execute them differently from the packaging or bundling concept.

How? Rather than a conveyor belt of packaged releases, this becomes concurrent streams of smaller deliverables, for example:

 

Stream Frequency Roles /
Processes
1 – Code objects checked in, tested & deployed Daily R&DM, SACM
2 – Knowledge updates created & tested for the new functional requirements Every other day SACM, SV&T, Knowledge Management
3 – Formal Operational acceptance tests 1-2 times/week SV&T, SLM, BRM, App/Tech Function Managers
4 – Hardware deliveries As required R&DM, Tech Mgmt
5 – ELS & Continual Service Improvement Daily CSI, SLM, BRM, Service Owner

 

You’ll notice that I’ve referenced existing ITIL processes, functions and roles. We’re still using best practices (or good practices if you prefer) which are tailored to your organization and may need to be tailored for this approach. But the concept of creating a new knowledge CI and linking it to a functional requirement doc, service & hardware CIs and accounting for its status and verifying it is not new.

You need good tooling, you need reasonably mature Config Management and ditto for knowledge management, but there’s no reason why if it isn’t already happening in your organisation that you can’t use your DevOps approach to implement good config & knowledge management at the same time.

Change Management is still change management. Very little needs to (pardon the pun) change. It still acts as an approval/authorisation broker at various stages over the lifecycle, it can still devolve production release approval to the automated build and integration test process. But this is a policy addition driven by your transition (and service) strategy, not a whole new process.

You’ll also notice I’ve lumped ELS (Early Life Support) and CSI together. ELS never ends under this approach. But think back to the joining of Dev and Ops and you’ll realise that ELS loses significance. I’ve kept it here because there are some really good ELS practices you’ll want to keep: good defect/incident management at a heightened level with a razor-sharp focus on issues caused by change, regular sunrise/sunset meetings with sponsors and business owners. But I’ve merged it with CSI because this complements the very nature of Agile and also crucially gives you a perfect opportunity for a closed-loop feedback system into either operational, tactical or strategic improvements on a daily basis.

So you don’t need a dedicated DevOps process. You need a DevOps -focused transition strategy, design and execution. You need sensible tweaks to existing processes and policies. You need good tools for build, test, config and knowledge. You need good practices and good leadership.

You can do all of this with existing ITIL, just as you can with any other framework.

What happens when you ignore service design and acceptance.

I recently discussed service support / operations on twitter with someone frustrated at being asked to provide support for a public cloud service he had very little ability to. Not technical capability, because he seemed capable enough, but access to the systems to do more fundamental fixes. We didn’t get far into the details, but it seemed he was being asked to deal with something which hadn’t been thought about when the service was provisioned.

This is sadly not an uncommon situation among support teams who often have no say in the choice of system/service, no time to get familiar with it, and no means of pushing back on critical gaps even if they do get a chance to see it beforehand. These are often gaps that a 5 year old could often spot, let alone experienced engineers but which seem to be frequently ignored by people whose shopping list only has one thing on it: functionality.

Continue reading

Change requests: get the basics right

Most change requests get raised, authorised and implemented.

When I’ve had occasion to post-mortem a failed change for a new client, I’d usually expect to hear one of the following phrases:

  • I didn’t know what I was supposed to be doing
  • It shouldn’t have broken that, it was supposed to be totally unrelated…
  • How was I to know the backups were running at the same time?
  • Wait….I thought John was doing that reboot?
  • We only overran because we had to back it out…

…all of which are avoidable.

Continue reading