ITIL & DevOps

Two paths with a common goal: "Value for Customer"

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 Smartphones. Desktop applications are the primary medium for users to interact with IT solutions. In other news, the human genome sequence has just been released.

From a technological perspective, there were no auto-scaling, automation-ready, audit-friendly AWS or Azure based solutions available. Hardware is getting more affordable and Datacentres have become a mainstream solution to support the increasing role of IT in business operations. Organizations are starting to realize the importance of what's inside the "black box" of IT. Discussions about servers, storage, switches, routers, software 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 the era of service management.

Fast forward today, and you will be surprised if I tell you that neither Microsoft, Facebook nor Google uses ITIL/ITSM anymore, but that doesn’t mean rest of the world should stop using it. My recent gathering at Dublin, some were very blunt “Do we really need a release calendar to follow?” When we have virtualization on server level and on far more granularity like containers as process level virtualization, when we have Github for continuous code control and Jenkins for continuous integration and testing? We can isolate & prepare environments to test our developed code output in minutes rather than days without much risk on production platforms and still able to revert back to few hour passed configurations with few clicks.  

Question came to my mind, ITIL/ITSM gives better control in the hands of Change Managers, others would say it gives better tracking to avoid incidents for Service Managers, but in reality its costing business a lot by taking away “Agility.” ITSM/ITIL was perfect when Software Defined Data Centres as well as Cloud Environments weren’t matured enough as of today.

In today’s industry, we often hear such varying opinions around DevOps and ITIL. These concepts are typically pitched against each other, as an “either or decision.” Either we are an ITIL or a DevOps company but it’s rare to host both. Let’s be clear: ITIL is important. Around two million people have been trained in it, and as the closest thing to an industry standard for IT management that currently exists, it has global reach.

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. ITIL/ITSM delivered a more holistic framework, with greater focus on previously overlooked aspects of service management. The concept of the "service life-cycle" was introduced to explain how various processes are interlinked and could be aligned for the successful delivery of services. 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.

DevOps is neither a framework nor a methodology. Its adopting best available tools in market for continuous delivery in a most control manner. Before someone consider introducing DevOps, they have to ensure they do internal organizational analysis on three below aspects:

·         ·         Organizational Delivery Culture

·         ·         Empowering Tools

·         ·         Well trained manpower

 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 structure alongside a common language between Business and Technology. It helps you see the bigger picture of the inter-dependencies and improvement opportunities within your system. 

As a framework, rather than a methodology. ITIL expects you to combine its guidance with other techniques to ensure you deliver what's required: value to your customers.

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 with agility. Bigger the risk, bigger the reward, a shared responsibility between Development Manager and Service Manager is important to make DevOps a success story.