A few months ago I published a blog about Cloud Financial Management and FinOps that created a bit of a stir. I have to admit, this was exactly what I was hoping for. My goal in writing the piece was to generate discussion around FinOps and Cloud Financial Management. After talking to several FinOps practitioners and others who had feedback on the post, I wanted to share what I’ve learned and some of the interesting discussions this has generated.
First things first, I want to make a few things clear here that I didn’t in the original post:
- My commentary on FinOps is directed towards the FinOps Foundation’s publications, not individual FinOps practitioners or members. I’ve since talked to several folks who call their practice FinOps (and have been practicing this since long before the FinOps Foundation was founded), and it meets almost the exact description of what I term “Cloud Financial Management” in my blog.
- My goal isn’t to criticize names (I don’t really care what we call this movement), but to get an open dialogue going on how we can all work together to solve the big challenges that consumers of public cloud face today. There’s enough going on in the world without having to worry about what we call these practices.
"It doesn’t matter what we call it, we’re all in it together."Senior FinOps Manager, Pearson
Preamble aside, here are a few of the things I’ve learned after speaking with several FinOps community members:
Focus on finding and resolving the cause, not just the symptoms
One of my critiques of what I read about FinOps from the FinOps Foundation is that it seemed to be only treating the symptoms, rather than searching for the underlying causes. It looked at cost-saving tactics devoid of business context. What I learned is that this might be true in the early days of practice, many organizations are now able to mature their practices and start to tackle the larger strategies that are linked to the underlying causes.
Tim Prentice, Cloud Service Delivery Manager at Air New Zealand, has been involved in the FinOps community for years. He told me that for his first few years on the job, it was a lot of tactical blocking and tackling the work head-on, looking for ways to optimize Air New Zealand’s cloud spend. But what he quickly realized was that none of that was really saving the business any money. In fact, sometimes the cost-saving tactics they put in place would inadvertently hide opportunities on how the team could realize even more value.
Ultimately, Tim was able to evolve the FinOps function to focus more on business transformation to keep pace with consumption economics.
Empower engineering without sacrificing productivity
In my original blog, I wrote that “One of the core tenets of FinOps that I find problematic is that engineers should consider cost and margins when they are deploying infrastructure.” This statement, that engineers shouldn’t care about cost, was one of the most debated comments in the conversations I’ve had over the past few months.
I have to admit that I’ve shifted my viewpoint on this topic as a result of these conversations. As Ben Zavadoski, Cloud Business Operations Manager at Pegasystems told me, “I have rarely come across an engineer that didn’t want to know what the cost of resources are… the difference between how an engineer thinks about cost is to start at the unit costs and calculate up, whereas finance goes from the top down.” While it’s a good thing that engineers are more interested in learning about their spend, it’s critical to ensure this doesn’t become a time-sink for them. Ben has taken several steps to ensure this doesn’t happen at Pega, including naming conventions, automated account provisioning, and a programmatic approach to tagging to name a few.
Ashley Hromatko of Pearson agrees with this approach, she told me that they initially took cost out of the engineers’ purview altogether, and her team would perform cleanup tasks after the fact. They realized that a more effective approach is to educate engineers with “FinHacks” and lunch and learns on topics like different tiers of S3 or Spot Instances. They’ve seen great success with this approach—for example, one engineering team has moved to provisioning all net-new workloads on Spot.
Culture matters more than I realized
Beyond stating that one of the goals of Cloud Financial Management (CFM) is to drive a cost-conscious culture, I didn’t spend much time on culture in the previous post. What I’ve learned from customers like Secureworks is that CFM is all about culture. “We wouldn’t have been nearly as successful without a culture of accountability”, said Steve Dion, IT Director, Cloud and Infrastructure Services, Secureworks.
Accountability is a word that comes up over and over again in my conversations with CFM practitioners. And that doesn’t mean developing a culture of policing—but rather a culture of ownership. Secureworks is a good example of an organization that developed a highly successful centralized CFM team that provides reporting, cost control, and also training and enablement. This team was tied closely to the Cloud Center of Excellence (CCoE), which Steve says is the biggest driver of cloud culture at Secureworks.
The connection to the CCoE is one of the critical components that the FinOps concept is missing. The CCoE defines standards for cloud use that enable the business to follow best practices and provides structure through policies. The CCoE must be cross-functional in order to be successful, which is why CFM must be a key contributor. As Steve Dion said in his presentation at CloudLIVE “You can’t have a successful CCoE if it’s driven by a single organization.”
I’ve been greatly enjoying these conversations with the community on this topic, thanks to all the people who gave me the opportunity to have these discussions! We’re committed to helping build and support a community of practitioners in this space. If you want to talk about CFM/FinOps/whatever you call it, best practices you’ve found to be successful, or your experience as a whole, please reach out to me on Twitter!