Thankyou for starting this discussion.
On Fri, Apr 6, 2012 at 5:11 PM, adrianco <adrian.c...@gmail.com> wrote:
> By useful I mean that the definition is a framework that encompasses all the
> other definitions (within reason), while also providing guidance for people
> trying to decide whether a company is "doing" DevOps, and whether a
> candidate's resume includes DevOps skills. To do this, the definition has to
> be broken into several aspects, and some aspects have to scale
> progressively. When I asked around I found that there is a maturity model
> definition for Agile development, but couldn't find a definition for DevOps
> (http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration), so
> that seems like a good thing to attempt.
>
> I'm not claiming that this is definitive or complete, and I would like input
> from others to validate, guide and extend this definition, if they think it
> is useful.
<--snip-->
> 2. CMMI for Operations
Applying CMMI to DevOps is an interesting idea, and one that could be
useful. It would speak to senior managers who have heard that DevOps
aims to improve business outcomes, and want to understand the
opportunities they have for improvement. Considering the same problem
from the bottom of the organisation (or for the candidate assessing
whether a company is "doing" DevOps) might lead us towards the Joel
Test[1].
In both cases, the contentious part is the definitions. For example,
achieving your Level 5 appears to require organising around PaaS; I
don't agree that that's the pinnacle of DevOps in general, though it's
certainly going to be true for some organisations.
> 3. Personal experiences and skills for people doing DevOps
>
> There are two components to a personal experience, the skill set of the
> person, and the maturity of the organization where they acquired that
> experience. One possible model for this is the
> http://en.wikipedia.org/wiki/Six_Sigma#Implementation_roles Six Sigma "belt"
> levels, although the names matter less than the categories.
I'd take a step further back and suggest that the categories matter
less than the intent. Who is the audience for this section? How
would it be applied?
When I was starting my career as a system administrator, the SAGE "Job
Descriptions for System Administrators"[2] had a big impact on me,
providing a roadmap for my growth as a professional. It was easy to
figure out where I stood, and what I needed to work on to improve.
Where do junior sysadmins these days go for guidance? Perhaps, for
operations staff, the SAGE levels simply need to be updated to reflect
the soft skills and tools families that have come to prominence since
the originals were written.
Looking to Six Sigma for guidance here gets my hackles up. Two main points:
* I don't feel that Six Sigma implementation is analogous to DevOps
in any meaningful way
* The tone is exclusive, not inclusive, and antithetical to the
principles of the movement
I don't think we're at a point where looking to evaluation or
accreditation schemes is useful.
Conversely, I think there's a lot of value in helping individuals
identify opportunities for self-improvement and professional
development. I'd love to see something that speaks to that audience.
> 4. Skills and Tools
>
> There needs to be a clear enough definition that a hiring manager can get
> guidance to write a DevOps oriented job spec. They will do that anyway...
> There are many varieties of DevOps skills, just as there are many varieties
> of Developer skills and Operations skills. The key is that DevOps should
> combine skill sets along with the concepts of how to integrate them.
I don't agree that "doing DevOps" involves "hiring DevOps", or that
being able to write a "DevOps job spec" is a generally useful thing.
Conversely, I do want to be able to hire developers and system
administrators who have developed the skills (soft and hard) that I
associate with DevOps - whether or not the candidate is familiar with
the term. Then again, that was true before *I* was familiar with the
term.
Zac
1: http://www.joelonsoftware.com/articles/fog0000000043.html
2: http://static.sage.org/field/jobs-descriptions.html
I'd take a step further back and suggest that the categories matter
> 3. Personal experiences and skills for people doing DevOps
>
> There are two components to a personal experience, the skill set of the
> person, and the maturity of the organization where they acquired that
> experience. One possible model for this is the
> http://en.wikipedia.org/wiki/Six_Sigma#Implementation_roles Six Sigma "belt"
> levels, although the names matter less than the categories.
less than the intent. Who is the audience for this section? How
would it be applied?
When I was starting my career as a system administrator, the SAGE "Job
Descriptions for System Administrators"[2] had a big impact on me,
providing a roadmap for my growth as a professional. It was easy to
figure out where I stood, and what I needed to work on to improve.
Where do junior sysadmins these days go for guidance? Perhaps, for
operations staff, the SAGE levels simply need to be updated to reflect
the soft skills and tools families that have come to prominence since
the originals were written.
Looking to Six Sigma for guidance here gets my hackles up. Two main points:
* I don't feel that Six Sigma implementation is analogous to DevOps
in any meaningful way
* The tone is exclusive, not inclusive, and antithetical to the
principles of the movement
I don't think we're at a point where looking to evaluation or
accreditation schemes is useful.
Conversely, I think there's a lot of value in helping individuals
identify opportunities for self-improvement and professional
development. I'd love to see something that speaks to that audience.
I don't agree that "doing DevOps" involves "hiring DevOps", or that
> 4. Skills and Tools
>
> There needs to be a clear enough definition that a hiring manager can get
> guidance to write a DevOps oriented job spec. They will do that anyway...
> There are many varieties of DevOps skills, just as there are many varieties
> of Developer skills and Operations skills. The key is that DevOps should
> combine skill sets along with the concepts of how to integrate them.
being able to write a "DevOps job spec" is a generally useful thing.
Conversely, I do want to be able to hire developers and system
administrators who have developed the skills (soft and hard) that I
associate with DevOps - whether or not the candidate is familiar with
the term. Then again, that was true before *I* was familiar with the
term.
Zac
1: http://www.joelonsoftware.com/articles/fog0000000043.html
2: http://static.sage.org/field/jobs-descriptions.html