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.





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


  • Robert,

    I agree with most of what you write, but I think that some aspects of DevOps can be adopted into even the most critical and stable environments. Continual integration into a test environment with full automated end-to-end testing of each module as it is checked in is entirely appropriate here, as is automating deployment to ensure that it is always done correctly.

  • Hi Stuart.

    What happened to the world where we did end to end testing as part of the migration of change and innovation to production? I think we all still do this, I think that the growing complexity of “releases” that made this difficult as so much of it was manual.

    As you correctly state, “continual integration into a test environment with full automated end-to-end testing of each module as it is checked in is entirely appropriate here, as is automating deployment”, is great re-learning for us all!


  • Another thing we can learn from the DevOps people is the integration of tools and processes for Change and Release Management with those for the Software Development Lifecycle (SDLC). I know of one place where submission of a change request for deployment just needs a single click of one button. All the required artifacts are already in place by the time they get to that point and the tools automatically put things in the right format.


Insights from the app driven world
Subscribe Now >
The Sociology of Software >How (Not) to Lie with Data Visualization >DevOps and Cloud Computing: Exploiting the Synergy for Business Advantage >