When I was revising my book Architecture and Patterns for IT, I started to delve into the then-emerging topic of DevOps. One of the models I put forward in my investigations was a naive "Change vs. Stability" diagram, something along the lines of this:
Moving on with the 2nd in my series of Enterprise Devops posts.
As I write this, I am listening to this excellent presentation of John Allspaw and Paul Hammond of Flickr, which goes into great detail around the core DevOps problem of writing code and applying continuous integration principles.
However, my intent in this blog has more to do with the problem of "infrastructure as code." As I noted previously, DevOps practices in the enterprise case would need to accomodate a wide variety of tools and middleware beyond Java, RoR, and the LAMP stack.
I have promises to keep. I've told numerous interested folks over the past few months that I would "soon" have some material out on Enterprise DevOps. So, here is the first in a series of posts on the topic.
To start: Semantics matter. What would we mean by Enterprise DevOps? And in particular,
how is "Enterprise DevOps" a value-adding, distinct category within the broader world of DevOps?
While the first (2006) edition of my book featured an IT value chain, I realized that I needed to think more deeply about IT value in the second edition. One new set of influences was Lean thinking applied to IT management. I'd read The Goal, other Goldratt books, and much Lean material. In particular, I was thinking about the following classic passage from The Goal, in which the protagonist (Alex Rogo) is asked:
...tell me, what is the goal of your manufacturing organization?" he [Jonah] asks.
"The goal is to produce products as efficiently as we can," I tell him.
"Wrong," says Jonah. "That's not it. What is the real goal?"
One of the first topics covered in all the systems dynamics discussions I've seen is the correct use of the word "feedback." As Sterman states:
In common parlance the term "feedback" has come to serve as a euphemism for criticizing others, as in "the boss gave me feedback on my presentation." This use of feedback is not what we mean in system dynamics. Further, "positive feedback" does not mean "praise" and "negative feedback" does not mean "criticism." Positive feedback denotes a self-reinforcing process, and negative feedback denotes a self-correcting one. Either type of loop can be good or bad, depending on which way it is operating and of course on your values. Reserve the terms positive and negative feedback for self-reinforcing and self-correcting processes, and avoid describing the criticism you give or receive to others as feedback. Telling someone your opinion does not constitute feedback unless they act on your suggestions and thus lead you to revise your view.
Tonight I tweeted the following:
Businesses seek to stimulate positive feedback loops. Engineers try mightily to avoid them. Essence of the IT/business divide?
I've been telling everybody and their sister that the Kindle version of my 2nd edition was only $9.99.
Boy, was I wrong. That's the price only for the 1st edition. (Why, oh why, do I so often believe things too good to be true?) The price for the 2nd edition Kindle was not released until today, and it is a much steeper $42.67.
Not only that, it's really confusing to get the Kindle 2nd edition. If you first go to Amazon you get this (click for larger):
Disregard the $9.99. That's the first edition. You don't want that (unless you're a scholar interested in what I changed between editions). Trust me, the 2nd edition is better.
Notice the tiny little "+" icon I've circled on the screenshot above. Click that:
(click for larger)
There's the real 2nd edition Kindle, with the price circled. Sorry for the price misinformation. Really not sure why they are burying it that way.
On another topic, if you do the "Click to LOOK INSIDE" you'll get this surprising result:
(click for larger)
Bet you didn't know I was also an expert in the oil and gas industry! And only that cover is wrong, if you scroll down you'll see my book.
We're trying to get this straightened out, needless to say. But the interactions between my publisher and Amazon are a bit opaque to me.
Anyways, what matters is you can get the book. Please let me know how you like it.