I’ve been on a kick recently about how DevOps, security, audit, and compliance all fit together. Spoiler alert: they all do fit together. In fact, we’re better off individually and collectively when we bring security, audit, and compliance into the DevOps tent and treat them like we would any other function that has valuable expertise to contribute to help our organizations win. We’d all benefit from what we can learn from each other.
I delivered a talk on September 13, 2017 to the local section of the Automated Software Quality organization on how to bring audit, security, and compliance into the DevOps movement. I provided a lot of resources at the end of the talk. Here they are with a description of each.
I wrote for XebiaLabs on leading a DevOps transformation within your organization. It’s based on a white paper I co-authored with a bunch of really amazing people at Gene Kim’s DevOps Enterprise Forum in 2016. The post covers five simple (but not easy) tips for making progress on adoption of DevOps patterns and practices within your organization. The tips include understanding other people’s goals and the problems they face, identifying a target mindset, and then developing and executing a plan with the most effective tactics.
In retrospect, I’ve been writing a lot for other blogs and less so for myself. Whatever gets the word out and advances the cause, right?
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.
A few years ago, I went through some executive coaching individually and as a group. In one of the individual sessions, the coach and I were talking about my team and the meetings I had with them. The coach asked me how I wanted someone on my team to feel after meeting with me. I had to think about it because I had never been asked that question before. And yet, it was an incredibly important answer to have. After a minute or two, I came up with the following answer.
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.
I started my career as a developer. My success was determined largely by how much I could produce and how fast I could produce it. I was an “individual contributor.” As I grew in my career and gained experience and perspective, I realized a couple of things. First, what I could produce was insignificant compared to what a high-performing team could produce. Second, what I most enjoyed was not producing stuff myself — it was creating opportunities for others to be happy and successful. (That’s now my personal mission statement.)
I decided I had to become a better leader because, regardless of what title I had, that was my real job. Becoming a better leader was the only way I was going to be successful — as defined by the success of the people, teams, and organizations I led.
I’m not that interested in the charismatic leaders or leaders who succeed by “force of personality.” I’m more interested in leaders who put systems in place and create environments for the people and organizations they lead to be successful. I can’t “be” anybody else — but I can learn the principles, values, and systems they used for their success and adopt what I think will work for me.
I’ve discovered some “go to” resources in my quest to become a better leader. These resources achieved that “go to” status based on how useful they are to me — measured primarily by how often I reference them and how much they’ve shaped how I think, speak, and act.
Culture has a huge impact on the performance of an organization — for better or worse. In fact, some say culture is the only sustainable competitive advantage an organization can have. Despite culture’s importance, it has also been “fuzzy” and notoriously hard to quantify. The problem has been that we’ve had no good way of describing, assessing, or measuring culture. That changed when Dr. Ron Westrum, a sociologist, came up with his “Three Cultures Model”.