Dealing with division through DevOps

Source – information-age.com

The phrase “Too many cooks spoil the broth” can be applied to any number of scenarios, while another favourite—“A camel is a horse designed by committee” — explains the possible results of combative collaboration.

Typically, the problem lies with people wanting different things from a project—an issue that should have IT professionals nodding knowingly. A long-term issue within businesses has been the disconnect between two teams who use IT to achieve different business goals. In the red corner, stand the Developers. In the blue corner, Operations.

The former team does just what their name implies: they develop. They drive innovation within an organisation and ensure that the company is on its toes and moving forward. Operations, meanwhile, may seem more prosaic, but is absolutely vital—their team keeps the lights on, the phones ringing, and emails pinging.

Both of these teams are working for the greater good of their organisation, and yet tension is created as businesses struggle to understand how to incentivise these teams.

Business incentives

So, what does a business want from a developer? Typically, speed. In many organisations, the rule is 80/20: businesses demand 80% of the functionality in 20% of the time. This, unfortunately, leads to bypassing the final stages of the developer journey: the fine-tuning. This often includes things like security, whether a solution runs on all platforms, testing, and documentation.

The emphasis instead is on using small teams of developers who can push solutions out as quickly as possible, with the term “fail fast” often used to illustrate priorities. Essentially, the business doesn’t mind failure, as long as it isn’t dragged out and they learn from the experience. This approach means that developers are incentivised around how quickly they can get new features rolled out and working.

Then, you have the operations team. Their job is to keep things stable, make sure there’s no downtime, and that everything is always available. Their incentives are based around ticking these boxes and, essentially, keeping the business’ IT running smoothly. No pressure, right?

So, now that the business leaders have incentivised their IT teams and headed to the golf course for a quick nine, what’s left at the office? The developer team works quickly to throw solutions into production before giving themselves a celebratory pat on the back, while the operations team grind this to a halt, saying, “you can’t put that in my system because it isn’t developed properly; it’s unstable, it’s untested, and I could lose my bonus if it impacts the environment.”

This, of course, causes friction. This scenario is a reality that exists in many organisations today, and it’s not the fault of the developers or the operations team. It’s the business’ fault for giving mixed-signals.

This approach can cause significant problems. Developers will grow disinterested and stop building cool solutions for your business, while crashes will occur as whatever does get rolled out has usually skipped the key final stage of development.

In order to address this issue, IT professionals should air their grievances to businesses that insist on this approach, and should also point the way to embracing a DevOps culture.

Deliver DevOps

DevOps is a cultural, conceptual idea that a business adopts and says, “this is how we want to work”—much in the same way a company would turn to a new supply chain technique. DevOps cannot be bought out of a box, and is instead a change in how a business’ IT culture works.

DevOps breaks down the wall between developers and operations team. Now, you have developers who are told that they can roll anything into production because they will then be responsible for it. So, if something fails at 2 a.m., the person responsible for that solution will get the call, not somebody from another team.

This gives the developer the option to roll out a solution as quickly as they want, because they are the ones who will suffer the pain or discomfort of its failure. If this sounds like all bad news for the developer, there’s a flip side.

DevOps means that Operations can no longer act as the Department of “Saying No.” Even if members of the operations team won’t be expected to learn code, they are now very much part of the development process.

From the very first design meetings, to witnessing how solutions will help achieve business goals, the operations team is now integrated into the development process and bears some of the responsibility for that.

This may seem terrifying for IT professionals who have only worked one way, but IT has always been about change and lifelong learning. Pushing past your comfort zone and into a new area is healthy in IT, and can help deliver success.

If businesses are willing to embrace a DevOps culture, they will avoid having two teams who are at war with each other, and whose output is flawed at best. Essentially, your IT environment can be the horse, instead of the camel designed by committee.