News, Reviews and Resources for ITSM Professionals.

Trust me: The DevOps Movement fits perfectly with ITSM

Home » itSMF, Opinion » Trust me: The DevOps Movement fits perfectly with ITSM

Gene Kim

Gene Kim

This article has been contributed by Gene Kim, Author of the book “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win”.

In my thirteen year journey of studying high performing IT organizations, I’ve started to see a new and unsettling trend.  Whenever I mention ITIL and IT Service Management in presentations and briefings, people in the audience snicker. When I ask why, they roll their eyes, and talk about the shrill, hysterical bureaucrats that suck life out of everyone they touch, doing everything they can to slow the business down, preventing everyone from getting work done.

This is simply not true. In fact, every time I’ll argue that ITSM skill sets are ever more important in a world where there is an ever quickening business tempo.

However, an even more troubling trend is that ITSM practitioners will dismiss emerging movements such as “DevOps,” suggesting that it’s a passing fad.

It is my genuine belief that that patterns and processes that emerge from DevOps are the inevitable outcome of applying Lean principles to the IT value stream.  It is an inexorable force that will likely change IT in a manner we haven’t seen since the birth of client-server computing in the 1980s.

More importantly though, ITSM practitioners are uniquely equipped to help in DevOps initiatives, and create value for the business.

The DevOps Movement fits perfectly with ITSM. My goal is to help you become conversant with DevOps and aid you in recognizing the practices when you see them. I hope this article will illustrate how information practitioners can contribute to this exciting organizational journey.

What Is DevOps?

The term “DevOps” typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations, resulting in the fast flow of planned work (i.e. high deploy rates), while simultaneously increasing the reliability, stability, resilience and security of the production environment.

Why is it that Development and IT Operations are singled out?  Because that is typically the value stream that is between the business (where requirements are defined) and the customer (where value is delivered).

The origins of the DevOps movement is commonly placed around 2009, as the convergence of numerous adjacent and mutually reinforcing movements, most notably the  “10 Deploys A Day” presentation given by John Allspaw and Paul Hammond and the Agile system administration movement (Patrick DeBois).

Currently, DevOps is more like a philosophical movement, and does not yet have a precise collection of practices, descriptive or prescriptive (e.g. CMM-I, ITIL, etc.).  On the other hand, it is an incredibly vibrant community of practitioners who are interested in replicating the performance outcomes and culture described so vividly by organizations such as Etsy, Amazon, Netflix, Joyent and so forth.

DevOps aims to address a core, chronic conflict that exists in almost every IT organization.  It is so powerful that it practically pre-ordains horrible outcomes, if not abject failure. The problem? The VP of Development is typically measured by feature time to market, which motivates as many changes, as quickly as possible.  On the other hand, the VP of IT Operations is typically measured by uptime and availability.

Until very recently, it was impossible to get both desired outcomes of fast time to market and sufficient reliability and stability.  Because of these diametrically opposed outcomes (“make changes quickly” vs. “make changes very carefully”), Development and IT Operations were in a state of constant inter-tribal warfare, with ITSM practitioners put right in the middle.

Although many people view DevOps as backlash to ITIL (IT Infrastructure Library) or ITSM, I take a different view.  ITIL and ITSM still are best codifications of the business processes that underpin IT Operations, and actually describe many of the capabilities needed into order for IT Operations to support a DevOps-style work stream.

I am part of a team who wrote “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win”, which codifies the “good to great” transformation we’ve observed these organizations making.  Our goal is to create a prescriptive guide that shows how Development, IT Operations and ITSM practitioners can work together to create phenomenal organizational outcomes that none of them could achieve alone.

What are the unpinning principles of DevOps?

In “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win” we describe the underpinning principles in which all the DevOps patterns can be derived from as “The Three Ways.”  They describe the values and philosophies that frame the processes, procedures, practices, as well as the prescriptive steps.

image 1

The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).

The focus is on all business value streams that are enabled by IT.  In other words, it begins when requirements are identified (e.g., by the business or IT), are built in Development, and then transitioned into IT Operations, where the value is then delivered to the customer as a form of a service.

The outcomes of putting the First Way into practice include never passing a known defect to downstream work centers, never allowing local optimization to create global degradation, always seeking to increase flow, and always seeking to achieve profound understanding of the system (as per Deming).

image2

The Second Way is about creating the right to left feedback loops.  The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made.

The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it.

image3

The Third Way is about creating a culture that fosters at two things:  continual experimentation, which requires taking risks and learning from success and failure; and understanding that repetition and practice is the prerequisite to mastery.

We need both of these equally.  Experimentation and risk taking are what ensure that we keep pushing to improve, even if it means going deeper into the danger zone than we’ve ever gone.  And we need mastery of the skills that can help us retreat out of the danger zone when we’ve gone too far.

The outcomes of the Third Way include allocating time for the improvement of daily work, creating rituals that reward the team for taking risks, and introducing faults into the system to increase resilience.

What Are The Areas Of DevOps?

We divide up the DevOps patterns into four areas:

area1

Area 1: Extend Development into IT Operations:

In this area, we create or extend the continuous integration and release processes from Development into IT Operations, integrating QA and infosec into the work stream, ensuring production readiness of the code and environment, and so forth.  The steps include:

  • Create the single “repository of truth” containing both the code and environments
  • Create the one-step Dev, Test and Production environment build process
  • Extend the deployment pipeline processes into production
  • Define roles and integrate QA, Infosec, Ops/CAB into Dev workstream

First,  we put everything needed to rebuild the service into a common repository from scratch, including both the application and the environment (i.e., operating system, databases, virtualization, and all associated configuration settings).

Next, we will make a one-step environment creation process available at the earliest stages of the Development project.  By using a common build process and requiring that Development be responsible for ensuring that the code and the environment work together, we’ll have an unprecedented level of production ready, even at the earliest stages of the development project.

This impacts the ITSM process areas of release, change, and configuration management.  The ways that ITSM practitioners can actively integrate into the DevOps value stream includes the following:

  • Find the automated infrastructure project (e.g., puppet, chef) that provisions servers for deployment.  We can help that team with our release management readiness checklists, security hardening checklists and so forth, integrating them into the automated build process.
  • Define pre-authorized changes and deployments, and ensure that production promotions are captured in a trusted system of record that can be reviewed and audited.
  • Define changes and deployments that require authorization, such as security functionality that is relied upon to secure systems and data (e.g., user authentication modules).  The goal is to ensure that changes that could jeopardize the organization (e.g., the infamous 2011 Dropbox failure where customers discovered that authentication was disabled for four hours) never occur.

Area 2: Create IT Operations feedback into Development

The steps in this area ensure that information from IT Operations is radiated to Development and the rest of the organization.  IT Operations is where value is created, and this feedback is required in order to make good decisions.

The specific steps in this area include:

  • Make all infrastructure data visible
  • Make all application data visible
  • Modify the incident resolution process and blameless post-mortems
  • Monitor the health of the deployment pipelines

The first step overlaps with the ITSM process areas of event management, while the second step requires creating the monitoring infrastructure so that there’s no excuse for developers not to add telemetry to their application (e.g., “since it only requires one line of code, even the laziest developer will instrument their code”).

The third step then enables IT Operations and Development to resolve incidents quickly, by ensuring that all relevant information from the entire application stack is at hand to determine what might have caused the incident, and then to restore service.

ITSM practitioners can help by ensuring that the process areas of event management, as well as incident, problem and knowledge management are modified to incorporate Development.

Area 3: Embed Development into IT Operations

According to the Second Way, the goal of steps in this area is to create knowledge and capabilities where we it is needed, and shorten and amplify feedback loops.  A delightful quote that frames this comes from Patrick Lightbody, CEO, BrowserMob.  He said, “We found that when we woke up developers at 2am, defects got fixed faster than ever.”

To facilitate creating tribal knowledge within IT Operations and shared accountability for uptime and availability with Development, the steps in this area include:

  • Make Dev initially responsible for their own services
  • Return problematic services back to Dev
  • Integrate Dev into the incident management processes
  • Have Dev cross-train Ops

Area 4: Embed IT Operations into Development

This area is the reciprocal of Area 3, and the goal is to create the service design and delivery equivalent of designing for manufacturing (DFM).  In plant engineering, DFM recognizes that the primary customer of engineering is the manufacturing personnel, and therefore one of the engineering goals is to parts are designed for easy assembly, minimizing the likelihood of putting on parts on backwards, over-tightening, being damaged during transit or assembly, and so forth.

Similarly, in addition to ensuring that IT Operations needs are integrated into the daily Development processes of design, requirements specification, development and testing, the product and processes are designed with resiliency in mind.

The steps in this area include:

  • Embed Ops knowledge and capabilities into Dev
  • Design for IT Operations
  • Institutionalize IT Operations knowledge
  • Break things early and often

This includes embedding or liaising IT Operations resources into Development, creating reusable user stories for the IT Operations staff (including deployment, management of the code in production, etc.), and defining the non-functional requirements that can be used across all projects.

Conclusion

It is my firm belief that ITSM and the DevOps movement are not at odds. Quite to the contrary, they’re a perfect cultural match. As DevOps gains momentum I’m excited by what we can achieve using a winning combination of the two. It is my sincere hope that by reading this article, you’ll better understand what DevOps is, see why it is important and be energized by the possibilities it creates, and generate some ideas of how to put some of these practices into place in the IT organizations you help support.

You can hear more from Gene on this topic at the itSMF Norway conference taking place in Oslo, 12-13 March.

 

Guest Contributor

This post was written by a guest contributor. Please see their details in the post above. If you'd like to guest post for The ITSM Review please contact us.

More Posts - Website




10 Responses to " Trust me: The DevOps Movement fits perfectly with ITSM "

  1. Well, it was my intent to summarise my learning from my year-long exploration of the intersection of DevOps and ITSM, which I called Kamu http://www.itskeptic.org/kamu (see also the G+ community https://plus.google.com/communities/100333597017661142255 ).

    But I don’t need to. Thanks Gene 🙂

    This article summarises beautifully how DevOps and ITSM should work together and answers a number of my questions.

    The only proviso I’d add is that – like the Phoenix Project book – it makes it all sound too easy. There is so much re-engineering hidden in a phrase like “Create the one-step Dev, Test and Production environment build process”. It’s hard enough in the green-field and stand-alone systems where DevOps excels, let alone in legacy systems.

    This is a massive journey. Some of us won’t make it. And for some of us we shouldn’t try: if the legacy environment is sufficiently entangled and embedded in old technology, and sufficiently high risk (think forex) then it would be folly. Once again there is much hidden in a phrase like “Experimentation and risk taking are what ensure that we keep pushing to improve, even if it means going deeper into the danger zone than we’ve ever gone” that no CEO should let slip past without examining the organisational risk.

    So i don’t agree about the universality and inevitability of DevOps, at least not in any useful planning horizon. Nevertheless I agree DevOps has much to teach us. Carefully. Thanks again Gene.

    • Byron Miller says:

      Some of the vocabulary & process of the 3 ways (As explained above) is tough to translate to legacy/COTS application support typical in large enterprise shops and is largely open to interpretation if you ask me. Because of this interpretation, there is lots of room for some amazing opportunities to help define “DevOps” type methodologies framed in a more corporate / enterprise architecture. I’d love to discuss more of this with you and pick your brain over time.. hit me up if you’re interested 🙂

  2. […] DevOps thinking and how the DevOps and ITSM practices are decidedly complementary to each other. Trust me: The DevOps Movement fits perfectly with ITSM (The ITSM […]

  3. […] Kim, G. (2014). Trust me: The DevOps movement fits perfectly with ITSM.Disponible en: http://www.theitsmreview.com/2014/03/trust-devops-movement-fits-perfectly-itsm/ Fernández, CM. Piattini, M (2013). Modelo para el gobierno de las TIC basado en las normas ISO. […]

  4. […] Kim, (2014) – Trust me: The DevOps Movement fits perfectly with ITSM […]

  5. […] DevOps guru Gene Kim describes in this article on the integration of DevOps with […]

  6. […] This article from Gene Kim provides an introduction to DevOps also makes the most essential relevant point – That implementing DevOps is an exercise in optimizing software and IT service delivery from a whole systems thinking point of view, and hence why it is synergistic with ITIL, the internal IT procedure framework that deals with the same systems management tasks. […]

  7. […] This article from Gene Kim provides an introduction to DevOps also makes the most essential relevant point – That implementing DevOps is an exercise in optimizing software and IT service delivery from a whole systems thinking point of view, and hence why it is synergistic with ITIL, the internal IT procedure framework that deals with the same systems management tasks. […]

Leave a comment