The goal of this article is to describe how in fact DevOps and ITSM are different sides of the same coin and to make the case that they are mutually supportive and in actual fact co-dependent and indivisible.
1. Value is defined in the eye of the beholder
Both DevOps and ITSM present the need to focus on value as defined by or through the customer/consumer lens. In fact this can be said of pretty much any quality system or process framework you wish to review, be it Lean IT, Six Sigma, Agile/SCRUM, etc. A key theme of each of these models is that Value has to be defined from the perspective of the service consumer not the provider. I believe the best definition of value comes from the COBIT 5 IT Governance Framework. COBIT 5 focuses on 5 key principles, and Principle #1 is all about “Meeting Stakeholder Needs”. Value is defined as meeting Stakeholder Needs through 1) Benefits Realization, 2) Risk Optimization and 3) Asset Optimization.
In short, Stakeholder Value is realized when the IT organization is able to deliver the outcomes the service consumer wants and is willing to pay for in the most efficient manner possible. All this has to be done without putting the company in harm’s way by taking on undue risks related to confidentiality, integrity and availability (CIA) of business information and data. DevOps does a good job of focusing development efforts on increased efficiency and asset optimization by looking at ways to standardize and automate testing and release cycles. It does this through the use of cloud provisioning tools and run book automation software. In essence, DevOps is focused on asset optimization by moving testing and deployment work from time- consuming manual activities, to software based automation leveraging pre-defined, tested, and pre-approved scripts. One could also make the argument that moving more workloads to standardized and automated provisioning methods reduces risk through the limitation of human error.
ITSM on the other hand focuses on defining exactly what is meant by “Benefit Realization” through the definition of Services within the overall Service Portfolio and a published and consumable Service Catalog. It also focuses on establishing IT Management processes related to a Service Lifecycle including: Strategy, Design, Transition and Operations practices, in other words: Plan, Build, Run. All of these practice areas focus on service outcome management related to benefits, availability, reliability and CSI. All internal and external stakeholders who participate in a shared Service Delivery Model need to follow common practices for delivering those services,otherwise the goals of “Benefit Realization and Asset Optimization” are put at risk due to inefficient, ineffective and redundant IT Management practices.
In summary, to truly deliver on the COBIT 5 definition of Stakeholder Value, an organization would need to deploy both DevOps and ITSM principles and practices. Focusing only on one side of the coin will not provide the currency needed to realize the return on capital and limit the ability to get the job done!
2. Value is delivered by functional and non-functional requirements
How would you view a product that had as many features as a Swiss Army Knife but failed to deliver on all the other non-feature based quality elements you have come to associate with that brand? It may have more options than you can practically use, but even that is of no use if you received its shipment two weeks after the party it was intended for. And if the knife can’t be opened without pulling out a small pry bar, when you do the blade snaps like glass, and you can’t find a support number to complain and return your product, how useful would that be to you? This example highlights the importance of capturing and delivering on both product feature (functional requirements) and product quality (non-functional) requirements. In ITIL® terms these two categories are referred to as Utility (features or fit-for-use) and Warranty (usability or fit-for-purpose). To only deliver features but not consider the necessity of the non-functional requirements is a recipe for disappointing customer satisfaction scores and plummeting consumer confidence.
Unfortunately understanding and capturing both sets of requirements is a current challenge for most IT organizations, and common scenarios include:
- Not capturing both functional and non-functional requirements during demand intake causes IT to deliver services that do not meet business needs;
- Having limited to no input of non-functional requirements into planning tasks is a recipe for not getting the service design specifications correct for product development and build activities;
- Not understanding the non-functional requirements for design specifications causes confusion and gaps in the identification of acceptance criteria for the build, testing and promote to production tasks;
- Deploying incomplete releases that have been insufficiently tested, and without defined and established support models being introduced to the run/production environment detracts from the time available to do work that actually creates stakeholder value.
DevOps typically focuses on capturing feature-based requirements when defining short release cycles. What is often lacking is the DevOps stated requirement of bringing Operations requirements earlier into the release lifecycle. This is in fact where ITSM provides the necessary non-functional (warranty) considerations required during the Service Strategy, Design, Transition and Operations phases of the Service Lifecycle. You can easily make a case that without ITSM warranty requirements DevOps will not fully understand the non-functional aspects of the releases it needs to standardize and automate.
3. The IT Value System – Partner Network
Former US Secretary of State Hillary Clinton is quoted as saying “It takes a village to raise a child!” The same principle applies within an IT value system: every organization, no matter how large or small, shares a common characteristic in that they all use multiple supplier types to accomplish the IT mission. In essence, every IT organization uses a network of partners to deliver end-to-end services. For most organizations, there are a variety of internal development and infrastructure groups spread across different business units, each owning a small piece of the service model with their own priorities, practices and tools trying to collectively accomplish enterprise goals. Now add external suppliers and the increasing trend to move to micro service outsourcing with external cloud providers, and this model gets even more complex.
This overall operating model provides value stream perspective for IT Governance to evaluate current practices, direct and prioritize improvement efforts and monitor progress against strategic goals. However, to realize these objectives it is important to understand the overall big picture of IT Value generation and the required integrations before senior leadership is equipped to set priorities for Continual Service Improvement.
All of the elements represented in the IT Factory model (see figure below) can be found in any service organization. DevOps, along with other project and software development lifecycle (SDLC) methods, are useful for defining improved ways of managing the build/maintenance activities for customer value creation
ITSM provides the basis of defining the customer engagement activities, described in this diagram as the Store Front. ITSM processes are also key to providing non-functional design criteria as input into the planning, build and maintenance activities executed by the IT Factory as well as the ongoing support and CSI activities. In short, ITSM processes provide the required design requirements DevOps is looking for in order to bring operations requirements earlier into the design build lifecycle. As described earlier in this paper, both DevOps and ITSM are required and in fact are indivisible from each other.
Practising rapid paced releases without addressing non-functional and operations requirements is a formula for creating increasing levels of production instability and unplanned downtime which both decrease customer satisfaction. However, establishing rigid, autocratic and bureaucratic processes leaves an organization unable to move at a speed necessary to adjust to shifting market and business needs. This is the challenge presented in this paper, and further shows why both sides of the DevOps coin are necessary to make the investment required to generate value.