Is there such a thing as enterprise DevOps? You bet.

After all, at the end of the day, DevOps is simply a methodology — one that enables faster, more efficient, and higher-quality software releases, which are all good things whether you’re a startup with three employees or an enterprise with 3,000.

And that’s why DevOps is for everyone — especially today when DevOps has reached maturity. Let me explain…

Why Opposition to DevOps Persists

We are at the maturity phases of DevOps adoption. While bleeding edge practices around microservices, Kubernetes, etc., steal the show, the 3+ years-old core concepts of DevOps are mature, and there is tremendous adoption. However, there is still some opposition. And it comes from all sides of the house — Security, Development, Operations, and Testing, each with their own flavor of distaste. Security believes going faster is going to create more vulnerabilities. For Development, it may not be streamlined enough (i.e. Operations still exists). For Operations, there is a fear of loss of control; and for Testing, testing for things like security faster usually means more issues to have to deal with.

Not only do some folks from these functions still harbor hesitation over DevOps, but they also operate in an enterprise, where the concerns are accompanied by the enterprise’s inability to make changes at the same rate of startups.

The Tale of Two DevOps

The problem is that there is some ambiguity in terms of what DevOps actually is. And that is because there are two DevOps. First, there is DevOps the function. The function is pretty clearly defined as the people who generally report to Operations, but serve developers to build and maintain delivery chains, and provide infrastructure. This definition does imply organizational structures, and it is much easier to argue that this function does not fit into existing structures than to argue that the broader DevOps definition does.

The second definition of DevOps is the practice which drives development — “drives” being the keyword. It is not an end. In fact, if a DevOps environment were to “complete” implementation, they would instantly be a non-DevOps environment. The reason is that if you practice DevOps, you are building an environment that can also easily adapt. Lack of adaptation was a core issue in waterfall-based development practices, so that eventually the delivery chain dictated the application versus the other way around (which is how it should be.) The DevOps journey never actually ends.

Opposition is the equivalent of saying we do not want to improve our processes or applications, which would not hold up to most organizations’ goals when it comes to application development. The term DevOps alone can be frustrating because there are so many acronyms out there, but the word serves one primary purpose. It allows us to have a conversation about DevOps without redefining it every time.

Why Agility Improves Security and Quality

Next, we move on to the concern that has some merit and grounding in tactics — and that is the concern that DevOps environments expose the organization to more bugs and security exploits.

This seems intuitive for those who have years of experience in quality and security. However, the drive of DevOps is not to break processes, but rather to make them more efficient. In efficient environments, security and quality are actually easier to implement, and better.

To speak to the concerns of the security and testing professional that speed generally creates more issues, speed does not mean less testing or fewer considerations addressed. It is actually the opposite. In a DevOps delivery chain, there are generally more checks and balances, but they happen on computer time, not human time. Thus, those checks and balances are faster, more accurate, and repeatable. So agility, in this case, can and should mean more secure and greater software quality, not less.

The Beauty of the DevOps Practice

The best thing about DevOps the practice is that it does not assume organizational structure. It does not assume application structure, and it does not assume age or maturity of adoption. Organizations do not need to immediately have “two-pizza” development teams. They do not need to have container-based microservices applications, and they do not need to be one-year-old startups in Silicon Valley. And to address the greatest misnomer, developers suddenly do not necessarily need to be friends with Operations, or vice-versa. They just need to share the same goals.

Let’s take an extreme form of the most unlikely candidate for DevOps and see why DevOps is still useful. Let’s consider XYZ corp, a 10,000+ employee organization with a library of monolithic applications, and 100 developers supporting them. Most of the development is integration-based, where legacy custom code is a mystery to all. Projects are initiated by business units and driven by project managers and business analysts. Let’s say this hypothetical organization is in the construction industry and does not have commercial end users — certainly not technical ones.

Why would XYZ corp want to consider adopting DevOps best practices? For the same reasons they consider operational improvements everywhere: lower costs, and greater efficiency. While better user experiences and more frequent releases will end up benefiting them in a huge way, they cannot deny that streamlining development and making their application more effective for the user base won’t reduce the cost of creating the application, reduce the need to hire more employees, and solve more operations problems sooner. Projects will have more checkpoints for end users to validate what they asked for, which means that the risk of project failure is lower, and the spend on that project will be better utilized. Improved release velocity also boosts competitiveness as they’re better able to meet and exceed frequently changing customer expectations.

XYZ corp does not need to reformulate infrastructure the day after their embrace of DevOps. What they need to do is simply hunt for opportunities to automate, and treat application development as part of their core value versus a cost center. The reality is that even if XYZ is not facing the same pressures of quality applications today, it’s only a matter of time until they will. Eventually, technology will be such a part of their core business that better applications will be required.

Unicorns Not Required

You do not need to be a unicorn company or development team to embrace DevOps, because DevOps is the practice which drives greater efficiency of your operations and delivery chain, not the prescription on how to build it. The bleeding edge tools are there, and will always be there. But to embrace DevOps, you don’t need to use all of them. What you really need to do is focus on automation, quality, and the responsiveness of your software delivery chain.