Skip to main content

Integrating ITSM and DevOps

As the pace of technological innovation increases and digital disruption becomes the norm, the need to adapt and accelerate IT service management (ITSM) processes is more critical than ever. It’s no longer a debate about whether ITSM and DevOps should interface; it’s time now for ITSM professionals to understand how the practices they use to co-create value can underpin (or undermine) the flow of work and pervasive use of automation in a DevOps environment.

It’s easy to understand why ITSM professionals are skeptical about DevOps. ITSM performance metrics and service level agreements (SLAs) often revolve around the IT organization’s ability to mitigate risks, minimize impact, and “guarantee” availability. On the surface, these measures aren’t bad. It’s when we sacrifice speed, agility, and innovation in the process that the business starts to suffer.

Even with the evolution to ITIL 4, the what and why of ITSM haven’t changed. A customer-focused culture in which everyone understands how they contribute to the co-creation of value will always serve an organization well. It is the how that must be adapted in support of DevOps. It is therefore important that ITSM practice/process owners, managers, and stakeholders gain a breadth of knowledge about DevOps practices and principles, such as The Three Ways, Continuous Integration and Continuous Delivery, and DevSecOps, among others. It’s also important for ITSM professionals to have a clear understanding of new approaches to automated pipelines and continuous testing in order to accelerate and modernize your ITSM processes in support of DevOps. Understanding these DevOps concepts will help ITSM professionals to understand that many of the controls historically addressed through policies and manual processes can now be achieved, perhaps even more effectively and efficiently, through automation.

But what about the “No tools before the rules” mantra we so often hear? That hasn’t changed either. What has changed is the widespread acceptance of Agile and Lean values and practices within IT. DevOps doesn’t stand alone. Its roots are in Agile and Lean and the need to take an iterative, incremental approach with minimal waste. By streamlining processes and striving for “just enough” control, ITSM professionals can craft processes and practices that work with – not against – DevOps. By embracing concepts such as “policy as code” and process automation, ITSM professionals can leverage DevOps practices and achieve greater control than could ever be achieved through the use of tickets and queues and manual checklists and approvals. Simply put, rules + tools = modern ITSM.

The adoption of DevOps practices – particularly within an Enterprise – does not eliminate the need for ITSM. ITSM introduces a common language and proven practices that help ensure end-to-end IT services:
  • Support business strategies
  • Result in a positive customer experience 
  • Deliver value
  • Deliver the required levels of quality, stability, and reliability
Applying Agile, Lean and DevOps principles to ITSM modernizes the approach and improves the ability of both ITSM and DevOps to deliver business benefits.

To learn more about how to adapt your ITSM practices in support of DevOps, consider the following ITSM Academy certification courses and workshops:


ITIL® is a registered trademark of AXELOS Limited.

Comments

Popular posts from this blog

The Four Ps of Service Design - It’s not all about Technology

People ask me why I think that many designs and projects often fail. The most common answer is from a lack of preparation and management. Many IT organizations just think about the technology (product) implementation and fail to understand the risks of not planning for the effective and efficient use of the four Ps: People, Process, Products (services, technology and tools) and Partners (suppliers, manufacturers and vendors). A holistic approach should be adopted for all Service Design aspects and areas to ensure consistency and integration within all activities and processes across the entire IT environment, providing end to end business-related functionality and quality. (SD 2.4.2) People:   Have to have proper skills and possess the necessary competencies in order to get involved in the provision of IT services. The right skills, the right knowledge, the right level of experience must be kept current and aligned to the business needs. Products:   These are the technology managem

What Is A Service Offering?

The ITIL4 Best Practice Guidance defines a “Service Offering” as a description of one or more services designed to address the needs of a target customer or group .   As a service provider, we can’t stop there!   We must know what the contracts of our service offering are and be able to put them into context as required by the customer.     Let’s explore the three elements that comprise a Service Offering. A “Service Offering” may include:     Goods, Access to Resources, and Service Actions Goods – When we think of “Goods” within a service offering these are the items where ownership is transferred to the consumer and the consumer takes responsibility for the future use of these goods.   Example of goods that are being provided in the offering – If this is a hotel service than toiletries or chocolates are yours to take with you.   You the consumer own these and they are yours to take with you.               Note: Goods may not always be provided for every Service

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables.  An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and th