Big Enterprises Need Big DevOps

The more I encounter organizations adopting a DevOps approach, the more I believe that everyone needs DevOps.

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. Strategy and planning future

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.

Written by

Andi Mann

CA Leadership

Andi is VP of Strategic Solutions at CA Technologies and an expert across cloud, mainframe,…

Published in


View this topic
  • James Holland

    This is great. Hooray for Disney’s imagineers!


    become a new brand in the share market research with its accurate research. Proven
    itself always right whether market is bull or bear. Last week all paid clients
    booked handsome profit in NIFTY, BANKINIFTY & STOCKS. Now for the coming
    week we expect more correction can come in NIFTY as the IRAQ issue is getting
    more tense, If it happens more then you will see a sharp fall in all world marketNSE BSE, STOCK TIPSbecause as we know all world run on
    crude & most of the crude comes from IRAQ. So be ready for a sharp fall so
    sell will be the best strategy for next week also. Traders can make a sell
    position in NIFTY around 7600-7650 with stoploss 7750 for the target of
    7300-7200.One can also make a sell call NIFTY 50 stocks as per NIFTY levels. You
    can also take our two days free trial to check our accuracy. For further updates
    you can visit our website.



  • king lear

    testing comment functionality, please do not publish this

  • Rachel Macik

    Love the personal pic :)

    • CAHighlight

      Thank you!

  • Plutora Inc

    This is a good case study. 2.3 sec’s off a login transaction is big.

  • Michele Hudnall

    While the analysts were hyping DevOps, I posted the oversight of not including security as part of that discussion as you are highlighting here. Instead of just talking DevOps, it should be DOS (what’s old is new again :-) – DevOpsSec. As a previous AppDev person, it’s the app, who’s using it, why and where rather than the device and having the service available.

    As you rightly point, out Security should be baked into the solution.

    Nice Post and Timely!


    • CAHighlight

      Thank you for your feedback Michele. Agreed – security cannot be overlooked. Appreciate your input!

  • Mitesh

    I would love a printed copy

  • Lars Johansson

    I love the idea of BYOID! This makes me choose if I am almost anonymous (with my Hotmail Nicname) or official with identity from an official organisation. My Identity Provider will attach identity with right level of LoA according to the need of the Service provider.

    • CAHighlight

      Thank you for your comment. BYOID has tangible benefits for end users and relying parties but it also has to be weighed in the balance with potential risks and liability concerns. It will be interesting to see how BYOID plays out in the enterprise.