DevOps Zone is brought to you in partnership with:

Leaving university, I thought I'd be a developer happily knocking out code but was always drawn to tech support. How do we help people use our tools better? Now, I mostly specialize in consulting and introducing new customers to our tools. I am a Tech Evangelist and Lead Consultant at Urbancode. Eric is a DZone MVB and is not an employee of DZone and has posted 78 posts at DZone. You can read more from them at their website. View Full User Profile

Breaking Down IBM’s Definition of DevOps

06.04.2013
| 3980 views |
  • submit to reddit

As there is no “official” definition for DevOps, many individuals and organizations have their own definition. This morning at Innovate, IBM introduced its take:

DevOps is an enterprise capability for continuous software delivery that enables clients to seize market opportunities and reduce time to customer feedback

Wow. That’s dense. It’s also good. In this blog post, I’ll unpack that definition and we can enjoy the tasty treats it contains.

“Enterprise capability”

When we say that DevOps is an “enterprise capability”, we are saying quite a lot. First, that there is no single individual, team or tool that “does DevOps”. DevOps emphasizes systems thinking as opposed to silo’d thinking. This is related to the first “DevOps Way” that Gene Kim promotes.

An enterprise that accepts DevOps will reject the notion that developers are there only to make new features and operations should only keep things runnings. Instead, a DevOps capable organization will recognize that the easiest way to keep things running is to never deploy the new features and that these mandates pit Dev and Ops against one another. Developers should have additional responsibility for building applications that are easy to test, release and monitor and operations must embrace changes.

“Continuous Software Delivery”

Gone are the days of 18 month release cycles. We strive to deliver more frequently and even continuously. Continuous software delivery means that we are continuously updating our back-logs (planning), and developing. These lessons we learned well from Agile. In fact, Agile practices are typical building blocks in a DevOps transformation.

That said, we also view completed, but unreleased features as an inventory waste: something we have invested in but are not yet deriving value from. When we look at the Agile Manifesto‘s call for valuing “working software” a DevOps capable enterprise reads “software working in production”. While automating production deployments may not be the immediate goal, we should be working to streamline that delivery.

Further, by “working” we do mean actually functioning. If releases are high risk, nail biting affairs we will not be able to do them frequently. Everyone in IT must contribute to driving down risk through better architectures, automated deployments, more consistent environment architectures.

Many organizations successfully underwent Agile transformations but lack the rapid planning, testingdeploymentand release capabilities to fully benefit from continuous software delivery. DevOps integrates agile development with continuous testing and deployment as well as continuous monitoring and customer feedback to assist in planning and backlog prioritization.

“That enables clients to seize market opportunities”

Why are we doing DevOps? Because traditional IT practices are too slow to meet the needs of our businesses. Companies increasingly compete on software and need to be able to rapidly change course, or exploit a new or transient market opportunity. The challenge before the industry is to become more nimble. DevOps focuses on building this nimbleness as an enterprise capability.

“Reduce time to customer feedback”

How do we know what to build? A big part is getting feedback from our users. While we often think of continuous delivery as a “left to right” process moving from development to production, knowledge flows “right to left” from test to development and from users in production towards the business.


Move artifacts left to right, and knowledge right to left in DevOps

Periodic focus groups aren’t enough. We want near instant feedback on each of our continuous, small releases. Are we making more money? Are the customers getting tasks done quicker? How often are error pages showing up? Do we need to rollback or change course? Authors that focus on business and technology often focus on putting together key metrics and acting on their trends. While tools can help a larger cultural change happens as IT operations is no longer seen just as the guys who keep the web site running, but also as key enablers of figuring out what changes should be made.

Wrapping it back up

So there you go. A dense little definition that encourages better cross-silo collaboration and systems thinking; an emphasis on faster delivery from idea to software working in production; more frequent, smaller changes that exploit market opportunities, and faster feedback that supports experimentation and learning.

This “big” definition of DevOps focuses on more than just the relationship of development and operations. While DevOps is named for bringing those two warring groups together, the vision is broader. IT should be working to serve business goals, and will be more successful if different functional silos collaborate rather than fight.

Published at DZone with permission of Eric Minick, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)