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

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 the

Four Service Characteristics

Recently I came across several articles by researchers and experts that laid out definitions and characteristics of services. ITIL provides us with a definition that can help drive the creation of value-laden services: A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. An area that ITIL is not so clear is in terms of service characteristics. Several researchers and experts put forth that services have four basic characteristics (IHIP): ·          Intangibility—Services are the results of actions not things. They have no physical presence and represent a logical set of elements. One way to think of service is “work done for others.” ·          Heterogeneity—Also known as “variability”; services are unique items because of the mechanisms used to deliver services-that is people. Because the people element adds variability, the service is variable. This holds true especially for th

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service". I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize: SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle. ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with