View source for DevOps and YaSM

<itpmch><title>DevOps and YaSM | YaSM Service Management Wiki</title>
<meta name="keywords" content="what is devops, devops processes, devops process model" />
<meta name="description" content="DevOps describes an approach that aims at unifying software development ('Dev') and software operation ('Ops'). DevOps is not a well-defined framework or process, but rather a set of practices and philosophies." />
<meta property="og:url" content="https://yasm.com/wiki/en/index.php/DevOps_and_YaSM" />
<meta property="og:title" content="DevOps and YaSM | YaSM Service Management Wiki" />
<meta property="og:description" content="Does DevOps replace ITSM and service management best practice? Can YaSM and DevOps go together?" />
<meta property="og:site_name" content="YaSM Service Management">
<meta property="og:type" content="article" />
<meta property="og:image" content="https://yasm.com/wiki/en/img/yasm-frameworks/devops/devops-service-management-processes-yasm.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="900" />
<link href="https://plus.google.com/104150539756444616711/posts" rel="publisher" />
<meta name="pinterest-rich-pin" content="false" />
</itpmch>
<html><div class="noresize"><a href="https://yasm.com/wiki/de/index.php/DevOps_und_YaSM"><img src="https://yasm.com/wiki/en/img/yasm-wiki/YaSM-Wiki-Deutsch.png" width="140" height="36" style="float:right;" alt="auf Deutsch" title="This page in German" /></a></div><br style="clear:both;"/>
<p>&nbsp;</p>
<p><b>Comparison:</b> YaSM and DevOps</p>
<p><b>Part of</b>: <a href="https://yasm.com/wiki/en/index.php/What_is_YaSM#yasm-other-service-management-frameworks" title="YaSM and other service management frameworks and standards">YaSM vs. other service management frameworks and standards</a></html>
<p>&nbsp;</p>

<span id="What_is_DevOps.3F"><span id="md-webpage-description" itemprop="description"><b><span style="color:#465674;">DevOps</span></b> describes an approach that aims at unifying software development ('Dev') and software operation ('Ops'). DevOps is not a well-defined framework or process, but rather a set of practices and philosophies. At times it's also called a 'movement'.</span></span>
<p>&nbsp;</p>

<html><div itemid="https://yasm.com/wiki/en/img/yasm-frameworks/devops/devops-service-management-processes-yasm.jpg" itemscope itemtype="https://schema.org/ImageObject">
<meta itemprop="caption" content="DevOps, service management processes and YaSM: Can DevOps and the YaSM process model go together?" />
<meta itemprop="width" content="1200" />
<meta itemprop="height" content="900" />
<meta itemprop="dateCreated" content="2018-09-21" />
<meta itemprop="datePublished" content="2018-09-22" />
<meta itemprop="dateModified" content="2022-11-12" />
<meta itemprop="representativeOfPage" content="true"/>
<span itemprop="thumbnail" itemscope itemtype="https://schema.org/ImageObject">
  <meta itemprop="url" content="https://yasm.com/wiki/en/img/yasm-frameworks/devops/480px/devops-service-management-processes-yasm.jpg" />
  <meta itemprop="width" content="480" />
  <meta itemprop="height" content="360" />
<meta itemprop="dateCreated" content="2022-11-12" />
<meta itemprop="datePublished" content="2022-11-12" />
</span>
<span itemprop="thumbnail" itemscope itemtype="https://schema.org/ImageObject">
  <meta itemprop="url" content="https://yasm.com/wiki/en/img/yasm-frameworks/devops/400px/devops-service-management-processes-yasm.jpg" />
  <meta itemprop="width" content="400" />
  <meta itemprop="height" content="300" />
<meta itemprop="dateCreated" content="2024-11-06" />
<meta itemprop="datePublished" content="2024-11-06" />
</span>
<meta itemprop="keywords" content="What is DevOps?" />
<meta itemprop="keywords" content="DevOps processes" />
<meta itemprop="keywords" content="DevOps service management" />
<figure class="mw-halign-right" typeof="mw:File/Thumb"><a itemprop="contentUrl"href="https://yasm.com/wiki/en/img/yasm-frameworks/devops/devops-service-management-processes-yasm.jpg" title="DevOps, service management and YaSM"><img srcset="https://yasm.com/wiki/en/img/yasm-frameworks/devops/400px/devops-service-management-processes-yasm.jpg 400w, https://yasm.com/wiki/en/img/yasm-frameworks/devops/480px/devops-service-management-processes-yasm.jpg 480w, https://yasm.com/wiki/en/img/yasm-frameworks/devops/devops-service-management-processes-yasm.jpg 1200w" sizes="100vw" src="https://yasm.com/wiki/en/img/yasm-frameworks/devops/devops-service-management-processes-yasm.jpg" fetchpriority="high" decoding="async" width="480" height="360" class="mw-file-element" alt="Does DevOps replace ITSM and service management best practice? Can DevOps and the YaSM process model go together?" /></a>
<figcaption><span style="font-variant:small-caps;"><b>Fig. 1: <a href="https://yasm.com/wiki/en/img/yasm-frameworks/devops/devops-service-management-processes-yasm.jpg" title="DevOps in service management">Use of DevOps in service management</a></b></span></figcaption></figure></div></html>

__TOC__
<br style="clear:both;"/>

Traditionally, organizations doing software development tended to work in 'silos'. Developers, testers, administrators and operational staff were organized in separate teams, handing over (biggish) chunks of work from one team to another.

This linear structure often creates problems, as teams focus on their own areas of responsibility and are less interested in overall success.

A typical example are the often conflicting interests between software development and operations: While the developers' focus may be on the fast completion of code, operations is a lot more concerned about software quality and rigorous testing, to keep the production environment stable.

DevOps is about breaking down these silos and creating cross-functional teams, so that developers, testers and administrators work closely together from the very beginning. Each team takes collective accountability for how actual users experience their software. The objective is faster, more reliable deployment of software, in line with the fast-changing needs of the customers.

To make this approach work, DevOps promotes the use of other, related practices, such as [[YaSM_and_Agile_Service_Management|Agile]], [[YaSM_and_Lean_Service_Management|Lean]], Continuous Integration [[#Wikipedia-Continuous-Integration|[1]]], Continuous Delivery [[#Wikipedia-Continuous-Delivery|[2]]], etc.

==The Three Ways of DevOps==

Everything in the DevOps approach can be derived from a few basic principles, known as the <i>'Three Ways of DevOps':</i>

===The first way===
<i>Systems thinking:</i>
*Organizations need to focus on the performance of the entire system, as opposed to the performance of individual silos.
* This includes trying to remove bottlenecks to optimize the flow of work.

===The second way===
<i>Amplify feedback loops:</i>
*This principle states that feedback loops should be short, allowing for frequent and continual improvement.
* Issues should be regarded as feedback and corrective action taken swiftly.

===The third way===
<i>Culture of continual experimentation and learning:</i>
*The third way says that experimenting, taking (calculated) risk and learning from successes and failures are essential for making progress and perfecting the organization's operations.

==Why is DevOps so popular?==
 
ITSM frameworks like [[ITIL]]<sup><small>&#174;</small></sup> have earned themselves a reputation for being overly complex, slowing organizations down. DevOps is often seen as a way to break free from this world of rigid processes and get things done faster.
 
And indeed, the DevOps principles enable many organizations to be more responsive to changing business environments and customer needs:
*Work is broken into smaller chunks, leading to shorter development and release cycles.
*Cross-functional teams, spanning development and operations, ensure that operational needs of new software are considered from the beginning.

Another reason for DevOps being so popular is the availability of modern technologies and concepts that support its adoption, such as cloud services, virtualization, containerization, microservices, etc.

==Does DevOps replace ITSM and service management best practice?==
 
The term 'DevOps' was first coined in 2009 by Patrick Debois [[#Patrick-Debois-Twitter|[3]]]. Interest in DevOps grew quickly and, amid much hype, many were lead to believe that DevOps was a better alternative to ITSM and [[Service Management|service management]] frameworks like ITIL.

There are many benefits of DevOps, but over time it has become clear that organizations can hardly work with free-wheeling cross-functional teams alone. [[Service Management Processes|Properly defined processes]] are still needed to provide direction and control. How else would organizations ensure, for example, that the [[Service|services]] offered are aligned with customer needs, and delivered as promised?

So today, the common view is that DevOps and ITSM are not the same. They are complementary and should be combined.

==Why service management best practice is not old stuff==

[[What_is_YaSM#YaSM_and_ITIL.2C_ISO_20000.2C_SIAM.2C_VeriSM.2C_DevOps.2C_.E2.80.A6|Service management frameworks]] contain lots of time-tested advice for being successful as a service provider. They describe, for instance, how to
*[[LP1: Set the strategic direction|Formulate and execute a service strategy]]
*[[LP2: Design new or changed services|Define services based on customer requirements]]
*[[SP5: Assess and coordinate changes|Manage changes and their associated risks]]
*[[LP4.6: Resolve incidents and service requests|Resolve service incidents and fulfil service requests]]
*[[LP4: Operate the services#LP4.4|Measure service quality]]
*[[LP5: Improve the services|Continually improve the services]]
*[[SP3: Manage customer relationships|Manage relationships with customers]]
*[[SP11: Manage suppliers|Manage suppliers]]
*[[SP9: Ensure compliance|Ensure compliance]].

These are essential capabilities for every service provider, yet DevOps has nothing, or very little, to say about them. It would thus be wrong to dismiss the time-honored service management practices as old hat. In fact, they are as relevant as ever.

What should be dismissed is the notion that service management as a discipline is difficult and bureaucratic. Service management frameworks can come across as very complex, but it has always been mistaken to try to 'implement' everything dogmatically. The key is to understand the principles behind the frameworks, select those parts of the guidance that offer the most benefits, and define clear, tailor-made processes that work for the organization.

====A case in point: The dreaded change management process====

<html>A particular ITIL<sup><small>&#174;</small></sup> discipline that is often regarded as cumbersome and excessively bureaucratic is <a class="external" href="https://wiki.en.it-processmaps.com/index.php/Change_Management" title="IT Process Wiki | ITIL Change Management">change management</a>, with special criticism reserved for the dreaded <a href="https://yasm.com/wiki/en/index.php/YaSM_Roles" title="Definition: Change Advisory Board (CAB)">CAB</a> meeting. Its poor reputation is the result of some organizations treating every change the same, leading to a huge number of changes to be discussed and CAB meetings dragging on forever.</html>

Surely, this cannot work for organizations that adopt DevOps, where changes are frequent and need to be deployed rapidly.

But the need to control changes will not go away, whether organizations follow the DevOps approach or not. This is because, by some estimates, more than half of all service incidents are caused by poorly coordinated or tested changes. So the way forward is not to dump change management, but to understand the principles behind the process and make it work better.

Change management in ITIL<sup><small>&#174;</small></sup> is about controlling risk caused by changes. ITIL<sup><small>&#174;</small></sup> does not mandate in any way that every change be discussed by the CAB, but offers several ways of dealing with changes: High-risk changes are to be authorized by the CAB, but these should be few in number. For most changes, the risks are well known, and for such changes ITIL<sup><small>&#174;</small></sup> recommends the definition of (pre-approved) standard changes, including change models.

In a DevOps environment, where testing and deployment is often automated and standardized, the risk of changes going wrong is greatly reduced. DevOps thus enables organizations to define even more standard changes and further shrink the workload of the CAB.

So DevOps has by no means rendered the [[SP5: Assess and coordinate changes|change management process]] irrelevant. Rather, DevOps provides an opportunity to deal with changes more efficiently.

==Is DevOps for all service providers?==

DevOps has its roots in software engineering, and therefore it is particularly well suited for software-based services. For other types of services, the picture is less clear, although DevOps is very likely to hold some useful recommendations for most service providers.

As an example, a logistics services business makes heavy use of fixed assets such as vehicles, warehouses, etc. It is obvious that this kind of equipment cannot be upgraded in short cycles, as is the case with software.

Still, even in environments where service components cannot be 'virtualized' and changed at short notice, applying some DevOps ideas may prove beneficial, such as putting cross-functional teams in charge of services across their whole lifecycle, from service design to deployment, operation and improvement.

So all service providers are encouraged to explore the DevOps approach.

==Can YaSM and DevOps go together?==

<html>The <a href="https://yasm.com/en/products/yasm-process-map" title="The YaSM Process Map">YaSM process model</a> represents established service management best practice and can be applied to IT services and all other types of services.</html>

The model includes activities for [[LP2: Design new or changed services|designing]], [[LP3: Build new or changed services|building]], [[LP3: Build new or changed services#LP3.5|testing]], [[LP3: Build new or changed services#LP3.6|deploying]], [[LP4: Operate the services|operating]] and [[LP5: Improve the services|improving services]]. But the YaSM model is not prescriptive and users are free to adapt the processes to their needs and execute them in the most effective way.

For example, [[LP3: Build new or changed services#LP3.5|testing activities]] include the creation of [[LP3: Build new or changed services#Test-script|test scripts]], running tests, [[LP3: Build new or changed services#Test-report|documenting test results]], etc. Exactly how tests are executed must be decided on a case-by-case basis and will depend on the nature of the service components to be tested. Organizations that follow the DevOps principles will certainly try to automate testing wherever possible.

Much the same applies to deployment. The YaSM model describes [[LP3: Build new or changed services#LP3.6|the typical deployment activities]], and organizations that have adopted DevOps will implement this as an automated process.

<html>So the YaSM model is not specifically aligned with DevOps, but with its streamlined, straightforward <a href="https://yasm.com/en/products/yasm-process-map" title="The YaSM Process Map: Service management process templates">set of processes and templates</a>, YaSM gives organizations a kind of skeleton for their service management processes, and the flexibility to build DevOps principles into these processes.</html>

==Where can I learn more about DevOps?==

Most service management publications these days include sections about DevOps, explaining the basic concepts and highlighting how service management can benefit from the DevOps approach.

Otherwise, 'The Phoenix Project' [[#DevOps-Phoenix-Project|[4]]] is often said to be a must read for anyone who looks for a first introduction to DevOps. It's a novel telling the story of an IT manager who suddenly finds himself promoted into a senior role, applying the DevOps approach to speed up the delivery of value from IT projects.

<html>Naturally, there is also a lot of information about DevOps on the internet. One of the best resources for DevOps on the web is <a class="external" href="https://devops.com/" title="Devops.com - Where the world meets DevOps">devops.com</a> [<a href="https://yasm.com/wiki/en/index.php/DevOps_and_YaSM#DevOps-com" title="Reference: DevOps.com">5</a>] with a huge amount of original content, including blog posts by industry experts, featured articles, webinars, podcasts etc.</html>

==Notes and references==

<span id="Wikipedia-Continuous-Integration">[1] [https://en.wikipedia.org/wiki/Continuous_integration Continuous Integration]. -- Wikipedia. Retrieved August 14, 2024.</span><br />
<span id="Wikipedia-Continuous-Delivery">[2] [https://en.wikipedia.org/wiki/Continuous_delivery Continuous delivery]. -- Wikipedia. Retrieved August 14, 2024.</span><br />
<span id="Patrick-Debois-Twitter">[1] Follow [https://www.linkedin.com/in/patrickdebois/ Patrick Debois on LinkedIn]!</span><br />
<span id="DevOps-Phoenix-Project">[2] Gene Kim, Kevin Behr, and George Spafford, 2013. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. IT Revolution Press, Portland, Oregon; USA.</span><br />
<span id="DevOps-com">[3] Devops.com (2018). Where the world meets DevOps. Retrieved from https://devops.com/</span><br />

<html>By:&#160;&#160;Stefan Kempter&#160;<a href="https://www.linkedin.com/in/stefankempter"><img style="margin:0px 0px 0px 0px;" src="/wiki/en/img/yasm-wiki/bookmarking/linkedin.jpg" width="16" height="16" title="By: Stefan Kempter | Profile on LinkedIn" alt="Author: Stefan Kempter, IT Process Maps GbR" /></a>&#160;&#160;and&#160;&#160;Andrea Kempter&#160;<a href="https://www.linkedin.com/in/andreakempter"><img style="margin:0px 0px 0px 0px;" src="/wiki/en/img/yasm-wiki/bookmarking/linkedin.jpg" width="16" height="16" title="By: Andrea Kempter | Profile on LinkedIn" alt="Contributor: Andrea Kempter, IT Process Maps GbR" /></a>, IT Process Maps.
<p>&nbsp;</p>

<p><small>
<span itemprop="breadcrumb" itemscope itemtype="http://schema.org/BreadcrumbList">
<span itemprop="itemListElement" itemscope itemtype="http://schema.org/ListItem">
<a itemprop="item" href="https://yasm.com/wiki/en/index.php/DevOps_and_YaSM#What_is_DevOps.3F"> <span itemprop="name">What is DevOps?</span></a>
<meta itemprop="position" content="1" /></span> ›
<span itemprop="itemListElement" itemscope itemtype="http://schema.org/ListItem">
<a itemprop="item" href="https://yasm.com/wiki/en/index.php/DevOps_and_YaSM#The_Three_Ways_of_DevOps"> <span itemprop="name">Three Ways of DevOps</span></a>
<meta itemprop="position" content="2" /></span> ›
<span itemprop="itemListElement" itemscope itemtype="http://schema.org/ListItem">
<a itemprop="item" href="https://yasm.com/wiki/en/index.php/DevOps_and_YaSM#Does_DevOps_replace_ITSM_and_service_management_best_practice.3F"> <span itemprop="name">Does DevOps replace ITSM and service management?</span></a>
<meta itemprop="position" content="3" /></span> ›
<span itemprop="itemListElement" itemscope itemtype="http://schema.org/ListItem">
<a itemprop="item" href="https://yasm.com/wiki/en/index.php/DevOps_and_YaSM#Can_YaSM_and_DevOps_go_together.3F"> <span itemprop="name">The YaSM model and DevOps</span></a>
<meta itemprop="position" content="4" /></span>
</span>
</small></p>

<!-- define schema.org/WebPage --> <span itemid="https://yasm.com/wiki/en/index.php/DevOps_and_YaSM" itemscope itemtype="https://schema.org/WebPage" itemref="md-webpage-description">
  <meta itemprop="name Headline" content="DevOps and YaSM" />
  <meta itemprop="alternativeHeadline" content="DevOps processes" />
  <link itemprop="url" href="https://yasm.com/wiki/en/index.php/DevOps_and_YaSM" />
  <link itemprop="primaryImageOfPage" href="https://yasm.com/wiki/en/img/yasm-frameworks/devops/devops-service-management-processes-yasm.jpg" />
  <meta itemprop="inLanguage" content="en" />
  <link itemprop="citation" href="https://yasm.com/wiki/de/index.php/DevOps_und_YaSM" />
  <link itemprop="publisher" href="https://yasm.com/en/#YaSMBrand" />
  <link itemprop="copyrightHolder creator" href="https://yasm.com/en/contact#ITProcessMapsOrg" />
  <link itemprop="author" href="https://yasm.com/en/misc/team#StefanKempter" />
  <link itemprop="contributor" href="https://yasm.com/en/misc/team#AndreaKempter" />
</span><p></html>

<!-- This page is assigned to the following categories: -->
[[Category:Service management frameworks and standards]][[Category:DevOps|!]]
<!-- --- -->