Codifying DevOps

191 views
Skip to first unread message

Guillaume FORTAINE

unread,
May 20, 2012, 7:16:40 PM5/20/12
to dev...@googlegroups.com
Hello,

For your information :

http://java.dzone.com/articles/codifying-devops

Best Regards,

Guillaume FORTAINE

bongo

unread,
May 22, 2012, 7:26:37 AM5/22/12
to dev...@googlegroups.com
For starters, it's "DevOps" not "Devops" or "devops".

Secondly, link bait spam.

Finally, I am yet to find someone who is a consultant - especially one of 15 years - who is well endowed enough with experience and the know how of current industry trends and best practices, to write a blog post on how companies should be practicing said best practices. Consultants are usually last to the party, clean up all the free booze left around, and are too busy taking photos of the party while everyone is off someone else.

I am really not impressed.

Stefan Goethals

unread,
May 22, 2012, 7:29:46 AM5/22/12
to dev...@googlegroups.com
Funny....

Stefan Goethals

unread,
May 22, 2012, 7:30:33 AM5/22/12
to dev...@googlegroups.com
That 'Funny' was about bongo's silly reply...

Evan Bottcher

unread,
May 22, 2012, 7:42:00 AM5/22/12
to dev...@googlegroups.com
wait… I'll just get some popcorn...

David Lutz

unread,
May 22, 2012, 8:01:50 AM5/22/12
to dev...@googlegroups.com
I've got marshmallows...

;-)

Gildas

unread,
May 22, 2012, 8:09:46 AM5/22/12
to dev...@googlegroups.com
David,

I just wanted to point that the article was actually written by
Patrick Debois, who invented the term devops (and as far as I know he
prefers it with no capital letters) as he organised the first
devopsdays in Gent in 2009.

You might not agree with the way he tries to formalize it (myself I'm
not a big fan of the formalism) but I think he has all the legimacy
required to try and do it.

Regards,
Gildas

On Tue, May 22, 2012 at 1:26 PM, bongo <da...@sonicb.com> wrote:

Matt Ryanczak

unread,
May 22, 2012, 8:26:50 AM5/22/12
to dev...@googlegroups.com
On 5/22/12 7:26 AM, bongo wrote:
> I am really not impressed.

...with this reply. Yet another example of how the ongoing tone of this
list defeats any meaningful discussion...

Matt O'Keefe

unread,
May 22, 2012, 10:13:56 AM5/22/12
to dev...@googlegroups.com
Maybe "bongo" is a "brogrammer" who practices "BroOps" who's sensibilities were offended? He does mention booze and parties... :)

Matt Joyce

unread,
May 22, 2012, 10:45:48 AM5/22/12
to dev...@googlegroups.com

Please let us not impune he rich culture of the noble bro.

bongo

unread,
May 22, 2012, 10:50:36 AM5/22/12
to dev...@googlegroups.com
Haha, BroOps, I love it.

Sorry guys - it was tongue in cheek and (what I thought) full of sarcasm. I have to agree with Gildas on his thoughts with formalism, as I try and to optimise and simplify my day job (and all things in life).. but it's awesome to see people see building and stretching and thinking outside of the box of devops.

:)

mpron

unread,
May 22, 2012, 10:53:12 AM5/22/12
to devops
Just wanna make sure everyone knows that this was posted with the
written permission of Patrick DuBois. Great guy. See source links in
the author block at the top and under the tags at the bottom.

Now, back to the debate.

Patrick Debois

unread,
May 22, 2012, 10:55:05 AM5/22/12
to dev...@googlegroups.com
Hi David and list,

I can't apologize for the fact that I'm consultant, that's just the way
it is.

The fact that I accidentally came up with the term devops doesn't give
any more credibility than anyone out there. What I think about the name
should be in uppercase or lowercase is even completely irrelevant.

I can't help my passion for devops and I will not apologize for it
either: it drives me to organize devopsdays and blog and tweet about it.
Feel free to ignore my opinion in any way.

I totally understand that while reading the blogpost, your bullshit
detector kicked and as a matter of fact it totally should! You should
not believe anything on the internet without giving it good thought.

From the beginning that the term "devops" was used, there has been
endless demands ranging from a Devops Manifest to a definitive
description. It always made me cringe at the idea: whatever you write
down can interpreted dogmatically. During my 20 years (yeah I should
update my blog), I've seen this happen to Itil, Agile or whatever ideas
are out there. Before you know it , it can lead to hollow things like
"devops" training or "devops" certification But I beg to say that those
'framework' by themselves aren't good or bad. It's the dogmatic
application of the ideas that give them a bad name.

On hindsight, not having a specific definition has proven a good thing:
it allowed the community of ideas to grow and expand. Discussions that
happened on this mailinglist like "you're not using a configuration
management, so you're not devops" really make me sad. I want to keep
expanding the ideas. No matter what your definition of devops bring your
ideas to the table! I've always quoted: "Cloud has more than 40
definitions, does it make it any less useful?"

But here's the real dilemma: people new to the subject are asking me
over and over again , do you have any references or sources of
information we should read? Only being able to answer follow the twitter
hashtag or search google, didn't feel right either. After many
consideration (almost 3 years now) I finally became convinced that the
benefits to bundle all the information outweighs the danger of people
taking it prescriptive or applying it narrow minded.

Enter my blogpost: because I'm so sensitive about this matter as well
(like my other co-authors), I decided to put our current train of
thought on the web. A few tweets later I started noticing people were
kind of silent about it, not sure what to think about it. Did Patrick go
to the darkside? Rest assured I'm a jedi and will be a jedi4ver.

There is not intend to be pre-scriptive! I know it's a long article, but
if you were to read it to it's full extend you will see I explicitly
don't want that to happen! I apologize if this was how it came across
but I think if it's just the skeptic reflexes kicking in.

We are grouping interesting "devops" stories and practices together. So
people can find them in one place. Many of these stories seemed to be
one-offs tricks/hacks. Hard to structure in a book. For me personally
the structure of the areas made me help to group the stories. Also it
allows to think about layers (like people and process) we are giving
less thought than merely tools. The fact of the maturity levels was a
side effect; I literally mention: "they are useless if you want to lie
to yourself or your colleagues"

But enough of my reasoning, what could we do to improve it? Please tell
me your worries (that is on it's content :).

I make no plea to agree with me, just to learn and understand.

Patrick


Gildas

unread,
May 22, 2012, 11:43:50 AM5/22/12
to dev...@googlegroups.com
On Tue, May 22, 2012 at 4:55 PM, Patrick Debois
<patrick...@gmail.com> wrote:
> Hi David and list,

Hi Patrick,

[SNIP]
> From the beginning that the term "devops" was used, there has been endless
> demands ranging from a Devops Manifest to a definitive description. It
> always made me cringe at the idea: whatever you write down can interpreted
> dogmatically. During my 20 years (yeah I should update my blog), I've seen
> this happen to Itil, Agile or whatever ideas are out there. Before you know
> it , it can lead to hollow things like "devops" training or "devops"
> certification  But I beg to say that those 'framework' by themselves aren't
> good or bad. It's the dogmatic application of the ideas that give them a bad
> name.

Yes and I'm sure the people who wrote stuff about Agile were adamant
saying their presentation should not be taken dogmatically, and still
it was :)

[SNIP]
> But here's the real dilemma: people new to the subject are asking me over
> and over again , do you have any references or sources of information we
> should read? Only being able to answer follow the twitter hashtag or search
> google, didn't feel right either. After many consideration (almost 3 years
> now) I finally became convinced that the benefits to bundle all the
> information outweighs the danger of people taking it prescriptive or
> applying it narrow minded.
[SNIP]
> There is not intend to be pre-scriptive! I know it's a long article, but if
> you were to read it to it's full extend you will see I explicitly don't want
> that to happen! I apologize if this was how it came across but I think if
> it's just the skeptic reflexes kicking in.
>
> We are grouping interesting "devops" stories and practices together. So
> people can find them in one place. Many of these stories seemed to be
> one-offs tricks/hacks. Hard to structure in a book. For me personally the
> structure of the areas made me help to group the stories. Also it allows to
> think about layers (like people and process) we are giving less thought than
> merely tools. The fact of the maturity levels was a side effect; I literally
> mention: "they are useless if you want to lie to yourself or your
> colleagues"
>
> But enough of my reasoning, what could we do to improve it? Please tell me
> your worries (that is on it's content :).

I think it might be better to present this as a "devops fieldbook"
instead of trying to structure/derive laws/rule from the different
stories you have and then articulate the book along those laws/rules
(1).

You can organise chapters based on the value or difficulty you
(writers of the book) affect to each story, if you want to provide a
sense of progression. People will understand it's not prescriptive and
you don't have to define a target/ideal like they have in CMMI and
such.

I believe devops is a journey. And I believe there's more value in the
journey itself than in an hypothetical target/goal/ideal.

Cheers,
Gildas

--
1- something along the lines of what was done in the "5th discipline
fieldbook" http://www.amazon.com/The-Fifth-Discipline-Fieldbook-Organization/dp/0385472560

Matt Joyce

unread,
May 22, 2012, 12:39:19 PM5/22/12
to dev...@googlegroups.com
I think any attempt to codify devops at this point is both premature and ultimately destructive.  At the very least codify some guidelines to follow before setting stuff in stone.  Ala, do not tie devops codes of conduct to existing technology or paradigms.

Scalability and adaptability are what tech is all about.  Operations is the duct tape that keeps our world's data moving.  And to be duct tape we cannot be specialized.

Jaime Gago

unread,
May 22, 2012, 12:48:45 PM5/22/12
to dev...@googlegroups.com
Unless the specialization is being the duct tape, that is what "Devops is a journey not a destination" means to me. Another way to put this is we change specialities all the time, that is our speciality.

J.

Matt Joyce

unread,
May 22, 2012, 12:56:22 PM5/22/12
to dev...@googlegroups.com
try selling that to a cto.  i'd love a video.

Miles Fidelman

unread,
May 22, 2012, 1:09:33 PM5/22/12
to dev...@googlegroups.com
Any CTO who prefers a packaged methodology over doing some homework and
tailoring technology/process to the specifics of their business, is a
CTO to be avoided. (And boy, if you hear your CTO talk about "total
quality management" or "six sigma" - that's the time to run for the
door. c.f. Dilbert for references to "stink like a dead weasel").
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra


Joe McDonagh

unread,
May 22, 2012, 1:22:59 PM5/22/12
to dev...@googlegroups.com, Miles Fidelman
Not sure I see the connection between Six Sigma and this kind of
mentality...
Joe McDonagh

AIM: YoosingYoonickz Google: Joseph.E.McDonagh
IRC: joe-mac Skype: therealjoemac

Eric Shamow

unread,
May 22, 2012, 1:45:38 PM5/22/12
to dev...@googlegroups.com
On Tuesday, May 22, 2012 at 1:09 PM, Miles Fidelman wrote:
Any CTO who prefers a packaged methodology over doing some homework and
tailoring technology/process to the specifics of their business, is a
CTO to be avoided. (And boy, if you hear your CTO talk about "total
quality management" or "six sigma" - that's the time to run for the
door. c.f. Dilbert for references to "stink like a dead weasel").

Any methodology can be misapplied or broken badly.  Agile is very often misapplied as has been pointed out elsewhere on the list - it doesn't mean that Agile as a methodology is worthless.  The same is true for Six Sigma.

-Eric

Henk Langeveld

unread,
May 22, 2012, 4:34:55 PM5/22/12
to dev...@googlegroups.com
On 22/05/2012 17:43, Gildas wrote:
> I think it might be better to present this as a "devops fieldbook"
> instead of trying to structure/derive laws/rule from the different
> stories you have and then articulate the book along those laws/rules
> (1).
>
> You can organise chapters based on the value or difficulty you
> (writers of the book) affect to each story, if you want to provide a
> sense of progression. People will understand it's not prescriptive and
> you don't have to define a target/ideal like they have in CMMI and
> such.
>
> I believe devops is a journey. And I believe there's more value in the
> journey itself than in an hypothetical target/goal/ideal.

Indeed, as with Agile and Lean, continuous improvement is an essential
part of Devops.

Just the other day Alan Shalloway mentioned the paradox of
"standard work" on the kanbandev list:

> To best understand this, let’s look at two quotes from Taiichi Ohno:
>
> * "No standards no kaizen"
> * "I told everyone that they weren't earning their pay if they left
> the standardized work unchanged for a whole month"

http://www.netobjectives.com/blogs/standard-work-why-we-need-it-0

For certain things, we do need standards, but as we improve things,
the standards may become stale. But before you get into that rythm,
it may help to just do what others have shown works.

Cheers,
Henk

Matt Joyce

unread,
May 22, 2012, 5:06:31 PM5/22/12
to dev...@googlegroups.com
To put it my own way...

Tell a person not to do something, they will want to do it.
Tell a person they should do something, they will avoid doing it just to spite you.
Show a person something works, and they will adopt it immediately.

Leadership by example is the only leadership there is.

-Matt

Ernest Mueller

unread,
May 22, 2012, 7:33:45 PM5/22/12
to dev...@googlegroups.com
At 06:16 PM 5/20/2012, Guillaume FORTAINE wrote:

>http://java.dzone.com/articles/codifying-devops

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.

6. NOOPS

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)...

Ernest

James Holmes

unread,
May 22, 2012, 9:51:27 PM5/22/12
to dev...@googlegroups.com
The key to Agile culture (including devops, lean and anything else we choose to call Agile) is the Shu Ha Ri principle. If people can't see a "standard" set of tested, working practices, they'll have a tough time evaluating what to keep and what to throw away. This appears dogmatic at first; the point is that once the set of practices have been mastered the practitioners are then free to change them, discard them and invent new ones.

The benefit of this is that not everyone needs to fully understand up front why the whole set of techniques exists. They'll work this out themselves over time by actually doing them. This gets the team up and running with their adoption immediately and leverages the experience of those who've come before them, rather than expecting each new team to reinvent the wheel.

damone...@gmail.com

unread,
May 22, 2012, 11:27:13 PM5/22/12
to dev...@googlegroups.com
I see your point about being careful of DevOps being heralded as a panacea for all ills. But DevOps isolated to just the point of contact between Dev and Ops isn't the answer either.

You could say the macro perspective is "Lean" in it's purest form, but DevOps has as much claim to it in the technology realm as Agile does. The only proof I need that "big picture" isn't properly represented by Agile is that the Agile movement has been around for a long time (in "tech years") yet completely missed the big picture that you needed the align and optimize the entire development to operations delivery cycle to properly implement Lean in a software as a service world. Sure you can reference a handful of sharp folks who have been saying this all along… but the vast majority of the thought, effort, dollars, and time that has gone into Agile has resulted in a prescriptive methodology for software development that starts with requirements and ends with "code complete". I'm sure the purists will cringe at this and the manifesto will roll over in it's grave… but that is where that movement has gone. It's become a local optimization that doesn't address the "global" concern of the development to operations delivery cycle (i.e. what the business actually cares about and pays for)

Now on to DevOps… Are we not doomed to repeat the same mistake if we don't take the all inclusive holistic approach? The whole point of having a "dev" and an "ops" is to take business ideas and manifest them as running features for customers. What's the point of the "focus on the relationship between dev and ops at the product level" if it doesn't optimize the whole system to achieve it's purpose? In order to optimize that relationship for that purpose you have to include all the pieces that must come together to make that happen. That doesn't mean that everyone has to be a generalist in everything (your example of conflating security and availability), but it does mean that everyone has to understand the system they are a part of and how to work together to fulfill the purpose of the system.

When the original DevOps conversation started, it was taking a broad system-wide view. The two seminal events both talked about Dev and Ops as if they were the entire technology house split into two sides. Paul Hammond (Dev) and John Allspaw (Ops) represented the entire Flickr technology team (at least figuratively if not literally). The first DevOps Days in Ghent was framed as bringing together the two self-identifications that rarely gather at the same conference, Dev and Ops.

Post DevOps Days Ghent the conversation definitely became deployment centric. Why? Because deployment is the canary in the coal mine for a broken development to operations lifecycle. It's the flash point where the pain is felt, but the root cause of that pain comes from somewhere else.

Now that I'm 5 paragraphs into a rant… :)

I'm realizing that I probably should have asked what you meant by "focus on the relationship between dev and ops and the product level"? Can you provide examples of what is and isn't in scope by that DevOps definition?

Erik Hollensbe

unread,
May 23, 2012, 12:09:58 AM5/23/12
to dev...@googlegroups.com
All I took away from this entire thread, was that DevOps is to systems people what Web 2.0 was to designers.

To be completely unmistaken: folks, it's getting warm on this list from all the hot air.

I won't speak for anyone but myself, but it'd be nice to get back to talking about actual technology that serves the needs of people straddling the development and operations divisions in companies.

Don't blame me for the rage; blame Phil Hollenback, it's all his fault for egging me on. :)

-Erik

damone...@gmail.com

unread,
May 23, 2012, 12:37:40 AM5/23/12
to dev...@googlegroups.com
Being concerned with improving process and organizational dynamics = hot air?

That is like saying that rather than studying "hot air" like TPS, Lean, ERP, or Operations Management the business world would have been better off if everyone just focused all that effort on building better robots.

Pick any company that you would consider to be a low performing organization and drop off the exact list of tools used by Etsy or Amazon. Would they suddenly perform just like Etsy and Amazon? Of course not. Why? Because they didn't understand all of the stuff you are calling "hot air".

Eric Shamow

unread,
May 23, 2012, 12:39:41 AM5/23/12
to dev...@googlegroups.com
Erik,

You may do better on the devops-toolchain list, which although relatively inactive of late, is intended for specific discussion around tooling.

For better or for worse devops is as much if not more a management/cultural issue than a tools-based one.  The tools only exist to facilitate the culture change.

-Eric

-- 
Eric Shamow
Sent with Sparrow

Chad Woolley

unread,
May 23, 2012, 12:47:33 AM5/23/12
to dev...@googlegroups.com
"M" is the mute thread hotkey in gmail...

Noah Campbell

unread,
May 23, 2012, 1:01:08 AM5/23/12
to dev...@googlegroups.com
That's why there is devops-t...@googlegroups.com, so tool discussions can rage on in their full gory detail.

-Noah
Noah Campbell
415-513-3545
noahca...@gmail.com



Gmail - benkrueger

unread,
May 23, 2012, 6:09:31 AM5/23/12
to dev...@googlegroups.com
Honestly, tools are well and good and necessary, but engineers aren't good at things like building reliable bridges and skyscrapers solely because of their tools. It's because of all the icky, gooey, sometimes painful process maturation, codification, and scientific rigor they've spent a very long time refining. Who wants to cross a bridge built by engineers that consider this kind of stuff "hot air"? I can't speak for anyone else, but I consider pursuing that kind of professional maturation to be the greater mission here.

ranjib dey

unread,
May 23, 2012, 6:19:57 AM5/23/12
to dev...@googlegroups.com
i have found to keep the toolchains and principles or methodologies tied together, It helps me explaining how the principles are implemented or practiced in day to day life. I agree the a tool only communication should happen in the different group, but it does not harm to mention them in this forum as long as they add value to the communication. 
Also, our individual perceptions are derived from our own experiences, which differs vastly. I am not as  experienced as the other in this thread, but i have seen places where the major bottle neck was culture or process or mindset. But i have also seen cases where practicing devops is difficult primarily due to the tech stack or tools. Note, its not impossible may be, but it considerably difficult compared to other stacks. So, as long as we dont restrict the scope of this movement to only certain use cases or domains, both methodology as well as tool chain specific learning are important. Their proportion might differ case by case.

ranjib dey

unread,
May 23, 2012, 6:27:16 AM5/23/12
to dev...@googlegroups.com
Sorry for the horrible english. Rephrasing it.

i have found keeping the toolchain and principles or methodologies together works well.  It helps explaining how the principles are implemented or practiced in day to day life. I agree that a tool only communication should happen in the different group, but it does not harm to mention them in this forum as long as they add value to the topic. 
Also, our individual perceptions are derived from our own experiences, which differs vastly. I am not as  experienced as the others in this thread, but i have seen places where the major bottle neck was culture or process or mindset. But i have also seen cases where practicing devops is difficult primarily due to the tech stack or tools. Note, its not impossible may be, but it considerably difficult compared to other stacks. So, as long as we dont restrict the scope of this movement to only certain use cases or domains, both methodology as well as tool chain specific learning is important. Their relevance might differ case by case.

James Bailey

unread,
May 23, 2012, 6:58:11 AM5/23/12
to dev...@googlegroups.com
On 23 May 2012 11:09, Gmail - benkrueger <ben.k...@gmail.com> wrote:
> Honestly, tools are well and good and necessary, but engineers aren't good at things like building reliable bridges and skyscrapers solely because of their tools. It's because of all the icky, gooey, sometimes painful process maturation, codification, and scientific rigor they've spent a very long time refining. Who wants to cross a bridge built by engineers that consider this kind of stuff "hot air"? I can't speak for anyone else, but I consider pursuing that kind of professional maturation to be the greater mission here.
>
DevOps has always been about more than just the tools. It is
phenotypically similar to "Operations Management", Ben Rockwood has
written an excellent blog post about this and I can heartily recommend
it and some of the reference material in the article.[0]

Good Operations Management knowledge brought systemic order and
efficiency to organisations involved in the physical manufacturing
technologies of the last 3 centuries. This wisdom was written down
and distilled into the books you can buy today. So DevOps in it's
place and time has naturally grown from within the information
technology industry. Being a child of the 21st century the blogs came
first from Patrick, Ben and many others, the books and the courses on
how to do DevOps are following, all of this will codify DevOps.

Embrace it!

Jim

[0] http://cuddletech.com/blog/?p=642

Ernest Mueller

unread,
May 23, 2012, 8:09:29 AM5/23/12
to dev...@googlegroups.com
Well, but Agile hasn't dropped the ball - it's
just that it's just now getting around to us.
When you look at the actual big picture there's a
lot to it. The Agile Austin group, for example,
has SIGs on agile dev, agile QA, agile
architecture, agile product development, agile
UX, agile leadership... And now DevOps. Just
because now we're down with the concepts that are
new and shiny to us doesn't mean we now know how
to fix all the other parts of an organization.

Going and looking at the first diagram in
Patrick's article - no, optimizing the
relationship between HR and Sales is not
"DevOps." That's ridiculous. It's overreaching
IMO just like my security example. DevOps isn't
just chef and puppet, or just about deployment,
but I think its focus is realistically on the
part where ops is actually embedding into the
rest of the organization instead of being a
segmented sideshow and optimizing the process of
actually delivering services. Yes, dev and ops
represent the "two sides of the technology house"
- and I think Ops can properly be understood to
rep Net and Sec and all that as we move forward -
but the scope is not "everything in an
organization all the way to HR and Finance." Ops
is waking up and smelling the coffee here, not
inventing coffee. The expansion dilutes the
usefulness of the focus. DevOps isn't
lean/agile/OM but better. It's an application of
those principles to a product team creating and delivering software.

The next DevOps Areas part I think is
great. It's the initial "well DevOps is
everything!" thing that sounds like consulting gig scope creep to me.

Ernest

Patrick Debois

unread,
May 23, 2012, 8:23:50 AM5/23/12
to dev...@googlegroups.com
Hi Ernest,

obviously! not that all improvements are 'devops' issues. That would be
stretching it too far indeed.

The reasoning was more that when we try to optimize your 'dev & ops'
problem,
the bottleneck for improving it may well be outside dev & ops.
So you have to have a broad view, otherwise you're still trying to solve
some problems with a narrow view.

While reasoning on the stories for the book , it made me think about the
things happening in other parts of the company that have an influence on
the dev and ops tension.

- hiring/HR policy can have it's effect on the devops tension , what
kind of persons fit well in this problem
- financial incentive of each groups can have have an impact on the problem

I've seen the same thing happen with agile teams trying to solve 'devops
problems' within the dev team only.

Makes sense?
>> have been saying this all along� but the vast majority of the
>> thought, effort, dollars, and time that has gone into Agile has
>> resulted in a prescriptive methodology for software development that
>> starts with requirements and ends with "code complete". I'm sure the
>> purists will cringe at this and the manifesto will roll over in it's
>> grave� but that is where that movement has gone. It's become a local
>> optimization that doesn't address the "global" concern of the
>> development to operations delivery cycle (i.e. what the business
>> actually cares about and pays for)
>>
>> Now on to DevOps� Are we not doomed to repeat the same mistake if we
>> don't take the all inclusive holistic approach? The whole point of
>> having a "dev" and an "ops" is to take business ideas and manifest
>> them as running features for customers. What's the point of the
>> "focus on the relationship between dev and ops at the product level"
>> if it doesn't optimize the whole system to achieve it's purpose? In
>> order to optimize that relationship for that purpose you have to
>> include all the pieces that must come together to make that happen.
>> That doesn't mean that everyone has to be a generalist in everything
>> (your example of conflating security and availability), but it does
>> mean that everyone has to understand the system they are a part of
>> and how to work together to fulfill the purpose of the system.
>>
>> When the original DevOps conversation started, it was taking a broad
>> system-wide view. The two seminal events both talked about Dev and
>> Ops as if they were the entire technology house split into two sides.
>> Paul Hammond (Dev) and John Allspaw (Ops) represented the entire
>> Flickr technology team (at least figuratively if not literally). The
>> first DevOps Days in Ghent was framed as bringing together the two
>> self-identifications that rarely gather at the same conference, Dev
>> and Ops.
>>
>> Post DevOps Days Ghent the conversation definitely became deployment
>> centric. Why? Because deployment is the canary in the coal mine for a
>> broken development to operations lifecycle. It's the flash point
>> where the pain is felt, but the root cause of that pain comes from
>> somewhere else.
>>
>> Now that I'm 5 paragraphs into a rant� :)

Gildas

unread,
May 23, 2012, 8:35:05 AM5/23/12
to dev...@googlegroups.com
On Wed, May 23, 2012 at 2:09 PM, Ernest Mueller
<ernest....@gmail.com> wrote:
> Going and looking at the first diagram in Patrick's article - no, optimizing
> the relationship between HR and Sales is not "DevOps."  That's ridiculous.
>  It's overreaching IMO just like my security example. DevOps isn't just chef
> and puppet, or just about deployment, but I think its focus is realistically
> on the part where ops is actually embedding into the rest of the
> organization instead of being a segmented sideshow and optimizing the
> process of actually delivering services.  Yes, dev and ops represent the
> "two sides of the technology house" - and I think Ops can properly be
> understood to rep Net and Sec and all that as we move forward - but the
> scope is not "everything in an organization all the way to HR and Finance."
>  Ops is waking up and smelling the coffee here, not inventing coffee.  The
> expansion dilutes the usefulness of the focus.  DevOps isn't lean/agile/OM
> but better. It's an application of those principles to a product team
> creating and delivering software.
>
> The next DevOps Areas part I think is great.  It's the initial "well DevOps
> is everything!" thing that sounds like consulting gig scope creep to me.
>
> Ernest

I'm not sure devops is only about product teams and
creating/delivering software. I think it applies to everything
IT-related in a company.

And yes, that means it can be relevant for stuff that concerns HR, as
long as there is IT involved (or even sometimes just processes). And
the truth is that IT is everywhere in a company nowadays.

Gildas

Ernest Mueller

unread,
May 23, 2012, 8:49:51 AM5/23/12
to dev...@googlegroups.com
Sure, I just think that's agile/lean, not "big
DevOps." I think it's more of a service to folks
to show how they are plugging into something
larger as opposed to just extending their sub-thing.

Ernest
>>>been saying this all along… but the vast
>>>majority of the thought, effort, dollars, and
>>>time that has gone into Agile has resulted in
>>>a prescriptive methodology for software
>>>development that starts with requirements and
>>>ends with "code complete". I'm sure the
>>>purists will cringe at this and the manifesto
>>>will roll over in it's grave… but that is
>>>where that movement has gone. It's become a
>>>local optimization that doesn't address the
>>>"global" concern of the development to
>>>operations delivery cycle (i.e. what the
>>>business actually cares about and pays for)
>>>
>>>Now on to DevOps… Are we not doomed to repeat
>>>Now that I'm 5 paragraphs into a rant… :)

Spike Morelli

unread,
May 23, 2012, 8:58:27 AM5/23/12
to dev...@googlegroups.com
I admit to be ignorant when it comes to agile so I'm asking this list: how does agile position itself compared to devops? in my ignorance and exposure as a sysadmin or even a manager, agile has always been a dev thing. I know it's not, but that's been my experience on the ground. year after year. company after company. But if agile is finally coming around and there's more to it like Ernest mentioned (just recently I discovered the Agile Management book, been meaning to read that since then), how does that intersect with devops?

And maybe I'm pushing the meaning of devops, but, like many ppl on this list, I didn't need that term to tell me that config management was good. However I did need that term to remind me that collaboration was good. Agile did not do that for me, devops did. Like Ranjib said, tools are useful and so is terminology, a couple FOSDEMs ago I argued that the shift of operations toward dev tools and practices represented a step toward a common story that would in turn help with the dialogue. What I really got out of devops however is the 'break down the silos' message. It was the thing that opened the doors to Lean, of which I'd also like to better understand the role of in this discussion.

Break down the silos, communicate better, be transparent, eliminate waste, deliver value. That's what I care about. And it can be done everywhere. In HR, in finance, in prod dev. Is that devops? probably not. Is that Agile? not sure. Is that lean? in part. Do we need even something for that? possibly not. am I going mad? possibly yes :)

I've been a big proponent of devops in HR because devops starts with the people you hire since it's a cultural movement. It's also true that hiring is a big silo, we ask recruiter to get someone and when they do they 'toss him/her over'. That's a silo right there. Would you say that it's not pertinent because it's not strictly about technology? Why would you draw the line around ops/devs? what if we renamed it?

About codifying stuff, as much as I've never been a fan of hard rules, I think guidelines are a lifeline so I will never oppose anybody trying to go that direction and I think nobody should. If you want to be of service, try to help them avoid the pitfalls you see and guide them toward what you think is best.

On 23 May 2012, at 14:23, Patrick Debois wrote:

Hi Ernest,

obviously! not that all improvements are 'devops' issues. That would be stretching it too far indeed.

The reasoning was more that when we try to optimize your 'dev & ops' problem,
the bottleneck for improving it may well be outside dev & ops.
So you have to have a broad view, otherwise you're still trying to solve some problems with a narrow view.

While reasoning on the stories for the book , it made me think about the things happening in other parts of the company that have an influence on the dev and ops tension.

- hiring/HR policy can have it's effect on the devops tension , what kind of persons fit well in this problem
- financial incentive of each groups can have have an impact on the problem

I've seen the same thing happen with agile teams trying to solve 'devops problems' within the dev team only.

Makes sense?

On 23/05/12 14:09, Ernest Mueller wrote:
Well, but Agile hasn't dropped the ball - it's just that it's just now getting around to us. When you look at the actual big picture there's a lot to it. The Agile Austin group, for example, has SIGs on agile dev, agile QA, agile architecture, agile product development, agile UX, agile leadership... And now DevOps. Just because now we're down with the concepts that are new and shiny to us doesn't mean we now know how to fix all the other parts of an organization.

Going and looking at the first diagram in Patrick's article - no, optimizing the relationship between HR and Sales is not "DevOps." That's ridiculous. It's overreaching IMO just like my security example. DevOps isn't just chef and puppet, or just about deployment, but I think its focus is realistically on the part where ops is actually embedding into the rest of the organization instead of being a segmented sideshow and optimizing the process of actually delivering services. Yes, dev and ops represent the "two sides of the technology house" - and I think Ops can properly be understood to rep Net and Sec and all that as we move forward - but the scope is not "everything in an organization all the way to HR and Finance." Ops is waking up and smelling the coffee here, not inventing coffee. The expansion dilutes the usefulness of the focus. DevOps isn't lean/agile/OM but better. It's an application of those principles to a product team creating and delivering software.

The next DevOps Areas part I think is great. It's the initial "well DevOps is everything!" thing that sounds like consulting gig scope creep to me.

Ernest


At 10:27 PM 5/22/2012, damone...@gmail.com wrote:
I see your point about being careful of DevOps being heralded as a panacea for all ills. But DevOps isolated to just the point of contact between Dev and Ops isn't the answer either.

You could say the macro perspective is "Lean" in it's purest form, but DevOps has as much claim to it in the technology realm as Agile does. The only proof I need that "big picture" isn't properly represented by Agile is that the Agile movement has been around for a long time (in "tech years") yet completely missed the big picture that you needed the align and optimize the entire development to operations delivery cycle to properly implement Lean in a software as a service world. Sure you can reference a handful of sharp folks who have been saying this all along… but the vast majority of the thought, effort, dollars, and time that has gone into Agile has resulted in a prescriptive methodology for software development that starts with requirements and ends with "code complete". I'm sure the purists will cringe at this and the manifesto will roll over in it's grave… but that is where that movement has gone. It's become a local optimization that doesn't address the "global" concern of the development to operations delivery cycle (i.e. what the business actually cares about and pays for)

Now on to DevOps… Are we not doomed to repeat the same mistake if we don't take the all inclusive holistic approach? The whole point of having a "dev" and an "ops" is to take business ideas and manifest them as running features for customers. What's the point of the "focus on the relationship between dev and ops at the product level" if it doesn't optimize the whole system to achieve it's purpose? In order to optimize that relationship for that purpose you have to include all the pieces that must come together to make that happen. That doesn't mean that everyone has to be a generalist in everything (your example of conflating security and availability), but it does mean that everyone has to understand the system they are a part of and how to work together to fulfill the purpose of the system.

When the original DevOps conversation started, it was taking a broad system-wide view. The two seminal events both talked about Dev and Ops as if they were the entire technology house split into two sides. Paul Hammond (Dev) and John Allspaw (Ops) represented the entire Flickr technology team (at least figuratively if not literally). The first DevOps Days in Ghent was framed as bringing together the two self-identifications that rarely gather at the same conference, Dev and Ops.

Post DevOps Days Ghent the conversation definitely became deployment centric. Why? Because deployment is the canary in the coal mine for a broken development to operations lifecycle. It's the flash point where the pain is felt, but the root cause of that pain comes from somewhere else.

Now that I'm 5 paragraphs into a rant… :)

Christopher Little

unread,
May 23, 2012, 9:17:02 AM5/23/12
to dev...@googlegroups.com

I've always thought DevOps extends into the business more broadly (than narrowly Dev+Ops) because neither Dev nor Ops are the app owner or the customer.

 

Dev may build the features and functionality of the app, and fundamentally manages the cadence of those changes delivered to Ops for controlled exposure to the world, but inside the business there’s an app owner who studies the customer and fundamentally drives the app’s existence from infancy to grave. And that’s where I think DevOps discussion expands well into the organization via that loop from App Owner / customer back around into Dev and Ops.

Eric Shamow

unread,
May 23, 2012, 10:20:13 AM5/23/12
to dev...@googlegroups.com
On Wednesday, May 23, 2012 at 8:09 AM, Ernest Mueller wrote:
The next DevOps Areas part I think is
great. It's the initial "well DevOps is
everything!" thing that sounds like consulting gig scope creep to me.

I'd very much disagree on this.  Pushes for agile culture come from all different areas of the business - to assume they must be driven from the top, or from a customer or finance-centered unit is eliminating an entire vector by which this culture can make inroads.

I've personally been involved in multiple engagements at customer sites in which I was brought in purely to work with the Dev and Ops team, but found myself invited to meetings with senior execs who now wanted to replicate what we'd done across the organization.  Even more commonly, I've been at these meetings and heard from other team leads "ahh!  That's what we're doing with our agile project across the business units" - and now suddenly it's not people throwing buzzwords and forms at each other, but actually communicating.

DevOps isn't the solution to all business process problems as a whole, but just as there is a stub for dealing with technology resources in other business initiatives, DevOps very much should include some course-grained strategies for dealing with non-IT units.  It's up to the implementer to decide how/if to implement these or integrate them with other solutions.

YvesHanoulle

unread,
May 23, 2012, 10:31:32 AM5/23/12
to dev...@googlegroups.com
I'm one of these people doing agile for a long time and interested in DevOps thanks to the personal evangelisation of Patrick. 

2012/5/23 Spike Morelli <f...@spikelab.org>
I admit to be ignorant when it comes to agile so I'm asking this list: how does agile position itself compared to devops? in my ignorance and exposure as a sysadmin or even a manager, agile has always been a dev thing. I know it's not, but that's been my experience on the ground. year after year. company after company. But if agile is finally coming around and there's more to it like Ernest mentioned (just recently I discovered the Agile Management book, been meaning to read that since then), how does that intersect with devops?

And maybe I'm pushing the meaning of devops, but, like many ppl on this list, I didn't need that term to tell me that config management was good. However I did need that term to remind me that collaboration was good. Agile did not do that for me, devops did.
for that, I think the best way is  too look at the agile manifesto.

>We are uncovering better ways of developing software by doing it and helping others do it. 
>Through this work we have come to value:

>Individuals and interactions over processes and tools
>Working software over comprehensive documentation
>Customer collaboration over contract negotiation
>Responding to change over following a plan

>That is, while there is value in the items on the right, we value the items on the left more.

For me, nothing in this says that it's just about development team.

yes, it's true that in the beginning ops were ignored by agile.
I see 2 reasons for that
A) the people who created the manifesto, were developers
B) a lot was happening in smaller companies, and hus they did all the deployment themselves.

I'm sure you can all find lots of other reasons.
for me they don't matter

DevOps, just as agile is about the mostly mindset, just as lean is and BeyondBudgetting
(I think this discussion proves it)

Like Ranjib said, tools are useful and so is terminology, a couple FOSDEMs ago I argued that the shift of operations toward dev tools and practices represented a step toward a common story that would in turn help with the dialogue. What I really got out of devops however is the 'break down the silos' message. It was the thing that opened the doors to Lean, of which I'd also like to better understand the role of in this discussion.

Break down the silos, communicate better, be transparent, eliminate waste, deliver value. That's what I care about. And it can be done everywhere. In HR, in finance, in prod dev. Is that devops? probably not. Is that Agile? not sure. Is that lean? in part. Do we need even something for that? possibly not.

yes, let's now not create silo's between agile, DevOps, lean etc...
 
am I going mad? possibly yes :)
nothing wrong with being mad. It's the world that can't deal with people behaving different then the main stream
;-)
 
yves

Matthias Marschall (@mmarschall)

unread,
May 24, 2012, 3:23:21 AM5/24/12
to devops
> The reasoning was more that when we try to optimize your 'dev & ops'
> problem,
> the bottleneck for improving it may well be outside dev & ops.
> So you have to have a broad view, otherwise you're still trying to solve
> some problems with a narrow view.
That's absolutely true. If you're stuck with a narrow view, you'll sub-
optimize your area of responsibility. This will not help the end-to-
end process bringing business ideas into customers hands. It's really
important that everyone cares for the whole process and tries to
influence other contributors to achieve overall success.

That's were a lot of agile approaches fall short: They're often stuck
in optimizing development only. They define an interface e.g. to the
product owners (user stories and a backlog) but do not really tell
them how they find the right ideas, validate them, etc. This is were
Lean Startup or, even more concrete, Running Lean comes into the
picture. And they often use a Definition of Done, which does not
include releasing features.

For me, lean ideas are the basis for optimizing the overall flow. On
top of lean ideas we find Lean Startup/Running Lean for finding and
validating product ideas, Agile for optimizing product development
(and collaboration between product owners and devs), and devops for
optimizing rollout and operations (and collaboration between dev and
ops, obviously). I guess I need to draw a pic to make that
clear ... ;-)


|--- Lean Startup ---|
|---- Agile ---|
|----- Devops ----|
|----------------- Lean --------------------------------|
(please excuse my poor application of ASCII art)

Matthias

Matthias Marschall (@mmarschall)

unread,
May 25, 2012, 3:38:03 AM5/25/12
to devops
I tried to beautify the picture showing my how I think Lean, Agile,
and Devops relate to each other:

https://cacoo.com/diagrams/uapwdcN6SDfwClDY

Do you think this is helpful?

Matthias

On May 24, 9:23 am, "Matthias Marschall (@mmarschall)"

damone...@gmail.com

unread,
May 25, 2012, 5:17:36 AM5/25/12
to dev...@googlegroups.com
Hi Matthias,

I think it is, but I see DevOps as being more "glue" that holds the top row together (and all parts being inspired/informed by Lean).

I drew it this way awhile back (and threw in the relationship to ITIL for good measure):

It was part of this post:

The encouraging thing to me is that all of this boils down to vocabulary and taxonomy differences.... not differences in intent or actions. So while vocabulary and taxonomy are critical, it's not like we are arguing for different outcomes!


-Damon

Matthias Marschall

unread,
May 25, 2012, 10:40:49 AM5/25/12
to dev...@googlegroups.com
Hi Damon,

I really like your post (and it actually was the one I based my ideas on without being able to recall the source). Especially I like this picture:

http://dev2ops.org/storage/ahha_kaching_plusdevops.gif

One question, though: Do you include finding and validating ideas and all typical product management/product owner work in the "Dev" box? (I separated it because I think typical agile processes do not really help you there but Lean Startup and Running Lean do...)

And I've another question (there might be an obvious answer, which is elusive to me right now):

I like the idea that devops is the glue between all the practices (which are based on lean principles), but I lack to see concrete examples e.g. what devops practice helps in the early stages of ideas finding and validation or to bridge the gap between finding ideas and developing them?

And one more question: Is devops a set of practices (based on lean principles) or is it a mixture of practices and principles? (Again, something which might have been discussed a thousand times - but it's elusive for me right now...)

BTW, I'm not totally happy with my diagram yet. I already see some issues:
- Lean Startup includes Development & Deployment, so it might better be seen as a specific variant of lean principles instead of a set of practices. So I guess it's clearer to only put "Product/Market fit" part of "Running Lean" into the first box
- Devops is, as you say, more than deployment and operations, so the yellow arrow should maybe read Ops only. But would devops really span _all_ the arrows in the practices line (see my question above)? Or does it span only Dev & Ops boxes...? You're saying: no. And I hope for concrete examples ;-)

I updated my diagram (putting devops only around dev+ops right now - but I'm more than happy to change this if you convince me to do so!)

https://cacoo.com/diagrams/uapwdcN6SDfwClDY


I'm very glad that we seem to have the same intent. I'm curious to see whether we can add value by providing a clearer picture how everything fits together... for me, it's still work in progress to fill in all the details...

- Matthias

Patrick Debois

unread,
May 25, 2012, 10:55:28 AM5/25/12
to dev...@googlegroups.com
Hi Matthias,

I like the way you improved the drawing:
- I don't think devops has re�nvented any specific principles just
translated a lot of practices.
- This might be cosmetic but the way you put the bar of devops on the
top thicker, makes it stress the deployment section more (area1,area3)
in my diagram
- I think devops can really bring the return channel back to the product
owners so I'd balance the 'belly of the drawing devops color too'
- concerning your question can devops help in validate the
prototype/ideas? If we can expose the metrics and monitoring better to
the initial ideas, I think that is a valid way. Ops is used to thinking
in metrics, etc... almost like learning in prod.

Patrick

On 25/05/12 16:40, Matthias Marschall wrote:
> Hi Damon,
>
> I really like your post (and it actually was the one I based my ideas on without being able to recall the source). Especially I like this picture:
>
> http://dev2ops.org/storage/ahha_kaching_plusdevops.gif
>
> One question, though: Do you include finding and validating ideas and all typical product management/product owner work in the "Dev" box? (I separated it because I think typical agile processes do not really help you there but Lean Startup and Running Lean do...)
>
> And I've another question (there might be an obvious answer, which is elusive to me right now):
>
> I like the idea that devops is the glue between all the practices (which are based on lean principles), but I lack to see concrete examples e.g. what devops practice helps in the early stages of ideas finding and validation or to bridge the gap between finding ideas and developing them?
>
> And one more question: Is devops a set of practices (based on lean principles) or is it a mixture of practices and principles? (Again, something which might have been discussed a thousand times - but it's elusive for me right now...)
>
> BTW, I'm not totally happy with my diagram yet. I already see some issues:
> - Lean Startup includes Development& Deployment, so it might better be seen as a specific variant of lean principles instead of a set of practices. So I guess it's clearer to only put "Product/Market fit" part of "Running Lean" into the first box
> - Devops is, as you say, more than deployment and operations, so the yellow arrow should maybe read Ops only. But would devops really span _all_ the arrows in the practices line (see my question above)? Or does it span only Dev& Ops boxes...? You're saying: no. And I hope for concrete examples ;-)
>
> I updated my diagram (putting devops only around dev+ops right now - but I'm more than happy to change this if you convince me to do so!)
>
> https://cacoo.com/diagrams/uapwdcN6SDfwClDY
>
>
> I'm very glad that we seem to have the same intent. I'm curious to see whether we can add value by providing a clearer picture how everything fits together... for me, it's still work in progress to fill in all the details...
>
> - Matthias
>
>
> Am 25.05.2012 um 11:17 schrieb damone...@gmail.com:
>
>> Hi Matthias,
>>
>> I think it is, but I see DevOps as being more "glue" that holds the top row together (and all parts being inspired/informed by Lean).
>>
>> I drew it this way awhile back (and threw in the relationship to ITIL for good measure):
>> http://dev2ops.org/storage/Agile_DevOps_ITIL.gif
>>
>> It was part of this post:
>> http://dev2ops.org/blog/2010/11/7/devops-is-not-a-technology-problem-devops-is-a-business-prob.html
>>
>> The encouraging thing to me is that all of this boils down to vocabulary and taxonomy differences.... not differences in intent or actions. So while vocabulary and taxonomy are critical, it's not like we are arguing for different outcomes!
>>
>>
>> -Damon
>>
>>
>>
>>
>> On May 25, 2012, at 12:38 AM, Matthias Marschall (@mmarschall) wrote:
>>
>>> I tried to beautify the picture showing my how I think Lean, Agile,
>>> and Devops relate to each other:
>>>
>>> https://cacoo.com/diagrams/uapwdcN6SDfwClDY
>>>
>>> Do you think this is helpful?
>>>
>>> Matthias
>>>
>>> On May 24, 9:23 am, "Matthias Marschall (@mmarschall)"
>>> <matthias.marsch...@gmail.com> wrote:
>>>>> The reasoning was more that when we try to optimize your 'dev& ops'
>>>>> problem,
>>>>> the bottleneck for improving it may well be outside dev& ops.

Matthias Marschall

unread,
May 25, 2012, 11:07:43 AM5/25/12
to dev...@googlegroups.com
Am 25.05.2012 um 16:55 schrieb Patrick Debois:
> - I don't think devops has reïnvented any specific principles just translated a lot of practices.
yep, that's what I think, too

> - This might be cosmetic but the way you put the bar of devops on the top thicker, makes it stress the deployment section more (area1,area3) in my diagram
ok, that was not my intention... will fix it :-)

> - I think devops can really bring the return channel back to the product owners so I'd balance the 'belly of the drawing devops color too'
> - concerning your question can devops help in validate the prototype/ideas? If we can expose the metrics and monitoring better to the initial ideas, I think that is a valid way. Ops is used to thinking in metrics, etc... almost like learning in prod.
That's a very good point. Metrics and monitoring are a key ingredient for validating product ideas. That's indeed a good example on how devops can expand way into idea finding...

Here's version 0.3: https://cacoo.com/diagrams/uapwdcN6SDfwClDY

(I couldn't make myself wrap the whole "idea finding" box into devops... still feels a little weird. But I expanded devops way more into the first arrow due to the metrics gathering stuff...)

- Matthias

Jaime Gago

unread,
May 25, 2012, 12:00:38 PM5/25/12
to dev...@googlegroups.com
Matthias,
I think your diagram is very simple and easy to assimilate and quite accurate, there is one thing that IMHO is missing is the idea of "looping" represented by the circularity in Damon Edward's diagram.

It seems important to have a graphical representation of the "back and forth" happening between teams and processes, doesn't it?

J.

On May 25, 2012, at 12:38 AM, Matthias Marschall (@mmarschall) wrote:

Spike Morelli

unread,
May 25, 2012, 12:02:27 PM5/25/12
to dev...@googlegroups.com
So I like this diagram very much, thanks for drawing it Matthias, but I'm left with a question: if the principles are derived from Lean and devops is a 'practice', where does the 'cultural movement' fit? I don't wanna sound like I'm trying to put things in tiny boxes and sort them and stack them… but some clarity around what's a practice and what's culture and how the two interact might be good.

Going back to version.1 of that graph you had devops 'overflow' into the Lean box in the principles band and that to me represented that cultural part. But then so should the Agile box, in theory Agile was a set of principles and values before it was a methodology. Once you're there tho, you could be tempted to argue something similar about Lean startup at which point it seems safe to say that actually, that's the thing, those practices are built atop certain principles and therefore include them at their foundation.

If that's true then it follows that the cultural aspect of devops is no longer in devops itself, but rather in the Lean foundation and we can look at silos as a form of waste to be removed. That would also work well with silo breakdown in recruiting etc as Lean spans the entire spectrum. At the same time, following from the previous paragraph, looking at anything without the value/cultural foundation of Lean would be pointless and as such Devops is both practices and culture with culture taking precedence as that represents the foundations.

thoughts?

Spike

Kit Plummer

unread,
May 25, 2012, 12:09:17 PM5/25/12
to dev...@googlegroups.com
This is good stuff.  I'd really love to see an identification of the role/organization called "test" or QA.  If DevOps is indeed inclusive - then QA must be also regardless of the methodology, right?  I'm not necessarily advocating that QA be it's own box, but in principle and practice its a part of all "value" derived from any idea.  If nothing else quality should dictate the the loopback that then drives continuous improvement, or continuous evolution of the original idea.

Kit

Sebastian Otaegui

unread,
May 25, 2012, 12:12:25 PM5/25/12
to dev...@googlegroups.com
Hello all, 

I never post anything to this list but I am always reading and just wanted to point out that the change of tone of the discussion is very constructive.

kudos to you all.

Matthias Marschall

unread,
Jun 1, 2012, 12:27:31 PM6/1/12
to dev...@googlegroups.com
Thanks a lot for your thoughts. I agree with you: All practices have the lean principles at their core. The culture is founded in Lean. I tried to improve the diagram:

version 0.4: https://cacoo.com/diagrams/uapwdcN6SDfwClDY

Does it make it more clear (or less)?

Matthias

Spike Morelli

unread,
Jun 7, 2012, 3:47:39 PM6/7/12
to dev...@googlegroups.com


On 1 Jun 2012, at 09:27, Matthias Marschall wrote:

> Thanks a lot for your thoughts.

Thanks to you for getting us going with that first graph and continuing to improve it.

> I agree with you: All practices have the lean principles at their core. The culture is founded in Lean. I tried to improve the diagram:
>
> version 0.4: https://cacoo.com/diagrams/uapwdcN6SDfwClDY
>
> Does it make it more clear (or less)?

more, but it feels somewhat awkward/uneasy that operations is the only block not overflowing onto the Lean principles. Could it be that operations is 'Lean IT' and overflowing on Lean? I mean, otherwise you could argue that development is certainly not all Agile and actually for a large chunk it could sit in its own non-overlapping box.

But other than that I think you're onto something and from my personal experience with the ops group I work with the tone of the conversation has substantially moved toward Lean as set of principles and devops as an integration force all the way up to business (just yesterday we were asking to integrated graphite with warehousing and create a dashboard for our product owners).

hope that helps,

Ernest Mueller

unread,
Jun 7, 2012, 9:55:27 PM6/7/12
to dev...@googlegroups.com
At 11:27 AM 6/1/2012, Matthias Marschall wrote:
>Thanks a lot for your thoughts. I agree with you: All practices have
>the lean principles at their core. The culture is founded in Lean. I
>tried to improve the diagram:
>
> version 0.4: https://cacoo.com/diagrams/uapwdcN6SDfwClDY

I like it. I used it at a presentation today
even!
(https://www.isc2.org/EventDetails.aspx?id=8346&display=seminaragenda&origin=)

My main note is that it would be more visible in presentations if it
was not quite as long, it makes it thin and small-fonted...

But as for content, my main critique is that though it's accurate
enough, it doesn't really convey the nature of the relationship -
it's a box agile dev and operations are sitting in but it's not quite
showing how it commingles them.

Ernest

Jack Worthy

unread,
Dec 13, 2019, 5:32:20 PM12/13/19
to devops
I agree that 'codifying' DevOps might be a bit like chasing windmills... but I like the dialog, even though lately I've been a fool with a tool :

in the spirit of sharing, here's some books and guidance I've liked, many you may already be very familiar with, along with a link to a Lucid diagram where I've been capturing my thoughts (remember I'm a fool with a tool :) https://www.lucidchart.com/invitations/accept/61ad19a2-cbc6-442f-9476-43a23fbd9557 

VeriSM https://verism.global/

 

BeingFirst https://beingfirst.com/

 

Taming Change https://www.tamingchange.com/

 

Team Topologies https://teamtopologies.com/

 

Customer Expectation Management Method http://tschurter.com/wp-content/uploads/2018/10/Customer-Expectation-Management-Revised-e1538575324591.png

 

APQC PCF  https://www.apqc.org/resource-library/resource-listing/apqc-process-classification-framework-pcf-cross-industry-excel-7

 

Nicols WP https://www.nickols.us/difficult.pdf

 

Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation https://www.amazon.com/Value-Stream-Mapping-Organizational-Transformation/dp/0071828915/ref=sr_1_3?gclid=CjwKCAiAis3vBRBdEiwAHXB29G0behX5zj11Xl0xCxQvg8wAFZ3QigWAtjP14HEfyGcB72VM03jvqhoCNGIQAvD_BwE&hvadid=323590030477&hvdev=c&hvlocphy=9003712&hvnetw=g&hvpos=1t1&hvqmt=b&hvrand=12095849842679789977&hvtargid=aud-840076997981%3Akwd-746770535&hydadcr=24407_11048948&keywords=value+stream+mapping+book&qid=1576271981&sr=8-3

 

ISO/IEC 33020:2019 Information technology — Process assessment — Process measurement framework for assessment of process capability https://www.iso.org/standard/78526.html

 

THE OPEN GROUP IT4IT™ REFERENCE ARCHITECTURE, VERSION 2.1 https://publications.opengroup.org/standards/it4it/c171

 

Fugle Innovation Model https://www.researchgate.net/figure/The-Fugle-innovation-model_fig1_290440787

 

eG Innovations https://www.eginnovations.com/it-monitoring/whats-new


On Sunday, May 20, 2012 at 7:16:40 PM UTC-4, Guillaume FORTAINE wrote:
Hello,

For your information :

http://java.dzone.com/articles/codifying-devops

Best Regards,

Guillaume FORTAINE

Jack Worthy

unread,
Dec 13, 2019, 5:32:22 PM12/13/19