I just ran into your blog entry about devops. Pity we didn’t meet during devops’09 but I guess there will be plenty of other opportunities.

Interesting blog post that yields many reactions from my part.

First of all, openspace is mainly what we bring to it I too thought that it was sometimes too technical but at the same time I think it is because there are still some tools missing to lower the cost of bringing agility to ops [1].

As far as I know, all the companies having bridged the gap and doing “agile ops” have developed in-house tools to do it.

This in my opinion also answers your first question: there is no easy path at the moment to bring this into a company. It is mainly trial and error and before devops, there was very little communication between those involved in that pioneer work.

Hopefully this will change and new tools will lower the entry price tag by allowing re-usability, ensuring reproduceability of experience across workplaces/companies.

As for ITIL and Cobit. Well… I’ve been trying to think in the past at how agile and ITIL could work together, but I must say that I probably failed [2]. There are some similarities between some of the general ideas expresses in ITIL (for instance the scm used for puppet can be seen as a form of CMDB), but there are also IMHO fondamental differences, the first being that ITIL/COBIT are all about processes while agile prefers on interactions and people [3].

Lets just say that it’s probably best to set examples of Agile/bridged-devops practices in non-ITIL/Cobit companies and _prove_ that it works.

Because it is all about proof, right? If you can show a lot of examples from different environments that implements a method that just work, then ITIL should try to integrate it since I believe this will probably be enough to be considered a “best practice” [4]?

This leads to your question about access control. I have only quickly parsed your document on ACHEL and it brings me the following question: why do we want to implement this? For instance, why do we want a manager to sign a technical change (i-e is he the right person to take that decision)? This for me goes against the agile principles where you try to empower people because this is where they will try to do their best and it avoids the blame/”umbrella” culture (people being counter-productive by spending a lot of time/energy to protect themselves).

I believe a process like this may be the wrong solution to the wrong problem. I guess that what I want is to limit risk and bring as much value as possible.

In my opinion, a combinaison of agile values such as common ownership, peer review and of tools such as continuous testing and configuration management are preferable, especially if you have a scm that tracks what/when/who (not to blame someone about something, but to track what happened and fix it asap [5]).

On your last question, I personally believes that at least for a transition period, there might be 4 differents profiles: “classic devs”, “classic ops”, dev-that-care-about-ops and something else that I can’t quite completely describe yet even after the session we had at devops’09 [6].

I hope that everyone may become that something-else-I-can’t-quite-name-yet-because-I-don’t-know-how-to, but it might not be the case. What is sure is that there is a change of paradigm in the air and I’m happy about it because in 10+ years of experience in Ops I wasn’t so impressed by the statut-quo.

Cheers,
Gildas
–
[1] this was the purpose of the “missing tool” session and was something that was discussed in the non technical “what are our values/what name could we choose for our emerging movement”: we need a basic set of tools before this can happen,
[2] I should post some stuff about it on my blog though
[3] http://agilemanifesto.org/
[4] as a matter of fact, I’ve never seen any proof or reference in ITIL/COBIT. “Best practices” seems to be the new religion: you have to believe in its positive effect to be able to see it.
[5] see http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr esp. slides 32, 72 & 73
[6] this too should be a post on my blog….