Is DevOps Destroying the Wall Between IT and the Business?

Why is it that, after so many years, there's still a prevailing IT conflict between Development and Operations, especially in relation to changes being promoted to Operations?It wasn't always that way.

Why is it that, after so many years, there’s still a prevailing IT conflict between Development and Operations, especially in relation to changes being promoted to Operations?

It wasn’t always that way. In the early days of virtualization, the Development organization tested and then promoted change in virtual environments. Operations then worked it out and brought controls to bear. With the cloud, the same controls have started to appear, but there’s far greater business demand for innovation, differentiation and delivery of capabilities to help maintain competitive advantage.

And there are other differences, too. In most organizations, Application Development has dealt directly with the business and felt the brunt of the pressure to perform. But in today’s resource strapped environments, everyone is aware of the business cadence, and is feeling the heat.

So why is there still such a conflict between Development and Operations?  For one, there’s a fundamental metric difference between the two groups.  The Development organization is often compensated on code completion for a requested business change. The Operations team usually has site reliability as a major component of its performance. So one group is paid for change while the other is paid to reduce the change impact and the supporting operational processes, including change review, release management and back out strategies.

Given the rate at which new code has to be put into production, we can’t have a formal change advisory board for everything. But some changes do require a formal review process because of the risks and potential business impacts.

A primary imperative in this era of continuous change is therefore to understand exactly where to accelerate delivery with the fully automated introduction of new code into the production environment and where to enforce more formal change management processes. To do this, we need to classify systems into logical groupings that incorporate all relevant change-related attributes – including delivery cadence, risk tolerances and system type (i.e. systems of innovation, systems of differentiation or systems of record)  Based on these attributes, we can implement the most appropriate change process for any given piece of code.

In other words, business agility isn’t just about adopting ITIL and/or DevOps in some global or undifferentiated way.  It’s about applying best practices from both in a context-intelligent way – so the business can become more agile while simultaneously getting even better at mitigating IT-related risk.

Let’s think about demand for a moment. All demand is not created equal. If we are driving innovation, looking for rapid change, delivering on a mobile device with consistent and continual updates, DevOps is more often than not the correct philosophy.

When we are adding capabilities to an ERP system, which is considered a system of record, we’ll make changes in a structured manner with multiple groups. So cultural change management will be critical, and therefore the use of good process as defined within ITIL is more appropriate.  (Systems of Record will be updated on a scheduled process and these systems will typically have a long lifecycle in terms of organizational value.)

Of course, there is also Systems of Differentiation–applications that enable unique company capabilities and have a medium lifespan of three or more years, but require constant renewal or reconfiguration to meet changing business practices or customer demands.  Depending on the use and phase of the lifecycle, these applications will typically use DevOps at the beginning of the lifecycle and as they become subject to more structure and rigor.

Most organizations today are realigning priorities to better leverage IT investments with business objectives and new technologies. In the area where I work, we are planning to double our investment in Systems of Innovation. This is where DevOps excels. It can improve the value stream with greater frequency of delivery and focus on the feedback loop, which should extend across the entire life cycle of the solution to provide insight and value.

For instance, closed loop feedback delivers insight into the performance of a recent configuration updates, including critical information to assist in shaping future products in areas such as usability while minimizing education requirements.

One of the key components of DevOps is the concept of integrated tool chains across the life cycle. An associated success factor is automating as much of the complete cycle as possible, with the objective of accelerating the change velocity — not just to improve speed but to improve reliability and auditability. Doing this with an end-to-end perspective in mind, however, requires combining the individual technologies in a manner that facilitates what the financial services industry refers to as “straight through processing.”

Like all things in IT, the key to success is having the correct people. This area is often overlooked. The best DevOps-oriented team members won’t just be technically adept—they’ll be looking to innovate and advocate a culture of value to the business.  If the issues associated with culture and people aren’t effectively addressed, technology investments won’t deliver the desired value.

In an attempt to drive change velocity and innovation, DevOps could be for you. But remember, it’s not a panacea. It is a philosophy, a piece of the puzzle.  It can’t do it all.

Share your thoughts in the comments section below.





Written by

Robert Stroud

Robert Stroud is VP of innovation and strategy for IT Business Management at CA Technologies.…

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

  • 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.

  • 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.