DevOps and YaSM

 

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'.

Fig. 1: Use of DevOps in service management

 

 

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.

Notes and references

[1] Continuous Integration. -- Wikipedia. Retrieved September 22, 2018.
[2] Continuous delivery. -- Wikipedia. Retrieved September 22, 2018.
[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