DevOps vs ITIL?

DevOps is no different from mature ITIL Release Management, writes IBRS’ Dr Wissam Raffoul

There is debate within the IT industry about whether or not DevOps can replace ITIL.

From the ITIL perspective, many IT organisations, especially in Australia, have been implementing ITIL processes since 1994 with significant investment in technology and professional services. Hence, it is impractical to just drop ITIL and adopt DevOps.

This is because firstly, DevOps covers only Release Management, which is only one process of the 26 processes of ITIL v3; secondly, DevOps in not different from mature ITIL Release Management.

In this light, existing ITIL organisations embarking on digital transformation should plan to mature Release Management to match DevOps principles.

DevOps sites need to leverage the lessons learnt from ITIL implementation to enjoy a smooth business transformation as fixing only the software release process without integrating it with the remaining 25 ITIL processes is insufficient to raise the overall IT performance to the level needed by the digital world.

ITIL and DevOps can co-exist in the same organisation once brought to the right maturity level.


In the 1990s, client-server technology proliferation encouraged frequent software releases to production, albeit in an undisciplined fashion. This was due to developers coming from desktop background only experienced in building software to service few users. This led to many production environment outages.

Some Australian companies experienced up to 40 per cent service outages due to poor quality software releases. To combat this issue, many Australian organisations have adopted ITIL Release Management to control software releases in their Australian and overseas production environments.

This has ensured that committed service levels were achieved. In certain cases, the outages were reduced from 40 per cent to less than 3 per cent after Release Management implementation. The rationale was to ensure that software developers consider the production environment availability and stability requirements when designing software.

In the majority of cases, the development and production were different. Hence software releases that worked in the development environment did not work in production. In this light, IT operations staff were forced to restructure the released software to work in the production environment in a short period of time.

This has caused significant delays in stabilising the new software thereby severely degrading IT service image. To avoid this fire-fighting mode of operations, Release Management’s initial objective was to ensure developers consider the production environment service levels prerequisites by examining the following demands prior to releasing software:

  • Performance – Ensure that stress test or equivalent was run to simulate a realistic workload covering data transfer, database loads, special processing requirements (e.g. end of month processing) and server and network performance
  • Capacity – Understand the current and emerging capacity requirements; and establish a strategy to ensure capacity remains in line with demand
  • Support – Ensure support cover is in line with agreed service levels
  • Service level – Determine the production window availability requirements in terms of online and batch processing
  • IT Service Continuity – Ensure that the new software can be recovered by the existing disaster recovery plans or recommend alternate plans
  • System administration – Ensure that the existing system administration tools are adequate to provision and manage the infrastructure needed for the new software
  • Security – Ensure that the new software complies to the organisation’s security policy
  • Configuration – Ensure that the configuration requirements are defined and meet operations standards
  • Backup/Recovery – Ensure the new software backup procedures fit within the existing backup strategy if need be
  • People – Ensure existing IT operations staff can support the new environment

While fulfilling the above demands has reduced service outages, it delayed the release of new software to production. This is an unacceptable trade-off in the new digital world that favours consumerisation, mobility and the speed of releasing products and services to the market.

Release Management effect on software developers

To meet the emerging digital transformation needs, software developers are required to:

Read more: Red Hat to launch DevOps training services
  • Release innovative software
  • Be more responsiveness to business needs
  • Improve collaboration between IT groups and business stakeholders
  • Release quality software
  • Enjoy more frequent releases (especially for bug fixes)
In view of the above, enforced Release Management created the following challenges to developers:
  • To protect the production environment, IT operations staff forced the release to production to be according to an approved release plan. This meant that it could take weeks or months instead of hours and days to fix a bug or release new functionalities to production.
  • The tools used by IT operations staff are inadequate to manage increased number of servers located in different places such as in-house, traditional outsourced environment or public cloud.
  • There are no integrated tools between developers and infrastructure staff to cover the full software release lifecycle covering code generation, workflow automation, infrastructure provisioning automation, source code management and application performance management
  • The initial Release Management implementation reached a maturity level of 2-3. This meant transforming an undisciplined organisation to a disciplined one by exercising strict control but with no attention to efficiency. It implied that many activities were controlled manually. The result was severe tension between development teams advocating DevOps and IT operations due to the higher degree of automation required by DevOps approach.
  • Inability to write small chunks of code that can be deployed in hours to production instead of weeks
The friction between software developers and IT operations staff is expected to severely impact business digital transformation due to the following:
  • Delays in releasing software to production
  • Ineffective leverage of the public cloud
  • Delays in stabilising software services

The future of ITIL Release Management

The critical issue of Release Management is that it was implemented to maturity specification 2 or 3 at best in the majority of cases. Hence, to respond to the digital world needs, IT organisations wishing to remain ITIL compliant should elevate Release Management to at least maturity level 4. This will make it equivalent to DevOps if the following modifications were made:

  • Allow the categorisation of releases as “Emergency” to fix bugs, “Urgent” to quickly release new business functionality to production, and “Standard” to follow an agreed release plan. This will meet DevOps fast deployment demand
  • Integrate the tools that build software and provision infrastructure to align both teams mode of operations
  • Automate Release Management workflow covering submission, assessment, approval, implementation, testing, sign-off and continuous improvement
  • Focus on service performance measurement and reporting to unify development and operations mindsets
  • Ensure Release Management policies do not obstruct business operations[1]
  • Conduct post-implementation reviews to align Release Management operations with business transformation requirements on an ongoing basis
  • Automate Configuration Management function
  • Automate the integration between Release Management and other processes such as change, incident, problem, capacity, service continuity, availability, and service level management to deliver an end-to-end service instead of a point software solution
Next steps

ITIL sites should mature their Release Management by working closely with DevOps groups to become a virtual team thinking alike, breaking down silos and shouldering shared responsibilities. This requires new tools and skills to become service driven instead of remaining infrastructure or software oriented

DevOps staff should widen their horizon that software is only one element of services building blocks, and releasing software to small companies is different from delivering stable services to millions of users whereby all the production environment operational processes should be working in harmony to meet the digital world exigent service levels.

Dr Wissam Raffoul specialises in transforming IT groups into service organisations, with particular expertise in IT Service Management (ITSM), process optimisation, outsourcing and cloud strategies, enterprise systems management solutions and business-centric IT strategies.

Prior to joining IBRS in 2013, he was General Manager strategic consulting in Dimension Data advising clients on applying technology to improve business performance. He was also formerly a vice-president in Gartner /META Group and issued various research publications covering service delivery processes, centre-of-excellence models, managing outsourcing vendors, benchmarks, maturity models, IT procurement evolution and supply/demand models.

In previous positions, he headed HP ITSM consulting Practice in Australia. He also acted as an infrastructure manager, reporting to the CIO at a number of large organisations in government and in the financial and petrochemical industries.

Join the Computerworld newsletter!

Error: Please check your email address.

Tags DevopsITIL

More about Dimension DataGartnerHPIBRSIntegrate

Show Comments