The more I encounter organizations adopting a DevOps approach, the more I believe that everyone needs DevOps. I increasingly see how it addresses fundamental problems that nearly every IT organization faces. If you ask senior executives if their organizations are doing DevOps, you often get a blank stare. However, ask them if they are doing anything to foster better collaboration and communication between Development and Operations and you will find that there is not a single organization that is not doing something in this effort.
I am also coming to understand that DevOps is at a crossroads and you can see the signs of it in the way companies are using DevOps. Like ITIL before it, instead of sticking to a “pure” DevOps methodology, many companies are adapting DevOps and forcing it to flex. DevOps is such a good idea, yet it is so utterly foreign for so many (especially large) organizations that it apparently cannot take root without some fundamental compromise. Indeed, becoming mainstream – in anything from music to technology – almost always means change and compromise.
One major factor driving this evolution of DevOps is that large, complex, and regulated IT shops have a different perspective on both development and operations – especially when it comes to anything that touches existing, complex ‘legacy’ applications:
- They cannot achieve the same levels of agility and personal responsibility as a smaller or less complex organization.
- They cannot stream new code into production and just shut down for a couple of hours to fallback if it fails.
- They rarely ever have ‘two pizza teams’ for development or operations (indeed, they are lucky if they have ‘two Pizza Hut teams’).
- They cannot sign up for cloud services with a credit card without exceeding their monthly limit and/or being fired.
- They cannot allow developers to access raw production data, let alone copy it to their laptop for development or testing.
- They cannot choose to stream new code into production in violation of a change freeze, or even without the prior approval of a CAB.
- They cannot just tell developers to carry pagers ‘until their software is bedded in’ (not least because their developers have always carried pagers, and on a full-time basis).
- They cannot put developers and operators together because one team works 24×7 shifts in 7 data centers while the other works 16-hour days in 12 different locations.
Large enterprises do more planning, too. This is simply the nature of the beast in a large environment, where there are exponentially more stakeholders and the ripple effect of change is exponentially greater than in smaller or less complex businesses. The complexity that is endemic in large enterprises requires more extensive planning, as it must accommodate more moving parts.
Indeed, this planning is critical because, with so many stakeholders, ‘continuous release’ and ‘continuous integration’ are just a part of new feature delivery. Large organizations must also plan for , ‘continuous user training’, ‘continuous support training’, ‘continuous procurement’, ‘continuous budgeting’, ‘continuous hiring’, ‘continuous documentation’, and ‘continuous enablement’, just to name a few.
In smaller organizations with multi-disciplinary teams, DevOps can handle this workflow integrally, but in large enterprises, these are all separate departments, each with perhaps hundreds of staff. For example, just think about the training effort associated with streaming new features every week into critical production applications, in an organization with thousands of (often less-skilled) front-office staff. This is not just impractical, but actually impossible.
Large enterprises also have very different security and compliance requirements – for better or worse, necessary or not. Audit and Compliance at a large public company will be highly disapproving of any developer who has full access to code, infrastructure and data in both test and production. For some businesses, this is so incredibly unacceptable that it might even be prima facie grounds for censure or even dismissal. Such enterprises need functional isolation, assured in systems and processes like privileged user management, identity and access controls, data protection, and yes, change controls and audit trails. Some enterprise advisors (like Gartner’s Cameron Haight) actively encourage large enterprises to consider security explicitly as part of a ‘DevOpsSec’ – and very smartly so, I would say.
All this is why I think we are starting to see the evolution of DevOps for large enterprises. While the core values of collaboration, integration, and communication are (or should be) constant, it is clear to me that big enterprises nevertheless need a new form of DevOps – something like a ‘Big DevOps’. Maybe this is a different beast entirely from the ‘true DevOps’ – and maybe we shouldn’t even use the term ‘DevOps’ in deference to the true believers – but this is an evolution that will and must happen, whether we like it or not, for large enterprises to really benefit from this new approach on a broad, enterprise scale.
So I feel that DevOps is at a crossroads between ideology and practicality and that a more enterprise-appropriate approach will push through, sooner or later. As IT leaders, we can either drive this change and guide these enterprises in the right ways to approach DevOps; or we can just sit back and allow them to adopt whatever they think makes up ‘enterprise-grade DevOps’. One way or the other, we are not stopping it. Big enterprises need DevOps too, and there is no room in their reality for pointless dogma. Ultimately DevOps will happen in the enterprise, even if it is not exactly the same DevOps that we have seen so far. I do believe that it is time for DevOps to evolve so large enterprises can do it too.
Because traditional, large enterprises need something different from the DevOps of web-scale business.
Big enterprises need Big DevOps.