DevOps 101: Why DevOps Matters to Large Enterprises

DevOps isn’t something you can buy -- it’s something you have to do, and you have to do it yourself.

DevOps isn’t something you can buy — it’s something you have to do, and you have to do it yourself. The goal is to promote integration and collaboration of development and operations teams, so that we can accomplish faster time to market, with lower costs and higher quality.

We would never design and build cars, computers, or airplanes the way we build software today. For each of the disciplines involved in application development and delivery — development, testing, and operations — the mindset has to change.

We need to build software the way we build computers: The CPU, graphics card, and the hard drive already work before we go to assembly. We don’t have to cross our fingers, hoping all of the components will work together when we turn on the finished product.

DevOps gives us an opportunity to build the software development conveyor belt.

Software testers also have to stop thinking about their primary function as doing the testing. Instead, machines should be doing that work, and the testers should think of themselves as test engineers, building the engineering that tests the system for us. If I need to test this bit of software five times today, I have a machine do it five times, not a person doing the activity five times manually. This is the only way we are going to be able to up the rate of change without adding risk of failure.

The Ops mindset faces a lot of change, too. The traditional role for Ops is to watch systems and think in terms of infrastructure, but really it’s about application delivery. They need to think that they are part of the goal of fast, safe delivery of applications.

I recently worked up a video on DevOps 101, discussing the basics behind DevOps and why it is important for larger organizations to begin implementing this methodology. Please give it a view:

John Michelsen is CA's former CTO. He is no longer employed by CA Technologies.


  • When it comes to core transformation, it’s not really about the features. Without changing the way software is delivered, as soon as the transformation is complete, companies will be right back where they started. With a backlog of “feature requests” addressing new requirements or technologies.

    It’s not (only) the core application that needs to change, but the organizational process that delivers software to the enterprise. Employees (and customers) are having their experiences set by consumer technology. It’s no longer OK for IT to deliver like Microsoft (trivial updates for a year or two that make no difference to the user until a big update comes ever 12-36 months).

    Personally, I love when I’ve been away for a few days, come back to my phone and see a whole lotta app updates. Those updates often help me do the things I do, better. Who wouldn’t be excited? Why can’t we get that excited by enterprise tech?

    Some color to illustrate the point:

  • Pingback: Changing How You Deliver Software, Not What Software to Deliver - Shades of Grey in a Binary World()


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 >