Why DevOps matters to business

Why DevOps matters to business

Summary: There's a new game in town, called DevOps, which helps deliver business innovation on the same compressed 'jump in and iterate' cycles we associate with cloud application development


The cloud means that business people have to care more than ever about application development. But not old-style app dev — there's a new game in town, called DevOps. While I say 'new' it's been around for a couple of years in the cloud computing arena (I was introduced to it a while back by the team at OpsCode), but its impact is now becoming more prevalent. Just last week, Eric Knorr over at InfoWorld wrote about Devops and the great IT convergence.

Before I go on, a quick plug: if you happen to be at (or want to come to) Cloudforce London this Thursday September 15th, EuroCloud UK is hosting a meetup that afternoon to discuss How the Cloud Changes App Dev. I'm chairing the meeting, and I'll be sure to ask about the role of devops. We have a speaker panel from Bluewolf, Fujitsu and Grove IS with expertise in Force.com, Google AppEngine and heroku, plus other knowledgeable participants who'll contribute to a free-ranging discussion. [Disclosure: I'm chair of EuroCloud UK and we're at this venue courtesy of Salesforce.com].

So what is devops? In essence, it's the principle that development should not happen in isolation from operational delivery (and vice-versa). In the past, the team that built an application were separate from the team responsible for getting it up-and-running. Inevitably, this was a recipe for delay, disruption and duplication of effort. In the old batch-delivery world of project-based IT, that didn't matter so much, but in today's fast-moving cloud IT environment, it kills momentum.

This matters to business people because they want their business requirements delivered as rapidly as possible. By fusing application development with operations into an integrated process run by a joined-up team, you can shorten delivery timescales to fit into the same, agile, two-week sprint cycle in which development happens. Damon Edwards explained the business context of devops very eloquently in a blog post last year:

"The most fundamental business process in any company is getting an idea from inception to where it is making you money ... The whole point of DevOps is to enable your business to react to market forces as quickly, efficiently, and reliably as possible."

This fits in with the 'jump in and iterate' mojo of cloud application development and the commensurate expectations of line-of-business managers, who are looking for product delivery cycles to shorten months down to weeks. So devops isn't just an IT phenomenon, it has huge implications for how businesses operate and innovate too. I have a whole lot more to say on this topic in future blog posts. Meanwhile, for a taster, listen to the webcast I delivered last week on 7 Ways the Cloud Changes How You Think About IT.

Topics: Enterprise Software, Apps, Browser, CXO, Software, Software Development, IT Employment

Phil Wainewright

About Phil Wainewright

Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • DevOps done well....

    transcends issues such as delivery speed and duplication of effort. Ideally, DevOps should help groups increase awareness of each other's needs as far as information management, sharing, protection, distribution, etc. Most of the inefficiency and cost isn't in app dev, deployment, and maintenance...it's in information mishandling once the apps have been deployed.
  • Best practices

    Great stuff Phil.<br><br>See our best practices guide on DevOps:<br><br><a href="http://www.cloudbestpractices.info/DevOps" target="_blank" rel="nofollow">http://www.cloudbestpractices.info/DevOps</a>
    Cloud Best Practices
  • What drives me crazy

    The thing that drives me totally crazy is that twenty to thirty years after the fact, we have not gotten past these issues. Issues that I had addressed in both method and practices in the '80's and very early '90's. I used to think this wasn't rocket science as me and my team did Agile and DevOps each and every day. Hell, they were doing it just fine without me as the door literally hit me in the ass as I was leaving (disability discharge) the US Navy. I guess it really is rocket science.

    Structured methodology was supposed to fix all the ills of IT. Then it was Object Oriented. ... Now it is Agile and again an iteration of Agile called DevOps. All of these methodologies were how I was doing things all along using damned assembly language on an IBM/370. At the tender age of 14! I *thought* this was how everyone did things. This was what I taught my students and co-workers.

    Unless and until IT actually meets and greets standard engineering practices, especially process engineering, y'all will keep reinventing the past.

    [Grumbling back into my cave]
    Brian J. Bartlett