The DevOps movement has done the IT industry a great favor. Its philosophy brings important concepts like collaboration and transparency into the spotlight. But DevOps isn't the first movement to tackle these issues. Earlier approaches such as IT Service Management (ITSM) and ITIL have been addressing these areas for decades—and they're more relevant than ever in the current context of DevOps, Lean, and agile.
The path that led us here
Let's take a step back—about 15 years or so. We're at the turn of the century, with no Facebook, no Twitter, and no iPhones. Desktop applications are the primary medium for users to interact with IT solutions. In other news, the human genome sequence has just been released.
With the millennium bug behind us—although it was a lot less troublesome than we feared—the awareness of the potential impact of fragile IT solutions on the rest of the organization is very much in the spotlight. IT is struggling, and confidence in IT is declining fast.
From a technological perspective, there are no auto-scaling, automation-ready, audit-friendly AWS- or Azure-based solutions available. Hardware is getting more affordable and data centers have become a mainstream solution to support the increasing role of IT in business operations.
This is a good thing, because the burst bubble has put a lot of focus on cost reduction, and with Sarbanes-Oxley (SOX) compliance due to become a mandatory requirement for many organizations—taking audit-led effort to completely new levels—the challenges IT face are manifold.
Organizations are starting to realize the importance of understanding what's inside the "black box" of IT. The details of what IT delivers and whether it's worth the investment are keeping many a business leader awake at night.
"Organizations are starting to realize the importance of understanding what's inside the "black box" of IT."
Discussions about servers, switches, licenses, and such make little sense to most, and supported by familiarity with the application service provider (ASP) model, the peak of IT outsourcing has arrived. Enter service management.
Aligning IT and business goals
ITSM quickly became the common language for outsourcing companies and business leaders to identify and achieve their shared goals. Within this movement, the ITIL framework—which had up to that point been primarily used for IT operations management—became the de facto guidance for achieving IT and business alignment.
Much of the content within the two main ITIL v2 publications, Service Support and Service Delivery, was adopted by organizations, but in many cases, the balance fell heavily on the side of processes and procedures. Less focus (if any) was given to the "soft" parts of ITIL and ITSM, which were often perceived as optional.
The next release of ITIL, published in 2007 and updated in 2011, delivered a more holistic framework, with greater focus on previously overlooked aspects of ITSM. The concept of the "service lifecycle" was introduced to explain how various processes are interlinked and could be aligned for the successful delivery of services.
In ITIL, success is measured in terms of customer outcomes. When evaluating whether a service is valuable, it's the customer's perception of value that counts. Unless the service provider, whether an internal IT department or an external partner, has understood their customer's requirements, it's unlikely that real value is delivered.
"In ITIL, success is measured in terms of customer outcomes."
Addressing the customer experience is another key component of ensuring value delivery. It's not enough to cover only fitness-for-purpose; fitness-for-use is an equally important concept. A solution that delivers on every point in terms of functionality but is a pain to use, isn't an example of a service that delivers value as it should.
Processes don't remove the need for common sense
I can see you nodding in approval, but the logical next question is this: Considering that these great concepts have been a part of the ITSM world for a long time, is it reasonable to ask why some organizations fail to see IT as an integral part of the business, rather than a cost center? And why has the word process become something scary?
There are two key concepts behind many successful ITSM initiatives. The first is "adopt and adapt."
A head of a public sector organization from Estonia recently told me, when explaining the organization's approach to ITSM, that the framework they're using is ITIL, while the methodology is "common sense." It's a great illustration of the meaning behind adopt and adapt. While the service management mindset should be adopted, the guidance in the publications should be adapted to the specific needs of each organization.
In the past few years, I've had the opportunity to speak to many IT professionals from around the world. I wanted to understand what they see as their main challenges and where we could help them to be more successful. Regardless of whether the person I talk to is from development, QA, operations, or any other part of IT or rest of the organization, possibly the most common challenge is getting approvals from the Change Advisory Board (CAB). It seems a CAB can cause unfathomable levels of pain.
"Every change request needs to be documented, and it's then sent to the CAB. It then waits for the next CAB meeting, which could be several weeks away, and meanwhile we can't do anything." If you recognize this situation, I have great news for you—it doesn't need to be like that. Change requests don't need to be manually created by people responsible for delivering the changeand change approvals don't need to be granted by those sitting in biweekly committees.
Take the pain out of change management
Understanding the changes happening in your IT infrastructure is important. Risk assessment, issue tracking, and learning are difficult if there's no visibility. Teams both small and large have built tools to support the required levels of tracking and visibility. Xbox Live's operations team, for instance, has a great one.
The way to ensure the process is both fit for use and fit for purpose is to ask: "What is the simplest process I could design that would support the control requirements while ensuring that customer value is created?" You can view it as an Occam's razor, of sorts. In today's IT, the almost inevitable follow-up question is, "And what can I automate?"
Standard change is a helpful concept to reach for here—preapproved, fully automatable, and fully pain-free. While some changes have an unknown risk and impact, there's an increasing number where both risk and impact are known.
Having the CAB review every single change request isn't efficient, and it's definitely not common sense, especially when their costs can run to tens of thousands of deployments per hour in some organizations. However, having the CAB review change requests of unknown risk, when parts of the business need to be consulted because they might be impacted, makes a lot of sense.
ITIL aligns with agile and Lean
"But we have a CAB now," you might say. "How can we change the process so that the pain goes away?"
This is where the second key concept can help—"continual service improvement" (CSI). Becoming aware of the cause of the pain, and realizing that it doesn't need to be like this, can fill people with enthusiasm and willpower: We can make it work! But in the haste of rushing to change the world, more challenges may be introduced than solved.
The CSI principle of continually delivering improvements in small steps is often a good approach to this problem. CSI perfectly aligns with the concepts in Lean and agile, starting with a pilot that demonstrates value, addresses concerns, builds confidence, and takes lessons learned to the next iteration.
"Continual service improvement (CSI) perfectly aligns with the concepts in Lean and agile."
It would be unwise to automate every type of change at once or to claim that change management isn't needed at all. Organizations and IT systems are too complex for that. It's more sensible to start with one team or one service as a manageable first step.
Look at the types of changes. How many are similar and done frequently? Is the service resilient? Can it recover if the deployment of a change were to go wrong? In case the service is disrupted, would the customer be affected, or would the fix be applied (automatically) before the customer even notices?
There's no all-purpose answer. When adopting elements of best practice guidance, always make sure they're adapted to your organization's requirements and that the improvements in processes and services follow the CSI guidelines.
How to improve your processes
Always be on the lookout for opportunities to improve your services and your service management capabilities, and to increase the value you deliver. For example, the technological advancements of the past years have made it possible—and often, desirable—to leverage automation capabilities in order to spend time on more valuable activities.
While many organizations are afraid of increased risk of failure and decreased levels of auditability with automation, the truth is that automation can decrease risk and increase auditability significantly. While the success of many services relates to the mean time between failures (MTBF), increased attention to system and service resilience has led to mean time to repair (MTTR) gaining in importance. Before deciding where to focus, assess what your organization needs, and what it's ready for.
Let me be clear: ITIL is no silver bullet. It can't be the exclusive answer to every IT challenge you have. It provides you with a mindset, a structure, and a common language. It helps you see the bigger picture of the interdependencies and improvement opportunities within your system.
"ITIL expects you to combine its guidance with other philosophies."
As a framework, rather than a methodology, ITIL doesn't expect you to be able to find the definitive answer to life, the universe, and everything within its publications. ITIL expects you to combine its guidance with other philosophies, methodologies, and techniques to ensure you deliver what's required: value to your customers.
Motivate your organization
Whether you're a newcomer to IT wondering why things were ever done differently, or you're a seasoned IT professional disillusioned with the current state of affairs, please remember: as a rule, people want to do the right thing. Sometimes the smallest of nudges in the right direction can result in significant improvements.
When you have fresh ideas about how to do things better, don't keep them to yourself; share them. Your colleagues or business partners might not be aware of what you've achieved or of the new concepts and ideas you have assimilated.
But before you propose a new approach, try to understand why the old approach exists. As tech expert Adrian Cockcroft reminds us, many draconian rules and procedures are simply organizational scar tissue. There's a reason things are set up as they are. Perhaps the reason no longer exists or could easily be overcome by applying new knowledge, but you need to know why the fail-safes are in place.
In the end, the important thing is to focus on customer outcomes. Whether you are used to look at the world through an ITIL perspective or are more accustomed to DevOps, agile, or Lean, the ultimate priority should be on delivering results. Everything else is just a means to an end.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
