It’s rare that I have a free-standing excerpt that doesn’t need any help or elaboration. Jason’s crisp that way. I love the analogy.
Jason Bloomberg: Yeah, when I brought up the tin woodman analogy, that was – I don’t know, several years ago, 2006, 2007, somewhere in there – I was really talking about the software vendors who are struggling to bring a SOA story to their customers, because the vendors can’t sell architecture. Architecture is a set of best practices. It’s something you do; it’s not something you buy.
So all these vendors wanted to sell SOA, because SOA was the hot topic back in those days, but they couldn’t, because it was something you do. So what did they sell? Well, they sold Web services support and they sold middleware and they sold this and they sold that, but none of those were architecture.
So it’s the same as the story of the Wizard of Oz. You have these four people. They go to the wizard. And each one of them thinks they want something, but it’s not really what they want at all. The tin woodman thinks he wants a heart, but in reality, of course, he was the – the most loving of the four.
So each of the four, if you think about it, didn’t need what they thought they wanted. Dorothy was always at home. She was dreaming. She never left home. The lion was the most courageous of the four. He just didn’t realize it. Tin woodman was the most loving, and the scarecrow was the smartest.
And so – but they were all missing, the heart or the whatever. And so the tin woodman, what did he get from the wizard? Well, he got a clock, and it ticked like a heart, and that was good enough for him, because he really had all along what he was looking for.
And so the moral is that you can’t get best practices from a piece of technology. That’s something you have to bring to the technology. It’s something that people have to have, because it’s something you do with technology. And this is an important part of the DevOps story. The reason that we’re talking about DevOps today is because our technology has matured to the point that we can automate much of our operational environment.
So we don’t need to have people provisioning servers manually anymore. We don’t have to have people setting up networks manual anymore and reconfiguring – we don’t have to – we don’t have to have that. We can automate that, so now we can move those ops people and put them in a different role in working with the developers and focusing on the life cycle.
[…] The technology is the enabler, but if you don’t understand the organizational and architectural best practices, you’re not going to get it. You’re not going to get the value out of DevOps. And I actually wrote a blog post on this […] called the DevOps paradox, where all these organizations want to do DevOps, and what they’re doing is they’re setting up separate DevOps teams who are now separate from dev and ops.
And it sort of defeats the whole purpose, because the idea of DevOps is to sort of cut across the teams, to be less siloed, rather than more siloed. So setting up a DevOps silo defeats the whole purpose of DevOps. And people are scratching their head and saying, “well, why am I not getting the value that I read about in all these great podcasts about DevOps, saying all this wonderful stuff, and I’m not getting this value?”
Because they’re missing the organizational, the human side of the story. And that becomes the most important part.
The technology is an enabler. We couldn’t do DevOps if we didn’t have automated operations, but automated operations alone doesn’t give us any organizational benefits, unless we get the architecture right.