Dysfunctional DevOps
DevOps best practices are becoming very popular among successful technology organizations. DevOps, associated with agile development practices including continuous integration and continuous delivery, enables businesses to achieve a competitive advantage through rapid iterative application build, package, and deployment. DevOps is a set of principles and practices that help teams, including development and operations, to communicate and collaborate more effectively.
But DevOps also has a dark side, and I have been noticing some very dysfunctional behaviors in my consulting work to help organizations implement these best practices. The first problem is that DevOps is misunderstood by many people. Some folks believe DevOps refers to highly skilled developers who write the code and deliver the applications to production themselves.
If you are working in a large bank or other financial institution, this would probably violate a number of federal regulatory requirements, including maintaining a separation of duties as required by section 404 of the Sarbanes-Oxley Act of 2002. DevOps is not intended to give developers root access to production machines or bypass operational controls designed to protect the organization.
As a consultant, I often conduct assessments of configuration management practices, including DevOps. During these interviews, it is fairly common for engineers in the organization to introduce themselves as being “in charge” of DevOps. This is interesting because inevitably, these technology professionals are reporting into development or operations—but not both.
The whole point of DevOps is to promote cross-functional collaboration between technology professionals who have different areas of expertise. The person in charge of DevOps should be equally beholden to both development and operations. I have worked with CTOs to structure the DevOps leadership so they can be effective and employ a reasonable level of positional authority.
Recently, I attended a meeting of technology professionals to discuss DevOps best practices. As the meeting progressed, I realized they were all in the development organization. We were essentially having a high-level meeting on DevOps without anyone from operations actually participating in the discussion. This was matched by another organization where the CTO explained to me that DevOps was owned by the IT operations organization. I have also seen some tools vendors who have been distorting these terms to fit their marketing literature and sales strategy.
DevOps is not about a person having a great job description, and it cannot logically be owned by only one silo within the organization. DevOps focuses on sharing information more effectively between different teams that have their own areas of expertise. Developers know their technology and are in the best position to teach and educate the other stakeholders in the team. Operations knows how the application behaves under actual use and can often teach the developers a few lessons about that.
DevOps is all about improving the way we communicate and collaborate. Technology leaders need to ensure that their efforts to implement DevOps are aligned with the right principles and practices and stay far away from mislabeled—or, even worse, dysfunctional—behaviors trying to pass themselves off as DevOps.
