DevOps is the way to IT nirvana, magically conjuring up the unicorns of agility, reliability, efficiency, engaged employees, and accelerated implementation schedules.

…Except we know the reality. It’s not about the tools or gimmicks – DevOps is a philosophy, and if an organization is built to, or transforms to follow the right principles those goals can be reached. 

I want to address one particular aspect of this philosophy that I have not seen discussed enough – the Big Picture. There are two sides to this.

The Goal

Back to basics! The point of all the DevOps magic is to achieve some goal in a more efficient manner. Unless the developers and operations teams know what this goal is, and how they can contribute to it,  the wrong initiatives and work get prioritized, and the work done is less meaningful in the end. Surprise, there’s nothing dev-opsy about this, it’s all about good, traditional communication and management. The need for clear direction, planning, and execution and communicating it down the organizational structure doesn’t vanish even if the engineers are wizards. Make sure development and operations engineers have a good idea what the organization is trying to do, and let them find ways to contribute. It means better focused work, and more meaningfully engaged employees.

OpsDev

Having a two-way communication between development and ops isn’t really a DevOps thing either; it’s clearly a part of a healthy ITIL, Site Reliability Engineering, Agile, DevOps or pick-your-methodology organization. 

It matters for multiple reasons.

First, if there is a division in labor between the operational tasks and the development-oriented tasks, communication helps foster better cooperation between the respective employees and groups.

Second, it makes for better solutions – having operations weigh in on what kinds of things make life easier and reduce unnecessary work and engineering on the front end of projects can be incredibly helpful. (*cough* Proper application-level HA. *cough*)

Third, it is a sign of a healthy organization and makes the role of an operations engineer more rewarding. If the operations engineers don’t have the time or the opportunity to get involved on the front-end of projects, it either means that they’re overworked, or that they’re getting the mushroom treatment and handed projects they have to magically make work without having been able to influence the design. Both of these are significant red flags.

Conclusion

Like so many parts of the DevOps fever, once you unpack the principles behind it, it turns out that there are some good, common-sense ideas at play. It’s not that DevOps is conceptually that different from the ITIL wheels of continuous improvement, it’s more about figuring out how to actually allow that ideal to be reached without falling into the process morass ITIL brought us. Alternatively, in places where strict controls and processes are unavoidable, there are still great lessons to be learned from DevOps and Agile methodologies.