DevOps is more of a philosophy or way of working than it is a formal framework or standard. Nevertheless, the approach deserves merit, as it goes to the core of tension in most IT organizations—the need to be responsive to business change while maintaining a stable, highly available IT infrastructure, and delivering quality services that meet the needs of the business.
What does DevOps have to do with ITIL?
Let’s start with ITIL. ITIL is a global framework for delivering and managing technology as a service to the business. As a proven and well-adopted framework of IT best practices, ITIL includes the notion that a service is a means of delivering value to customers by facilitating the “outcomes” they want (achieving business results), without them having to deal with the cost and risk associated with that service.
ITIL maintains that customers want outcomes—the result of carrying out the service—and they understand that a service provider is required to provide whatever IT services are necessary to help them achieve those outcomes, through the application of people, processes, and technology. ITIL is vendor neutral (doesn’t require tools specific to a given vendor), not prescriptive (it must adapt to the organization that wants to practice it), and a proven best practice for IT (it just works.
DevOps and ITIL—In Conflict or Complementary?
While DevOps emphasizes collaboration and communication, so does ITIL. In fact, there is no inherent conflict between the DevOps movement and ITIL—upon examination, it becomes evident that the two are very complementary. DevOps provides us with “new light” in which we can examine the ITIL framework in several key areas, improving core processes, functions, and principles within ITIL.
Key Elements of a DevOps
- DevOps is not a product or technology, but rather an emerging “methodology” or way of working between two key groups within an IT service provider organization. DevOps:
- Should be holistic—involving people, process, and technology
- Can be thought of as an “extension” of Agile
- Is about breaking down “barriers” between application development groups within organizations, and their service and support function
- Is about ways to improve collaboration between development and operations team.
More a philosophy or way of working than it is a formal standard or framework, “DevOps” arose as a movement within IT best-practices a few years ago when IT managers began to realize that something needed to be done to close the communications and collaboration gap between development support operations staff, and to speed responsiveness to the business.
With the trend toward mobile devices, the “economy of apps” was born. Work began its transition to a mobile workforce, and applications—which had a larger footprint and used to reside on desktops—began their transformation to smaller, portable “apps.”
Office applications began to transition to the “cloud,” and an ever-increasing amount of work began on tablets, smartphones, and laptops. In conjunction with the trend toward mobile work, competition for customers and users continued to grow between enterprises.
The balance of eCommerce shifted to mobile devices, and it became imperative for organizations to stay ahead of their competitors—with regular updates to “apps” that could empower their workforce, attract customers, and perhaps amount to competitive differentiation. Developers began to feel the pressure to be more responsive to business demands for functionality improvements in apps.
The idea of “Agile” development teams was born, and development groups began to develop and deploy new, updated releases of code on a more frequent basis. Agile, which is a philosophy of how to carry out the development and deployment of apps, is also supported by methodologies such as Scrum.
How DevOps, Agile, and ITIL Relate
Whereas Agile is a methodology for speeding the development and deployment of applications (using techniques and processes such as Scrum), DevOps is a philosophy or way of working that has the potential to realize greater benefits and faster delivery through such Agile methods. DevOps is a “value add” approach to Agile development, emphasizing:
• Continuous involvement and engagement of operations teams with internal development teams, through the development lifecycle
• That operations teams should be engaged as early as possible, in fact right from the start—during the formulation of the vision and charter for the service solution
• Operations teams should also provide input to the technical and application requirements for the service, and advise on the feasibility of the proposed release schedule
• Improved deployment frequency, enabling faster time to market of new/improved application functionality changes
• Lower failure rate of new releases, more frequent fix updates, and faster recovery time in the event of a change failure
• The application of service automation to accelerate common “process models” such as a standard change, or routine release update
These notions of collaboration, optimized communication, and business responsiveness are not foreign to ITIL. In fact, the ITIL framework stresses the need for early involvement of technical management and application management functional teams in service strategy, service design, and service transition. ITIL is very clear that service operation functions—in particular, technical infrastructure teams—should provide early advisement to the design and development team on the supportability and fitness of the application to the live environment. They should also provide input on the technical architectures for the “service solution,” including service architecture, application architecture, network architecture, information architecture, database architecture, and so forth.
These notions of collaboration, optimized communication, and business responsiveness are not foreign to ITIL. In fact, the ITIL framework stresses the need for early involvement of technical management and application management functional teams in service strategy, service design, and service transition. ITIL is very clear that service operation functions—in particular, technical infrastructure teams—should provide early advisement to the design and development team on the supportability and fitness of the application to the live environment. They should also provide input on the technical architectures for the “service solution,” including service architecture, application architecture, network architecture, information architecture, database architecture, and so forth.
Application management staff (being responsible for the entire lifecycle of all applications—not just those developed in house), should be engaged very early in the life of a service. In fact, they should be the ones to work with the business, the person assigned as the business relationship manager (BRM), and the service owner to identify, define, and document the complete “service solution” requirements, and ensure these are captured in the service charter for the new or changed service being considered. According to ITIL, application management teams should work closely with development groups, who stay focused during service design and service transition on rapid development and deployment of applications that are a part of the total service solution. While development focuses on development activities across service design and service transition, application management manages the app across the entire service lifecycle, from strategy, through design and transition (working with development), and on into operation and continual improvement. This approach ensures that the service solution (which contains the app), not only launches well, but continues to perform during live operations, meeting the needs of business customers and users.
The importance of defining and implementing effective cross-functional communications, along with automated support systems, is also underscored by ITIL. All of the various stakeholders, from front line service desk staff and technical and application support specialists, to developers and customers, must be linked through well-planned and efficient communications channels so that escalations can be handled quickly, and the IT support organization can truly achieve optimum flexibility and responsiveness.
Like DevOps, ITIL is also very keen on the use of “models,” and the application of service automation to increase efficiency, speed execution, and lower costs. What ITIL emphasizes, however, is that to be successful, an IT service provider must first be strategy-driven, and process- before it can realize the maximum benefits of automation. The standard change, or release “model,” must first be documented and analyzed, the “gaps” must be taken out, and the process and interfaces must be streamlined and automated. Only then will maximum benefits and throughput be achieved.
Application management staff (being responsible for the entire lifecycle of all applications—not just those developed in house), should be engaged very early in the life of a service. In fact, they should be the ones to work with the business, the person assigned as the business relationship manager (BRM), and the service owner to identify, define, and document the complete “service solution” requirements, and ensure these are captured in the service charter for the new or changed service being considered. According to ITIL, application management teams should work closely with development groups, who stay focused during service design and service transition on rapid development and deployment of applications that are a part of the total service solution. While development focuses on development activities across service design and service transition, application management manages the app across the entire service lifecycle, from strategy, through design and transition (working with development), and on into operation and continual improvement. This approach ensures that the service solution (which contains the app), not only launches well, but continues to perform during live operations, meeting the needs of business customers and users.
The importance of defining and implementing effective cross-functional communications, along with automated support systems, is also underscored by ITIL. All of the various stakeholders, from front line service desk staff and technical and application support specialists, to developers and customers, must be linked through well-planned and efficient communications channels so that escalations can be handled quickly, and the IT support organization can truly achieve optimum flexibility and responsiveness.
Like DevOps, ITIL is also very keen on the use of “models,” and the application of service automation to increase efficiency, speed execution, and lower costs. What ITIL emphasizes, however, is that to be successful, an IT service provider must first be strategy-driven, and process- before it can realize the maximum benefits of automation. The standard change, or release “model,” must first be documented and analyzed, the “gaps” must be taken out, and the process and interfaces must be streamlined and automated. Only then will maximum benefits and throughput be achieved.
