Devops: It is Not About ITIL, It is About Proficiency
As you would expect, the Information Technology Infrastructure Library (ITIL) topic was brought up in the devops day held in 2010 in a LinkedIn facility in Mountain View, CA. We, of course, had the expected spectrum of opinions about ITIL in the context of devops – from “ITIL will never work for a true continuous development shop” to “well, you can make ITIL work under such circumstances.” Needless to say, a noticeable level of passion accompanied these two statements…
IMHO the heart of the issue is not ITIL per se but system management proficiency. If your system management proficiency is high, you are likely to be able to effectively respond to 10, 20 or 50 deploys per day. Conversely, if your system management proficiency is low, ops is not likely to be able to cope with high velocity in dev. The critical piece is alignment of velocities between dev and ops, not the method used to manage IT systems and services. Whether you use ITIL, COBIT or your own home-grown set of best practices is irrelevant. Achieving alignment of velocities between dev and ops is a matter of proficiency in system management.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)






Comments
Mark Koontz replied on Tue, 2011/08/30 - 2:54pm
If you're deploying to a production environment where a business process could be disrupted, then it's strictly up to the business tolerance for this kind of risk. A certain amount of diligence may be warranted in this case, and ITIL provides a standard means for applying diligence. It's up to the business whether diligence is quick or slow. If you're adding functions the business needs right now and it's a standard kind of deployment, then the change manager could convene a CAB this afternoon and your changes could be in tonight.
The ITIL processes help ask questions about whether you're prepared to support new function in operations:
When you use repeatable processes (like ITIL) for resolving these issues, it becomes possible to improve them for speed and quality.
ITIL doesn't need to be viewed as the Book of Bureaucracy. On the other hand, if your business wants to be bureaucractic, ITIL gives it a lot of ammunition.
Mark