Digitizing Service Management
Service management, by definition, is the art and science of integrating various activities to offer something of value (or a service) to the customer. Typically, service management has almost been performed by people in the middle. A set of so-called incident managers, problem managers, and other process managers would own end-to-end processes; and work with individual technology owners, be it Linux, Windows mainframe database, to manage interdependencies and conflicts so that the end user gets uninterrupted service.
What is Impacting Service Management Today
Introduction of digital technologies are impacting service management in various ways. I would like to broadly group them under three dimensions:
D 1: Evolving Technology Landscape
The first dimension that is impacting service management is the change in the underlying technology landscape that service management is expected to manage. In the past, when conversations on service management happened, it was typically about integrating infrastructure and applications.
Today, technology services include significant component of cloud (public) and services provisioned in software as a service model. Another component that is increasingly becoming crucial to doing business are bots of various kinds (robotic process automation and chat bots). Business is usually down when one of these are down and service management has to include them in their scope of accountability.
Data and supporting technology components are another component that are becoming crucial to business. And leveraging these data components are advanced elements like artificial intelligence (AI), machine learning (ML) models. Businesses increasingly need the data outputs on a real time basis to conduct business activities. Hence, service management has to include these elements in their preview.
Another aspect undergoing significant change from a technology perspective is the architecture itself. Historically, many commercially off-the-shelf (COTS) products had a very monolith architecture and overall IT architecture required integrations between multiple systems. Many times, these were hard coded point to point. There was a need for someone to preside over these silos and integrate them to provide a unified service to the end user. Increasingly, architecture is becoming a lot more modularize and driven through application programming interfaces (APIs). With this modular architecture, the need for a person to integrate across towers will shrink dramatically. But we have to also realize that this may not be fully true in an enterprise context. This is because there will be significant time lag before a lot of COTS and SaaS products we procure will be truly modular.
In summary, the scope of service management has to increase to include the various technology elements that are being used; public cloud, SaaS based applications, bots, data, and others. We also need to consider the impact of modularization of architecture as we define the role of service management.
D 2: Evolving IT Operating Models
The second dimension which has a significant impact on service management is the evolving operating model of IT teams themselves. IT functions are increasingly organizing themselves into product teams. Product teams bring together former project and operations teams under one leadership and align them to the business value chain. There is a single team responsible for both building new capability, which are projects, as well as maintaining the capability. The concept of a project itself goes away with the concept of products and agile teams doing more frequent releases. Product teams are expected to be able to work autonomously within the bounded context that they are responsible for. These teams are also expected to put significant effort into ensuring elimination of technical debt.
In this context, there is a lot more focus on eliminating operations through automation for example. The traditional model of having a help desk and segregated L2/L3 independent teams with progressively higher levels of skill, and so on, do not really fit into an agile product team construct. Similarly, moving to the new operating model is also expected to significantly reduce technical debt, which in the past led to incidents, service requests, and delay in resolving issues.
In a traditional service management context, one remains focused on a major incident; and in change management, on aspects like change approvals, managing releases, and protecting the production environment, managing configurations in the CMDB, and so on. Each of these need to change as firms move a lot more towards agile and DevOps based releases. As DevOps and agile logically moved towards, the concept of a project itself is eliminated and you are able to do releases in far more rapid frequency, sometimes even in minutes. Automation of the delivery pipeline and strong regression testing enables us to do these with far higher level of reliability. Traditional service management processes like change, release and configuration will have to change significantly work in this rapid release environment
Digital service management needs to significantly think through its role in the context of IT function evolution into product teams. Do we really need service management if each team is able to operate within bounded context without impacting others? How would service management processes evolve to address an operating environment where there is a release into production every few minutes?
D 3: Availability of digital technologies
The third dimension that we have to consider about service management in the digital context is how service management itself uses emerging digital tools. How do we move away from right person in the middle to automation of service management? How do we use a lot more data, to take decisions related to service management? Could there be, for example, service level achievement predictor that would predict and propose actions for us? Could AI enable us to do better correlation and hence trouble shooting?
To summarize
- the technology state that has to be managed through service management.
- changing IT operating models and
- use of technology within service management itself
is going to impact or define what service management of the future or digital service management will look like.
What has to change
Traditionally, mature service management has used best practice frameworks like IT infrastructure library, (ITIL) as frame of reference and has had an associated operating model. This talked about various process owners and roles for processes like incident management, problem management
The first interesting question to ask: is there actually a need for service management in the future? In an idealized scenario, there will actually be NO need for the traditional ‘people in the middle’ service management. Unfortunately, in an enterprise context, the idealized scenario, where small services work together using API similar to see in a web scale companies will take some time to emerge. There will still be a need for service management.
The key pillars of service management need to change significantly as the technology landscape and the IT operating model evolve. The technology or tooling solutions that are typically used for service management will also need to change. The information, or the knowledge base on which service management works like called trees for example or service level agreements is another element that would require significant change. Service management team will use a lot more data, from an application monitoring perspective, observability perspective, and so on, look to predict failures that rather than react to failures
Service management will be done not by being a person coordinating between teams but will be dome automatically. The role of service management team will be to configure some of these processes that enable management automatically. As an example, instead of being a change approval board that approves individual changes, the service management team will focus on auditing the regressions suite to ensure that the regressions test suite will meet needs so that then changes can be automatically progress to production.
Summarizing, service management will continue to be a need. The role of the service management function will change its scope of service it controls will increase. It will use a lot more automated tooling to manage things and it will work seamlessly within the context of a product team. We will discuss the future tools, operating models and goals of a digital service management organization in a subsequent blog post.
