VictorOps is now Splunk On-Call! Learn More.
Modern business, no matter the type of company, runs through technology. IT infrastructure and applications are being used to drive internal productivity as well as provide valuable services to customers. SaaS-based companies are required to maintain consistent uptime for end-users as their products are directly tied to their success. Efficient development, release and incident management processes are as important to B2B software companies as supply chain logistics are to B2C consumer products. Even minor hiccups can cause major disruptions to business and create negative customer sentiment.
Because of this, when the internet was in its infancy and software was just beginning to become popular with the common person, software engineers and IT professionals needed to define best practices for service management. Previous to SaaS, cloud-based applications and services, developers wrote code for months at a time and IT teams pushed updates every 6 months to a year. You would install on-premise software and you wouldn’t get any updates in functionality for long periods of time.
In this world, it made sense to define best practices for IT service management and software delivery – with the idea being that every organization would deliver products in the same fashion. This gave birth to the IT Infrastructure Library (ITIL), a framework of best practices for delivering and maintaining reliable applications and services. And, while ITIL offers an excellent basic outline for service delivery and upkeep, not all IT service management falls under the ITIL framework.
So, let’s explore the modern definitions of ITSM and ITIL, and see how they’re transforming to accommodate modern IT service and application delivery.
IT service management is the day-to-day execution and organization of planning, designing, delivering, testing, configuring and operating all IT infrastructure and applications. Whereas, the IT Infrastructure Library is a set of best practices for IT service management. While ITSM is often associated with ITIL, service management practices don’t necessarily need to follow the principles laid out by ITIL. ITIL covers five different sections of the ITSM lifecycle: service strategy, service design, service transition, service operation and continual service improvement.
Today, many engineering and IT operations teams are moving away from ITIL. They’re finding that some parts of ITIL are extremely applicable to the way they handle service management while other parts of ITIL don’t work well with their business. The key to effective IT service management is more about asking the right questions, identifying pain points in technical architecture and focusing on service delivery and incident response strategies that make sense to your specific business.
But, there are underlying processes in ITSM that every team needs to apply in some way shape or form. Let’s look at some of the common processes and tools used in IT service management and how they’re changing for the modern world.
While maintaining applications and IT infrastructure, things break. Before cloud-based applications and continuous delivery, IT operations would typically be in charge of all monitoring and alerting, ticketing and incident resolution. But, today, with the ability to continuously deliver features at any time, developers and IT teams are needing to find ways to collaborate in real-time, share accountability for uptime and fix incidents as they pop up.
Incident management falls on the shoulders of everyone in the engineering, security and IT operations organization. They need to record documentation and update tickets and find resolutions to problems that end-users encounter. Depending on the criticality of the service you build or the service involved in an incident, teams need to learn how to prioritize alerts and resolve key incidents faster. As teams and services grow, the only way to ensure service resilience is through the continuous improvement of an incident management strategy.
While incident management is more about the way DevOps and IT teams restore services in real-time, problem management is a more holistic view of the process behind all problems that happen or could potentially happen with IT services. Similarly to incident management, teams should look at their people, processes and technology when assessing how they approach the problem management lifecycle.
ITIL has specific policies for how IT teams should manage incidents and problems. However, in the modern world, one approach to problem management and incident management won’t work for every business. Look at ITIL as a general getting started guide for incident management and problem management, not as an end-all-be-all approach. Problem management and incident management are often highly reactive in ITSM. But, new technology in alert automation, on-call scheduling, and collaborative incident response are continuously driving more efficient workflows and a proactive approach to problem management and incident management.
Managing physical and technological assets is also, of course, a large responsibility in IT service management. Ensuring that users have access to the hardware and software they need and that appropriate levels of security are applied to all assets is a crucial aspect of ITSM. Service desks are responsible for maintaining documentation about all the changes they make to an organization’s assets and keeping inventory for physical devices.
Change management in ITSM is all about creating standardized processes and procedures for pushing changes to applications and infrastructure. In ITIL, change management is a part of the Service Transition phase, where IT teams are responsible for taking written code and pushing it into production environments. However, Agile development principles and DevOps collaboration have drastically sped up the change management process, all without hindering service reliability or security. Developers and operations teams collaborate throughout the entire development and release lifecycle to ensure continuous testing and delivery.
Both change management and release management are all about the management and organization of software development and deployment cadences across different stages and environments. In ITIL, release management was only enacted once developers had created a new service or feature, they’d packaged it up and sent it to IT for testing and deployment. However, modern DevOps-oriented teams are starting to test earlier in the development cycle and developers are offering up more support for services in production. Release management is becoming a collaborative effort – driving faster, yet consistently reliable, deployments.
While most of the other ITSM disciplines we’ve discussed here have been more process-oriented, CMDBs are more of a tool. Configuration management databases are used in IT service management to store information about the different hardware and software being leveraged within the organization and how they’re all connected. CMDBs help IT professionals and developers manage the way systems are configured and see how users across an organization take advantage of the tools and applications at their fingertips.
Service management in ITIL is all about organization, and while the level of organization may vary from company to company, CMDBs will always hold lots of useful documentation regarding the way applications and infrastructure interact with each other.
In practice, ITSM is more of an idea than a specific process. Service management is about doing everything in your power to continue delivering features and services to customers quickly without hindering service reliability, as well as learning to fix issues faster when something does come up. ITIL was established during an era where application development and IT infrastructure were optimized for on-premise services. While that standardized format worked well when every service was built, installed and used in a similar way, the process simply doesn’t work anymore.
ITSM in practice, in the modern world, is the process of building collaborative development and IT operations teams that continuously deliver reliable applications and services. In short, DevOps is the natural progression of ITSM. The people responsible for building software are now also taking responsibility for the uptime of the products they build. IT engineers are also getting more involved with the development process, helping them better understand how they can improve testing and release management.
DevOps isn’t replacing service management, it’s just a new mindset for approaching ITSM. Many elements of the ITIL framework can still apply, in general, to the DevOps process. But, it really depends on the service(s) you build, how you structure your teams and what’s most important to your business. DevOps is forcing engineering teams and IT operations to better understand how they collaborate and share visibility across everything they do – from service desks to backend engineers.
A DevOps engineer doesn’t truly exist. However, a DevOps-minded team does – made up of sysadmins, database admins, IT security analysts, front-end developers, platform engineers, etc. The difference between classic ITIL and DevOps is the way these different disciplines work together. Through continuous improvement and learning, developers and IT professionals are finding better ways to collaborate without slowing the development and delivery process.
Once code reaches customers, it’s everyone’s responsibility to ensure positive customer experiences. IT service management and ticketing shouldn’t be maintained in a small silo of your organization. Developers are just as responsible for rolling back faulty deployments and inserting themselves into the incident management process as anyone else. Instead of spending time maintaining incident documentation and updating tickets, DevOps teams are learning to resolve problems faster and use automation to update tickets as they go.
Real-time incident management is changing the way modern IT teams approach service resilience. From software development to release management to incident management, DevOps-centric organizations are streamlining their workflows across all aspects of service management. Many teams are finding that a centralized solution for on-call scheduling, monitoring, alert automation, collaborative firefighting and IT ticketing is reducing MTTA/MTTR, decreasing downtime and leading to better customer experiences.
Curious to see how you can make on-call suck less while simultaneously improving service resilience on your own team? Sign up for a 14-day free trial or request a free personalized demo of VictorOps to learn more.