Unlike ITIL, DevOps is more of a philosophy than a formal framework. DevOps, which is short for Collaboration between Development and Operations, arose as a movement within IT best practices when IT managers began to realize that something needed to be done to close the communication and collaboration gap between development groups and support operations staff.
After some time and examination, it became clear that there was no inherent conflict between the DevOps movement and ITIL—the two, in fact, are quite complementary.
The added value that DevOps brings to the ITIL framework lies in the tension created by forces at work within most IT service providers. Here are four ways a DevOps approach complements the ITIL framework.
1. Improve communication, collaboration and accountability
On the one hand, development teams are pressured by the business to deliver regular, frequent updates to apps, which are a key component of new and changed services. Small, frequent improvements in functionality can potentially boost user productivity, but also can carry the risk of destabilizing the production environment, affecting the availability of live operational services or causing destabilizing side effects. Operations, on the other hand, is charged with maintaining a balance between being responsive to the business and maintaining a stable IT infrastructure that provides high availability and delivers the service value that customers and users desire.
How DevOps complements ITIL:
- Through improved communications and collaboration, a DevOps approach to ITIL can bring visibility and a greater appreciation to development teams of the challenges faced by service operations.
- As a result, greater attention can be paid during development to assessing the impact of the new feature/functionality on existing IT support resources, capabilities and supporting infrastructure services. How these support services, resources and capabilities should be augmented or adjusted can then be factored into the design plan and development activities. The result is a service that not only features new and improved functionality, but also any improvements required in the area of IT supporting services, people resources and skills, and supporting systems and tools.
2. Overcome organizational barriers between teams
Development and operations teams often report to different senior managers within the organization. Development’s focus is on building new and improved software applications, responding to customer business units at an ever increasing rate. Secondary thought is given to how another part of the same organization will end up supporting this new or changed app, and what they will need in order to be effective. Emphasis is on delivering incremental chunks of new and improved software on a continual basis, matched to the customer’s specifications, without much regard to how those improvements work or perform in production. Often the attitude is, “The service desk will take care of that.”
How DevOps complements ITIL:
- By encouraging development to work more closely with operations, a DevOps approach helps overcome barriers, facilitating alignment between these internal teams. Development teams benefit from a broader exposure to the needs of operational support during design and development activities. Operational teams benefit by receiving early exposure to the design and development activity of new/changed services, and their supporting apps.
- As a result, operational supportability is more thoroughly considered in design and development activities, and the deployment and operation of the live “service” is much more effective.
3. Establish a uniform understanding of “value” across IT service functions
It is important to realize that “value” is a product of functionality, as well as the performance of that functionality. Not only what the app does, but also “how it does it,” is important. Is it available enough for the customer and user? Is it easy to use? Does it have enough capacity in terms of storage, bandwidth and compute power? Is it secure enough for the customer and users? Development’s focus is primarily the software app and the functionality delivered by that app. In production, however, the new/improved “app” is running on a number of supporting infrastructure services—network services, supporting platform services (mobile, smartphone or other device), interacting with or supported by other apps or services.
The app is in reality an element (albeit an important element) in a “service,” which is composed of multiple elements and supporting services or components. The challenge of operations is to ensure that the whole “service,” of which the app is a key part, is delivering the value sought by the user—in terms of the desired functionality, but also in terms of its performance.
How DevOps complements ITIL:
- DevOps helps assure that operations and development, as well as other functions, appreciate that it is the “service” that delivers the value to customers. According to the ITIL framework, the “value” of a service is a product of the utility delivered by the service, but also the warranty of that service. Think of “utility” as the functionality of the service—what it does, its “fit for purpose.” Users definitely want utility or functionality. But they also need sufficient levels of “warranty” in order to use the service. Warranty is the assurance that one is able to use the service when required (in other words, it’s “fit for use”). Aspects of warranty include acceptable levels of service availability, capacity, continuity, security and usability. For example, you might have a great smartphone with a cool app that provides lots of functionality, but what good is that if you can’t connect to a cellular or wireless network in order to effectively use that app? Without the desired levels of warranty (availability, capacity, continuity, security and so forth), the user will not be able to realize the full extent of the “value” from the service.
- ITIL, when used with a DevOps approach, places emphasis not only on the development and timely delivering of new and improved functionality, but also on the ongoing performance of that functionality when in live operation.
4. Ensure early participation in design and development
Development groups are typically focused on carrying out time-bound, project-oriented activities—developing discrete chunks of software code within limited timeframes, in order to meet deadlines and deliver increased functionality to apps in production. Their priority is on developing and delivering improved functionality—not so much as how that functionality will operate day in and day out while in production. Operations, in contrast, is charged with supporting both the functionality and the ongoing performance of the “service” of which the application is a major component. And the service must not only deliver the functionality the user seeks, but must also perform to acceptable service levels—levels of availability, capacity, and so forth—on a daily basis.
How DevOps complements ITIL:
- Often IT operations is not given the opportunity to provide input into design and development activities. The mindset is, “The service desk will take care of any supportability issues we haven’t thought of.” The problem is that supportability is an afterthought, and services become very labor intensive and time consuming to support when launched into production.
- A DevOps approach to service design supports the notion of getting early involvement of both development and operations teams in design activities. By encouraging collaboration between development and operations, DevOps also helps to provide operations with early visibility to new and changed apps so they can be positioned to deliver effective support when they go live.
Are you considering adopting DevOps practices?
Our new course, Adopting DevOps in an ITIL Environment, is designed for clients considering or in the early stages of adopting the DevOps methodology. Learn how to leverage both ITIL and DevOps in a complementary approach.
Subscribe
Never miss another article. Sign up for our newsletter.