Gordon Cullum CTO at Mastek outlines the typical stages organisations must pass through in order to adopt a successful DevOps strategy.

While the term “DevOps” may be deemed as a typical tech buzzword, the process, which can be both complex and daunting, is often overlooked.

However, the benefits are clear to businesses of all sizes and no matter whether an organisation is contemplating a major transformation or a minor improvement to its current software delivery pipeline.

DevOps offers benefits including greater customer responsiveness, faster lead times from commit to deploy, and the enhanced ability to scale and pivot in response to market changes.

So, why isn’t every business using DevOps practices? In reality, it is rare, these days, for an organisation not to have adopted any of the technologies and practices that have become part of DevOps. But often a company can be unsure of where to start, how to continue, and equally afraid of failure at any point along the journey.

This article is intended to summarise the typical stages that, in my experience, most organisations pass through as they adopt DevOps strategies in the attempt to improve their technology and processes. Every business will have unique needs and challenges, but there are recognisable stages common to most.

Preparation

Before setting out on a DevOps transformation an organisation needs to be prepared. One of the most important elements of this stage is ensuring that the goals of the transformation have been communicated across the organisation, that there is buy-in, that management will support staff in the challenges ahead and that this is transparent to staff.

A successful DevOps transformation relies on a business’s most valuable resource: its workforce.

Organisational and technical change will often put significant demands on them and so having their confidence that the transformation will succeed and their willingness to change old processes and attitudes, is vital.

Before setting out on a transformation path, it is therefore essential that a business clearly communicates the goals of the process with its staff.

Essentially, the primary DevOps goal is to optimise the flow of value from idea to end user, and with this, comes a cultural change that must take place for a company to be successful.

Whilst culture is a big focus, the DevOps goal is to make the delivery of value more efficient and effective whether that’s TTM, reliability, predictability or maximising skill re-use.

Getting expert support, to not only answer concerns but also run workshops to increase understanding of DevOps practice can also be pivotal to success.  

Inventory and consolidation

Before a business can start the process of change, it is essential to have a clear and comprehensive picture of existing technologies and an assessment of their complexity.

This list can then be used to identify ways to remove unnecessary complication, for example by eliminating duplication where different tools or processes do the same thing, getting rid of in-house products that are no longer fit for purpose and moving to standard technologies, tool sets and configuration methods across the organisation.

It’s important to help create clear schedules for the review and consolidation of technologies and let teams take the initiative in choosing which technologies to keep and how to manage the migration with agreed priorities and realistic deadlines.   

At this part of the process it’s also essential to turn migration goals into milestones and celebrate their success.

Early wins can deliver measurable cost and time savings to reassure senior stakeholders and also provide a less-pressured stage to build collaborative and constructive processes. Use this as opportunity to boost team morale and secure longer term buy-in before the more ambitious transformation begins. 

Improving the DevOps process

The success of the consolidation and standardisation process can typically cause a range of problems that are often a surprise to the organisation.

For instance, increased efficiency can place unprecedented strain on parts of the business, its processes, the application architecture and the infrastructure.   

Meanwhile, removing known bottlenecks can reveal previously unknown inefficiencies, while if improvement is uneven (as is likely), morale and collaboration between teams may fluctuate as the finger of blame is pointed.

These issues can be addressed through the improvement of DevOps processes and culture. Many staff, at this stage, are likely to see technical remedies as far more important than culture improvements, but it is vital to show them that cultural change enables technical improvement.

The business must therefore reduce bureaucracy, give teams autonomy to decide on solutions and encourage a blame-free culture. Ultimately, cultural change has to happen from the top down. 

Infrastructure as code

As efficiency and productivity continue to increase, there will be increasing strain on the infrastructure.

This is not least due to fact that the application of development good practice to infrastructure code is a relatively young and immature discipline.

It is also usually the trickiest to address and the hardest to make scalable. Even moving to the cloud does little to help if infrastructure provisioning is not sufficiently automated.

A high level of automation must be developed and applied to infrastructure configuration and provisioning.

The infrastructure also needs pervasive monitoring and logging, with automated responses to alerts about significant state changes and good data analysis to reveal trends. Without this, substantial time and money can be lost through inefficiency and inappropriate scaling.

Self-service

When a business feels its regular automation and monitoring challenges have been solved, it should put them to the test by providing teams with self-service capabilities.

Self-service infrastructure automation will increase team productivity and in time free up operations staff, so that they can focus more time on developing automation solutions.

Businesses need to bear in mind though that to achieve this level of automation, staff will need to be upskilled or people with relevant skills recruited.

However, it’s important to note that the upskilling of staff isn’t just the upskilling of technologies (AWS, Azure), it’s also about financial accountability, technological and architectural adherence and security.  

If at this stage the disciplines of immutable infrastructure haven’t been adopted, now is the time to do so.

Re-evaluate infrastructure automation and configuration patterns, looking for things that are no longer appropriate or necessary on immutable infrastructure, and enforce a discipline of no manual intervention for maintenance of servers/virtual machines/network infrastructure. Automated testing and monitoring should also be reviewed to ensure complete confidence in both.

Where next?

DevOps transformation can reveal new challenges and opportunities for a business. Technical innovation and market growth will eventually force more technical change, but the cultural changes should be long lasting and a permanent gain – but this can only be achieved if they are preserved.

Maintaining a DevOps culture is not the same as creating one; processes must be put in place that reinforce new attitudes and behaviours.

By demonstrating to staff that the sustained period of change they went through ends with more space to think and use their initiative, and greater support and reward for work that removes technical debt, a business will be well placed to continue to reap the rewards of DevOps transformation.