What is DevOps and why should I care?

In the Product Engineering world, DevOps is a culture and a set of practices that promotes a rapid and reliable build, test, deployment and maintenance of software applications or platforms. It promotes the culture needed to ensure continued ownership of software through the various stages of making changes live.

In essence, there is no handoff to any other team to deploy and maintain the software, it rests solely with the team that created it. This has the tremendous advantage of a joined-up value chain, and an acceptance of responsibility for the end product.

Where did DevOps come from?

DevOps has its roots in Lean and in Agile software development. These approaches seek to build effective teams, minimise waste in promoting software into production, and create rapid feedback loops to the team to amplify learning.

In Agile (or any delivery method), bugs from live systems disrupt sprints (the 2-week iterations to enhance a product). There is no clever way to manage that impact, so it must be recognised that bugs are a very bad thing and the team must do everything in its power to minimise them. This means having a robust test framework and having easily created test environments that match the behaviour of live operations exactly.

The only way to ensure effective and on-time delivery is to ensure that interruptions are minimised, that the team has easy access to high-quality test environments, and the right toolset required to automate deployments is implemented so that each successive delivery becomes more predictable, more successful and more reliable. Deployment mistakes are minimised through the use of automation.

The term DevOps is a contraction of two functions - technology 'Development' and technology 'Operations'.

What DevOps is not?

DevOps is a culture and set of practices, not an actual team. Although DevOps has a focus on safe, efficient deployment, it should not be considered as a deployment team. Having a team responsible for deploying software created by another team is a classic form of waste in Lean. Ironically, by creating a DevOps team to do deployments, one of the basic tenets of DevOps, has been broken. Having a hand-off to a DevOps team is anti-DevOps! DevOps lives in the development teams, who gain cross-functional skills.

It is advisable for a company to have a DevOps practice, however. The function of this group is to provide tried and tested tooling and frameworks and to ensure that DevOps professionals embedded in the Engineering teams are well supported and have a set of tools and techniques at their disposal.

DevOps is also not a technology Support team in disguise, parachuting in to resolve problems created elsewhere. Support is a distinct function and there is still a need to handle user queries, customer communications, outage management, and service management. Triage and Level 1 support is still required, but anything that cannot be immediately resolved by the Support team, becomes an Engineering escalation. The challenge which needs addressing comes back to the team which built the application.

Service Management are a separate discipline; DevOps should not encroach on or seek to change these domains, but will dovetail into them. Examples include Change Control and Acceptance into Service. Service Management and DevOps need to come together to find more streamlined ways to achieve shared goals.

The goals of Service Management complement those of DevOps. There is the same attention to reducing the amount of unplanned change, eliminating firefighting, increasing system up-time, and decreasing the amount of time it takes to repair a system.

Cultural Change

DevOps is a culture and set of practices. It removes the bottleneck of knowledge residing in one person or one team. Knowledge is shared. Mentors help with DevOps techniques and help people to solve their own DevOps problems.

DevOps relies on rapid experimentation and analysis of defects and errors in the field. A constant drive to improve, and to change what is broken is required, and teams need to be supported as they learn to experiment with DevOps techniques, and learn from experiments that don’t work, or when recovering the status quo when they make things worse.

Another behaviour is to avoid change for the sake of it. DevOps culture encourages developers to understand what a change is for and what the expected result is, to understand the domain and to make an impact. Understanding of the whole domain is an essential part of Lean thinking.

Lean, Theory of Constraints and Systems Thinking all contribute to DevOps thinking. See the whole and don’t rush to introduce local optimisations which don’t deliver the benefits expected when placed in a complex ecosystem of processes and behaviours.

DevOps culture requires organisation and behavioural change in order to be effective. This change includes team practices that facilitate greater collaboration between various technology disciplines, but the most important change is the one between Managers, Stakeholders and the Technology teams.

The focus should be on evolving product capabilities rather that all or nothing high risk capex-funded deliveries. If a large programme fails to deliver, it can invalidate two to three years effort. This could be 100 person years for a large programme of work. At an estimated cost of £400/day, that’s c£10m of investment in jeopardy.

That example is not uncommon. If a small iteration goes wrong, its a small amount of investment at risk. With real-time feedback to the team it can normally be corrected in a few hours, and, although delivering a smaller amount of value, confidence increases, as does the repeatable cadence.

Adopting DevOps

DevOps is about people, culture and behaviour. It has at its core a requirement for tools and techniques and processes that reduce human errors and prevent re-work and outages, but the key to effectiveness comes from the cultural changes that need to happen across the organisation as a whole. This is why we are passionate about the need for a whole-company digital transformation.

For business stakeholders it’s important to move the focus away from and all-or-nothing delivery culture, which is prone to failure for a variety of reasons, to an approach which has incremental value at its heart.

Why Does DevOps Matter?

DevOps can change an organisation into a continuous value-generating machine. It is not just the latest technology trend. DevOps can ensure that your investment in technology makes its way safely into the hands of users and customers, where it starts to generate revenue. It ensures that feedback is focused, and the quality of deliverables is high. It allows pivots and changes in direction to maintain relevance as markets, consumer preference and technology evolve.

DevOps improves the uptime of your site or service. If you’re in the business of delivering high availability services to you customers, DevOps is something that should be taken very seriously across the organisation.

Is DevOps too idealistic, or too good to be true?

Maybe, but what are the alternatives to changing a technology-enabled business for the better? We live in a complex world, and building an effective DevOps capability that provides real business value takes time and needs the support of the Executive team. It also needs clearly defined, realistic expectations.

The only real question is whether the Exec are willing to really look closely at the business's relationship with technology, and begin the journey to implement the changes needed to thrive in the fast moving, connected, technology age.