ITSM with ITIL vs DevOps, a Question of Requirements
Using a process management system for Enterprise IT Services Management, would typically mean using the Information Technology Infrastructure Library (ITSM with ITIL), in a historical sense, this has had some surprising weaknesses, the biggest of which was the complete lack of a Requirements Management (RM) phase. Requirements Management is the bedrock of Agile Development, and since all development is based upon defined requirements and then tested against those requirements throughout development, it was a major problem for Development teams. Not surprisingly the failure of ITIL to sufficiently accommodate Agile Development has lead to the rise of an ITIL alternative based upon Agile Development now known as DevOps. Which one would win in a comparison, ITIL vs DevOps?
An IT Services department using ITIL with a complete absense of RM is a road block to application development. There is no bigger disconnect between development and IT services than the failure of communication about product requirements. Without real time feedback about the clients needs from IT Services, there is a disconnect with the end consumer, potentially leading to a fall in consumer satisfaction in the product (which no longer meets expectations) and the potential loss of the business entirely.
It was not until ITIL v3 (2007) superseeded in 2011 by ITIL 2011, that a Lifecycle approach to IT Services Management was adopted. This greatly improved how ITSM aligned with business requirements with an emphasis on continual improvement, something that both the ITIL library of knowledge shares with Agile and DevOps.
Why Use The Scaled Agile Framework?
In an age where application development, IoT and Industry 4.0 are in the spotlight, playing an ever important, expanding role within the Enterprise; data silos between Development teams and IT Servces must be broken down to streamline the development process. The very strengths that make Agile great for software development, for its accommodation for constantly changing requirements is also needed for IT Services, but more than this, they need to be integrated. This is now possible with the Scaled Agile Framework v3 (Latest version is now SAFe v4 released 2016), which extends the Agile Methodology to include IT Services to what is now referred to as DevOps.
The ideal DevOps senario is one that leaves the now outdated ITIL behind.
The conflicting mainstream reality is one where IT Services Managers try to retain what works of ITIL and instead tries to adopt what works from Agile and DevOps, completely ignoring the Agile Change Management and work culture change required to make it work. The piecemeal pick and mix approach to Agile and DevOps adoption is fraught with risks, as Agile purists and trainers will preach; however the risk is likely no greater than abandoning a complete (less than optimal) working system (ITIL) for a system that is unused or untested system internally, regardless of the potential benefits. Of course, its not quite that simple, because Agile Methodology is now the defacto standard for application development, and is therefore already in use in most organisations to some extent or another. There is often a working Agile model, ready for extension to include IT Services and with an ALM software that supports not only the Scaled Agile Framework but also the implementation of ISO 20000, – transitioning to SAFe and DevOps becomes a far less risky proposition.
Whatever the migration senario, piece by piece or all-change to DevOps, a tool capable of scaling up Agile development is necessary. Unfortunately, many of the Agile Tools currently in use for Agile Development are not suitable for DevOps, not providing for the needs of an integrated Development and IT Services Department (codeBeamer ALM does support ISO 20000 via its features).
When adopting a DevOps Development strategy, – adhoc tools connected by API are often needed for specific tasks such as analytics (see article on Hybrid Cloud), however the core features of IT Service management (ie escalation managment) and Development must be integrated, using APIs for core functionality is not an effective solution, multiplying system failure risk, – providing more points of potential technical and service failure. For this very reason, tools with dozens of addon plugins should be avoided. As an example tool, an independent IT Service desk system,- no matter how good it might be, can not provide the integration required for real time feedback and provide complete traceability and transparency throughout the entire Application Lifecycle (including maintainence). Bugs reported by clients should feed directly into the Application Lifecycle Management platform (ALM Software) to developers with available capacity and without little or no interaction from IT Services as well as provide an continual progress report directly to the reporting user in real time.
For an optimal DevOps implementation at Enterprise Level, ALM Software is essential. Since software development is a value / revenue generating engine of most businesses, it makes sense that the collaboration tool (ALM Software is first and foremost a collaboration tool) used is designed for use with Agile Methodology and development, one that can be extended for IT Services (IT Service related tools are completely unsuitable for Agile Development). Real time feedback from IT Services and end users provides streamlines requirements management processes, enabling enterprise to build and extend products organically, – dependent upon user demand thus giving the users what they want, more quickly and to a higher standard. Moreover, real time bug reporting enables bug fixes to be made and rolled out remotely (in a IoT environment) even before 99% of users have encountered the fault.
Perhaps the biggest arguement for rejecting ITIL and adopting DevOps is a simple one, why keep two seperate bodies of knowledge suitable for IT Service Management (when both are in use) where only one is also suitable for Application Development, clearly here the optimal choice is to adopt the single integrated solution.
Another major factor is that ALM Software such as our very own codeBeamer ALM is suitable for ITSM and includes an integrated service desk as well as advanced business process management (codeBeamer BPM), necessary for integration with other ERP solutions. The reverse cannot be said, tools for just ITSM are NOT suitable for Agile application development, lacking the essential features necessary for managing Agile Requirements management for instance. The very requirement of application development software to be cutting edge ensures that ALM software is the most technically viable option.
Intland Software’s codeBeamer ALM is IioT ready, built for DevOps and the connected future of IoT and Industry 4.0 and is flexible enough for use with a migration away approach, from ITIL to Agile and DevOps.