Just another buzzword?

Graziela Tridapalli, Senior Consultant at Retail Reply, asks if DevOps is just another buzzword or can it really help your business?

You are the CIO of company XYZ, responsible for all of IT and operations. The business heavily relies on these two key departments running as efficiently and as cost effectively as possible, whilst also responding to innovation. In your ideal world all systems under your realm will run smoothly: no outages, no security breaches, no bugs, you can deploy changes anytime of the year.

The stats don’t lie: outages and breaks are mostly caused by change. That’s the main reason most businesses have change freeze in place, just before and during peak trading periods.

But how are you supposed to innovate and reduce time to market to respond to ever changing market demands without making changes when you need to? On the other hand, how can the systems remain stable if they are constantly being changed?

IT and operations have conflicting goals:

Team - IT
Goal - Turn around changes as quickly as possible to respond to market changes
Team - Operations
Goal - Keep systems stable. If something is working, don't touch it.

If you throw information security into the loop (and you should), the state of play will be even more chaotic. When organisational measurements and incentives across different siloes prevent the achievement of the global organisational goals the result is chronic conflict.

In these times where the only constant is change, ignoring the misalignment between IT and operations is not doing your company any favours, as the result is slower time to market than competitors, slower time to respond to incidents (usually when the customer alerts), and a general lack of trust in the department.

Regardless of what industry you are competing in, the way you acquire new customers and deliver value to them is dependent on the technology value stream, so addressing these issues is a matter of survival.

You are not impressed with lots of buzzwords out there promising to end your problems. Honestly speaking, if anything is promising to end your problems it is probably just a buzzword.

However, there are techniques that will help you address a lot of the issues IT departments have been facing. Let's take a closer look at one of those buzzwords which contains some of those techniques that can help you transform IT and potentially the business: DevOps.

DevOps is the result of applying Lean principles to the technology value stream. Its concepts can get quite technical, which is one of the reasons there is difficulty in getting buy-in from ‘the business’ for the initiative. However, that is absolutely critical, because DevOps is not just about the new tools that will help you automate a lot of the pain points experienced by your team, and consequently allow you to release new functionality quicker; a change in the culture is imperative in order to make the initiative successful, and without your support it is unlikely to succeed.

The key point about DevOps is ‘breaking down the siloes’: the idea is that you should organise your teams in a way that they share the goal to deliver a certain piece of functionality, meaning their goals are no longer disparate. That’s called a cross-functional team.

This concept builds on the agile manifesto, in which ‘the best architectures, requirements, and designs emerge from self-organising teams’. Unlike popular belief, this does not mean that no documentation and governance is required, but rather that in order to get something delivered efficiently and cost-effectively, if put your key people from the business, IT, operations, and information security into a single team with the same goal they will get the job done.

Proper governance and escalation points must be in place to ensure key decisions are approved by the relevant people, but ultimately you need to empower people. The business representative (usually known as the product owner in agile delivery) needs to have authority to make decisions, and only escalates when relevant.

The literature on DevOps usually ignores architecture, or considers architecture to be the architecture of the code produced, which is a mistake. It is important to include solution architects as part of the cross-functional team, as they have visibility of the bigger picture and are the best people to design the architecture of any solutions, making sure re-use and best practices are taken into account. This works even if your department/company is very big, as the principle of self-organising teams scales. There are frameworks such as Disciplined Agile Delivery (DaD) and SAFe that help scale DevOps practices.

Communication and collaboration are the key principles that need to be worked on in a DevOps initiative. If they are not working well, the chances of the siloes coming back are likely. Co-location is helpful, but not imperative (remote teams can also collaborate; there are good collaboration tools that will help with that).

Another important part of the cultural change is breaking down the work so that it can be delivered quickly. Rather than having N-year projects or programmes, which won’t deliver value until they are completely finished (and in most cases are already obsolete), the business and architects need to organise the delivery in smaller batches, small bits of functionality being delivered at a time. This will allow you to measure the uptake or effect of a certain functionality on the market and help make informed investment decisions.

Now that you understand the people and cultural part of the DevOps transformation, have a look at the tools and processes. It is important that you understand it will require considerable investment. You need to make sure you have a technically competent person who also understands the big picture to look into the tools and practices that will enable the transformation, which are appropriate for your business and your stage of the journey.

Here is a summary of the goals, known as ‘The three ways’:

Fast flow of delivery: the deployment pipeline needs to be automated as much as possible and prevent defects from being passed downstream. This is where things start to get technical, with things like test driven development, automated tests and builds, deployment and infrastructure, A/B releases, Blue/Green deployments (to name a few) supporting the concept. There are a number of tools and products to assist with each one of them.
Fast flow of feedback: issues in the value stream are detected faster (hopefully before the customer is affected), enabling them to be addressed quickly and preventing them from happening again. Feedback should be provided to technical and business stakeholders.
Foster a culture of continuous learning and improvement: share the knowledge and keep improving existing practices. Foster experimentation and controlled risk taking.

If your company works with off-the-shelf products you can still use of some of the DevOps practices, as customisation of such products is almost always required for any project.

You are probably thinking this is too big of a change, and you’re right. There will be challenges, such as how to include suppliers in the cross functional teams.

The best advice is to start small and broadcast successes. Start with a non-critical feature, and get the team used to the new practices and tools. From there get an influential stakeholder’s pet project. As the team builds confidence and delivers quality functionality quick, the business will get confidence on this new way of working and guess what, your department will look good, and soon enough you will be delivering customer value quicker and more reliably.

Note: Stats on DevOps organisations, as per Puppet Labs study* from 2013 until 2016: