Understanding ITIL4 and DX Using a Life Cycle Model at SKILup Days 2024

Hello, in today's lecture, I would like to share with you how to utilize ITIL-4 in the era of Digital Transformation (DX) from the perspective of service management. My name is Naka Hiroyuki. I work at Accenture, where I hold the position of Associate Director.

Also, I have been certified as an ITIL Ambassador by PeopleCert. I have over 15 years of experience in the field of IT Service Management, and I have published explanatory books on ITIL-4 in Japan. I appreciate the opportunity to speak with you today.

The first thing I want to share with you today is how IT operations are changing due to digital transformation (DX). With DX, there's a demand for changes in IT infrastructure as well. In traditional IT operations, for instance, monitoring was handled through inquiries and manuals.

Regarding governance processes, control was exercised manually. Deployments of servers, networks, storage, and the like could sometimes take days. I believe that methods for optimizing and managing demand across the organization often required considerable manual effort.

Regarding workload management, it was often limited to on-premises, and many organizations were previously groping their way through methods that utilized multiple resources, such as the cloud. Furthermore, many organizations have struggled with establishing mechanisms for security and IT control throughout the product lifecycle. I also believe that many IT departments have struggled to explain to the business side due to opaque usage methods and cost allocations regarding costs.

In the era of digital transformation, it is necessary to revisit and address these issues. In this slide, we refer to it as DX IT operations. Monitoring is realized through automated self-services that are executed promptly.

Governance processes will also be carried out through automated, trigger-based operations. Regarding deployment, we are now in an era where it can be completed in just a few minutes. As for managing and controlling demand, it is required to dynamically optimize utilization and capacity.

Workloads also demand the management across various environments, including the cloud, in a cross-sectional manner. For aspects like lifecycle security, it is necessary to have controlled measures in place in advance. Regarding costs, there is a growing demand for transparent, usage-based cost management.

Failing to achieve these measures makes it difficult to provide services at the swift cycle demanded by the business side. This is the environment in modern IT Service Management. At Accenture Japan, we advocate for something called Service Management SRE in response to this.

Originally, SRE stood for Site Reliability Engineering. This included concepts such as Infrastructure as Code, AIOps, Runbook Automation, SLAs, and KPIs. This has been further expanded to encompass DevOps as well, and such an extended interpretation of SRE has been advocated.

In response, Accenture advocates for something called Service Management SRE. This is not about site reliability but focuses on engineering related to service reliability. In addition to Site Reliability Engineering, it is necessary to incorporate DevOps and IT Service Management into our considerations.

I believe ITIL-4 is beneficial for this scope. Now, I would like to explain how we should utilize ITIL-4. First, I'd like to delve into the history of ITIL-4.

ITIL has evolved to align with the backdrop of each era. It first made its appearance in the 1980s in the UK. At that point, IT was regarded as a means of delivering technology to businesses, with an emphasis on how to consistently provide services on hosts.

From here, further downsizing occurred, leading to the advent of client-server service delivery models, which brought numerous servers and network nodes under management. As a result, the perspective on how to efficiently manage an ever-growing IT environment became increasingly important. ITIL-V2 emerged with the goal of focusing on the quality and efficiency of IT.

This was further developed with the appearance of ITIL-V3 in 2007, which expanded on the ideas of ITIL-V2, focusing on how to align IT and business. At this juncture, the concept of lifecycle management was incorporated into service management. Subsequently, ITIL-V3 was enhanced in 2011 with the addition of two new processes, making it more user-friendly.

However, since ITIL-V3 comprised 30 processes and functions, a drawback emerged: each process and function could become individually optimized and siloed, leading to inefficiencies. As a result, taking these reflections into account, ITIL-V4 was introduced. ITIL-V4 focuses on the flexibility between IT and business, implementing service management through the Service Value System.

Let me briefly introduce how processes and practices have evolved from ITIL-V2 to ITIL-V4. In ITIL-V2, the focus was on service delivery and service support, laying the groundwork for what would become ITIL-V4. Then, ITIL-V3 introduced the five domains of Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement, defining 26 processes and 4 functions.

ITIL-V4 inherits these and defines 34 practices, including those developed in line with the concept of ITIL-V3 and new ones created from the perspective of managing IT organizations. I'd like you to think of ITIL-4 as evolving consistently from the history of ITIL. However, ITIL-4 moves away from the service lifecycle concept to avoid siloing, organizing these into three practice groups.

Service Management Practices, General Management Practices, and Technical Management Practices. This made ITIL-4 somewhat challenging for organizations used to managing service management according to ITIL-V3 processes. To address this, Accenture proposes the IT Operating Model for ITIL-4, reorganizing the 34 ITIL-4 practices from the service lifecycle perspective once more.

In ITIL-4, the foundational concept involves creating service value streams by combining individual practices, thereby establishing the most suitable workflow for each business operation. There's a tendency regarding how these workflows are applied during the planning, development, and operation phases of a service lifecycle. The lifecycle is organized into phases to match these tendencies, showing when each practice is most likely to be utilized.

The IT Operating Model for ITIL-４ is designed to illustrate when each practice is typically employed, aligning with these trends. Let me briefly explain how to view it. On the left side, after service strategy and planning are completed, the model transitions into service development and then service operation.

These two stages are designed to proceed concurrently, accommodating an agile development approach. Service development and service operation are linked by three practices related to service transition: Change Enablement, Release Management, and Deployment Management. Through these, services transition from development to operation.

On the right side, we group elements necessary for organizational management: Organizational Management, Financial Management, Knowledge Management, and Improvement. These elements impact all practices and activities, hence their representation. Regarding the interface for IT service providers, customers, and suppliers, these are grouped together under a layer called Customer & Ecosystem, located at the top of this model diagram, where related practices are consolidated.

Using this model diagram to analyze an organization's service management enables the identification of issues from this perspective and facilitates working towards their resolution. By the way, this scope of ITIL-4, when compared to other commonly used IT lifecycle tools and methodologies, is illustrated in slides that show how they relate. Featured here are Babok, Pmbok, DevOps, IT4IT, Covid, and CMMI.

Each one is a framework used in IT service development and operation. How they relate to ITIL-4 will be explained n the following slides, showcasing the connection between these frameworks and ITIL-4. Firstly, Covid and CMMI provide a maturity model for all newcomers to ITIL-4, influencing every aspect from a control and management perspective.

Next, IT4IT organizes various workflows from the perspective of users planning, developing, and operating services, thus it relates to ITIL-4 from a perspective beyond organizational governance. DevOps has an impact as it pertains to service development. Pmbok is centered around the concept of project management and is related to project management activities.

Babok is a methodology for requirements definition and organizing business requirements. It influences the initial service planning phase and then impacts service design. By integrating ITIL-4 with other frameworks, its utilization can be maximized.

Now, let's discuss how to practically apply ITIL-4, focusing specifically on practices that are crucial in the context of digital transformation (DX). The sections marked in green, yellow, and orange are practices within ITIL-4 particularly impacted by DX. Firstly, Organizational Change Management is essential.

This requires an organization and development system that can adapt to Agile development and Service Reliability Engineering. From the perspective of service development, the premises for dynamic changes include the standardization of IT service design documents and the automation of testing, which falls within the scope of Continuous Integration. Furthermore, for releases that have minimal change impact and are frequent, mechanisms for automated changes and deployments are needed, including Continuous Delivery Deployment, and Infrastructure as Code.

For released services, mechanisms for comprehensive service monitoring, including log monitoring, and end-to-end synthetic monitoring will become necessary. In terms of operating services, enhancing escalation rules for collaboration with business departments and partners in the event of incidents or troubles, managing backlogs based on error budgets, and conducting post-mortems will also become newly essential. Additionally, it becomes necessary to decide which services will be provided as standardized, automated, routine services, to maintain a service catalog, and to automate workflows in coordination with change management.

To ensure operational services are functioning healthily, mechanisms to dynamically manage service usage and visualize the status of resource control will also be required. Also, managing IT assets within the operational environment, including both software and hardware assets, necessitates a mechanism for efficient management of these assets and governance-based management derived from them. Regarding infrastructure, mechanisms for self-healing, automatic service changes, provisioning, and Infrastructure as Code become necessary.

Security policies and controls also require mechanisms for automatic application. From here, we will briefly touch upon the changes each of these practices brings. Starting with Organizational Change Management, it's crucial to define the team patterns, expertise, and scope of responsibilities for building an SRE team.

Combining these options to create an SRE team that best fits the organization is necessary. SRE teams come with patterns such as COE type, Operation Concurrent type, and Multifunctional Engineering type, each with its advantages and disadvantages. Identifying which SRE type suits your organization and building a new team around that type is a necessary approach.

In Service Design, defining the functional requirements for the service's plan, design, build, test, operational test, release, and operation phases is crucial. It involves organizing what needs to be decided at each phase based on ITIL's concept of warranty, ensuring no considerations are overlooked through various definitions. These definitions function as rules for determining the operational requirements necessary for running the service.

In Service Validation & Testing, it's important to decide what needs testing and what does not, focusing on the perspective of testing. From a testing perspective, impact and frequency are crucial factors in determining priorities, deciding which items to test and which not to test. Starting with POC and moving on to unit testing and other various tests, there's a demand for additional testing as needed, such as performance tests, stress tests, and operational tests.

In software development & management, DevOps pipeline management becomes particularly important. Under pipeline flow control, it's essential to devise a mechanism for automatically deploying code by integrating various functionalities. Change Enablement is increasingly centered around a dynamic change management approach.

The challenge lies in automating checks that were previously done manually and enabling auto-deployment. In release management, the focus is on how to conduct validations and verifications to ensure quality. This involves standardizing and automating the mechanisms for validating each service component and release procedure to ensure they meet quality standards.

This approach extends beyond release management to encompass deployment management, necessitating decisions on which deployment model to adopt. In the Waterfall model, Big Bang deployment was the only method available, but Agile methodologies introduce various release strategies such as rolling deployment, blue-green deployment, canary releases, dark launches, and feature flags, among others. Choosing which deployment strategy to adopt requires careful consideration of each method's characteristics.

In monitoring and event management, the primary concern has traditionally been the management of the Infrastructure as a Service (IaaS) layer. However, there's now a need for mechanisms that can efficiently manage further layers such as Platform as a Service (PaaS), Container as a Service (CaaS), and Function as a Service (FaaS). Instead of traditional monitoring tools, there's a need to utilize products with strengths in observability, such as Datadog, Dynatrace, and New Relic, to perform end-to-end monitoring or to monitor the internals of containers.

Incident management involves several steps: Level 1, Level 2, Level 3, Level 4. Start with standardizing workflows. Next comes the automation of ticketing and script execution for automatic recovery.

Eventually, implementing a feature where AI analyzes new incidents based on past ones to suggest solutions becomes possible. Progressively stepping up through these stages can lead to the codification of incident management. In Service Request Management, the key is not to manage each request individually but to analyze and optimize numerous similar requests.

Tools such as Celonis for analysis, and ServiceNow's service optimization feature can help determine the most efficient and rapid processes for resolving similar requests. Program Management focuses on how to coordinate incident management with program management effectively. A thorough analysis allows the service desk, operational managers, and SRE teams across Levels 1, 2, and 3 to collaborate effectively on troubleshooting.

Standardizing and automating these activities enhance efficiency. Capacity & Performance Management necessitates the analysis of the current resource situation to proactively predict potential issues from a trouble prediction perspective. This analysis enables proactive measures against future problems.

Availability Management has two aspects: reactive and proactive. Many organizations practice reactive Availability Management, but to act proactively, it's beneficial to implement operations that address issues before they arise, in conjunction with the earlier mentioned Capacity & Performance Management. For Service Configuration Management, mechanisms for automatic management using the CMDB become necessary.

As management complexity increases, costs rise, and understanding the relationships between configuration items becomes challenging. To address these issues, a mechanism that automatically creates service maps using discovery functions is needed. Relatedly, in IT Asset Management, it's advisable to manage both hardware and software assets.

It's necessary to establish rules for planning and budgeting, acquiring and allocating, assigning, optimizing, decommissioning, and disposing, from each of these perspectives. In Infrastructure & Platform Management, the key is to determine what kind of automation solutions to implement for managing infrastructure. Additionally, for each automated solution, a dashboard should be prepared to assess its effectiveness.

Dashboards should be divided into categories for business, development, and operations, collecting metrics that check necessary KPIs, SLIs, SLOs, and other indicators from the perspective of each stakeholder to gain insights. In Information Security Management, utilizing various platforms, including services outside an organization's network in the cloud, has become common. Therefore, instead of perimeter-based security, a Zero Trust security model that allows for security checks at various transaction units is required.

Now, let's move into a summary. Today, we explored the IT Operating Model for ITIL4, demonstrating how ITIL4 can be organized from the perspective of the service lifecycle as it was in ITIL V3. From this viewpoint, analyzing DX IT operations reveals how digital transformation affects ITIL4 practices.

Service Management SRE (Service Reliability Engineering) is effectively employed in these efforts. Accenture considers Service Management SRE to be of paramount importance moving forward. To support these initiatives, I'll present six key success factors for implementing SRE at the end.

Starting with Why is crucial, highlighting the importance of not confusing the objectives and means of SRE. It's essential to gather directives from leadership layers, ensuring these activities are promoted under sponsorship. The remaining necessary elements are also outlined for your reference.

Today, Naka Hiroyuki from Accenture provided you with an explanation of ITIL4. I hope this has been of some help in your work. Thank you very much.