Companies looking to get the benefits of a DevOps mindset often get stuck in the trap of focusing on buying the "best" tool and implementing "best" practices.¹ Tools are chosen with very little, if any, collaboration with developers, testers, or operations staff. "Best" practices are determined by committees, again based on scant practical organization experience. While there are benefits to standardization, premature standardization, or standardization with no room for experimentation leads to stagnation and poor overall performance. And what works today will be unlikely to work as well in the future. The pace of change and innovation in DevOps means new opportunities for improvement are arising regularly.

It is common for companies to stall or slow in their quest to improve speed, quality, reliability, or security through a DevOps approach.  It is not technology that slows them down, but their culture.  They have practices and beliefs that make some aspects of DevOps seem impossible:

“Sure, developers at small start-up XYZ can put their own code into production, but we're in a regulated industry, and it would never work.”

“We need separation of duties. What you’re suggesting is impossible.”

“Audit or compliance would never allow a developer to test code.”

In this blog post, we’ve focused on separation of duties.  Separation of duties is an important concept and to some, it might seem to be incompatible with a DevOps approach, but it isn’t. In fact, in many cases the separation of duties in the context of DevOps offers more assurance of quality, security, and audit-ability than traditional approaches.