FierceDevOps

Last year I wrote several columns for FierceDevOps. Nancy Gohring was the editor there and graciously asked me to do so (she’s moved over to being an analyst at 451 and is doing awesome work over there). The FierceEmpire has shifted their stuff around and now it’s either impossible or impossibly tedious to find those pieces, so I moved them over to Medium. I’ve got to get my URLs to be my overly self-referential self, after all!

Questions around audit and compliance always come up in discussions about improving software, and certainly when it comes to introducing things like continuous delivery, DevOps, and esp. something as big and different as Pivotal Cloud Foundry. To that end, I wrote up a way to approach those issues, along with a few tips for dealing with compliance and audit for my FierceDevOps column last month.

The onerous steps auditors want you to do were usually put in there for good reason, but, as I put it:

Unfortunately, the way that three-ring binder wielding ninjas and IT staff battle it out over these and other compliance check-lists often loses sight of the original, good intentions. Instead, it infects everyone with a bad case of table-flipping madness. Thanks to cloud technologies and the empathy over table-flipping approaches in DevOps, we’ve been finding ways to get over compliance hurdles and even, in some cases, make compliance projects easier and better.

Management needs to establish strategic objectives that make sense and that can be used to drive plans and track progress at the enterprise level. These should include key deliverables for the business and process changes for improving the effectiveness of the organization.

It made me think that most of the corporate failures I’ve seen over the years were due to management being vague about what they wanted and what the team should be doing. Someone has to set the goals and, at the very least, it’s management’s job to make sure its done (they don’t have to do it, though I tend to think they do: they just need to make sure it happens).

1.) Bottoms-up ROI: We know everything and have put it in this spreadsheet

…if you have a good handle on the costs during some period of time where you were doing DevOps, and the gain that resulted from that period of time, you could come up with a bottoms-up ROI analysis. I think it’ll be somewhat dicey since it’s so hard to attribute costs and gains directly to DevOps but hey, it’s better than either telling people they’re asking the wrong question or its mute cousin: nothing.

2.) Were the efforts to change worth it? That is, DevOps is all cost

…if you want to run the numbers on something like “they tell me it will take three months and $50,000 in training and consultants to ‘do the DevOps'” this might satisfy your ROI craving. Again, you’ll need to have a pre-existing ROI at hand to simply plug your DevOps costs into.

3.) Pain avoidance and remediation

In the “DevOps is all cost” ROI scenario, we avoided ascribing gain to changing to DevOps. Again, while this is overly simplified, the deliverables of DevOps are to provide a continuous delivery process for your product and ensure that your product has excellent uptime. How could you account for the gain of those two desirables? You could create a way of assigning value to the knowledge you gain from weekly iterations about how to improve your product. You could also calculate the savings from avoided downtime.

My second column from FierceDevOps is up. It’s essentially a write-up of my DevOpsDays Austin talk (see slides here): a quick check-in on how DevOps is doing (good!) and my advice on what it can do to keep being successful.