The latest expert opinions, articles, and guides for the Java professional.
Is it intentional?
No matter how many times we show some amazing statistics (check out these updated slides from the video above) it never seems to do anything. Just look at these stats from our so-called DevOps Productivity Report:
- Compared to Traditional IT Ops teams, DevOps-oriented teams spend 21% less time putting out fires on a weekly basis.
- Compared to Traditional IT Ops teams, DevOps-oriented teams spend 33% more time improving infrastructure against failures.
- Compared to DevOps-oriented teams, traditional IT Ops teams require nearly 60% more time per week to handle support cases.
The tireless activities of Patrick Debois and the wily engineers in the DevOps community have at least had some effect: the fun, off-beat DevOps Days events are picking up steam and popping up like wild mushrooms all over the world. Other events driven by tool makers like Atlassian, Chef, CloudBees, PuppetLabs and ZeroTurnaround are also gaining traction.
But from an organizational perspective, most decision makers out there are finding it really easy to continually ignore the value of DevOps. Indeed–making it all happen is a lot of trouble, time and effort, plus it empowers employees at ground level in the organizational hierarchy so that management-level structures and paradigms are perhaps less necessary (oops, did I stumble on something here?)
So here’s what to expect: Your organization won’t be doing anything about DevOps again this year, just like last year and the one before that.
This news is both good and bad . The good side is that it’s not your fault (completely). But the bad news is still kicking your team in the ribs in spite of the significant benefits that DevOps methodologies and concepts retains over traditional IT Ops (as we call it).
My theory: the real decision makers in the IT world actually loath DevOps, but enjoy publicly supporting it and calling it a priority for “next year”.
Do organizations really hate DevOps?
Why do I ask? Because, like any socio-political movement (c’mon, let’s admit that this is what DevOps really means to organizations), the progressive ideals it professes are shamefully simple; this convinces people that if such easy things–i.e. communicating more, and working towards a common goal instead of at loggerheads–are not happening naturally, then things must be systemically screwed up and therefore unchangeable.
In an industry where enforcing wide-reaching changes on a short time scale is rarely embraced with many of the big organizations out there (which is to be expected), we keeping screaming at the top of our lungs that “DEVOPS CAN’T WORK UNLESS YOU CHANGE!”
It seems like there are two camps in this struggle for DevOps nirvana–the tiny fraction of awesome, highly-vocal fanatics, and the other 99.999% of people who fall into the “Never heard of it / Don’t really give a darn” category.
Changes to make: Cultural & Technical
There are some great books out there (I recommend The Phoenix Project), and even by taking a quick look at Atlassian’s DevOps Dojo, you’ll notice that they distinguish between “Cultural DevOps” and “Technical DevOps”. The technical side of things has seen amazing strides: Just look at Vagrant, Chef, Puppet, Amazon, Docker, Packer, JHipster, Selenide and dozens of more tools & technologies being used and embraced by a growing population every day. This momentum makes it easier to focus only on the technical approach to DevOps, leaving the cultural aspect out and further alienating both Dev and Ops camps.
But, Geert Bevin has written, the DevOps cultural change –or at least the preparation and understanding that a change to business as usual will be needed in the future–is kind of a prerequisite. In a classic chicken-or-egg scenario, the technical side of DevOps is needed to support the actions taken by DevOps cultural adherents; however, without the cultural side of DevOps, these tools would never have been created.
It’s important that we don’t allow the gap between the cultural and technical aspects of DevOps to grow too large. But unlike the growing number of ready-made technical solutions for better development and release of apps, there are no out-of-the-box solutions for altering an organization’s culture–it requires time, energy, thought and, namely, a willingness to change things up. That cannot be acquired, only inspired.
More on that…
In the meantime, while your organization ignores DevOps principles, you can read a report based on over 600 engineer responses, and perhaps use some of these stats as ammunition in your argument ;-)
See all the benefits of DevOps over traditional IT Ops in this report, which is the full version of the findings we discovered and presented in the consolidated slide set above.
[publication id=”58″ label=”Get the Report PDF”]
No comments yet.
Sorry, the comment form is closed at this time.