With an increasing number of organisations turning to DevOps to try to improve their software systems, it is becoming necessary to provide the business case for introducing DevOps, especially in organisations which perceive their main focus to be something other than software systems.

For me, building the business case for DevOps has three strands:

1. Using appropriate terminology
2. Recognising the huge technology shift which has occurred over the last few years
3. Emphasising the importance of operability in our software systems

There are of course other approaches we can take but the three strands I present here are easier for most organisations to grasp than more advanced concepts (such as Cycle Time and Batch Size) which need a higher degree of organisational awareness and maturity to address.

Slides

(Thanks to all those credited for photos on the final slide)

Video

Here is the interview I gave after the conference – it’s a summary of my opening talk:

(Watch on the UNICOMSeminars YouTube channel: http://www.youtube.com/watch?v=CwDTjHyOnUw)

Use Appropriate Terminology

It’s a little sad but probably inevitable that an increasing number of meanings have been attached to the term ‘DevOps’, as recruitment agents, lumbering tools vendors, and middle managers all climb on the DevOps bandwagon. Even within the tech community, there are many different meanings: developers doing operations; operations doing development; a synonym for infrastructure automation; identical to Continuous Delivery; or even a special ‘DevOps team’, which ends up keeping Development and Operations separate by sitting between them!

With all this confusion, I think it’s crucial to avoid using the term ‘DevOps’ and instead to talk to the business and other stakeholders in plain language. What exactly do you expect DevOps to bring to your organisation? For example, three out of the four pillars of DevOps (‘CAMS’) relate strongly to communication and cooperation: Culture, Measurement, and Sharing (the other being Automation). We could therefore begin to talk about the-thing-which-we-shall-not-call-DevOps in terms of “Highly Effective Communication between Development and Operations” (for example; there could be other phrases). The important thing here is to find terminology which is suited to your organisation and which will resonate with people there.

Recognise the Technology Shift

Since the days of the printed Yellow Pages business telephone directories, there has been a huge shift in technology. Back in the 1980s and early ’90s in the UK, almost everyone would have used the Yellow Pages in order to look up business details (for a plumber or a garage, for example). A quick straw poll of the audience at DevOpsSummit found that only three people out of the entire audience of 80+ had used a paper Yellow Pages in the last year: a big change compared to 20 years ago. In the UK, Yellow Pages were too slow to adopt web technology, and consequentially lost out in the business search market to the likes of Google and Microsoft; their ‘once a year’ deployment model (a paper book) was from a previous age.

In the same way, the skills and techniques needed for desktop software (such as floppy disk copiers and on-premise client-server installations) were substantially different from those needed for the web-based software of the dot-com era.

Today, we have reached another substantial shift in technology, skills, and approaches: the combination of cloud computing, virtualisation, and supporting software has brought us to the era of dynamic infrastructure. No longer are we in a world of 6-month hardware lead times, where the glacial pace of change allowed for an (unnatural) split between development and operations; we can now provision an entire production environment in minutes with Amazon EC2, Azure, or Rackspace, and businesses and customers expect and demand a different approach.

The only way to deliver large or complicated software systems at this new, fluid pace is for Development and Operations to build the systems together: in a word, DevOps.

The Importance of Operability

The third strand in making the business case for DevOps is to emphasise the importance of getting our software systems to run well in Production, that is, to focus on software operability. With large software systems increasingly open to a multi-country or even global market, the impact of downtime and outages can be huge, potentially crippling a business.

Poor operability manifests itself as bad application logging, unexpected failure modes, limited diagnosis hooks, a lack of resiliency, and so on; these anti-features cause outages or extended diagnosis times, and are usually the result of poor communication and collaboration between developers and operations people. The outages can cost organisations a huge amount of lost revenue and reputation, and a large number of these operability problems are fairly straightforward to address if the operational features are given sufficient priority during the development of the software.

The only way to ensure our software systems are highly operable – that is, work well in Production – is for Development and Operations to build the systems together, with a common purpose.

Summary

DevOps provides the communication, cooperation, (and automation) needed in order to deliver reliable 21^st-century large-scale software systems. In order to make the case for moving to DevOps, choose the right terminology (in plain language), identify and explain the technology shift which has occurred, and focus on the importance of software operability.

Further Reading

• Niek Bartholomeus (@niekbartho) on DevOps in a large enterprise: http://niek.bartholomeus.be/
• The Top 11 Things You Need To Know About DevOps – Gene Kim
• John Clapham (@johnC_bristol, Nokia Entertainment): http://www.infoq.com/articles/monthly-devops-01-nokia
• Where do I start with software operability?
• The Phoenix Project, by Gene Kim, Kevin Behr, and George Spafford

Thanks to Unicom for inviting me to Chair the conference, and to John Clapham (@johnC_bristol) and Stephen Nelson-Smith (@LordCope) for input.