The 2017 State of DevOps Reportis out. As in previous years, it provides a lot of information about the state of DevOps within the industry and some of the important factors that differentiate high-performing organizations from their non-high-performing peers. I noted a few highlights from this year’s report: the impact of leadership, the continued misconception about the perceived tradeoff between throughput and stability, and autonomy with teams and architectures.
I’ve spent some time around John Willis, one of the thought leaders in the DevOps movement. If you spend any time at all around John, you’re bound to hear him talk about W. Edwards Deming and the idea that Deming laid many of the foundational principles and practices of DevOps. After reading Deming’s book, Out of the Crisis, I have to agree. And now I’m a fan of Deming, too. Not as much as John (just look at his Twitter avatar), but a big fan nonetheless.
I’ve heard a lot of questions about DevOps, audit, compliance, and how they all fit together. I’ve fielded more questions from more people recently. In my mind, that means more people are applying DevOps patterns and practices to their work and the work they’re doing is real (as opposed to sandbox, pilot, or “let’s try this stuff out” projects). Why else would they be interested in audit and compliance?
Here are some resources that might be helpful if you’re “doing the DevOps” and interested in making audit and compliance efforts go more smoothly.
The Federal Government has a lot of legacy systems and spends a lot of money on them. In fact, according to a white paper on legacy system modernization from The American Council for Technology (ACT) and Industry Advisory Council (IAC), the Federal Government plans to spend $37 billion on “legacy” IT in 2017.
Lots of organizations struggle with legacy systems. Or more to the point, they struggle to maintain and make changes to them in a way that provides the pace and value the organization wants. So given the scale of this issue in the Federal Government, ACT-IAC took a crack at providing a “best practice” approach for modernizing legacy systems in the white paper I just referenced.
I read the paper a couple of times. I definitely had some strong thoughts and feels as I read it. I couldn’t keep them bottled up so I suggested some changes to how the Government should think about legacy systems modernization on Excella’s blog. I could’ve written a lot more (like on the role of DevOps, which shouldn’t be in the “DevOps/Sustainment” phase — see page 20 in the white paper), but the post was already getting lengthy. Let’s consider this a good start for discussion and iterate from there.
The 2016 State of DevOps Report is out and carries with it some fantastic information — just like the 2014 and 2015 versions. I love the statistics and the research — and the support it provides in making the case for DevOps. This year’s version even more so because it covers the topics of employee engagement and ROI.
You can also see my insights from last year’s report.
Yeah, I know. This “Keep Calm” thing has been done to death. I’m only adding to the craziness by associating it with the DevOps movement (although I know I’m not even close to being the first). In this context, CALMS is an acronym coined by John Willis and Damon Edwards and later added to by Jez Humble. CALMS represents five key aspects of DevOps and stands for Culture, Automation, Lean, Measurement, and Sharing.