One of the great things about DevOps is that adoption often starts at a grassroots level within IT departments. Developers and operations staff see a more automated and collaborative approach as a way of dealing with some of the frustrations they have traditionally had to endure. The broad availability of open source tools which can be adopted without the need to go through normal approval processes means that practitioners have been able to drive incremental efficiency and effectiveness in a free and open manner. All of this leads to a high degree of commitment and enthusiasm among IT teams.

This bottom up approach has its downsides, however. Activity can evolve in a piecemeal and inconsistent manner across, and even within, different teams. This allows practitioners to drive local step changes in performance and quality, but can impede scalability when you look to scale-up your DevOps activity. Those who have been through this scale-up process often highlight the balancing act required. While standardization of some elements is necessary, too much dictation of what practitioners should be using and how can undermine the very creativity, productivity and commitment that motivated teams in the first place.

In terms of practicalities, it makes sense to drive consistency in areas that benefit from central coordination, such as security and compliance, orchestration of the delivery pipeline via release automation, production systems monitoring, etc., but allow freedom by default in other areas. It is important, for example, to give developers freedom to choose the right frameworks and tools to address the needs of specific projects. In today’s multiplatform, multi-device world, too much standardization can easily result in ‘lowest common denominator’ output – not ideal when so much emphasis is placed on the customer experience as we have seen.

Perhaps the most important requirement when considering the longer term, however, is to think of DevOps less as a way of simply optimizing the inner workings of IT, and more as a strategic business enabler. Efficiency and responsiveness are critical, and DevOps can help immensely with these. But the overriding goal is to drive sustainable competitive advantage, and in an increasingly fast-paced, ever-changing business environment, this translates to a need for an ongoing flow of innovation and value.

It is no coincidence that many speak about DevOps as an enabler of continuous delivery. This doesn’t necessarily mean that you are constantly pumping out new software into the live environment, it’s more making sure at any moment in time you are ready to deploy that next release or enhancement should business needs dictate.

Read Pitfalls to Avoid When Evaluating DevOps for Database

This constant state of readiness and responsiveness is fundamentally what DevOps enables. If you are going to leverage the full potential, you cannot think and act parochially. You need to take a business-centric approach, make sure IT is properly skilled and working collaboratively, and put the necessary enablers and controls in place.