At 06:16 PM 5/20/2012, Guillaume FORTAINE wrote:
Hmm, I did ignore this as link spamming at first too. But now having
read it, I like it in general, I think a little more definition of
DevOps can help.
(Note, I started this email and left, and now there's a long "but is
it VALID to put people in BOXES using DEFINITIONS" kind of argument
when I came back. I don't think much of that. I believe a lot of
what's wrong with Ops right now is that it's protested too much that
it's an undefinable art and has therefore been 10 years late to the
game to uptake best practices well understood in even that 'cowboy
dev' world. Yes, you can define things and definition is useful,
though threatening to craftsmen, even master craftsmen.)
To respond to the actual article, which seems to not be attempted yet...
1. Devops in the right perspective
This is the one part I disagree with, sad since it's the
first! "DevOps as breaking down silos everywhere in the
organization" is hubris. That's called agile. DevOps is indeed the
focus on the relationship between dev and ops at the product
level. And there's nothing wrong with that. The movement grew out
of the agile operations movement for a reason. The core observation
that the same collaboration is needed in other areas is correct, the
generalization of DevOps to that is not. It's like security people
that say "well CIA, Availability is part of security so hey we should
be figuring out the load balancing and scaling!" You pat them on the
head, say "Sure, sure; now let the people who are actually experts in
that area work."
So yay for agile collaborative organizations; but it's not "Big
DevOps," it's that DevOps is one particular sticking point within
that larger framework that requires a lot of specific work.
2. DevOps Areas
I like these, I think Ben Rockwood's diagram helped me explain to
many people why DevOps isn't just one of those things and I agree
with this extension of it. Well done.
3. Area Layers
I like this OK. It seems very bottom up though. I think there's
some clear devops principles->methods->practices that go top down
from vision just as there are agile principles (e.g. manifesto)->
methods (e.g. Scrum)->practices (e.g. sprints, backlogs, planning poker).
4. Area Maturity Levels
Don't mind this but I agree in shying away from CMMI. No one uses
that crap even for dev any more. Even when it is used it's mostly just abused.
5. Area Indicators and Scorecard
Turning it into metrics is very needed and helpful. We are extremely
metrics driven at my current company - we contribute them and then
every week there's a 90 minute meeting where the entire management
team up to the CTO review them and ask in depth questions.
Please don't take us one step forward, two steps back with
incorporating an even more poorly defined term than DevOps. I
venture to say "working with product teams outside your company" is
similar to no NoOps definition I've ever heard before.
7. CAMS and Areas
This peters out without a whole lot of explanation, I don't know if
it really "maps" so much as "is representable with a similar diagram
for branding purposes" (which is fine)...