Over the last few years I’ve been involved in a number Digital Initiatives hoping to leverage the promise offered by DevOps to gain a competitive advantage, only to find that it was not the silver bullet first thought. While many of these initiatives were categorized as successes, only a handful of these initiatives were able to actually realize the value of DevOps by improving customer experience and getting new software into the hands of customers sooner. Some of these initiatives left those involved questioning whether DevOps could actually deliver measurable value to Digital Initiatives or whether it was just another fad.
While the DevOps path can be challenging, there is no doubt that as philosophy DevOps enables Digital Transformation by increasing the velocity at which software can be delivered and allows companies to respond to market changes faster. With that said, there are a few fundamental things to keep in mind when embracing DevOps to make the path a less challenging one.
Know ‘your’ definition for DevOps
One of the biggest issues with starting on the DevOps path is that there is no one definition that exists. DevOps means different things to different people, depending on their role, experience and the Organisation with whom they work. Knowing your definition of DevOps within the given context it applies, avoids endless hours of discussions over what DevOps is and isn’t, and what value it will bring.
In my experience the primary areas of DevOps are;
- Infrastructure Automation; scripting the provisioning and configuration of infrastructure components.
- Continuous Testing; end-to-end testing approach to achieve four capabilities, test early, test faster, test often and automate.
- Continuous Delivery; automating release management so software can be deployed readily at any time.
- Continuous Monitoring; end-to-end monitoring approach to ensure software is operating at optimum levels, including self-monitoring or analytics gathering.
Getting to know your definition of DevOps will help to create a common language and ensure that everyone is on the same page or book at least, helping your team to define a common goal and focus on achieving that goal.
Understand ‘your’ cultural landscape
DevOps is more than a set of methodologies, frameworks or tools. It’s a philosophical way to solve a business problem by breaking down traditionally siloed working environments to create cross-functional teams wholly accountable for success, increasing velocity and quality.
Transitioning to a DevOps working environment is more than simply changing job titles and reporting lines. It is about a deep seated cultural shift, to change the way people have been working and the way companies have been doing business for decades. It’s to move from isolated singular perspectives and experiences with little awareness or collective learning, to see things from different perspectives, cut across functional boundaries, and to create a shared culture of collaboration, velocity and collective learning.
Before starting your DevOps journey it is critical to assess the current cultural landscape including Vendor Relationships and ensure that your initiative has the right level of support. They key to fostering a DevOps culture is awareness and engagement at the right levels.
Build ‘your’ toolchain
DevOps working extends on the process and people foundations introduced by Agile practices, bringing in the technology and data elements to provide a more holistic approach to software delivery. Technological change is a critical component of any DevOps journey. Modern tools, processes and architectures enable continuous deployment at scale and self-healing systems.
With so many DevOps tools available in the market today it is imperative that you invest an appropriate amount of time to determine the tools that best meet your objectives based on your existing processors, cultural landscape, technology stack and architecture patterns to establish a healthy DevOps toolchain.
Define ‘your’ metrics
Many DevOps transformations focus on the culture and technology elements without the most critical element, measurement. Measurement is the secret ingredient and the key aspect of any technology transformation as it allows you to take a data-driven approach. The right metrics arms you with the data you need to inspect and adapt frequently, learning what’s working and what isn’t.
Metrics also provides a clearly defined format for capturing, reporting and measuring data making it easier to communicate and share this information across teams and the business. Unfortunately, there is no one metric for DevOps. To establish meaningful metrics you will need to identify the challenges that you are trying to solve within the context of your definition of DevOps and your cultural landscape.
DevOps is all about continuously delivery quality software so you might want to consider using a combination of the following metrics to see how fast you are moving without breaking things;
- Deployment Frequency / Time
- Lead Time
- Automate Test Pass %
- Defect Escape Rate
- Error Rates
- Incidents and Requests
- Application Usage / Traffic
- Application Response Times
- Mean Time To Detection (MTTD) / Meant Time To Recovery (MTTR)
Inspect and adapt
The DevOps path is not a destination, it’s a journey of continuous improvement, learning how to overcome your specific challenges to deliver quality software as quickly as possible. DevOps done right is the combination of people, tools and metrics to continuously deliver quality software by fostering a culture where software/product development and process improvement are approached with experimental mindset and shared learnings.
In the age of digital transformation where software is the true differentiator, DevOps allows us to place customer engagement at the heart of our digital transformations by shortening development cycles and increasing the speed of innovation putting customer experience first.
I have experienced first hand how frustrating it is to be part of a project team trying to implement DevOps as part of a broader digital transformation, without a shared definition in an organisation in where the culture was not ready for change. I hope that by keeping these fundamental things in mind you can ensure that your path to DevOps is a little less bumpy and avoid having an experience similar to mine.