FinOps Framework

The FinOps Framework describes the principles that drive FinOps practices, the personas that FinOps supports as stakeholders, the best practices and process models used to accomplish this, and the domains of activity FinOps practitioners will perform as they build a FinOps team and drive the cultural change that FinOps brings into their organizations.

 

FinOps Maturity

A “Crawl, Walk, Run” approach to performing FinOps enables organizations to start small and grow in scale, scope, and complexity. Taking quick action at a small scale and limited scope allows FinOps teams to assess the outcomes of their actions and gain insights into the value of taking further action in a larger, faster, or more granular ways.

Start at a Crawl and mature the capabilities that provide your company strategic value. There is no need to try to do all capabilities at once.

There is no value judgement here. Every organization does not need to be at the same level and each capability can be at a different level of maturity as well.

Examples: Gall’s law  tells us that complex processes that work have evolved from simple processes that work; they are not designed from scratch. Do not attempt to build full solutions, rather, build only the amount of solution that you need in any given case. For example, you should build the capability to Run when it provides business value. If you are in the Run phase and it is not adding value, you may be wasting a most precious resource: time.

In another example, you may be in the Run phase at buying commitment based discounts because you have a heavily VM based architecture that is very broad. Or, you may use a heavily serverless architecture that does not require a large amount of savings plans or RIs to be rate-optimized and you never need to develop this capability beyond the Crawl phase. None of these use cases is “better,” they are all well suited to their situation.

FinOps Lifecycle

Like Agile, DevOps, or other modern methodologies, we practice FinOps in an iterative loop, making small incremental changes to our cloud infrastructure as we advance. We describe this approach using the FinOps lifecycle which is comprised of three phases.

1. Inform: In this phase you create visibility, look at what you are using and where, set budgets, and create transparency
2. Optimize: In this phase, you identify ways to improve: Can I turn things off when not using them, make them the right size, or find other opportunities for optimization, and build mini-business cases for good ones.
3. Operate: In this phase you take action, make decisions, and exercise your organisation’s processes to act on the opportunities that bring you the most value.

 

Phases In Practice

At first, it may take a while to perform the work in each phase and you may be more explicit about moving from one to another. However, over time, this cycle of looking at usage, looking for opportunities to improve, and then taking an incremental action step will become more fluid and natural.

The ultimate goal is to exercise the FinOps lifecycle as frequently and quickly as possible, and to include as much automation to help that process as possible. This is how we take incremental steps toward building the culture of accountability and the governance to support our FinOps function.

We use this looping lifecycle with FinOps, in conjunction with Crawl Walk Run, to get more mature every time we go through the loop.

Important Concepts

Prioritization & Triage

When conducting our work in FinOps, because the work is cyclical and iterative, we want to establish a triage or prioritization model early on to drive our work. A FinOps team should often consider the question “What will I work on next?” The answer to that question will often be “The thing that gives us the biggest business value boost.”

How do you identify or document the value of any given step?

For now, consider that we want to use the Pareto Principle, or 80/20 rule, to focus on the costs or problems that appear as outliers in the data. We are naturally predisposed to look at these outliers (either small or large) but by taking a consistent approach to looking at the largest cost items, we will often improve our overall cost situation the most.

Pick The Right Approach

• As you focus in on the items to be addressed, take a moment as a FinOps team to think through various approaches you will use to address the opportunity. When identifying the right approach for integrating the FinOps Framework into your business processes and model ask the following questions.
• Are there any existing business processes, behaviors, or capabilities in place that could accelerate or empower Framework adoption? Are there any that could hinder it?
• What changes are needed in order to resolve those conflicts?
• What are the most valuable “missing pieces” of the Framework to deliver first, for maximum impact? Are there any elements that may require considerable effort to achieve, and is there sufficient support for that effort?
• When developing your Framework adoption roadmap (opens in a new tab), ask: what is the appetite for change within the business, what are the cadences and the pace of change that the business can realistically achieve?

Always keep the end goal in mind when building the FinOps Framework into your business – guide your actions by the key principles, and remember that this is a marathon, not a sprint! It will take time and an iterative approach to adopt the Framework and deliver success.

There is a tendency to dive into the solution we know, or to use the technique we are comfortable with, or the tool most recently used successfully.

Adoption of cloud is not just a technology problem, a business problem, or a system problem, it is very multi-faceted. Controls that traditionally were in place (procurement control on spending, IT control of technology selection, organizational control of speed, security physical control of environment) are less effective overall, so you may face and address issues that were handled by a wide variety of people in your organization previously all in one place.

FinOps teams can become the catchall for questions from capacity planning to cloud service selection to automation to reporting to architecture redesign. Therefore, it is important to have the right resources lined up for support.

Making Tradeoffs

Cloud tradeoffs are made on what we refer to as the iron triangle. All of these tradeoffs must be done by balancing the company’s goals. Decisions can be made to save money but you will be balancing against speed or quality. Similarly,  you could decide to spend more for better quality but you may give up on cost.

Unit Economics

Making all these decisions ultimately leads us to where a mature organization wants to be able to clearly articulate its costs through Unit Economics (opens in a new tab). The goal is to make decisions based on value.

Introduction to Cloud Unit Economics

 

Introduction

The Unit Economics Working Group is proud to introduce this practical guide about cloud unit economics. Our mission with this project is to create common ground, identify standards, and build a better understanding of what cloud unit economics are and how they can be leveraged by your organizations as part of a greater FinOps strategy.

• As you review this material, we welcome any and all feedback, questions, and comments on our Discussion Slack: #chat-unit-economics
• FinOps practitioners are also welcome to use our open Google Slides version of the Cloud Unit Economics Presentation Deck

Executive Summary

The cloud’s ability to scale resources up and down to align with current demand requirements, often referred to as elasticity, is simultaneously both one of the key benefits of cloud computing and its greatest liability.

This elasticity and the cloud’s inherent variable cost structures (that made the emergence of FinOps inevitable) have created new financial and operational challenges that require the creation of systems and processes to measure the variable costs and usage metrics associated with these dynamic infrastructure changes. This document focuses on Cloud Unit Economics as one such system that can bring a number of solutions.

Cloud Unit Economics is the specific application of the broader concept of unit economics to the cloud computing domain. Below you will find an introduction to its practical application and a methodology to quantify the associated cost and usage metrics of elasticity.

This document also covers how the application of unit economics can enable cloud-driven organizations to build more efficient systems and ultimately provide a common language to align both business and engineering leaders.

What is Cloud Unit Economics?

One of the most important concepts in FinOps is unit economics…

– Chapter 1: What is FinOps, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management

The FinOps Foundation define six principles that serve as guidance for the FinOps professional. Why do they specifically call out unit economics? What makes it such an important concept?

In short, it’s because Cloud Unit Economics directly supports each principle. Just like the FinOps practice as a whole, Cloud Unit Economics is not a goal in and of itself, but rather a powerful system for achieving the maximum return on your cloud investment in pursuit of the six principles of FinOps.

So, what exactly is Cloud Unit Economics?

Cloud Unit Economics can be defined as a system of profit maximization based on objective measurements of how well your organization is performing against, not only its FinOps goals, but as a business in the market. Cloud Unit Economics achieves these noble goals by leveraging the measurement of marginal cost (a.k.a., unit cost metrics) specific to the development and delivery of cloud-based software and marginal revenue (a.k.a., unit revenue metrics).

By calculating the difference between marginal cost and marginal revenue, you can determine where your cloud operations break even and begin to generate a profit — an important concept in economics overall and one of the most effective ways to make data-driven business decisions regarding your cloud investment.

A note on cloud unit economics to non-profits or the public sector

This document was written mostly with commercial SaaS and cloud-driven commercial organizations in mind. But, Cloud Unit Economics can be applied to other types of organizations. While most companies measure their success in revenue or profit, a public sector organization (e.g., federal, state, or local government) or nonprofit does not. Instead, value is typically measured in terms of the success (or failure) of the delivery of civic goods or services.

In addition, the value may be derived through the accurate forecasting of overall spending to maximize the use of budgeted resources. If you want to apply Cloud Unit Economics to a non-profit or a public sector entity, simply replace the words profit or revenue with value.

Using Cloud Unit Economics?

Cloud unit economics can unlock the following benefits:

• Quantify the cloud’s role in your financial performance. Cloud Unit Economics is an effective tool for a company’s management, investors, and employees to understand its financial performance.
• Forecast profitability. Based on a unit cost analysis, unit economics shows how profitable a business is or how soon it will achieve profitability, and what factors are affecting its margins.
• Build a plan for cloud cost optimization. Cloud Unit Economics allows companies to understand whether their product is overpriced or undervalued. This can help them identify what should be optimized, and how.
• Evaluate a product’s future potential. Relying on Cloud Unit Economics, businesses can better understand what products and features customers are using, making it easier to make changes to product roadmap and engineering priorities.
• Drive more responsible use of cloud resources by end users. Cloud Unit Economics can be used to measure the impact of end-user behavior on cloud costs, and to drive more cost-conscious behavior. If the end users are internal (employees), unit economics can spotlight opportunities for improved usage, such as not retaining too many copies of files, etc. If the end users are external (customers), unit economics can spotlight areas where usage may need to be shaped/governed via throttling, incentives to change behavior, etc.

Ultimately, by quantifying the cost to produce or the cost to serve, cloud engineers can articulate their contribution to gross profit margin due to the architectural, development, and operating choices they make. Product teams will have key data points to support pricing decisions, and the business will be able to forecast cloud costs better even though cloud resource consumption is variable.

Cloud Unit Economics also supports a broader set of metrics used to evaluate the profitability of products and customers. These include:

• Contribution margin – Contribution margin is the gross profit derived from selling one more unit of a product or service
• customer lifetime value (LTV) – the total worth to the business of a customer’s relationship
• customer acquisition cost (CAC) – the cost of winning over a customer to use your product or service which ties into the customer lifetime value metric.

FinOps Capabilities and Terms to Review

Cloud Unit Economics is a key way to communicate both the cost and the value of everything an organization is doing in the cloud. As such, it depends on key interactions across all other FinOps domains, and understanding their definitions is important. We recommend reviewing the following Capabilities before proceeding with the rest of the playbook.

• Data Analysis and Cost Allocation are fundamental to effective unit cost measurement
• Forecasting and Budget Management have clear intersections in terms of budgeting not only for expected cost but for the cost of supporting a demand that also must be forecast
• Strategic decision-making should be driven more by unit costs than total costs whenever possible
• Optimization activities should be aligned to reach or maintain unit metric target objectives
• FinOps culture — the way we incentivize our engineers, the way we communicate cloud cost and quantify value — is best expressed in terms of unit metrics

To get the most value and understanding from this playbook, review relevant Unit Economics and general FinOps terms before proceeding. Important terms will also be linked to definitions throughout the playbook.

Why Cloud Unit Economics is important

Measuring Unit Economics for Cloud IT is as important as it is complex. The ability to understand current costs, and to predict what future costs will be and should be, is directly tied to an organization’s Unit Economics capabilities.

More specifically, Unit Economics capabilities are critical to understanding:

• The connection between current business demand and cloud costs, at levels such as per customer, per feature, per product, etc.
• How predicted changes in business demand will impact future cloud costs, based on maintaining status quo consumption, architecture, provisioning patterns, etc.
• What your future cloud costs should be – if wasted spend is minimized by optimization, improved end-user consumption, and more efficient architectural patterns.

Complexity stems from many sources, including variable cost models, shared resources, on-demand provisioning, and disparate/siloed data sets. But organizations that effectively address this complex problem space will be rewarded with insights that will empower them to maximize the business advantage they obtain in the cloud.

Common Examples of Unit Economics in Use Today

One of the goals of this document is to help you learn how you might put Cloud Unit Economics to work for your organization. One of the most important details to determine upfront as part of your Cloud Unit Economics journey is what key metric best serves your business needs.

Consider using the following examples to kick start that journey and to give you a taste of what is possible:

• A Financial RiskOps SaaS company might measure their cost per analyzed financial transaction, which is not only tied to the company’s cost to serve, but also to how they price and package their products.
• A Governmental organization launching an application to let residents request literature might measure the cost per user to understand better how the site usage affects their costs.
• An Online Hotel Booking company might measure the cost of creating a reservation to learn how their costs change and forecast their costs during more popular travel times.
• A Rideshare company might measure the cost per ride by the time of day to determine the most cost-effective times to transport customers.
• A Video Conferencing SaaS company might measure the cost per active user and track who their most expensive customers are.
• A professional services firm might measure the cost per engagement team, and identify which teams are driving high costs with excessive discretionary application usage and/or file storage.

Cloud Unit Economics is a universally useful system, but there’s no one-size-fits-all approach to metrics. The right metrics are a product of what you do, who you serve, how big you are, and any other defining factors about your business.

Another way to look at cost to produce is managing and tracking costs of non-production costs.

• Financial – R&D costs and comparative costs by tech stack
• Technology/Engineering – Unit rates per Cost to Produce (Is there fat in the cost in non-production), Future architecture * deployment cost options based on service whitelist, etc.
• Forecasting – Future production cost

And Cost to serve is once the promotion to production begins.

• Sales – Tracking outliers that may be less profitable or abusive customers
• Financial – Gross margins, cost
• Technology/Engineering – Unit rates (blended costs based on how you buy cloud)
• Forecasting – Future growth and trending potential cost

How Cloud Unit Economics Benefits FinOps?

Cloud Unit Economics metrics provide a common language that enables Engineering, Finance and Business stakeholders to understand and discuss cloud spend in a meaningful way. They translate the esoteric language of the cloud bill into units of business value that resonate with stakeholder groups.

In so doing, they become the fuel that powers the inter-departmental collaboration required for FinOps to succeed. Conversations about absolute spend can move to focusing on the amount of business value achieved per unit of cloud spend:

• Cost per transaction/customer
• Cost per release
• Cost per acquired customer during a Marketing campaign

By tying cloud spend to business value, Cloud Unit Economics metrics provide insights that enable stakeholder groups to make informed decisions about how best to use the cloud to maximize business advantage. In an organization with mature Cloud Unit Economics capabilities, these measurements should function as primary drivers for business decisions, increasing the value of FinOps to the organization.

Cloud Unit Economics metrics also enable organizations to benchmark the performance of internal teams and the organization as a whole, when compared to industry competitors. They make it easier to identify areas for improvement and to establish efficiency targets:

• Reduce cost per unit sold by x%
• Increase revenue per dollar of cloud spend by y%
• Improve margins by z% through more cost-effective architectural patterns

Additional motivations to practice Cloud Unit Economics in FinOps include:

• Quantify the impact of cloud spend on business performance at granular levels
• Improved forecasting capabilities
• Improved data for product strategy and pricing decisions
• Identify market segments and products in which to invest, and those which should perhaps be de-emphasized or exited altogether
• Generate cost-to-produce and cost-to-serve value measurements
• Use uniform broad measurements to compare the performance of products and teams.
• Expose the level of elasticity in cloud costs (the extent to which cost changes correspond to demand changes)
• Fair Showback and Chargeback
• Distinguish cost changes due to architectural changes from those due to demand changes
• Identify optimization levers

Examples of Cloud Unit Economics by measurement categories include:

BUSINESS (Sales based on the way products are sold)	FINANCIAL (Service component value indicator)	TECHNICAL (Sum of FinOps tactics and engineering choices at infra value layer)
Cost per weekly active user	Cost variance reductions	Cost per core hour
Cost per million transactions	Spend risk reductions	Cost per GB of RAM
Cost per million in revenue

When to Start

Unit Economics should be discussed at the very beginning of the FinOps Journey; it will provide a stronger link with several stakeholders, especially at the business level when the only information they receive is a big cloud bill (and potentially growing month on month).

As the “How to Get Started” chapter explains, there are different stages during the adoption until it’s fully mature, nevertheless the discussions about defining the key metric(s) should begin as soon as the stakeholders are engaged.

Identifying the key metric(s) must be a priority and to be done as early as possible to allow the building of a prototype of how to collect and represent the outcome, but also will allow engineers to enable integration between the different systems to capture the data in a consistent and recurrent way, and give business stakeholders a clear view of what is contained and represented.

Once the key metric(s) are defined and tested, it’s time to start a journey of evolving them, by creating a systematic way to collect and process the information, and by enriching the core metric(s) with additional information (e.g performance, location, date/time, behavior).

The metric(s) should not be static, and should evolve according to business objectives, additional insights gained during time or any other reason that would bring clearer visibility about unit economics; this could imply changing the definition of the key metric(s), creating new ones, or even stop tracking.

Delaying this workstream has some additional downsizes, such as potential loss of revenue margin due to higher cloud-related costs, hide real cost of running a system in cloud, demotivation of the teams (e.g. business teams don’t understand the costs, engineers won’t be seeing a direct impact on cost reductions, finance teams will see an invoice getting bigger and bigger).

How to Get Started

Oftentimes, Unit Economics starts with sales and marketing to better understand cost per customer, cost of customer acquisition or cost of customer retention, using profit and loss numbers like revenue, COGS, or expenses as part of the Unit Economics calculations. Cloud Unit Economics uses cloud infrastructure unit cost as part of the value measurement calculation.

Building a sustainable Cloud Unit Economics practice starts with a strong unit cost model. Seek out people in your organization who are already thinking about or doing it at some level, even if not in the area of cloud spend. Enlist their support to build momentum for this important work. Courage is required; don’t be afraid of publishing a draft version of a model that has deficiencies. Sharing work early and widely is important to obtaining the feedback necessary to improve future iterations.

Planning should start as early as possible to identify the metric or metrics needed to collect meaningful data. This may give direction to engineering teams on the necessary data points to be collected later. Collecting and processing the data should happen as customers start onboarding a system.

Who defines the first metric?

Key principles:

• There is most likely no single metric to rule them all
• Unit metrics should be as close to the user’s workflow as possible
• Ideally, the metric should be defined by a FinOps expert together with the representatives of the end-user team (EM if this is an engineering team, Finance Manager for FP&A, etc.)
• The metric set should be maintained centrally by FinOps team with the premise that it is dynamic by nature

• All unit metrics should be actionable; if a unit metric is not actionable for a specific team, it should be changed

• The proposed metric(s) should have an acceptable level of correlation between its value and use of cloud-based resources

Who collects the data (push vs. pull)?

• This depends on the culture of the company and even on a specific team that is an end-user of the metric
• Usually, pull is a more user-friendly approach, but it is not always possible (especially if the unit metric denominator is something complex, like logs, and the central FinOps team does not have engineering capabilities or expertise to process the data)
• If you are considering push, think about which system components will need to push data to some type of centralized log or database
• Regardless of the collection approach you choose, bringing the metrics you use into a central location for processing, analysis and reporting will be necessary

In the beginning, the most important thing is to get started! With your first unit cost metric identified and the data necessary to calculate it flowing, be prepared to learn a few new things about your system and its use. Preparing the data and sharing those insights can be a powerful way to build support and encourage your organization to more broadly incorporate unit cost metrics into your cloud operations.

With your first metric under your belt, use the Cloud Unit Economics maturity model as a guide to planning your next steps and achieving more impactful use and adoption.

• Pre-Crawl: No Cost Models

• Not started any cost models

• Crawl: Unit Cost

• Blended unit cost based on the invoice.
  • Unblended Unit Cost based on contract pricing.

• Walk: Unit Cost Integration

• Unit cost used to convert unit forecast to budget.
  • Usage and cost conversations.

• Run: Unit Economics

• Cost to produce
  • Cost to serve a customer
  • Cost to serve an application
  • Cost to serve a file

The path you take will ultimately be dependent on the architecture of your organization. During the crawl phase of adopting Cloud Unit Economics, it is best to start with metrics that can be supported by existing data sources such as logs, data warehouses, or APM platforms.

Example: Cost per Customer

Cost per-customer (or cost-per-tenant) is a common goal that can typically be applied to most organizations and is often a good metric to start with. Using the maturity model as a guide, you could achieve cost-per-customer using the following process:

Crawl: Cloud Only

Depending on the complexity of the application, this may also be done in multiple phases, where some cloud costs are handled initially as “direct” and others “shared.”

Walk: Cloud + SaaS + Licenses

This could include things like Datadog, ServiceNow, or PagerDuty or BYOL (Bring Your Own License) like Windows or SQL Server which are run on cloud infrastructure. Once you start bringing in SaaS tools or Licenses, you may need to work with the team responsible for that product to understand the KPIs they care about and how they quantify time spent such as the SAM or ITAM team.

Run: Cloud + SaaS + Hybrid Costs + Human Capital

This is bringing in costs like labor or even on-premise costs that support a particular product or service. The run phase is typically when a firm starts collecting more than one metric for various parts of a complex system getting more granular over time.

Above is courtesy of Lucas Paratore, FinOps Pro Essay, and Cloud FinOps, Fuller & Storment, 2022.

Do what’s right for your organization

In other situations, engineering might play a more central role in your FinOps organization, and you can leverage engineering time to produce the necessary metrics. This might be where organizations start their journey, or it might be where you ultimately end up. Regardless of the resources you have at your disposal, start small and focus on clear metrics that will be tangible to all stakeholders.

Through all of this, the centralized function of FinOps should be apparent: the FinOps team should be responsible for maintaining the Cloud Unit Metrics repository and be capable of clearly articulating their business value. Without it, a company can end up with “one metric to rule them all” or a bunch of clashing metrics.

Who Should Own Unit Economics in the Organization?

Unit Economics typically will fall into several categories that follow FinOps personas. If you aren’t familiar with FinOps personas involved with building and operating your practice, catch up on the personas page.

	BUSINESS	BUSINESS	TECHNOLOGY	FINANCE	FINOPS
	Executives	Product Owner	Engineering and Operations	Finance/Procurement	FinOps
INPUT	A CTO/ CIO / CFO should own the initiative of Unit Economics and determine scope as it relates to coverage of Products	VP of Product / Product Owners should collaborate with Finance to determine key product metrics	VP Engineer collaborate with Product Owners define input requirements for metrics to best determine how to collect metric data from systems	Finance should collaborates with Product Owners to determine key product metrics	FinOps should be aware of executive scope and identify gaps in cost allocation alignment to strategy
OUTPUT	Actioning on business decisions as a result of cost metric data	Define frequency of reviewing unit cost and determine benchmark thresholds	Support solutioning automation and identify blockers to outputting metrics	Actioning on business decisions as a result of cost metric data	Integrate cost allocation with cost metrics

NOTE: This table is best viewed on a wide viewport, like a desktop or tablet.

Potential Challenges and Barriers to Adoption

What do we measure?

It is important to clearly define what is being measured. For example, let’s say you are storing customer data so you decide to measure the cost-per-GB. Then, one of your engineers figures out a new way to further compress the data, cutting your storage needs by about 30 percent.

In this scenario, your cost-per-GB does not change even though your storage costs have decreased. Instead, it would be more meaningful to measure something like a cost-per-stored-item (whatever that may be). Using a cost-per-stored-item as a unit of measure in this same scenario would show a 30 percent reduction because you are storing the same amount of data with fewer GBs of storage.

Collaborating with all of the necessary organizational stakeholders to first determine what drives business value is essential to getting this part right.

Which financial inputs do we include?

Defining and agreeing on the type of costs to report (e.g.: include or not discounts, negotiated rates, optimizations, shared costs, support, any other operational related cost)
Once you’ve decided what to measure, it is imperative that you clearly delineate what financial inputs make up your unit costs.

Is your organization receiving an enterprise discount? Do you have a private pricing agreement with one of your vendors? Are you receiving bulk discounts on licensing costs? Do you amortize upfront payments for commitments? Regardless of which stage your organization is at in the crawl-walk-run cycle, it is important to consider these types of questions when measuring and reporting your unit costs.

How many metrics are needed?

Expecting perfection when starting out is a huge barrier to success. Don’t let perfect be the enemy of good. Most often, a single metric can provide better information than a “peanut butter spread” allocation methodology for a product or service. A single metric based on usage is always better than taking total cloud spend and dividing it by a KPI like total number of customers. The unit metric has the ability to provide more nuanced information, like which customer is driving the most spend based on usage. A single metric may not be perfect, but it is a great place to start on your journey toward Cost-per-X. Integrate by observing your first unit metric and making an informed decision about whether there is a need for another metric.

The law of diminishing returns for investing in new metrics can happen quickly. Again, good enough is oftentimes substantially easier to achieve than perfection. Some firms may need several metrics to get to a solid Cost-Per-X while another firm might need only one. Overcomplicating at the beginning will prevent you from starting and getting a return on investment for your efforts quickly.

FinOps Principles

FinOps principles give us north stars to guide our activities as we practice FinOps. These principles were developed by FinOps Foundation members and honed through experience.

Overview

These principles are presented in no particular order and should be used all together as a set. Implementing one, without the others to the extreme creates problems just as implementing all except one will create. The principles are in open source in the FinOps Foundation github repository (opens in a new tab).

●     Teams need to collaborate:

FinOps is about cultural change: breaking down the silos between teams that historically haven’t worked closely together. Collaboration is the hallmark of FinOps. Teams must work together in near real-time as the cloud operates on a per resource per second basis. Continuous improvement and fast decision making are required and collaboration is the engine of the practice of FinOps.

●     Decisions are driven by the business value of cloud:

Unit economics and value-based metrics demonstrate business impact better than aggregate spend. Make conscious trade-off decisions between cost, quality, and speed (the iron triangle). Think of cloud as a driver of innovation, a driver of capability, and a way to get speed to market and customer satisfaction up.

●     Everyone takes ownership of their cloud usage:

Accountability of usage and cost is pushed to the edge. Individual feature and product teams are empowered to manage their own usage of cloud against their budget. Decentralize the decision making about resource usage and optimization. Technical teams must begin to consider cost as a new efficiency metric.

●     FinOps reports should be accessible and timely:

Process cost data quickly and consistently for better cloud utilization. Visibility into cloud spend is provided to all levels of the organization. Create, monitor, and improve real-time financial forecasting and planning. Focus relentlessly on clean data to drive decisions. Utilize internal team benchmarking as well as industry peer-level benchmarking.

●     A centralized team drives FinOps:

Centralized automation for FinOps reduces duplicated efforts. Executive buy-in for FinOps practices and processes is required. Rate and discount optimization is centralized. Centrally govern and control committed use discounts, reserved instances, and volume/custom discounts with cloud providers. Remove the need for engineers and operations teams to think about rate negotiations, then they stay focused on usage optimization.

●     Take advantage of the variable cost model of the cloud:

The variable cost model of the cloud should be viewed as an opportunity, not a risk. This includes just-in-time prediction, planning, and purchasing of capacity. Agile iterative planning is preferred over static long term plans. Make continuous small adjustments in cloud usage/optimization.