This site uses cookies to enhance your browsing experience and deliver personalized content. By continuing to use this site, you consent to our use of cookies.
COOKIE POLICY
In the current economic and business atmosphere, we are seeing a shift in the role of information technology, from simply providing and supporting services that facilitate business outcomes to contributing to a firm’s overall competitive advantage. It has been observed that IT departments are shifting from the back of organizations frontwards as their roles come to intersect with corporate strategy, sales and customer service.
With increased visibility and importance placed upon IT, so too does the demands from the business. Today, companies want their services provided faster and cheaper without compromising quality and availability. In response, many IT departments have become structured based on the principles of the IT Service Management (ITSM) frameworks, which offer best practice guidance on the delivery of services from strategy, design, transition, operation and continuous improvement. Organizations have claimed success, citing increased consistency and governance through a central IT body. With the foundation and adoption of the DevOps methodology, ITSM has come under criticism for being too slow and very inflexible.
I consider this to be largely a myth; not only can DevOps and ITSM work together, DevOps requires ITSM practices and principles to ensure that new services and changes to existing services can be provided without adversely impacting production ecosystems. DevOps is simply a new interpretation of a well-established framework.
With its initial body of knowledge articles published in the 1980s, ITSM frameworks offered firms a practical, best practice approach to deliver value-added services with a combination of people, process, and technology. ITIL, the current standard of IT Service Management, defines the process inputs, tools, techniques, procedures and process outputs from the IT Service Lifecycle covering Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement.
ITIL and the ITSM Service lifecycle provides IT organizations with a clear, consistent and repeatable framework for creating, delivering, evaluating, improving and retiring services, resulting in the value and outcomes required by the business while reducing overall IT risk exposure. What is nice about ITIL, is that it is platform and vendor agnostic, which allows greater flexibility in its adoption by IT organizations but provides clearly defined roles and responsibilities.
ITSM adoption brings visibility and governance to the delivery lifecycle. By offering a standard framework to address IT incidents and problems, through root cause analysis and monitoring services, IT leadership can have insight into the most pressing issues the organization faces and justify the expenditure of precious budget dollars. While visibility and governance are hailed as a foundation of ITSM, time spent controlling change and reducing risk can lead to increased release timelines. Downtime spent going through Change Advisory Board (CAB) processes or authorization control points may lead to an increase in non-value-added activities.
In response to the demands from the business for better quality of service offered, quicker delivery timeframes and at a lower cost, IT organizations were forced to rethink the way that they are structured, even if that meant eschewing well established ITSM best practices in favor of potential innovation opportunities. As a result, DevOps has emerged as a response to address these business needs. DevOps, as the name suggests, seeks to unify software development efforts with IT Operations to produce designated business outcomes at a rapid pace.
Although there is not a certified body of knowledge such as ITIL for ITSM, DevOps is a mindset which focuses on decreasing time to market based on smaller and more frequent releases, consistency and risk reduction. At the core of DevOps lies the use of orchestration and automation to replace human activities in infrastructure provisioning, integration, testing, and deployment. Despite the importance of tools to enable automation, these capabilities do not imply a true DevOps environment. A true DevOps organization is dependent on the adoption of its core principles including culture, sharing, lean and AGILE, and measurement in addition to automation.
The successful implementation of DevOps in an organization will instill a culture which seeks to break down the silos between functional teams. Within the DevOps model, teams who normally work through queue management and are largely disconnected, are merged and interact through the development lifecycle. By changing individual behavior to focus on openness, a DevOps culture can emerge over time through experience, repetition and improvement based on lessons learned. This level of collaboration allows the team to reduce waiting times between traditional work ‘hand-offs’ and deliver faster. Additionally, accountability is shared across the entire team. While DevOps empowers the team to work across the lifecycle from development to support activities, it also promotes the sharing of knowledge and skill sets over time to better the collective unit.
In keeping consistent with Lean and AGILE principles, DevOps seeks to eliminate waste. This streamlining involves the elimination of time-consuming steps in the design and release processes. DevOps is traditionally light in the creation of documentation and artifacts, which allow for more development cycles and response to feedback from the business. Automation is the method by which non value-added activities are removed. While certainly a time-consuming and expensive investment for IT departments, automation can eliminate repetitive and error prone work to optimize workflows and reduce bottlenecks.
High value automation activities generally fall into two buckets: continuous integration and continuous delivery. The former is a development practice in which developers integrate code into a single, shared repository daily, and eliminates the maintenance of multiple code bases. Each code check-in involves an automated build, automated unit testing and automated acceptance testing to maintain quality control standards. With the emergence of cloud technologies, developers in conjunction with engineering can leverage infrastructure as code to complete a full stack build. Continuous delivery ensures that software is in a releasable state throughout the development lifecycle. One-click deployments are a hallmark of continuous delivery, ultimately reducing deployment risk and increasing user feedback loops. As automation is implemented over time, DevOps allows for standardization across an IT organization, and any deviations from these established standards require documented processes and procedures. Key performance metrics captured during the lifecycle will help to build roadmaps for future DevOps projects as a part of continuous improvement endeavors.
At the surface, ITSM and DevOps are seemingly at odds with one another. The former focuses on structure, governance and control of services while the latter avoids traditional controls to create more development changes at a faster pace. However, like most frameworks, the combination of ITSM and DevOps principles can yield benefits in all organizations in deploying faster changes without causing disruptions to operational environments. It simply takes a bit of compromise and understanding of the value offered in each.
The way in which ITSM and DevOps can handshake is a concept known as ‘shifting left.’* The concept of shifting left, is to take elements of ITSM processes and embed them into your DevOps workflow at a point earlier than they would be otherwise.
Let’s take a look at how a DevOps approach builds in ITSM type control within a simplified high-level project workflow for changes to an existing service. Figure 3 illustrates a high-level project flow of based on an ITSM framework.
The project covers service design and transition activities related to requirements gathering, design, build, test, control and run activities, culminating in a go-live and a transition over to support operations. In this view, ITSM reduces risk by ensuring that releases go through required check points and a CAB to control changes, review deployment plans and ensure the deployment can be supported by operations after early life support concludes. Important to note, once a go-live occurs, the process will repeat for all subsequent releases. In this respect, there is a consistent framework and a set of common milestones for all releases for visibility at an executive level.
Figure 4 illustrates a high-level project flow of based on a DevOps framework.
You can see that there are similarities between the flows particularly around the importance of planning and capturing business requirements. Where the DevOps flow differs is in the consolidation of workflow tasks by shifting left.
Where ITSM calls for a service design package including but certainly not limited to elements of security, availability, capacity and service continuity, DevOps focuses less on diagramming and more on Test Driven Designs (TDD) on how development will meet the business requirements and achieve the desired outcomes. TDD allows developers to take incremental steps to writing clean code and incorporate the core elements of service design into tangible pieces which will allow scalability and build inherent quality control. Coupled with peer reviews as necessary, the shared accountability of the team mitigates any risk of working in an AGILE manner.
With testing at the forefront of design, DevOps builds in the control offered by ITSM before development concludes. This reduces unplanned work overall. It also eliminates the need for a traditional build authorization and a service validation and testing handoff during the release process by embracing automation and continuous integration capabilities. In this sense, both ITSM release management and DevOps follow the same release principles of build, test, approval and deployment tasks, albeit in their own manner across environments or software development efforts overall.
Now, adoption of DevOps in your organization does not mean that your organization is bereft of control. ITSM focuses on change management to evaluate changes and the potential impacts to production environments. This is an incredibly important function. DevOps absolutely benefits from enterprise level CABs but requires a slightly different mindset. In keeping with DevOps principles, the goal of change is to create many small changes, rapidly. Change management, instead of purely controlling change can adapt to facilitate change instead. Change managers in a DevOps sense can be seen as the conductor of a fast-moving train and are responsible for keeping it on the rails by ensuring that high priority changes do not conflict with one another (for example, think patch management). Instead of being held weekly or bi-weekly, these CABs can occur on a near daily basis.
Ultimately, as DevOps processes mature and a culture is created throughout an organization to embrace automation and DevOps principles, and end state can be achieved; this is to have all deployments classified and operate as standard change. Per ITIL® a standard change is classified as a pre-authorized, low risk, common change which follows procedure or work instruction. With automation reducing risk, it’s not out of the question to consider deployments to be triggered on demand from a service catalog.
While the adoption of DevOps can increase output in organizations, there are elements to be aware of. An implementation of DevOps can result in the silo-ing of a high performing DevOps team from the rest of the organization before it is scaled across an enterprise level. It will be imperative that IT leadership showcase the benefits of DevOps and not further alienate teams from upcoming organizational change.
Moreover, DevOps is built on small change and rapid feedback loops. As previously mentioned, the focus is less on traditional design elements and more on test driven design, it will be important up from not build too much without feedback. Once changes are made, however, leadership must be mindful of compliance elements. DevOps teams must ensure that they can pass audit findings by presenting the level of documentation required by the authorities. DevOps managers must ensure that documentation is kept up to date with the same rigor as innovation. Artifacts also will reduce the risk of individual tribal knowledge from developing and to be able to scale resources for future efforts.
Organizations who have embraced ITSM can effectively transition to DevOps because there are so many similarities between the two frameworks. DevOps and ITSM cover the basic elements of design, release and deploy but in slightly different ways. DevOps relies on orchestration and automation to replace tasks which are of little value add or are subject to error and uses metrics and measurements to plan for future opportunities for improvement. However, the reality is the structure of these tasks still exist across ITSM workflows and are measured using KPIs as a part of continuous service improvements. They may or not be done in an automated fashion and are certainly controlled as a measure of risk mitigation. But because of these basic parallels, a mixture of ITSM and DevOps methodologies absolutely can work for your organization.
I consider DevOps to be simply ITSM reimagined and rebranded for the modern IT era. Where DevOps builds onto and ultimately evolves ITSM is the importance of changing the hearts, minds and behaviors of IT staff to collaborate across IT departments. Building a culture and organizational structure aimed at breaking down barriers between resource and stakeholder groups is essential to making DevOps a reality, an investment equally as necessary as automation. It is important to remember that we consider the transition from ITSM to DevOps to be the end state for IT not the means to an end.
*England, Rob (2017). What DevOps Means for an ITSM Enterprise [PowerPoint slides]. Presented at Pink Elephant 2017.