Dev & Ops: has the eternal struggle finally ended?

The main goal of development these days is to rapidly produce and release new features to meet changing business and customer needs, while operations continue to focus on maintaining a stable and robust system. With change being the implicit “enemy” of stability there has always been a friction between development and operations, and addressing this conflict is one of the objectives of DevOps. As an approach, DevOps focuses on rapid, iterative build and release cycles in order to become more reactive to changing customer needs. It’s characterised by a cultural shift where Dev and Ops function as one team, focused on delivering business value.

Since the first European DevOpsDays conference in 2009, which had a little less than 70 people attending, there has been a lot of progress and nowadays everyone seems to know something about DevOps and the benefits it can deliver. Most organisations have undertaken IT programmes with the ambition to transform their development and IT departments to deliver on the promises of DevOps – increased agility, improved quality, reduced downtime, and lower costs.

So have these programmes delivered on their promises and has the wall between development and operations finally fallen? In some organisations, yes, but many still struggle while others are yet to embark on their journey. According to Gartner, this is the year when DevOps will evolve from a niche to a mainstream strategy employed by 25 percent of Global 2000 organisations. In other words, while some advances have been made there are still some major battles to be fought.

For enterprises that have already begun their DevOps journey, the questions often become “why is this so hard?” and “why am I not seeing the benefits I expected?”

Why is Enterprise DevOps so hard?

As I described in my previous blog, Conquer your Systems of Record, many organisations see Agile and DevOps as a “thing” you do and fail to recognise that this is a culture change that affects people more than anything else. Technology may be an enabler for this change, but the hard work is getting people to think differently and establish new ways of working.

The aim is to align roles and processes across development and operations in the context of shared business objectives. It’s about better collaboration and for larger organisations this can become complex when an application cuts across several teams, environments and backend systems, all changing at different pace.

Take mobile banking as an example; it’s essentially an app that sits on a customer’s smartphone talking to a banking system, or more often several banking systems, in order to display the latest account balance, or to make a payment. The development and operational teams responsible for the mobile app might be able to turn around changes in days whereas the teams responsible for the payments system may require weeks, if not months. It’s impossible to create one cohesive team that covers all build, release and operational processes for the entire end-to-end solution in situations like this. So the challenge isn’t just about breaking down barriers between individual development and operation teams, but to make this work across multiple teams and system boundaries as well. Decoupling of systems can help, but be mindful of the additional effort required to re-architect and componentise existing systems.

Why isn’t DevOps realising the expected benefits?

There are many potential reasons for this, but a chain is only as strong as its weakest link. If an organisation only focuses on a few priority areas there is a risk that other areas end up holding everything back. Securing executive support for a new and “sexy” mobile app might be easy in the digital age, but failing to do the same for downstream systems puts the entire project at risk.

Unrealistic expectations is another reason DevOps initiatives are perceived to underperform. Take lowering costs as an example – I don’t think anyone disputes that DevOps can drive down costs over time, but people have different views on how to achieve this. To successfully transform an organisation and truly get behind the DevOps philosophy there needs to be an investment in both people and technology so costs will not come down overnight. If immediate cost reduction is a priority, don’t be under the illusion that DevOps will do the trick as cultural change, training and employee empowerment don’t go hand in hand with slashing staff and other “popular” cost cutting exercises. Establishing what is most important and making sure there are clear and quantifiable metrics to track and report against will be key for avoiding the wrath of the executive team later on.

Fasten your seatbelts

Embedding DevOps in an organisation, particularly a larger one, is hard, requires investment and will take time. It is also a lot more than technology, with cultural changes needed throughout the organisation, so the question will inevitably be if it is worth the pain?

In today’s rapidly changing environment, with disruptive forces seemingly around every corner, it is essential for an organisation’s survival to embrace change and DevOps is a key enabler for this. According to a study from the John M. Olin School of Business at Washington University, 40% of the Fortune 500 companies will be gone within 10 years.

“It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.”
– Charles Darwin

It might be a bumpy ride, but stepping off isn’t really an option and organisations simply have to buckle down and get on with it. So with that in mind I wanted to highlight a few areas where a bit more focus can help soften the ride.

Training

Many rely on external recruitment activities to bring in new skills, but the increased competition for talent forces many organisations to move fast, sometimes too fast, which can lead to problems later on. Apart from failing to spot potential skill gaps there is also the cultural fit of new hires, which is extremely important in a highly collaborative environment that DevOps fosters.

“If you think it’s expensive to hire a professional, wait until you hire an amateur.”

Hiring external talent can help, particularly to speed up adoption, but it can also cause friction with existing teams and people who may feel overlooked for potential roles. Don’t forget that your employees often sit on knowledge and expertise that can be very hard to replace. Finding a DevOps “evangelist” within the organisation will help strengthen the internal support. So before looking externally, chasing that “superstar” to come in and save the day, focus on your existing employees; upskill and train in the basics as well as advanced subjects covering not only technology specific, but also softer skills such as communication and collaboration. In the end, this may turn out to be a cheaper approach than extensive external recruitment while helping to raise the standard across the organisation.

Communication & Collaboration

Getting teams that are used to working in silos to share information with each other is probably one of the hardest things to achieve, and technology is just a small part in making this a success.  Once the team barriers are starting to come down, they have to start thinking about what DevOps is meant to accomplish, both in terms of improving agility and producing measurable business results.

This will be a big change, particularly for operational teams that have been used to working relatively independently with little, if any, interaction directly with the business. It is important to establish new communication channels early on and foster an open and transparent dialogue between all parties. Setting clear and measurable goals that everyone can understand and thrive towards is also very important, which will be covered in the next section.

Measure & Metrics

You can’t know whether you are successful or not unless you define what success is. With established and quantifiable metrics for success, you can measure progress and continuously improve the process until you reach the desired outcome.

“If you can't measure it, you can't improve it.” – Peter Drucker

If you’ve ever been involved in DevOps conversations, you’ve most likely heard about deployment frequency, lead time, failure rate etc. While metrics in this space are relatively easy to define and measure, it is critical to map them back to business outcomes. Failure to do so will bring on the “so what?” moment when reporting back to business executives that release cycles have been cut down from weeks to days, or the failure rate has dropped by 30%.

Final words

We’ve talked about some of the reasons why DevOps struggles to get traction within larger organisations, but it really boils down to a clash of cultures between a traditional management structure and the philosophy behind DevOps. It’s a battle between a traditional vertical world where the strategy is set at the top, power trickles down and tight rules circumscribe discretion, which is pitted against the flat, horizontal world of DevOps with a focus on outcomes, continuous innovation and empowerment that liberate the full talent of those doing the work.

If you’re going to take away one thing from this blog then it should be that DevOps isn’t just about breaking down barriers between development and operational teams. It’s about a wider cultural change that spans the entire organisation where a vertical mind-set needs to be replaced by a horizontal one. It may start out in smaller pockets throughout the organisation, but for DevOps to reach its full potential, the vertical thinking needs to be “eradicated” all the way to the top.  So guess who you need to get on-board to make this a reality?