What Kind of DevOps are you?
First, let me state that I abhor buzz words. They are fat candy for little minds. That said, the buzz word "DevOps" does address a real and particularly endemic issue in IT which is development staff are from Mars and IT operations personnel are from Venus. This is nothing that ten trillion web pages haven't said already and that the industry doesn't widely acknowledge.
What is interesting is how different shops have hurled themselves into the arena trying to solve (or not) this issue.
How do you spell DevOps?
Get into a room with your IT teams and bring up the topic of DevOps and you will see two distinct patterns.
The first is characterized by a shop that is intensely focused on Continuous Integration (CI) and Continuous Delivery (CD) as the answer to all their DevOps challenges. The ANSWER to the ills described in Pheonix Project is to automate build and deployment thereby eliminating the need for operations staff. Management loves it because they can trim the pesky Ops guys who do nothing but keep the lights on and with their new cloud strategy, who cares about that. It's all about getting code to production.
I call this a Big D, Little O (Devops) shop.
The counter spin of this exhibits in shops where the Operations team have taken up the DevOps banner. Their ardor is stability, consistency, and reliability and it is only interrupted when those %@#$$%@ developers try to shove their untested, crap code into the nasty bits of our servers. They still hold to ITIL like a twenty something holds on to his Pokemon, that is to say it eclipses everything including the big truck that is about to run them over. For these shops, DevOps is generally about automating the provisioning of infrastructure. A good DevOps shop can stand up environments in the blink of an eye simply by pushing the EeeeZ button, spinning around three times and yelling "Hypervisor Engage" in their best Patrick Stewart accent.
I call this a Little D, big O (devOps) shop.
But Corby, aren't CI/CD and automated provisioning the definition of awesomeness? The Internet says so...
Of course they are, but so are reality TV shows about naked people doing weird crap in the jungle. That doesn't mean we should all take our clothes off and live off bug fat for three weeks.
The fundamental issue surfaced by DevOps is one of organizational culture and how that culture defines the interactions of of its constituent parts (or not).
By making DevOps about solving the little problems that make YOUR life better, You've missed the entire point. Worse, you have masked the real issue with HYPERNOISE (the effluent that comes out of the ass of big product companies when they leach their technology (relvancy be damned) onto a buzz word).
DevOps solutions that are isolated to development OR operations are at best exercises in mental masturbation and at worst, exacerbating a potentially lethal condition (Hi there boys and girls, can you say outsourcing? OUTSOURCING).
It is not about tools, or process. It is about people working together towards the common goal of getting stuff done.
Thanks Corby… I've always felt perspective is what matters when it comes to this topic… For those who have to execute the miracles (I truly believe that most projects start with no factual basis that they can be delivered successfully... Luck and miracles many times are the difference between the results being viewed as "it could have been worse" or "are you kidding me... we're launching on time / on budget") demanded by the pace of change companies are facing, there are few alternatives to Agile, DevOps and other emerging practices... They add value and you have to consider them vs the alternative to stay the course… Agile and DevOps, implemented well, can provide needed cohesion, but only on a limited scale... In my opinion, the rate of failed projects is higher today than it has ever been in my 30+ years of doing solution engineering / development... If it's true that technology and practices are advancing faster than ever, then why are we failing so often?… It seems obvious to me, but I’m perplexed that companies / executives don’t see the need to improve leadership practices, on pace with technology advances, to ensure there is full scale corporate cohesion aligning the opportunities and challenges to ensure people are working together to define purpose, common goals, success, and the mechanisms to execute effectively… I’ll share an experience that contributes to my perspective… I interviewed with a company about a year ago that was undergoing an Agile transformation… Everyone was excited and the hyper-noise was pouring from the lips of everyone I met… When I asked the simple question – “Why Agile?”, not one person was able to articulate a cohesive corporate rationale for using Agile to achieve a strategic opportunity or challenge… I think the use of Agile was a good decision for this company but my friends still working there, tell me the transformation has been anything but a success and the company continues to exchange one problem for another.