With the arrival of new technologies like virtualization and cloud, as well as new methods such as “agile,” pressure is on the release management and operations team to deliver development outputs to production more quickly. DevOps is a relatively new development that meets this need, raising many hopes for the faster, better delivery of new functions, from development to production.
DevOps is also a cultural movement bringing together the diverse capabilities and traditions of application development, release management, testing and operations – hence the name DEVelopment and OPerationS.
The diagram below depicts the critical drivers (red) and enablers (blue) for DevOps success, thus establishing DevOps as a critical foundation for the digital era.
However, integration of Ops and Dev teams does not mean returning to old, bad habits of developers having access to production systems for on-the-spot tweaking or ops folks applying untested patches! Too much of business today depends on IT. We can’t put our IT systems at risk by getting lax on governance and compliance.
Frameworks like ITIL (IT Infrastructure Library) or COBIT (Control Objectives for Information and Related Technologies) provide the processes and measurement systems to control risk and establish governance. However, these processes have often been implemented too rigorously and inflexibly in the past, to the extent that a “wall” was built between dev and ops that one could only scale with approval from the infamous “change advisory board.”
This concept was introduced in ITIL’s change management process. But it doesn’t have to be applied so rigorously. The architecture of the process allows for flexibility, depending on the nature and risk impact of the change.
Only “normal changes” with a certain, predefined level of risk have to be evaluated and authorized by a change advisory board or another level of seniority. “Standard changes” that come with little risk, are well understood and highly automated do not need the same level of review. Thus, they become the perfect type of change for DevOps!
Standard changes are used for routine requests such as installation of a new program on a PC or the delivery of a patch to a single server. The procedures are well known and completely automated. The same is true for DevOps-style changes: The risks are comprehensible and the possible impact limited since each step, from testing and packaging to deployment and monitoring, is heavily automated.
Thus, adding DevOps to ITIL is not a contradiction but a perfect complement, updating ITIL for the new reality of IT management. And this framework will be needed more and more as technology moves toward modern, single-purpose, loosely coupled systems and apps. Adding DevOps capabilities to our traditional process and governance environment will allow us to jumpstart in the digital era.
Shifting the emphasis on new technologies and process structures also has an impact on the IT organization. IT will now have to operate in two modes, since not all applications are suited for DevOps-style delivery. Besides mainframe solutions, the big, packaged applications such as SAP or Oracle will be upgraded in major releases for the foreseeable future.
With a bi-modal approach, organizations will need to move away from the traditional understanding of ITIL, being mostly for operations with emphasis on “incident-problem-change-config,” to the strategic elements of the service lifecycle, such as demand management, service portfolio management, governance and continual service improvement.
Markus Schweizer is an Associate Partner at CSC’s Digital Strategy and Transformation team in Switzerland. He has extensive experience in IT management consulting with emphasis on service management, governance and strategy. Connect with him on LinkedIn.