DevOps and YaSM: Difference between revisions
No edit summary |
No edit summary |
||
(2 intermediate revisions by the same user not shown) | |||
Line 19: | Line 19: | ||
<p> </p> | <p> </p> | ||
<span id="What_is_DevOps.3F"><span id="md-webpage-description" itemprop="description">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. At times it's also called a 'movement'.</span></span> | <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> </p> | |||
<html><div | <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="caption" content="DevOps, service management processes and YaSM: Can DevOps and the YaSM process model go together?" /> | ||
<meta itemprop="width" content="1200" /> | <meta itemprop="width" content="1200" /> | ||
Line 36: | Line 36: | ||
<meta itemprop="dateCreated" content="2022-11-12" /> | <meta itemprop="dateCreated" content="2022-11-12" /> | ||
<meta itemprop="datePublished" 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> | </span> | ||
<meta itemprop="keywords" content="What is DevOps?" /> | <meta itemprop="keywords" content="What is DevOps?" /> | ||
<meta itemprop="keywords" content="DevOps processes" /> | <meta itemprop="keywords" content="DevOps processes" /> | ||
<meta itemprop="keywords" content="DevOps service management" /> | <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__ | __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. | 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. | ||
Line 60: | Line 66: | ||
Everything in the DevOps approach can be derived from a few basic principles, known as the <i>'Three Ways of DevOps':</i> | 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?== | ==Why is DevOps so popular?== | ||
ITSM frameworks like [[ITIL]] | ITSM frameworks like [[ITIL]]® 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: | And indeed, the DevOps principles enable many organizations to be more responsive to changing business environments and customer needs: | ||
Line 79: | Line 93: | ||
==Does DevOps replace ITSM and service management best practice?== | ==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 frameworks like ITIL. | 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 services offered are aligned with customer needs, and delivered as promised? | 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. | So today, the common view is that DevOps and ITSM are not the same. They are complementary and should be combined. | ||
Line 104: | Line 118: | ||
====A case in point: The dreaded change management process==== | ====A case in point: The dreaded change management process==== | ||
<html>A particular ITIL | <html>A particular ITIL® 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. | Surely, this cannot work for organizations that adopt DevOps, where changes are frequent and need to be deployed rapidly. | ||
Line 110: | Line 124: | ||
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. | 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 | Change management in ITIL® is about controlling risk caused by changes. ITIL® 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® 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. | 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. | ||
Line 145: | Line 159: | ||
<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> | <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> | ||
==Related articles== | |||
<html><figure class="mw-halign-left" typeof="mw:File/Thumb"><a href="https://yasm.com/wiki/en/index.php/YaSM_and_Agile_Service_Management" title="Agile service management"><img srcset="https://yasm.com/wiki/en/img/yasm-frameworks/agile/400px/agile-service-management-processes-yasm.jpg 400w, https://yasm.com/wiki/en/img/yasm-frameworks/agile/480px/agile-service-management-processes-yasm.jpg 480w, https://yasm.com/wiki/en/img/yasm-frameworks/agile/agile-service-management-processes-yasm.jpg 1200w" sizes="100vw" src="https://yasm.com/wiki/en/img/yasm-frameworks/agile/480px/agile-service-management-processes-yasm.jpg" decoding="async" width="400" height="300" class="mw-file-element" alt="Agile service management based on the YaSM process model." /></a><figcaption><span style="font-variant:small-caps;">Agile and the YaSM process modell</span></figcaption></figure> | |||
<p><a href="https://yasm.com/wiki/en/index.php/YaSM_and_Agile_Service_Management" title="Agile service management">Agile service management</a></p> | |||
<p>Agile software development is an approach to 'lightweight' software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams and the customers.</p> | |||
<p>How to apply agile principles as a service provider, and is the YaSM service management model compatible with Agile?<br /><a href="https://yasm.com/wiki/en/index.php/YaSM_and_Agile_Service_Management" title="Agile service management and YaSM">[ ... Read more ]</a></p> | |||
<p style="clear:both;"> </p> | |||
<figure class="mw-halign-left" typeof="mw:File/Thumb"><a href="https://yasm.com/wiki/en/index.php/YaSM_and_Lean_Service_Management" title="Lean Service Management"><img srcset="https://yasm.com/wiki/en/img/yasm-frameworks/lean/400px/lean-service-management-yasm-process-model.jpg 400w, https://yasm.com/wiki/en/img/yasm-frameworks/lean/480px/lean-service-management-yasm-process-model.jpg 480w, https://yasm.com/wiki/en/img/yasm-frameworks/lean/lean-service-management-yasm-process-model.jpg 1200w" sizes="100vw" src="https://yasm.com/wiki/en/img/yasm-frameworks/lean/480px/lean-service-management-yasm-process-model.jpg" decoding="async" width="400" height="300" class="mw-file-element" alt="Lean Service Management based on the YaSM process model." /></a><figcaption><span style="font-variant:small-caps;">Lean service management and YaSM</span></figcaption></figure> | |||
<p><a href="https://yasm.com/wiki/en/index.php/YaSM_and_Lean_Service_Management" title="Lean Service Management">Lean service management</a></p> | |||
<p>Organizations applying the Lean principles have experienced increases in profitability and customer satisfaction.</p> | |||
<p>Lean was originally developed in the manufacturing industry, but today lean principles are also successfully applied in many other areas - including the service industry.<br /><a href="https://yasm.com/wiki/en/index.php/YaSM_and_Lean_Service_Management" title="Lean service management">[ ... Read more ]</a></p></html> | |||
<br style="clear:both;"/> | |||
==Notes and references== | ==Notes and references== | ||
<span id="Wikipedia-Continuous-Integration">[1] [https://en.wikipedia.org/wiki/Continuous_integration Continuous Integration]. -- Wikipedia. Retrieved | <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 | <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="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-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 /> |
Latest revision as of 11:07, 8 November 2024
Comparison: YaSM and DevOps
Part of: YaSM vs. other service management frameworks and standards
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. At times it's also called a 'movement'.
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 Agile, Lean, Continuous Integration [1], 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 'Three Ways of DevOps':
The first way
Systems thinking:
- 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
Amplify feedback loops:
- 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
Culture of continual experimentation and learning:
- 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® 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 [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 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. Properly defined processes are still needed to provide direction and control. How else would organizations ensure, for example, that the 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
Service management frameworks contain lots of time-tested advice for being successful as a service provider. They describe, for instance, how to
- Formulate and execute a service strategy
- Define services based on customer requirements
- Manage changes and their associated risks
- Resolve service incidents and fulfil service requests
- Measure service quality
- Continually improve the services
- Manage relationships with customers
- Manage suppliers
- 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
A particular ITIL® discipline that is often regarded as cumbersome and excessively bureaucratic is change management, with special criticism reserved for the dreaded CAB 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.
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® is about controlling risk caused by changes. ITIL® 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® 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 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?
The YaSM process model represents established service management best practice and can be applied to IT services and all other types of services.
The model includes activities for designing, building, testing, deploying, operating and 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, testing activities include the creation of test scripts, running tests, 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 the typical deployment activities, and organizations that have adopted DevOps will implement this as an automated process.
So the YaSM model is not specifically aligned with DevOps, but with its streamlined, straightforward set of processes and templates, YaSM gives organizations a kind of skeleton for their service management processes, and the flexibility to build DevOps principles into these processes.
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' [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.
Naturally, there is also a lot of information about DevOps on the internet. One of the best resources for DevOps on the web is devops.com [5] with a huge amount of original content, including blog posts by industry experts, featured articles, webinars, podcasts etc.
Related articles
Agile software development is an approach to 'lightweight' software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams and the customers.
How to apply agile principles as a service provider, and is the YaSM service management model compatible with Agile?
[ ... Read more ]
Organizations applying the Lean principles have experienced increases in profitability and customer satisfaction.
Lean was originally developed in the manufacturing industry, but today lean principles are also successfully applied in many other areas - including the service industry.
[ ... Read more ]
Notes and references
[1] Continuous Integration. -- Wikipedia. Retrieved August 14, 2024.
[2] Continuous delivery. -- Wikipedia. Retrieved August 14, 2024.
[1] Follow Patrick Debois on LinkedIn!
[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.
[3] Devops.com (2018). Where the world meets DevOps. Retrieved from https://devops.com/
By: Stefan Kempter and Andrea Kempter , IT Process Maps.
What is DevOps? › Three Ways of DevOps › Does DevOps replace ITSM and service management? › The YaSM model and DevOps