It would seem that the devops discussion is mostly driven by development’s incentives, and appropriately so, given developers’ focus on building functionality for the business user. So it’s no surprise that development is the originator of the whole devops lifecycle, but are there any dangers lurking in a one-sided focus on devops issues?

A hefty majority of devops articles come from writers of the development persuasion who are motivated by the legitimate frustrations of the application deployment process. The movement to agile development has been a key contributor in the increase of handicaps encountered as a result of more frequent transitions from development to operations IT groups. Online and verbal discussions identify the primary challenge as getting IT operations to be more creative and flexible in their approach to changes coming from the application development discipline.{1}

Given its critical involvement in deploying new and enhanced applications, why hasn’t IT operations been more active within the devops movement? Given the opportunity for IT operations to be more effectively heard by its primary IT companion organization, why hasn’t IT ops been more responsive to devops strategic initiatives? Given that changes to the operational model are almost guaranteed, why isn’t IT ops more proactive in anticipating such changes? Given the need for more effective alignment with the business user, whose automation needs are frequently accommodated by inhouse development, why hasn’t IT ops seized the chance to leverage this obvious path to improving IT’s core value proposition to end-user communities? I’ve heard many theories, but few have resonated.

Devops is a maturing discipline and is obviously offering an increasingly visible value proposition for the enterprise. This growing devops “maturity” is driving more effective partnerships and better integration opportunities. That’s the good news. The bad news is that the devops partnerships and integrations are not coming fast enough to appease the significant IT market demand. One proof point is the rapid escalation in demand for SaaS application deployment, which is a symptom of the ongoing struggle between development and operations groups in satisfying end users’ business demands. Competitive options now exist (and are expanding) for businesses to choose alternatives to IT-delivered and -supported applications, which further fuels the customer’s questioning of IT’s contribution to achieving corporate business objectives.

“Services” Mindset of IT Operations Essential to Devops

Fundamental to understanding the mindset of IT operations is its emphasis on delivering and maintaining “services” that are of value to the business community.

Solutions to business problems and support for business models, strategies, and operations are increasingly in the form of services. The popularity of shared services and outsourcing has contributed to the increase in the number of organizations who are service providers, including internal organizational units. This in turn has strengthened the practice of service management and at the same time imposed greater challenges upon it.{2}

An essential requirement for devops success is to think of, prepare, implement, and support the new application as a mandatory component of a service that is being offered to the business customer. That service is positioned as having an intrinsic value that is broader than the application by itself; as a result, the business executive can easily identify it as critical to achieving business goals. IT operations brings a rich experience of managing those services to devops initiatives. Ops needs to be more aggressive about sharing that unique perspective at the same time that IT development needs to be more attentive to those IT service management (ITSM) best practices that are documented, promoted, and used on behalf of devops by its core practitioners.

IT operations has struggled for decades to deliver more and more technology services with fewer and fewer resources — and is actually doing a fair job.{3} Fundamental to that achievement has been a focus on ITSM best practices specifically designed for improving the operational alignment between IT and its business customers. These guidelines and processes have been captured and documented by leading ITSM professionals for the Information Technology Infrastructure Library (ITIL), funded by the UK’s Office of Government Commerce (OGC).

As a starting point for understanding the mindset, roles, and values of IT operations within the devops discussion, ITIL V3′s focus on delivering business value through more effective IT services is invaluable. ITIL positions these best practices as “based on expert advice and input from ITIL users [and] … both current and practical, combining the latest thinking with sound, common sense guidance.”{4} The success of that “common sense” approach has contributed significantly to the rapid acceptance and global implementation of ITIL V2 and V3 by ITSM organizations over the last 10 years.

Bridging the Devops Gap

So what might the operations perspective on devops initiatives be? I would offer that ITIL’s V3 Application Management (AM) function {5} is probably one of the more useful resources available for describing that operational viewpoint. It is written as a set of best practices or guidelines for supporting …

the organization’s business processes by helping to identify functional and manageability requirements for application software, and then to assist in the design and deployment of those applications and the ongoing support and improvement of those applications.{6}

As such, ITIL AM is designed to help bridge the devops gap and articulate some of the common language or terminology now lacking between the development and operations organizations.

As a process improvement approach, the Capability Maturity Model Integration (CMMI) has become a highly successful, best practice model for software engineering. CMMI is a set of process guidelines driven primarily by development’s need to deliver applications of value to the business user and secondarily by how the end customer uses the application as a service to achieve business purposes. This is a subtle yet critical distinction. The CMMI model does not adequately address the service mentality and service priorities of the IT operations organization, which has fully embraced ITIL for that role instead.

In the August 2011 issue of Cutter IT Journal, Bill Phifer of HP Enterprise Services created a compelling case for embracing a host of ITSM processes, with the ITIL Service Lifecycle becoming the needed counterbalance to the development perspective that is incorporated and respected within CMMI (see “Next-Generation Process Integration: CMMI and ITIL Do Devops,” Vol. 24, No. 8). The strength of ITIL is its unrelenting emphasis on “serving” the needs of the business community and adapting any IT deliverable to the “whole” of the system — as perceived by the business customer, not IT operations. For devops, this requires a correlation of management processes and tools that can address the demands coming from end users, business functions, and technologies as well as applications. ITIL in its intended form {7} does not create a focus on IT management processes for the sake of IT personnel. An ITIL-oriented project fails miserably when such an IT-only focus happens.

Notes

1 Read, Chris. “DevOps: State of the Nation.” Agile Web Development & Operations, 30 November 2010.

2 Introduction to the ITIL Service Lifecycle. ITIL V3. Office of Government Commerce (OGC), 2010.

3 McAfee, Andrew, and Erik Brynjolfsson. “What Makes a Company Good at IT?” The Wall Street Journal, 25 April 2011.

4ITIL (www.itil-officialsite.com).

5 ITIL Service Operation. ITIL V3. OGC, 2007. (ITIL published a “Summary of Updates” in August 2011; see www.itil-officialsite.com.)

6 ITIL Service Operation. See 5.

7 Fry, Malcolm. ITIL Lite: A Road Map to Full or Partial ITIL Implementation. The Stationery Office, 2010.

avatar

Bill Keyworth

William Keyworth focuses on IT operational excellence. Bill has established a reputation as a credible and consistent voice in maximizing business value from IT operations.

Discussion

  9 Responses to “Where Is IT Operations Within Devops?”

  1. I guess I’m bemused by the claims I hear sometimes that DevOps “comes from Dev” or that most of the activity or practitioners come from the development side. That is absolutely not my experience.

    The vast majority of initial interest in DevOps was from Ops professionals – via Velocity and DevOpsDays, and Opscamp. It had its origins in the Agile Infrastructure movement and the initial sponsors were sysadmin-arena vendors in the monitoring and system provisioning spaces. I know that certainly many devs have gotten involved especially from the continuous integration side, but my experience has been of Ops driving DevOps initiatives, not being dragged there by Dev (although certainly in response to their dev customer requirements for more release velocity).

  2. avatar

    In my experience, CMMI undermines Agile and ITIL (as usually interpreted, rather than as a framework for describing ITSM) undermines Devops:

    CMMI is brilliant for building something that can be fully specified upfront (eg a satellite). It’s much less useful where requirements evolve or cannot be understood a priori. Agile’s emphasis is on getting early feedback, to validate implementations, but also designs/understanding of requirements. In practice, this is coming to mean instrumenting the application to understand actual behaviour, rather than interviews to gather opinions.

    ITIL’s underpinned by Configuration Management (you’ve got to know what you’ve got and how it’s set up to support most of the processes and functions). However, ITIL’s concept of CM is very different from the Devops view of CM: “treat infrastructure as code”, which arises from the observation that how the infrastructure’s set up can be just as important as the source code of an application.

    How’s the world getting on at having a common revision control system across Dev and Ops?

  3. In response to Tim’s last question, we use a common revision control system across Dev and Ops here. All artifacts – code, configs, system model – are in RCS (Perforce in our case) and we wrote a model driven automation tool that instantiates it all in the cloud dynamically. Then, even when certain binary chunks (VM images, Windows updates) aren’t in our own revision control per se, pointers to them are (similar to many folks don’t keep images or other blobs in their revision control for Web sites).

    A good 1/3 of DevOps is Ops learning best practices from devs, and using the same revision control is one of them. (1/3 is Dev learning best practices from Ops, and 1/3 is the interface between the two, IMO.)

  4. As for Tim’s first points – it is possible to implement an ITIL (or CMMI) approach that is friendly to agile/DevOps but it is certainly not the default. See “Visible Ops” by Gene Kim, a standard reference for WebOps folks, as an “ITIL-lite” approach.

    One does wonder if it’s so much against the grain that it’s not worth it – like it’s probably possible to implement communism well despite its natural tendencies, but nobody has yet…

    I personally use the ITIL concerns as a guide but don’t get stuck in the weeds. Some of its guidance is quite aligned with DevOps and in fact promotes thinking more rigorously about it – think of what you’re delivering as a service, and DevOps spans the service design (Ops embed into Dev), service transition (CI and model driven automation), and service operations (devs also responsible for their app’s runtime) sections. Specific implementation tips do tend to be so “old school” and ignorant of virtualization/cloud/Web that they are best ignored in favor of new innovation, that’s true.

  5. I won’t dispute your personal observations about the strong interest in devops manifested by IT Operations. It is definitely there…but I would venture that the source for thought leadership on the potential and best practices of devops seems to come mostly from development. Why is that? I tried to highlight how Development still carries ultimate responsibility for getting the applications initiated, tested and implemented and the primary purpose behind devops is to smooth the transition of that code change into the existing infrastructure …the very infrastructure in which IT Operations naturally resists change. For me the contrast between CMMI, ITIL and Agile is interesting as case study criteria in that it highlights where the leadership for devops is coming from within the organization. (…and I agree that ITIL should be accommodated as guidelines for best practices and not a formal project checklist.)

  6. avatar

    I would agree that the “Services” Mindset of IT Operations is crucial to its success.

  7. I found this quote interesting “Online and verbal discussions identify the primary challenge as getting IT operations to be more creative and flexible in their approach to changes coming from the application development discipline.”

    It would almost seem that Devops is focused on removing inflexible barriers or perceived heavy handed controls on moving application changes to production. Meanwhile the folks in Operations adopting ITSM are working with a focus on ensuring Service Availability through fit for purpose controls. (potentially conflicting goals)

    The operations perspective is well founded in that most data tends to point to changes to production being the primary source of service downtime.

    I have written a perspective piece on the roles of Release and Change Management in respect to this challenge.

    The Primary Roles of Release & Deployment Management
    http://bit.ly/uujNN2

    Troy

  8. Troy, your description of roles as identified within the IT Ops “service” perspective was a worthwhile read. It highlights how many processes, tasks, groups and tools have to play together in order to get the application released and deployed. Without this kind of high level service perspective, it’s easy to see how quickly and easily the relationship between development and operations gets sticky. Thanks for sharing … Bill

  9. Hi,
    While conventional application development is a huge industry, IT development is in as much a research phase as it is under development.
    Thanks

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>