March 25, 2019 - Blog

One Size Does Not Fit All – The Challenge of DevOps Adoption

Ronan Laffan, Principal Consultant, Advisory Services, Version 1

"There is no “one size fits all” when it comes to DevOps implementation and processes. It should vary depending on what you’re doing, what type of organisation and software applications you use, deploy or manage..."

Ronan Laffan, Principal Consultant from Version 1 Advisory Services recently hosted an exclusive webinar discussing The Organisational Challenges of DevOps and Agile Adoption. The following blog post is the first in a series of articles based on this challenging issue. Please subscribe to the blog if you would like to receive updates from the rest of this series.  

In today’s rapidly advancing digital business landscape, IT is increasingly attempting to align to organisational business strategy. Many organisations are realising that the key to success is to seek early value and rapid responsiveness from IT, two areas where traditional approaches to software development such as the Waterfall model fall short.

For this reason, many of our enterprise customers are shifting towards modern methodologies such as Agile and DevOps and away from the less iterative and inflexible processes that hinder their agility and ability to react to opportunities and threats. DevOps carries many advantages over traditional development lifecycles and platform management processes including improved operational support, reduction in time to fix, increased team flexibility, greater agility and improved processes across IT teams.

Based on our experience with public and private sector customers across the UK and Ireland, the greatest organisational challenges faced in applying DevOps and Agile methodologies lie in the successful cultivation of collaboration across all the stakeholders involved in bringing the project, software or service to fruition.

With the majority of organisations structuring their IT departments and teams around the traditional functional siloes, it is no surprise that Agile and DevOps thinking can be a major culture shock for C-Level, senior management and stakeholders. Teams push to change priorities and processes to align towards shared goals underpinned by cross-functional communications, integrated delivery processes, multi-team management ,and all enabled by new tools and automation techniques that rethink how IT operates.

For an organisation delivering in an Agile manner, development teams work to deliver early value with frequent iterative deliveries. Complexity and delivery challenges will arise if there is a misalignment between Agile development teams and governance processes imposing delivery gates built in a Waterfall world. It is extremely difficult for Agile teams to achieve their objectives for agility if there is misalignment and lack of communication between stakeholder groups within the organisation. For example, when operational concerns are considered separate to development ones there are often multiple stage gates imposed when releasing to production resulting in long release cycles.

DevOps Practices

Much of what is termed DevOps has grown from a diverse set of best practices that emerged in the developer community over the past 10-15 years.  DevOps is the combination of software development and information technology operations processes – it is not a technology. It works to deliberately restructure the fundamental relationship between these development teams and IT operations teams. IT operations usually have responsibility for infrastructure alongside the support, operations, lifecycle management, service monitoring, etc. Typically, IT operations have been the ‘gatekeepers’ when deploying code to production – independent of the Development team. DevOps seeks to close this gap, to bring the developers and operations people together – in one team – either geographically or virtually – while still respecting the separation of duties required for secure and robust processes.

The DevOps approach enables communication and collaboration bringing diverse job functions together on one team built to achieve shared objectives and a common goal.

DevOps uses technology and automation tooling to enable effective process. It relies heavily on automation – of test, of build, of deployment, of management, of monitoring etc. – effectively applying technology to optimise the business of IT. Technology enables communication, it integrates responsibilities to reach across those team roles. There are many ways you can structure this so long as it enables continuous delivery of IT services. Agile development methodologies focus on delivering early business value and DevOps focuses on organising people and communications to deliver this.

DevOps is not the same for everyone

There is no “one size fits all” when it comes to DevOps implementation and processes. It should vary depending on what you’re doing, what type of organisation and software applications you use, deploy or manage. In organisations building bespoke software, it is an enabler to getting that software out to customers quickly and then consistently, and effectively managing its lifecycle as it continues to evolve. Other organisations are focused on the deployment of commercial off the shelf software packages or adopting Software as a Service (SaaS) applications – DevOps can still play a role in the build, configuration deployment, integration tooling, testing, patching, monitoring of those applications. You will feel pain if you attempt to apply the same model to every situation, but there are still DevOps practices that make life better in every situation.

Unfortunately, some of the documentation and thought leadership on the whole topic have been driven by companies that are often Cloud natives building SaaS application – the majority of which would lack any legacy, complex or highly integrated systems beyond the 10-year age mark.  For the conventional organisation, Agile and DevOps approaches will differ, but are still just as relevant It’s about early business return, how to be highly responsive to business, how to focus on creating value and ensuring IT does not operate simply as a cost centre. Culture is key; you won’t “do Agile” or “do DevOps” if you don’t believe in collaboration, if you are not willing to challenge hierarchical cultures and if you don’t believe that technology can help you or if you don’t actively champion adoption and change.

DevOps Adoption Maturity Matrix

Our Advisory Services team at Version 1 has developed a comprehensive Maturity Matrix for organisations adopting DevOps. This helps us to assess current state of processes, tools and organisational structure, assess what a target should be that will fit that environment and business drivers to create real value. It allows us to consider the actions and focus areas to build capability, change ways of working and adopt new tools. It builds a plan that is appropriate for a specific customer, considering what industry best practices can be realistically applied, what will deliver value and what fits to the nature of the business technology in use.

DevOps Maturity Shapes

The output of Maturity Assessment summarises as a simple spider graph the current and target states across the set of functions or domains assessed. The shapes we see emerging on these graphs depict the priorities for that specific industry, the categories of software application deployed, the balance of agility, stability, risk mitigation that applies to define business value through IT in that business.

For example, we evaluated DevOps Maturity for a company building a Software as a Service offering. Automation across all areas was vital, but Test Automation was identified as key to enabling safe evolution of their SaaS platform into the future and an essential foundation for continuous delivery of code.

That’s one example – but when we analysed an organisation whose key IT system is classic ERP enterprise package software, we derived the diagram with the shape shown below. What matters to this customer is effective safe support, patching and configuration change. DevOps approaches can support this greatly through automation of patching, testing, monitoring even though there is no custom development undertaken by this customer. It is also DevOps, but it is a different shape that applies to a different target maturity level.

Summary

For anyone considering evolution to DevOps approaches, evaluation of their priorities through a structured Maturity Assessment is an excellent starting point to identify priorities, goals and build a plan. The Maturity Shape allows us to highlight to senior management what matters in their business, what value DevOps can bring. It offers reassurance that organisational priorities are embedded in plans that deliver value to business.

It shows the path to adoption of DevOps techniques as a way to achieve the business agility and operational processes that ultimately allow you to deliver early value and responsivity, and effective risk management for your business.

About Version 1 

We are experts in migrating and running complex enterprise applications in public cloud

Contact Version 1 using the form below to learn more about uncovering your organisation’s DevOps Maturity Shape.

Contact Version 1 - DevOps Maturity Matrix