There is a trend of late with development managers suggesting that they need to embrace DevOps—albeit without the “Ops.” The argument goes that the operations team is just too slow and lacks necessary skills to really participate in DevOps.
Instead, I am hearing development gurus envision a new Wild West consisting of continuous integration servers, container-based deployments, and credit cards at the ready to sign up for external cloud-based service providers. Developers deploying their own code to production is often an assumption in this bold “new” world.
In the same discussions, I have been asking colleagues if they are aware of the guidance found in industry standards from the IEEE and ISO or the leading frameworks such as ITIL v3 and ISACA Cobit. Most of my colleagues argue that this guidance is too difficult to understand and really impossible to implement.
Recently, I asked a roomful of colleagues engaged in this debate if they would be willing to see a medical doctor who did not know the latest approved protocols or if they would want to be represented by an attorney who did not bother to read up on recent case law for the issue he was arguing before the court. We expect professionals in other industries to be aware of industry-accepted standards and also to possess the skills required to operationalize and innovate when necessary.
When organizations implement IT controls such as a separation of duties, there is an implicit knowledge transfer from developers to their operations counterparts. This process ensures that code is under version control and that standard procedures exist for automated application, build, package, and deployment, thereby significantly reducing risk due to human error as well as reducing keyman risk. The flip side of the coin, however, is that operations needs to recognize their responsibility to innovate and ensure customer satisfaction.
Too often, operations relies on ill-defined regulatory compliance and organizational structures to avoid addressing the root cause of dysfunction, which is usually a lack of technical expertise. In my opinion, the solution is not to just allow development to go off on their own, but rather to address the issues and challenges on both sides of the DevOps partnership.
For one thing, many large organizations should ensure that operations engineers actually understand how to create valid and useful IT controls that reduce risk while still ensuring rapid and reliable application build, package, and deployment. Industry standards and frameworks should be operationalized to the extent required for regulatory compliance. These IT controls reduce risk and avoid human error when they are approached in a valid, lean, and pragmatic way.
Accelerating without proper controls is similar to speeding up the rollercoaster while the cars are not properly aligned on the tracks. Going faster won’t avoid cars being derailed. We want speed, but we also need to avoid human error while improving reliability and enhancing security. Many organizations need to mature in their use of DevOps to bring all the stakeholders together in a productive and effective way.
