A useful working definition of DevOps

This post was written by Matthew Skelton co-author of Team Guide to Software Operability.

There has been a spate of articles published recently – triggered by discussions at the ‘2nd DevOps State of the Union’ event – that have identified an apparent need to agree on a definition of DevOps. The folks at ScriptRock wrote a typically excellent piece on The Problem with Defining DevOps which is worth reading (including comments), and Steve Thair of the DevOpsGuys followed up with a very useful post about the need to adopt a different cognitive frame when thinking about DevOps.

Since 2012 I have helped people from perhaps 30 different organisations in Europe, India, and the UK to adopt, improve, understand, and/or experience DevOps (via client engagements and the Experience DevOps workshop, which I co-facilitate). Reflecting on the conversations I have had with people about their challenges and successes, I have come up with a useful working definition of DevOps that holds for all these organisations, without resorting to a vague “DevOps is… good” platitude:

Highly effective, daily collaboration between software developers and IT operations people to produce relevant, working systems

Here is why I think this definition works well.

Definition of DevOps

highly effective

In order to build and operate the kinds of complex, distributed software systems required for 2014 and beyond, we need to emphasise effectiveness over efficiency for technical teams. Delivering changes rapidly, reliably, and repeatedly is not possible if we aim to minimize ‘costs’ at specific points of the value chain, as this kind of efficiency usually ends up causing unnecessary constraints. We instead should focus on flow and completion of work in progress: Change Request tickets should not sit in a queue for days; we should not separate ‘testing’ as something that happens only ‘after development’; and changes should not sit waiting weeks and weeks for the Staging or Pre-Production environment to be available.


Interaction between teams focussed on ‘new features’ (Dev) and teams focussed on ‘maintaining service’ (Ops) must be regular (at least daily) and built into the rhythm of work in the organisation, not just at certain project checkpoints (Inception, Service Transition, etc.).

collaboration between

Collaboration literally means ‘working together’ (co-labor-ation) – not the the idea of ‘occasional updates via Skype’ that some folks have. The ‘working together’ means ‘working together at the same keyboard and screen’ (co-lo or remotely via screen sharing). Dev and Ops people working at the same screen using the same tools is a crucial part of making a more effective delivery and operations practice; I have spoken about the collaborative value of tools for DevOps, most recently at DevOps Exchange meetup group.

Software developers

Anyone whose primary focus on a given day is on enabling new features using code I count here as a software developer, whether they are working with applications or infrastructure. I also include testers in this group, as an understanding of code is increasingly important for effective testing in a DevOps and Continuous Delivery context.

and Operations people

Anyone whose primary focus on a given day is smooth, safe, effective running of the main Production or Live environment I count here as an Operations person. This means definition covers teams that are segregated (‘Dev’, ‘Ops’) and also teams where roles are shared or rotated.

to produce

We need to emphasise that the systems we build and run are produced by a combination of Development and Operations people. The old idea of ‘Dev producing’ and ‘Ops running’ systems is both unhelpful and inaccurate. Instead, we see ‘the system’ as including the teams and processes included in delivery and operations: metrics, monitoring data, operational improvements, RUM data, and other valuable feedback (think: Continual Service Improvement!) flowing from Production and Ops teams towards Dev teams.


The systems we (Dev + Ops) build must meet business needs and be useful for customers. This means we need strong engagement with Product Owners and others in ‘the business’ – together with metrics from Production – in order to be sure we are delivering what is really needed.


The systems we build must actually work effectively in Production, addressing operational concerns such as reliability, performance, diagnostics, traceability, etc. That is, the systems must have been built with operability in mind, including the IT Operations folk as customers.


The systems we build are a combination of written software, IT infrastructure, auxiliary systems such as monitoring, log aggregation, etc., and teams of humans: algorithms + silicon + wetware carbon.

Other aspects

Some organisations such as Netflix have very little separation between teams for ‘new features’ and teams for ‘maintaining live service’, but we can certainly say that Netflix has:

Highly effective, daily collaboration between ‘people focussed on new features’ and ‘people focused on live service’ to produce relevant working systems

Separate ‘Dev’ and ‘Ops’ teams is not a pre-requisite for DevOps! I characterised the Netflix DevOps ‘topology’ as ‘Fully Embedded’, but other DevOps team topologies exist and work in different contexts.


5 thoughts on “A useful working definition of DevOps

  1. Good post and certainly moves the line forward in terms of progress. I can’t help but think though that the definition is just the start of this thread. If we’re doing this to reduce the barrier to entry and accessibility of DevOps as a concept then we must go further than a definition and deliver something rooted in more tangible, measurable things. Perhaps controversially, I can’t help but think how ITIL would have been defined without its comprehensive framework. It was certainly over-scoped and over-constrained, but it was at least fairly easy to get a working knowledge of its structure so people could get started on adoption without being caught up in understanding.


    1. Thanks for the comment, Chris. I absolutely agree that we should not focus on a once-and-for-all definition, because that implies a lack of on-going learning and improvement (which would be rather anti-DevOps!). In fact, I think we need to communicate better the *purpose* of what is really behind DevOps: relevant systems that work well in Production.
      The debate around a definition of DevOps hopefully helps to emphasise that DevOps is not something that can be ‘pasted in’, bolted on, or bought (in fact, much like real ITSM/ITIL, as you suggest), but rather as a cultural artefact of coordinated effective development and operations, which smooths & improves delivery and operation of the software systems.
      If we wanted to provide some form of structured guidance (.e. answering the question “Ok, how can we ‘do’ DevOps?”), we would want the organisation to:
      – Understand the real communication paths within IT
      – Find the unwanted gaps between teams, and move them closer
      – Identify people or teams who do things which are ‘painful’ for them currently
      – Factor in time to help ease the pain for both dev and ops sides of IT, allowing space for learning, collaboration, and sharing experience



      1. Thanks Matthew, that last section was exactly what I was looking for. The more tangible we can make the first iteration for new adopters, the more accessible the movement will become for established organisations. I’m keen to bring a group of practitioners and advisors together around this “framework” approach to see if we can get some level of acceptance from the community for it.


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: