Mastering the Ongoing Challenge of Management Buy-In for FinOps: How a PoC Can Pave the Way
published at 09-27-2024 by Manuela Latz
Insight from Day-to-Day FinOps Practice
From my experience, the initial push for FinOps often comes from the platform teams, cloud foundations or landing zones of a company. These teams, typically consisting of only a handful of people, are responsible for provisioning, securing and managing resources from public cloud providers used within the enterprise. They might define policies, provide cloud accounts, onboard teams to operate in the cloud and engineer the overall cloud infrastructure. They are where the cloud ends come together.
It is therefore no wonder that the need for FinOps and the first practical approaches take root within these teams. I frequently observe that the individuals involved are self-motivated, despite having little to no formal time or resources specifically allocated to FinOps activities. FinOps is set up from a bottom-up adoption model (or at least an attempt is made). These teams voluntarily dedicate spare working hours to transparency and optimization efforts, mostly manually and usually without official support, tools, or the authority to act (e.g., the authority to purchase central upfront savings plans or ensure that teams to act on optimization recommendations).
And this is why FinOps practice is still in its infancy in many companies, especially in organizations whose core business is not IT, failing to scale and grow out of its “volunteering project” state.
Implementing the FinOps framework and all capabilities and activities coming with it, requires strong advocates with decision-making power, especially in the early stages of adoption. The aspects of organizational awareness and alignment as a high priority are often neglected when the FinOps seed is planted.
But why is it so hard to gain the necessary advocates within management to effectively establish FinOps? Enabling an organization to achieve transparency on cloud spend, reduce cloud costs where useful and build cost-efficient cloud solutions should be no-brainer, right?
When starting your FinOps journey, there is often a lack of cloud cost transparency and measurable optimization potential that could offer hard proof of the necessity of FinOps. Furthermore, decisions such as the purchase of commitments or the implementation of usage optimizations, depend on stakeholders who do not simply change their current processes or adapt their behavior at the request of individual employees. If you ever tried to convince procurement that a 3 year upfront savings plan is worth it or wanted to get a product team to prioritize storage tier management over feature development during a running PI, you know what I’m talking about.
In practice, however, FinOps has been shown to scale more quickly through an organization if management prioritizes the topic.
So, how do you persuade key decision-makers and the management to allow you to invest your own working time in FinOps. How do you get support to involve other departments and gain access to data and information?
Conducting a small, but effective PoC will help to make FinOps a priority
A FinOps Proof-of-Concept (PoC) can be a game-changer by requiring fewer resources, involving only a few key stakeholders, and focusing on demonstrating the value needed to convince management of the importance of implementing FinOps practices.
Instead of trying to create transparency everywhere or buying commitments for the entire organization, the main FinOps capabilities (transparency for cloud cost and usage, commitment management and KPIs) can be applied to a small area of your cloud consumption, for example, just a few cloud accounts.
Tip: Instead of officially requesting for PoC participants, leverage the existing knowledge within your platform team. Which teams do you already closely work with? Who within your organization is particularly focused on managing cloud costs? Who have you already had discussions with about improving cloud cost forecasting and budgeting? These teams are typically more receptive to the FinOps ideas and easier to engage for testing FinOps measures.
For official POCs, I recommend creating a concise one-pager tailored to your organization. This should include a brief description of the goals (cloud cost transparency and optimization of), the methodology for achieving these goals (FinOps), as well as the scope (approx. 3 months) and the participants (e.g. 20% resources from the platform team and 20% resources from the engineering team). Once the project is approved, focus your activities and efforts on the following three key components:
Component 1: Creating Transparency
One of the first challenges you are most likely to encounter when introducing FinOps to your company is the ability to track and report cloud cost development within the context of the organization's structure. Key questions often arise: What are the current costs across all development accounts? Have the costs for a particular team or product (that uses multiple cloud accounts) increased? Can all active cloud accounts be linked to actual teams, or are there unused accounts still active? Who are our top five areas, applications, or products utilizing the most cloud resources?
During the PoC, the goal is to make cloud costs allocatable and easily accessible for other stakeholders within your organization without immediately investing in a new cloud cost transparency tool (yet). A simple but clear allocation logic can help allocate cloud spend quickly with existing tools, avoiding the need for a comprehensive tagging strategy.
For example, what can help is implementing a single account naming convention, such as
subsidiary/brand-productname-specifics [e.g., data collector]-stage
which is applied to the POC's accounts.
Image 1: Suggestion for naming convention for faster cloud cost allocation (provided by Liquid Reply)
When using cloud provider tools such as AWS Cost Explorer or Azure Portal, the naming convention approach allows you to filter and export data, e.g. “everything with the stage ‘dev’ in it” or “everything with product name X”, in a straightforward and efficient manner. This enables you to quickly gain insights on the key questions mentioned above.
Note: These small steps towards transparency later serve as strong arguments for securing further time and resource investments in FinOps, including a comprehensive tagging strategy and establishing a well-thought-through governance.
Component 2: Implementing Two Quick Measures
FinOps requires investment – in people, tools, capacities, and process adaptation. But who wants to invest when the goal is to reduce costs? To justify the initial investments, it is essential to make the impact of FinOps measurable by providing clear evidence that both centralized and decentralized efforts with the technical teams can lead to real cost-savings.
During the PoC, gathering evidence for both rate and usage optimization is therefore key. To achieve this, start by focusing on the low hanging fruits and quick wins first.
For instance, you could:
- Purchase a small, low-risk commitment in the production account for rate optimization
- Implement virtual machine shutdowns overnight in the dev environment (excluding machine learning accounts) for usage optimization
Choose optimization options that:
- Your team can easily implement or execute, such as purchasing an Account-Level Savings Plan or Reserved Instances (RIs)
- Require minimal stakeholder involvement or approval (e.g. monthly commitments might not need approval, whereas upfront ones do)
- Are easy for technical teams to implement without extensive feasibility testing (e.g. for AWS: S3 Intelligent Tiering instead of S3 Standard; for Azure: downgrade premium disks to standard disks)
- Are measurable with onboard cloud provider tools (These tools allow you to filter and view data tied specific cloud usage metrics, such as running hours, storage classes, number of requests, or GB stored ...)*
The goal is to optimize a small portion of your consumption and make these improvements and cost-savings measurable. This will demonstrate what can be achieved with minimal effort, giving management and decision-makers a glimpse of the potential impact if more resources were available to implement FinOps activities.
*For a detailed overview of which data can be viewed, the following documentation is helpful:
- AWS: https://docs.aws.amazon.com/cost-management/latest/userguide/ce-filtering.html
- Azure: https://learn.microsoft.com/en-us/azure/azure-portal/manage-filter-resource-views
Component 3: Making Successes Measurable and Annualizing Them
If you manage to purchase even a small commitment, make sure to highlight its impact loudly and proudly to boost the relevance and awareness of FinOps as a practice and emphasize the need for resources and management attention.
Determining the savings is relatively straightforward and can for instance be done using tools like the AWS Cost Explorer. The following example, parameters and filters are sufficient for determining savings through EC2 reservations:
Service: EC2
Linked Account: The POC accounts
Usage Type Group: EC2: Running Hours
Charge Type: Usage, Reservation Applied Usage, Savings Plan Covered Usage
Cost Types:
- Unblended Rate à This shows your EC2 usage for running virtual machines, regardless of how they were purchased (i.e., whether discounted or not), at the list price for each machine type and region
- Amortized Rate à This shows the actual amount paid, taking into account any savings from commitments
With the Usage type Group restrictions, you can see how many hours were actually run across all machines and calculate unit prices per running instance hour
With just a few impactful figures, you can quickly and clearly present PoC successes to any skeptics. Even if detailed cost allocation at the application, project, or team level isn’t available yet, these initial results are enough to highlight the relevance of FinOps practices.
If you don’t have access to your billing data, you can still track instance performance and manually record cost data for actively running instances to create a before-and-after comparison that demonstrates cost improvements.
Conclusion:
In the FinOps community, the importance and value of all domains and capabilities are well recognized, along with the need for continuity in practice. However, many companies often perceive the expected changes as requiring more effort than the results justify, and they may be hesitant about making large investments.
The PoC delivers small, measurable results that can be easily applied across the organization. It also provides a way to compare the effort involved with the potential benefits. The primary goal of the PoC is to get a "foot in the door". The more support you gather from within the platform team in the early stages of FinOps, the easier it becomes to expand the practice gradually.
It is crucial to understand that not every persona involved in FinOps will be ready to embrace the FinOps Practice right away. Mastering the beginning and developing a process to get around that lack of readiness is something I think you have to master if you want to get into FinOps and set up a FinOps team.