The digital imperative calls upon organisations to empower fusion teams. Harnessing the business value of DevOps is one way you can do this. In the first of two blogs, our Strategic Account Consultant Harrison Kirby explores what DevOps means how it can help you accelerate success.
The need to deliver value efficiently and reliably is ever increasing. We must continue to leverage DevOps and continue to push the standard ever higher to achieve current demand while preparing ourselves to meet future expectation.
What is DevOps?
For those of us working in DevOps consulting, this question is akin to “what is the point in life?” – the answer is a matter of perception and a universal response is hard to define. To try and answer this, let’s go back to the big bang, the origin of DevOps.
It’s somewhat common knowledge that the buzzword ‘DevOps’ first arose as part of the first DevOpsDays meetings in 2009, and it’s true to say that is where the name came from, but the true origins go back to the 1950s. This is when Taichii Ohno, Shigeo Shingo, Eiji Toyoda and Edward Deming created TPS, the Toyota Production System.
TPS really is the foundation of DevOps, realised in three principles: Quality at Source (QatS), Just in Time Production (JIT) and Continuous Improvement. The objective of TPS was to eliminate waste and achieve the best possible efficiency. Wind forward 60 years and the same challenges the manufacturing industry were facing in the 1950s are now relevant to software development; the same elementary principles are being applied.
We’re now in 2022 and industry experts have yet to agree on a definition of DevOps as it largely depends on perception. For example, a developer may see DevOps as continuous integration, the practice of automating the contribution of multiple code contributors into a single project. A manager may see it as a way of reducing silos between development and operations. A cloud engineer may see it as infrastructure as code (IaC), the practice of provisioning infrastructure using codified, consistent and portable artefacts.
These are all correct answers, and we could go on to describe 100 other definitions, but this would defeat the objective of the question. If we zoom out a little, and look at what we are trying to achieve, the answer becomes quite simple: DevOps is whatever you need to do to deliver value reliably and efficiently.
The key, aligned with the perception of value, is to pick and choose elements of DevOps that apply to your context and can remove constraints you are currently facing.
What do we mean by value in the context of DevOps?
Value is a broad and subjective term used to describe how much something is worth to somebody and therefore is a perception based on a given reality. In the context of DevOps, value is primarily orientated around delivering changes, including new features and tweaks to applications to meet the needs of the end user.
For example, this could be releasing a new feature that enables users to interact with greater ease, such as a chatbot or improvements to increase the performance of the application.
As we all know, technology evolves rapidly and so the ability to deliver at pace with quality is critical – and this is where DevOps can help you.
How do I find where I need to accelerate?
The only way to move faster is to identify and remove current constraints. It’s likely you’ll already know what these are, but a great way to quantify and evaluate which constraint to target is to perform value stream mapping. This is a separate topic in itself but, put simply, it’s made up of demand and the activities required to turn demand into value.
This can be applied almost universally, with my favourite example being buying a new car. In this case, demand comes from a customer who has made a purchase, which triggers many activities such as getting the parts, assembling the electronics, painting the body and so on. Value is then only achieved when the customer picks up the car.
Let’s take a more technical scenario where a new feature needs to be developed and deployed to a web-based application. We write down the left-to-right activities required to deliver the new feature: Business Analysis > Feature Definition > Development > Deploy to Test > Deploy to Production.
We then look at these steps and identify where we think the main constraints lie. To evaluate our constraints effectively we need to measure three key metrics across our value stream: wait time (the time it takes to start a process), process time (the time it takes to execute a process) or failure rate (out of 100, how many times does the process work the first time).
For instance, let’s hypothetically say we have completed our value stream mapping exercise and found that our deploy to production activity takes five hours and fails 30% of the time, whereas typically for this type of app we want this step nearer around ten minutes and 99% successful. It’s clear that these are serious constraints hampering our ability to release value in a timely and quality manner to the user and should be top priority for improvement.
Once you have conducted your first mapping exercise, it’s key to continue the exercise on a routine basis to evaluate and remediate your next set of constraints to push your reliability and efficiency even higher to secure your pipeline to value.
To find out more about common constraints you might come across and how DevOps can help mitigate them, head over to my second blog.