DevOps Zone is brought to you in partnership with:

Israel Gat ("agile_exec") is recognized as the architect of the agile transformation at BMC Software. Under his leadership, BMC software development increased Scrum users from zero to 1,000 in four years. Dr. Gat currently focuses on technical debt, large-scale implementations of lean software methods and devops. Israel is a DZone MVB and is not an employee of DZone and has posted 36 posts at DZone. You can read more from them at their website. View Full User Profile

Devops: It is Not About ITIL, It is About Proficiency

  • submit to reddit

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.

Published at DZone with permission of Israel Gat, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Mark Koontz replied on Tue, 2011/08/30 - 2:54pm

I think ITIL is agnostic on the issue. If you are deploying to a QA or user-acceptance environment, then these deployments would be standard, pre-approved changes and you could deploy as many as you want as fast as you want.

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:

  • Can the service desk quickly answer questions and resolve incidents?
  • Is extra operational support needed during the break-in period?
  • Will users know how to use the new function?
  • How quickly can operations accept responsibility for the changed application?

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.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.