FinOps Capabilities

FinOps Capabilities represent functional areas of activity in support of their corresponding FinOps Domain. Functional activities are tasks or processes that allow one to meet the demands of a FinOps practice by iterating through the lifecycle phases. These functional activities and processes are intended to be in service of enabling, educating, sharing knowledge, advocacy, actionable tasks, business objectives, and FinOps maturity improvement.

Cost Allocation (Metadata & Hierarchy)

Cost Allocation is the set of practices to divide up a consolidated invoice or bill among those who are responsible for its various component parts.

Definition

Cost Allocation is the set of practices to divide up a consolidated invoice or bill among those who are responsible for its various component parts. In the context of FinOps this typically involves dividing up consolidated Cloud Service Provider invoices among various IT groups who use cloud within the organization.

FinOps, itself, is necessary due to the large quantity of billing and usage data provided by cloud providers, and the speed at which it is delivered. Cloud billing and usage data is aggregated into a few data sources, often with millions of lines of data, delivered multiple times per day. Cost Allocation can be a challenge to appropriately divide the total cloud bill among the many parts of an organization who are using it.

Cost Allocation is done through a combination of functional activities primarily focused around the use of a consistent hierarchy of accounts, projects, subscriptions, resource groups and other logical groupings of resources (and the naming of these hierarchical groupings); along with resource-level metadata – tags or labels – applied within the cloud service provider, or by a third party FinOps platform.

All of the clouds provide tools to allow users to arrange hierarchy groupings, and to apply metadata to those groupings. The naming standards used for the accounts, resource groups, projects, and folders, can also be useful in determining the owner of any group of resources.

All of the cloud providers also allow for the use of tags or labels which can be applied as metadata to most individual resources, and which then appear in the billing and usage data when turned on by the user.

Increasingly, FinOps platforms and cloud providers are adding the capability to more flexibly manage resource metadata and hierarchy groupings either within the cloud provider or in the cost and usage data after delivery by the cloud provider.

Cloud provider invoices can be analyzed, using a combination of hierarchy and metadata to allocate costs to various organizational, functional, or financial targets within the user company. Any resources or hierarchy groupings which have no metadata attached can be addressed by the FinOps team as a compliance issue. Resources and hierarchy groupings which can be directly attributed to an internal target can be mapped to that target. Resources and hierarchy groups which are shared, can be identified as shared cost, and then various models of distributing those costs can be applied.

An important prerequisite to effective cost allocation is the metadata strategy, which should include all of the details governing the cost allocation process. The strategy should create a list of metadata which should be applied, possible values, compliance requirements, and mechanisms for doing so. Likewise, it should indicate a mapping of those metadata or hierarchy groupings to internal identifiers within the user organization, such as the business unit, P&L group, cost center, application ID, etc. to which costs will be allocated. There can be multiple layers of cost allocation and multiple ways to slice the cost and usage data as well. For example, finance may need to see costs divided into the Cost Center, but some engineering teams may need more granular breakdown by application, and there may also be a need to see all costs related to Production environments for all applications, or costs which are identified as R&D costs.

Maturity Assessment

Those at the highest maturity are allocating more than 90%, where those at Walk maturity are not far behind and allocation above 80% with the remaining cohort at Crawl.

Crawl

At lower maturity the mechanisms for allocating cost will be less granular and more general, and the ability to handle shared costs or untagged cost will be less effective, granularity of cost allocation will likely be at the business unit or portfolio level
Crawl phase cost allocation might include simply dividing the total bill by account, project or subscription where a list of these is known to belong to a specific cost center or business unit
Accounts, projects or subscriptions which are unknown would be fairly common as cloud use grows, and the FinOps or finance team might need to investigate these to determine an owner some months
Tags or labels may be used for some cost-allocation, but not used consistently, or not used for a majority of spend
A Metadata strategy, including resource and hierarchy naming standards might exist, but it may not be followed consistently
Use of Cloud Service Provider tools

Walk

At a walk maturity, mechanisms for allocating cost will be well-established, and there will be a variety of mechanisms, but all may not be used consistently or universally, and some shared costs or unallocated costs may still exist, granularity of cost allocation will typically be at an application or service level
Walk phase cost allocation will typically include a combination of factors, such as accounts, projects or subscriptions which are identified by metadata or naming standard as belonging to specific cost centers, resources within shared cost pools which can be identified as belonging to a particular cost center, and some mechanisms for the distribution of shared costs
There will likely still be either legacy or less critical parts of the cloud infrastructure which are not consistently using the cost allocation standards, which may still require some manual or estimation effort
There may be some shared cost infrastructure which cannot be directly allocated without some information not available in the cost and usage data, but which can be either budgeted for directly as a shared cost or which can be divided by agreed-upon factors which are available (e.g. the percent of directly attributable other costs paid by an application is the same percent paid of the shared cost items)
Use of a combination of Cloud Service Provider tools and third party tools of various types
KPIs for cost allocation understood, not automated likely

Run

At the run maturity, costs should be allocable to as granular a level as required by an organization, with direct allocation or consistent mechanisms for distributing shared cost items, and the strategies for metadata, hierarchy and naming standards are being used consistently and effectively universally.
Multiple sources of data are being brought together to effectively allocate shared costs at the level they can be where this is critical to the organization
There are few scenarios where all cost is not allocated at the most granular level or is unidentified, requiring essentially no research or reporting generation time
Use of Cloud Service Provider tools, third party tools, home developed and maintained tools and automation
KPIs well understood and automated

Functional Activity

As someone in a FinOps Practitioner role, I will…

develop the Naming Standards for all required and optional layers of hierarchical groupings
develop compliance standards for various groups

As someone in a Business/Product role, I will…

provide feedback on cost allocations made to products within my control

As someone in a Finance role, I will…

determine the organizational and budgetary units to which cost will be allocated
determine how to allocate percentages of any shared cost items

As someone in an Engineering/Operations role, I will…

determine how and when metadata will be applied to hierarchical groupings and resources
enforce and automate metadata standards for cost allocation metadata
identify and provide all metadata sources required for analysis and cost allocation

As someone in an Executive role, I will…

review and approve cost allocations assigned to organizations within my control
review and approve cost allocation strategies
determine and provide feedback when cost allocation must become more granular or mature

Measure(s) of Success & KPI

Measures of success are represented in the context of cloud costs and may include one or more key performance indicators ( KPI ), describe objectives with key results ( OKR ), and declare thresholds defining outliers or acceptable variance from forecasted trends.

The majority of cloud costs can be categorized and allocated directly to an organizational unit. According to the FinOps Community of Practitioners, comprehensive allocation translates to at least 80% of cloud spend is allocated for a FinOps practice operating at a Crawl maturity level; and 90% for a FinOps practice operating at a Run maturity level
Ability to surface the percentage of cost that cannot be categorized and allocated directly, and which must be investigated at a low level
Metadata compliance as a percent of spend (i.e. 80% of cost has appropriate allocation metadata, or is within a known hierarchical grouping)
Stakeholder notifications for missing allocation metadata when resources are deployed

Inputs

Cloud Adoption Frameworks / Architecture Frameworks from Cloud Service Providers
Established reference listing an organization’s valid values for each element of allocation metadata (e.g. Project names, Application IDs, Cost Center IDs, Contacts, Organization groupings, etc.)
Reporting which surface percentage of spend that is allocated and unallocated by established allocation metadata
Roles defined for cost ownership
Existing tag/label standards for operations, existing naming standards
Understanding of the capabilities of CI/CD, platform, cloud provider capabilities

Data Analysis and Showback

Data analysis and showback is the ability to create a near real-time reporting mechanism which calls to attention total costs for the desired business entity, opportunities for cost avoidance, and KPIs.

Definition

Data analysis and showback is the ability to leverage data, along with metadata on cloud resources and resource hierarchies, to create a near “real time” reporting mechanism for stakeholders which calls to attention: Total costs for the desired business entity, opportunities for cost avoidance, and KPIs for financial health (e.g. performance of rate reduction commitments, unit cost measures for key services, efficiency metrics aggregated by desired “team”, organizational unit, etc…).

In the context of FinOps, this work will typically focus on the cloud cost and usage data. This Capability relies heavily upon adequate data ingestion and data normalization capabilities. The results from the work for Data Analysis & Showback will typically be available for Chargeback & IT Finance Integration.

It is within the scope of this Capability to create the data repository of normalized, queryable data from which reporting, analysis, and visualization of cloud cost and usage will occur. Many of the optimization capabilities and alignment with other organizational processes and systems will likewise rely upon the data sources created by this Capability.

In many cases, organizations will rely upon the native cloud-provider tools to satisfy this capability. In other cases, third party tools will provide much of this functionality.

As cost showback is a fundamental aspect of FinOps, all FinOps domains should be considered and accounted for. Hence, reaching the highest maturity level should be considered a work in progress across the FinOps Domains.

Maturity Assessment

Responses showed organizations operating at a FinOps Run maturity, also had enabled all their personas to take advantage of self-service reporting for analysis of cloud cost data. FinOps Walk maturity was reflected in cohorts where cloud cost data reports were available across all personas but only a subset had the ability to leverage self-service reports for analysis. Restricted or no access to self-service reporting was reflected in organizations operating at a FinOps Crawl maturity

Crawl

Focus on reporting optimizations for services aligning to your highest spend. Often these will be compute right sizing and idle capacity.
Users are tracking costs at the account level.
No governance exists to manage wasteful spending.
Few if any Product Teams are using unit economics to measure their cost effectiveness.
Tagging is nascent or non-existent and tagging requirements are not fully defined.

Walk

FinOps practitioners are aggressively marketing optimization reports and can point to examples of engineers taking action to optimize spend.
Some of the more mature product teams have implemented unit economics and can use them to tell effective cost management stories.
Tagging is fully defined and communicated to the user community.
Rate optimization activities are tracked and benefits are exposed.

Run

Optimization reporting extends beyond core services and the FinOps team is able to share optimal architecture patterns.
There may be one or more options to see costs in a multi-account/multi-provider pane of glass.
Unit costs for key services are developed and tracked over time for efficiency.
Select Optimizations are governed as a compliance item (data expiration, elimination of waste, etc.).
Unit economics has gained traction and most product teams are engaged in related activities.
Users are tracking costs by tags
Tagging is governed and compliance is at high levels opening the doors for more sophisticated costing views.
Organization has reached a maturity point in rate optimization where coverage is high, while maintaining consistent savings; this may also go beyond standard compute and database rate reduction into lesser utilized services and potentially even custom rate negotiations have taken place.

Functional Activity

As a FinOps Practitioner, I will…

spend a significant amount of effort in collaboration with Engineering/Finance/Procurement/Product Management to build a cost reporting ecosystem which is aimed at helping consumers understand the important aspects of their spend, as well as, opportunities to optimize their spend.

As an Engineering Manager, I will…

take an active role in consuming and fully understanding cost reporting so that I may: set achievable cost objectives for my teams, meet KPIs that are meaningful to my business partners, manage development cycles (producing business capabilities vs.implementing optimizations), and provide accurate forecasting.

As a Finance/Procurement Manager, I will…

use the reporting ecosystem to develop a cost allocation model which accurately reflects the total cost of business capabilities, ensure that cloud cost models are allocating dollars to the desired level of the organization, and ensure integration with existing Finance processes.

As a Business/Product Manager, I will…

develop KPIs to measure the cost effectiveness in achieving my desired business outcomes. These KPIs will be used in frequent collaboration with my engineering counterparts.

Measure(s) of Success & KPI

Overall Tagging Compliance is 90% or above
The cloud cost reporting ecosystem becomes a fundamental aspect of the IT department
Most product teams are publishing information related to their unit economics
FinOps team can define desired level of commitment coverage vs. utilization

Inputs

Detailed Billing or Cost and Usage Report
Service Specific API pulls
Business Intelligence application/s
Consistent Marketing
Organizational Structure

Managing Anomalies

Anomaly Management is the ability to detect, identify, clarify, alert, and manage unexpected or unforecasted cloud cost events in a timely manner.

Definition

Anomaly Management is the ability to detect, identify, clarify, alert and manage unexpected or unforecasted cloud cost events in a timely manner, in order to minimize detrimental impact to the business, cost or otherwise.

Managing anomalies typically involves the use of tools or reports to identify unexpected spending, the distribution of anomaly alerts, and the investigation and resolution of anomalous usage and cost.

In the context of Cloud FinOps, anomalies are levels of spending that are different from the normal or expected spend.

Anomaly detection identifies data points, events, and/or observations that deviate from a dataset’s normal behavior. Detection tools & procedures allows the FinOps team to react quickly in order to maintain spend levels that an organization expects. To quickly find those needles in your cloud haystack, using automated, machine learning–based anomaly detection is key. These tools are generally offered by cloud providers and third party platforms.

Detected anomalies can be effectively dealt with only when cost allocation metadata or other operational metadata exists to determine who can best evaluate the anomaly for resolution.

Having Anomaly Detection tools that provide this granularity of cost by service, by account/project, by cost allocation tag, etc. is critical for triage.

Triage Anomalies is the practice of driving incoming work by priority so that the highest impacting alerts are handled first.

Resolving Anomalies typically involves some level of investigation and then either a change to adjust the environment, or to adjust the expectation of the cost of the affected scope. Another resolution may be to simply acknowledge the anomaly.

Example A

Imagine a new testing infrastructure created to accommodate a testing period for a new application. If this environment has not existed before, it may be flagged as anomalous because it varies from historical spending patterns. So while automated tools will see this as anomalous, it is expected from the perspective of the humans launching the new environment, and the anomaly can be dismissed after ensuring it’s within the expected new cost of the new environment.

The concept “inform to ignore” has been applied, which represents gathering information to justify taking no action.

Note: Anomalies may not directly result in a change in cloud spend.

Example B

If a team starts using a new cloud service offering, replacing the usual one, you can learn of this through anomaly reports that show your cost by cloud service offering. Reporting & Tracking Anomalies is a function of anomaly management. You must also be able to track anomalies, record impact to spend, and resolution. Both push notifications or data visualization can be used as methods to report & track anomalies.

Considerations alongside Budget Management Capability

Part of your anomaly triage process may include a postmortem step to understand if the anomaly detection and resolution has or will impact variance to overall budget. Having a strong communication/collaboration between Engineering and Finance if anomaly causes an unfavorable impact to budget is critical to making near-real time decisions. See the Budget Management Capability for more details.

Considerations alongside FinOps Intersections with Other Frameworks

Managing anomalies will also be an important touchpoint between the FinOps function and the Security function. Security anomaly detection tools may detect problems which do not dramatically affect cost, and vice versa.

For example, anomalies that detect a new service can be very significant for companies that require sign-off—for security or compliance reasons—before using new services. See the FinOps Intersections with Other Frameworks Capability for more context and information.

Maturity Assessment

Organizations operating at a FinOps Run maturity was reflected by practitioner respones that indicated it takes hours for their teams to be aware of unexpected cost increases. Responses indicating that it takes up to a day or multiple days for teams to be aware of cost anomalies were cohorts operating at a FinOps Walk maturity. Responses indicating teams were unaware of unexpected cost increases for a week or more were reflected in organizations operating at a FinOps Crawl maturity

Crawl

Understanding that anomalous spending might occur
Manually checking for anomalous spending
Reacting to anomaly active post billing
Using budget alerts vs an anomaly detection service
Limited granular detection minimizing context insights
Unexpected spending is manually investigated and routed when necessary to a suspected owner for resolution

Walk

Some form of automated detection or reporting or tooling (usually provided by the Cloud Service Provider in use
Use of anomaly detection tooling in most or all departments and teams
Context-relevant thresholds (percentage of spend change, single item spend amount ceilings, forecast breach alerts, etc.)
Cost allocation metadata provides context to segment anomalies
Unexpected spending automatically routed to responsible teams
Create initial KPIs – # of alerts & spend associated with alert

Run

Mature Anomaly detection tooling embedded across the organizations
Automated handling of anomalous spending alerts, with appropriate severity
Connected to event management or ticketing systems.
Granular context-related anomaly alert thresholds linked directly to service components
Alert thresholds iteratively updated in line with service lifecycles
Analysis results in full RCCA post-mortem / future prevention

Functional Activity

As someone in a FinOps Practitioner role, I will…

establish requirements for anomaly detection tool selection that is appropriate for cost monitoring and capable of defining, refining, detecting and alerting unexpected cloud spending events (cost anomalies).
work with stakeholder teams to establish anomalous detection thresholds and reporting/notifications frequency
document and communicate anomaly detection mechanism and thresholds to all stakeholders
ensure that anomaly detection is tied appropriately to cost allocation metadata
generate reports that surface all and/or alerted anomalous spending

As someone in an Engineering/Operations role, I will…

ensure anomaly detection tooling has access to raw spending data at appropriate real-time granularity and frequency
ensure that my team is aware of the correct processes and actions to respond to and address a cloud cost anomaly
provide feedback to FinOps on the correctness of established thresholds and detection coverage
determine the cause and resolve issues with anomalies

As someone in a Finance role, I will…

help establish anomalous percentage thresholds that trigger financial review of budget to actual
provide contingency capacity within forecasts for cloud costs to accommodate anomalous spending trends that align with established thresholds

Measure(s) of Success & KPI

The count of anomalies within a period of time; including consistent identification of a proper anomaly
Spend associated with alert within a period of time; represents total anomaly detection
Time to detect the anomaly; this is the time it takes from the anomaly reporting to someone acknowledging it.
Duration of the anomaly; the length in time for resolution of the anomaly
Time to investigate and address an identified anomaly; time of investigation of a true anomaly is real time wasted cost in many cases
Educating teams on understanding how variable types of cloud spending can be by product, as to better define what is anomalous and who is accountable
The count of actioned anomalies and spending amount avoided (to nearest billing period)
The count of unactionable anomalies and categorized but justification to ignore (i.e. new service, performance testing, customer peak, false alert).
Tracking number of alerts suspended (ignored) to identify teams who might not be adhering to protocol or policy

Inputs

Cloud cost and usage data (API or File based)
Anomaly detection tooling
Cost allocation metadata established and aligned to the organization’s reporting needs
Anomalous spend notification to stakeholder teams
Stakeholder real-time visibility into cost and usage reporting data
Documentation of triage process and expectation of personas

Managing Shared Cost

Learn how to appropriately split cloud costs that are shared and build a complete picture of how your organization uses various cloud costs across its products, departments, and teams.

Definition

A foundational Principle of FinOps is: “Everyone takes ownership for their cloud usage”. The true key to understanding total cost of ownership is built upon transparency and accuracy, but unallocated shared costs hinders both of these. Without appropriately splitting costs that are shared, engineers and product managers lack a complete picture of how much their products are really costing.

The goal of Cost Sharing can be full allocation; however it can also be the adoption of an informed ignore approach. The latter is where a business decision is explicitly made about shared platform services coming from a central budget versus a from a portion of each cost center’s budget.

\Almost every organization has cloud costs that need to be segmented and allocated to business departments; the cost of running networking services, Support costs which benefit all Engineering teams or simply the cost of service resources from a cloud provider for which they do not (yet) support tagging/labelling.

As organizations increase their adoption of public cloud, without a strategy and processes in place to assign shared cloud resource costs to specific business owners, it becomes increasingly difficult to understand how to properly and fairly allocate costs, and to actually forecast and budget.

Maturity Assessment

Practitioners in the segment that were operating at a FinOps Run maturity indicated they employed a weighted cost sharing model or had developed a custom model for managing shared costs. Responses showed most practitioners had adopted strategies for managing shared cost with a relatively significant segment operating at a FinOps Crawl maturity indicating they use a fixed sharing model or did not manage shared costs

Crawl

cost allocation metadata established enabling 80% of spend being allocated unallocated costs
shared costs are not identified beyond common Support charges
product owners and engineers are unaware of their portion of shared platform/service costs resulting in reduction in accuracy of forecasting and budgets
shared platform owners are not able determine costs generated by internal customers

Walk

robust cost allocation metadata established with minimal or no unallocated costs
shared platform owners are able to showback costs generated by internal customers
product owners and engineers are aware of their portion of shared platform/service costs and include these costs
shared cost process documented to enable and manage expectations of “fair share” onboarding of new cost centers/business units
shared costs are split using an appropriate distribution model(s) (proportional, fixed, even-split) across the entirety of the organization

Run

product owners and engineers are aware of their portion of shared platform/service costs and include these costs as part of their forecasting & budget planning
shared platform/service owners are able to fully allocate and chargeback costs generated by internal customers
shared platform/service owners are able to recover costs generated by internal customers and perform accurate forecasting/budget planning
shared cost recovery reflects commercial discounts/commitment based discounts
bill reconciliation process for tracking of shared cost changes including support for credit adjustments over charged periods.
shared cost process automated to enable “fair share” onboarding of new cost centers/business units
shared costs are distinguished from dedicated costs

Functional Activity

As someone in a Business/Product role, I will…

identify shared services/infrastructure which are part of my product and engage with stakeholder FinOps personas to determine how to
understand cloud providers common use cases, and have a basic understanding of billing and pricing models

As someone in a Finance/FinOps role, I will…

understand the basics of how cloud computing works, know the key services offered by cloud providers being used, including their common use cases, and have a basic understanding of billing and pricing models
work with Finance to ensure required allocations are implemented to support financial reporting so shared costs can be assign to specific business owners.
build processes and define rules to enable full allocation of shared costs.
allocate the shared costs based on the defined rules and create stakeholder persona reporting
understand available cost sharing models (fixed, proportional, even-split) and determine which models should be applied based on the use case

As someone in an Engineering/Operations role, I will…

architect solutions that support segmentation of cost such that shared costs can be allocated to specific business owners
know much of all the shared platform costs that have occurred for which my team is responsible

As someone in an Executive role, I will…

Measure(s) of Success & KPI

Shared platform/service owners are able to fully recover costs generated by internal customers
The majority of cloud costs can be categorized and allocated directly allocated to an organizational unit. According to the FinOps Community of Practitioners, comprehensive allocation translates to at least 80% of cloud spend is allocated for a FinOps practice operating at a Crawl maturity level; and 90% for a FinOps practice operating at a Run maturity level
Ability to surface the percentage of cost that cannot be categorized and allocated directly
Effective reporting on shared costs showing trends to inform forecast and budget planning
Effective reporting that identifies spend drivers and responsible stakeholder teams of shared costs that may go underlooked by current enterprise accounting policies
Shared cost policies and design patterns socialized among stakeholder personas

Inputs

Adjusted and amortized cloud cost & usage data
Cost allocation constructs aligned to the organization’s reporting needs
Stakeholder real-time visibility into cost and usage reporting data
Shared resources (networking, shared-storage, K8s Node, etc)
Platform services (logging, database, security, etc)
Enterprise level support
Enterprise level discounts
Licensing, 3rd party SaaS costs

Forecasting

Understand forecasting cloud costs – how future cloud infrastructure and application lifecycle changes may impact current budgets and influence budget planning and future cloud investment decisions.

Definition

Forecasting is the practice of predicting future spending, usually based on a combination of historical spending and an evaluation of future plans, understanding how future cloud infrastructure and application lifecycle changes may impact current budgets and influence budget planning and future cloud investment decisions.

This capability also involves collaboration between stakeholder teams like Finance, Engineering, and Executives to build agreed upon forecast models and KPIs from which to establish budgets that align with business goals.

Unfortunately, there is no one forecasting method that fits all situations.

Cloud spend is variable which is inherently difficult to predict. Specifically engineers can start workloads at any time typically without having to go through a procurement process.

Accurate financial forecasting depends on an organization’s other FinOps Capabilities also being robust in order to provide accurate data as input. For example, a foundational element of this capability is the ability to fully categorize and allocate cloud costs.

There is a potential gap between engineers, finance, and procurement where finance has financial reporting responsibilities, and procurement has accounting responsibilities, and both need assistance from engineers and leadership to meet these obligations. When Finance, Engineering, and Executives build models to forecast cloud spend reliably and accurately, cloud cost forecasting will inform investment and operational decisions to accelerate an organization’s growth.

You should understand the basics of how cloud works, specifically you should know the key services around compute and storage for the cloud providers your organization is using and their billing and pricing models. You will also need to understand financial processes around forecasting, budgeting, procurement, and allocations.

Depending on the cloud providers your organization is using, you can gain some of this knowledge through training and certifications. Specifically for AWS, we recommend the AWS Cloud Practitioner certification, for Google the Google Cloud Platform Fundamentals course, and for Azure, the Azure Fundamentals learning path.

Forecasting Methodologies

Trend-Based

Uses historic trends to forecast future spend. Ideally this takes seasonality into consideration. Seasonality can include annual peaks during holidays but also daily peaks when more people are using a service during specific hours of the day. Trend based forecasting will not be able to capture out-of-band events such as launching a new product or feature, launching in a new country, or the effect of TV commercials on consumer behavior.

Driver-Based

Uses Key Performance Indicators (KPIs) to forecast the effect on business results. KPIs can be things like active accounts, widgets sold, ad impressions and so forth. The business will forecast the KPIs factoring in organic growth, like more people on the Internet, and inorganic growth, like new launches and marketing efforts. Cloud workloads that scale based on a specific business KPI are forecasted by applying the KPI growth on actual spend. Driver based forecasting will not be able to forecast workloads that don’t exist in the cloud yet but are planned to be launched in the future.

Rolling Forecast

To predict next month, quarter, and year. It allows companies to adjust their plans based on any shifts in the business such as economic changes, COVID as an example. As the economy changed a rolling forecast would be adjusted to forecast that change and allow the company to alter their plans with the new data.

Static Forecast

Predict for the fiscal year only with no adjustments.

Special Projects

Are planned cloud workloads that currently do not yet exist in the cloud. Their cost needs to be estimated by engineers and layered into trend or driver based forecasting to get a complete picture of future cloud spend. Special projects can also be costs that will not materialize on the cloud bill like licensing fees, professional services, or small workloads running on other cloud providers where automation isn’t feasible.

Maturity Assessment

Most respondents indicated they were still working to improve accuracy of their forecasted spend with organizations that had a forecasted spend within a 5% variance of their actual cloud spend were also in the segment operating at a FinOps Run maturity.

Crawl

a variety of cloud cost data-sources and tools are used for forecasting by stakeholders across the organization
forecasts are created manually and/or ad-hoc
forecasts are trend-based
forecasting variance analysis is done manually
limited/aggregate forecasting visibility (only by business unit or cost center)
Engineering/Operations teams are not involved with the creation of cloud cost forecasts or tracking of discrepancies from forecasted spend

Walk

forecast costs tracked against actual usage and used to establish budgets
forecast is inclusive of cloud rate optimization and commitment-based discounts
forecast models are rolling and trend-based
forecast updates are done on a regular cadence but not automated
stakeholder teams (Executives, Engineering, Finance) have access to cloud cost forecasting data
cloud cost forecast data is used to supplement back-end accounting system data
regular review cadence by FinOps team of forecast thresholds and trends with stakeholder teams

Run

global policy for applying allocation metadata to prevent unallocated cost
forecast tracked and updated against discount-adjusted, amortized cloud usage
forecast models are a combination of rolling, trend-based and driver-based
forecast is inclusive of usage optimization opportunities
forecasts aligned to the organization’s allocation constructs being used across the organization for reporting cloud costs
granular forecasting visibility (by business unit, cost center, team, product, service, etc …) in the context of organizational KPIs
stakeholder teams (Executives, Engineering, Finance) have real-time visibility into a single source of truth for how cloud usage is impacting forecast trends and budgets
integration and automated data flow between cloud cost forecast data and back-end accounting systems used for broader organizational reporting

Functional Activity

As someone in a Business/Product role, I will…

develop product centric KPIs to measure the cost effectiveness in achieving my desired business outcomes
establish forecasting threshold variances that are in alignment with the product-line that i own
use these KPIs to inform forecast models in collaboration with my engineering counterparts

As someone in a Finance/FinOps role, I will…

establish requirements for when forecasting is due and how frequently forecast updates are needed
generate granular forecasts with reasonable accuracy
help to establish forecasting KPIs that are in alignment with business goals
explore optimization opportunities with teams that are forecast to overspend
provide forecast data for cloud costs to enable stakeholders to create budgets
provide granular reporting to teams on forecasted spend by different business-centric dimensions
provide reporting on budgets vs actuals vs forecast to establish trends and compare against variance KPIs

As someone in an Engineering/Operations role, I will…

monitor for cloud spend forecasts exceeding budgets
work with FinOps stakeholders to identify actionable optimization opportunities to avoid forecasted overspend
get approval for planned changes which will have a negative impact to our cloud spend projections / budgets

As someone in an Executive role, I will…

be aware of cloud cost forecasts and monitor for impacts to the business
establish forecasting threshold variances that are in alignment with business goals
manage competing priorities for active project timelines when forecasted spend impacts budgets for high-priority initiatives
ensure successful communication between the FinOps team and Business Units

Measure(s) of Success & KPI

The majority of cloud costs can be categorized and allocated, including shared costs. According to the FinOps Community of Practitioners, comprehensive allocation translates to at least 80% of cloud spend is allocated for a FinOps practice operating at a Crawl maturity level; and 90% for a FinOps practice operating at a Run maturity level
Forecast models leverage discount-adjusted, amortized cloud usage data
Forecast cost vs actual cost trends within established percentage threshold of variance. According to the FinOps Community of Practitioners, acceptable levels of forecasting accuracy translates to a maximum 20% variance from actual spend for a FinOps practice operating at a Crawl maturity level; a 15% variance for a FinOps practice operating at a Walk maturity level; and 12% variance for a FinOps practice operating at a Run maturity level.
Stakeholder notifications for forecast variance threshold exceeded & risk of budget overspend
Forecast frequency that includes intermediate forecasts to update budgets based on business drivers
Teams and Business Units are responsible for managing their budgets based on forecast data

Inputs

Adjusted and amortized cloud cost & usage data
Cost allocation constructs aligned to the organization’s reporting needs
Commercial & commitment based discount data
Cost anomaly trends
Forecasting models and tooling
Stakeholder real-time visibility into cost and usage reporting data

Budget Management

Budgeting for Cloud is a process of collecting estimated expenses for a specific period of time. Decisions on how to operate as a business, what to invest in and other strategic decisions are made based on budgets.

Definition

Budgeting for Cloud (or other IT expenses) is a process of collecting estimated expenses for a specific period of time. Decisions on how to operate as a business, what to invest in and other strategic decisions are made based on budgets. If actual expenses do not match the budget, it can impact the operations and other decisions that were made based on those budgets.

The term ‘favorable to budget’ means that there are less expenses than as planned in the budget.

The term ‘unfavorable to budget’ means that there are more expenses than as planned in the budget.

It may sound like being favorable to budget is ideal, and while it is not necessarily a bad thing, it is far from ideal. Had the budget more accurately reflected there being less expense, the business might have made different decisions to invest in more or grow in different areas.

Budget Management contains the acts of:

Accumulating the estimated expenses for a specific time period.
Tracking actuals and forecasting remaining spend and comparing to the budgeted amount to identify material variances to budget that are favorable or unfavorable.
Investigating the causes of variances to budget.

Maturity Assessment

Most respondents indicated they were still working to keep their budgets aligned with their actual cloud spend; organizations staying within a 5% variance of their budgeted cloud spend were also in the segment operating at a FinOps Run maturity.

Crawl

Budgets set at the enterprise/top-level and not broken down into smaller units.
Engineering teams are aware of the budget. Finance tracks actuals to budget at least quarterly.
Budget process is largely handled between finance and business/product leaders but
not largely understood by all.

Walk

Cloud spend budget is broken down into departments/product teams and accumulated to calculate the enterprise/top-level spend budget.
Engineering and Finance teams meet monthly to discuss actual expenses to budget and reports are created monthly.
Review process exist to monitor, alert and handle budget under/overruns.
Variances to budget are investigated monthly.

Run

Engineering teams proactively predict the cost impact of changes and raise awareness to budget leaders when material impacts are expected.
There is strong communication/collaboration between Engineering and Finance and reports are updated and variances are investigated automatically.
Budget under/overruns are predicted in advance allowing teams to respond appropriately.
The process for budget setting/adjustments is easily understood and followed by all teams.

Functional Activity

As someone in a Business/Product role, I will…

Understand my business/product strategy and that it is reflected in the budget estimates that we prepare
Work with Finance and Engineering teams on budget planning to gain their input
Guide teams on importance to maintain cloud spend within budgets

As someone in a Finance/FinOps role, I will…

Work with budget leaders in budget planning
Help monitor cloud spend vs budget
Provide reporting on budget vs actual vs forecast
Alert teams who are projected to materially overspend or underspend
Work with teams who are forecast to overspend on possible optimisations
Communicate to appropriate leadership when material underspend to budget is expected so that they can make appropriate decisions

As someone in an Engineering/Operations role, I will…

Get approval for planned changes which will have a negative impact to our cloud spend projections / budgets
Monitor for cloud spend forecasts exceeding budgets (See: Forecasting)
Assist budget leaders with planning on future cloud spend
Allocate time to optimise cloud spend to maintain budget

As someone in an Executive role, I will…

Guide teams on importance to maintain cloud spend within budgets
Stay up to date with actuals to forecast so that I can make appropriate decisions

Measure(s) of Success & KPI

Overall Budget vs Actuals
- Measuring accuracy of budget estimations
- Favorable variance to budget (Potential benefit)
- Unfavorable variance to budget (Risk)
Expense Burn Rate
- Rate of expense incurred over specific period of time (daily, weekly, monthly)
- Can be used to help forecast expense to budget
Variance to budget are identifiable/understood
- What caused the variance?
- Why did it happen and will it happen again?

Inputs

Department/Product budget estimates
Forecasted cloud spend
Actuals from cloud bill
Usage/Rate Optimisation recommendations

Get Involved

Get involved and contribute to the community by sharing your real world experiences related to this Capability in the form of a story or providing a playbook for how you have implemented best practices in your organization. Your real world experiences can be provided in the context of:

one or more cloud providers
the types of cloud services used (compute, storage, database, etc…)
describe a combination of tooling, platform or vendor, and processes including KPIs
the industry the organization belongs to
the complexity of the organization (global enterprise, start-up, etc…)
the [FinOps personas](https://www.finops.org/framework/personas/) involved / organizational roles

Workload Management & Automation

Workload Management & Automation focuses on running resources only when they are needed, and creating the mechanisms to automatically adjust what resources are running at any given time.

Definition

Workload Management & Automation focuses on running resources only when they are needed, and creating the mechanisms to automatically adjust what resources are running at any given time. This Capability is intended to give FinOps teams the ability to match supply to demand most efficiently, and effectively optimize cloud usage through measurement of workload demand and provisioning capacity dynamically.

Maturity Assessment

A large number of respondents indicated the had little automation or no plans to automate. Practitioners taking advantage of opportunities to automate activities such as tagging policies, budget alerting, storage lifecycle policies, containerization, and discounted rate options were in the cohorts operating at FinOps Walk and Run maturity

description of the characteristics of each maturity level (crawl, walk, run) for this Capability in the context of the organization’s FinOps practice.

Crawl

Manually assign tags to all resources, e.g. Environment = Test/UAT/Dev.
In general practice, Non-production instances not needed post working hours, so encourage engineers to manually stop and start the non-production instances when not needed.
Build dashboard of resource state for respective environments.

Walk

Schedule automation to stop & start resources based on the tags.
Automatically trigger alerts if resources don’t have the specific tags.

Run

to be filled in by community members with real-world experience here

Functional Activity

As someone in an Engineering/Operations role, I will:

Stop the non-production resource by end of day (EOD)
Start the non-production resource as business starts
Make sure the required tags (Environment in this case) assigned to all the resources
Work with automation team to automate stop & start the resources
Introduce another tag to provide the exception to the schedule
- a. e.g.: StopResourceEOD: Yes/No,
- b. If No, then another tag with justification, PurposeToAvoidStop: UAT is in Progress
Work with automation team to auto assign the required tags
Build automation to send communication in advanced with list of resources being affected during business hours, to respective resource owner

As a FinOps Practitioner, I will:

Work with application owner to assign the missing tags to the resources
Automate the communication of the statistics of the affected resources by the automation, non-tags resources

Measure(s) of Success & KPI

Here are some crowdsourced measures of success from our community:

Make sure resource dashboards build based on the specific tag values.
Create threshholds for cost and usage that meet your requirements for balancing development and production workloads. For example, an organization might want to set a threshhold or alert to help prevent non-production usage cost from exceeding the 30% of PROD server cost.
- Additionally, this same organization might create a measure of success where the critical testing phase cost shouldn’t exceed more than 30% of total non-production spending.

There are likely many more cases and examples out there, so please get in touch with recommendations, changes, and feedback.

Inputs

the information used that contributes to the measure(s) of success listed above; information here may include specific datasources, reports or any relevant input

Managing Commitment Based Discounts

Spend-based commitment discounts and resource-based commitment discounts are the most popular rate optimizations that cloud service providers offer. Learn how to navigate CSP native tooling and FinOps platforms to better plan, manage, and benefit from these types of discount constructs.

Definition

Cloud services have different approaches that leverage spend commitment to offer discounts on services. These vary from customized commercially negotiated discounts, to spend-based commitment discounts like AWS Savings Plans, resource-based commitment discounts like Google CUDs and others.

Spend-based commitment discounts and resource-based commitment discounts are the most popular rate optimizations that cloud service providers offer. This is partially because CSP native tooling and FinOps platforms enable you to plan, manage, and benefit from these types of discount constructs.

Each cloud service provider has a slightly different offering with its own specific rules on how it works and the discounts it provides. You must also consider the implementation models that organizations use, based on their needs, and how the overall process should work inside an organization.

Altogether the implementation of these strategies drives an organizations Effective Savings Rate (ESR). It is important to note that under utilization of a commitment based discount would also negatively impact ESR as would significant usage not covered by discounts.

Maturity Assessment

Responses indicate that organizations operating at a FinOps Run maturity utilize high levels of available cloud discount constructs to improve costs rather than pay on-demand pricing. Responses showed most organizations had adopted some strategies for using cloud discount offerings with the majority in cohorts operating their cloud cost management practices at a FinOps Crawl and Walk maturity

Crawl

Analysis and purchases are performed across many business units in an adhoc manner
Purchases may be made in ways that do not provide the greatest overall discounts to the business
Purchasing or management done reactively when spending is too high or someone gets upset about not hitting a forecast/budget.
Tech teams autonomously making commitments without considering WACC/NPV or other finance centric considerations.
Finance folks buying without proper understanding of planned infrastructure changes

Walk

Centralized analysis and purchasing occurs in a semi-regular cadence with input from both Tech + Finance.
Alerting when commitment utilization declines, stops being used, or needs attention due to deviation from established norms
Regular evaluation of long term business technology plans
Constant evaluation of new releases/updates from Cloud Providers
Adhoc reporting on KPI’s

Run

Frequent purchase cycles occur with automated allocation of discounts according to business requirements
Metrics driven management of when to make changes and a bi-drectional connection between rightsizing/utilization/refactoring and the proper commitment type and term
Regular reporting occurs on KPI’s

Functional Activity

written for each persona responsible for the functional activity and processes encapsulated by his Capability. each one should be associated generally to one of the FinOps Phases (Inform, Optimize, Operate). for example:

As a [FinOps Persona], I will [functional activity] so that [desired outcome] is achieved.

Measure(s) of Success & KPI

Ability to measure the overall effective savings rate of Cloud Rate Optimization efforts for both technology-based and monetary-based commitment discounts
For resource-based commitment discounts, maintaining a utilization upper-waterline around 80% for steady-state usage
For spend-based commitment discounts, purchasing commitments with at least 90% savings per dollar of commitment for an established threshold of peak variable usage
Analysis and purchase decisions for commitments are made in the context of interruptable/batch/highly variable workloads
Ability to identify unused commitment based discounts with daily resolution
Ability to notify stakeholder teams about expiring commitments with sufficient time to plan a new purchase
Purchasing of commitment based discounts are viewed as investments by stakeholder teams like Execs/Productment/Finance; the investment is the cost of the commitment over the entire period, and the return is the savings provided
Hybrid purchasing strategy that Aligns commitment terms with infrastructure workload characteristics and lifecycle
Purchasing commitments that deliver more than 10% return on investment
Mitigate risk by purchasing commitments with a break-even within 9 months
Analysis and management is done centrally using a holistic view of the organization’s cloud estate and not at each individual cloud sub-account level
Analysis for making commitment purchases is supplemented with planned infrastructure and/or workload capacity changes
Committment purchases are spread over the year to allow for flexibility by always have some % of commitments expiring; this enables re-evaluation of commitment levels at regular intervals informed by forecasted future usage
Analysis and purchase decisions for commitments are made in the context of any negotiated commercial discounts offered to enterprises by the cloud service provider in exchange for overall cloud spend

Inputs

the information used that contributes to the measure(s) of success listed above; information here may include specific datasources, reports or any relevant input

Resource Utilization & Efficiency

Optimizing resource utilization and efficiency is about making sure you are getting sufficient business value for every cloud cost. Practitioners can do this by creating the means of collecting and viewing cost and usage over time, and by building both manual and automated policies to help teams optimize how they use cloud services across the infrastructure.

Definition

In context to FinOps, resource utilization is about ensuring there is sufficient business value for the cloud costs associated with each class or type of resource being consumed. It is necessary to observe a resource’s utilization over time to understand if the performance, availability or other quality metrics are of value for the expense incurred.

For compute resources, there may be times when it is deemed that for performance or availability gains, average utilization may need to decrease and the extra expense incurred is worth the value creation the resource provides. Or the opposite may be true and performance expectations can be lowered to improve cost. For these decisions to be made, resource utilization, efficiency and cost must be looked at together.

By comparison, for storage resources, it is necessary to estimate the latent inefficiency in the stored data, and by extension the potential gross savings that can be realized by removing, or rightsizing, that inefficiency. Keep in mind that different data sets have unique latent inefficiencies and require tailored approaches. For example, highly compressible (yet uncompressed) data has relatively high latent inefficiency, whereas encrypted data has relatively low (or no) latent inefficiency. And data that is infrequently accessed but stored in a high cost, high performance storage class (or tier) also has relatively high latent inefficiency. It is then necessary to estimate the cost of applying data efficiency infrastructure to thus realize net savings, along with the performance and availability impact of that infrastructure to ensure it meets the needs of users and applications.

The management of resource utilization and efficiency translates into identifying whether there is scope to reduce resource costs while maintaining the required performance and, if there is, making the changes required where it is economically worthwhile to do so.

Maturity Assessment

Respondents operating at a FinOps Run maturity optimize cloud resource utilization through enforced policies, where responses showing a hybrid approach, including formalized engineering processes surfaced cohorts operating at a FinOps Walk maturity

Crawl

Has some visibility into resource utilization and efficiency using one or more sources such as cloud billing data, infrastructure monitoring tools, data efficiency tools, cloud provider insights/tools.
Define a business efficiency metric – i.e. a metric that speaks to your business that can be used to measure how efficient a resource is

Walk

Able to put a $ value against costs that can be avoided by rightsizing underutilized or inefficient resources.
Able to measure the cost required in performing the action, summing costs across people, infrastructure, and paid solutions. For example: “it will cost 50 man hours to make this change at an hourly rate of X”, or “it will cost $0.01/GB for a data efficiency platform to surface the savings potential of the data”.
Measure the cost required in performing the action – i.e. it’ll cost 50 man hours to make this change at an hourly figure of xyz.
Takes manual action to review recommendations and take appropriate action(s) to increase efficiencies.

Run

Uses cost and utilization data to drive automated processes to either:
- Alert humans to analyze. Outcomes could be to update the architecture/sizing of resources deployed or suppress the notifications for these resources as there are good reasons for running at levels that look suboptimal on the surface.
- Resize or stop/start compute resources
- Apply tailored storage class and data efficiency changes

Functional Activity

As someone in a Business/Product role, I will…

Clearly define service KPIs so that engineering are able to design and/or purchase efficient services within the defined boundaries
Provide demand forecasts and information on the demand pattern profiles (daily/weekly/monthly/cyclic)
Establish the business goals for the objective – i.e. release to customers as quickly as possible, reduce the effective storage rate by >20%, release to customers w/ an availability of 99.99%, etc. (aka Business Value Creation!)

As someone in a Finance/FinOps role, I will…

Highlight any opportunities to increase utilization and efficiency and work with the teams to review feasibility of alternative options
Help create the reporting to track and report on the impact on value of underutilization and inefficiencies
Partner with the Engineering organization to establish budgetary & efficiency targets

As someone in an Engineering/Operations role, I will…

Architect and/or purchase services with the KPIs and forecasts guiding decisions
Use elasticity best practices to automatically scale resources with the workload demands
Build and/or purchase automation to output measure and metrics needed to measure utilization and efficiency
Regularly review utilization and efficiency of resources, and identify opportunities to improve

As someone in an Executive role, I will…

Deliver the business value creation vision and strategy
Provide executive level support in the defined KPIs, establishing credibility in the FinOps efficiency program

Measure(s) of Success & KPI

Data efficiency is applied to at least 50% of stored data (i.e. net savings coverage is >50%)
Effective $/GB/mo storage rates are reduced by at least 30% relative to the S3 Standard baseline.

Inputs

the information used that contributes to the measure(s) of success listed above; information here may include specific datasources, reports or any relevant input

Measuring Unit Costs

Cloud unit economic metrics enable you to determine the revenue you’ll gain from a single unit of your business and the cost associated with servicing it, revealing the business value of your cloud spend.

Definition

This Capability is about developing metrics that reveal the business value of your cloud spend. By calculating cloud spend for total revenue, you can attach growth in cloud spending to your overall business growth. When these are in line, it makes sense that cloud spend isn’t wasted. When cloud spend is growing faster than the business, there may be cause for concern. For a customer-facing application, that unit might be a user or customer subscription; for an ecommerce platform, it might be a transaction; and for an airline, it might be a seat.

When practitioners address measuring unit costs, it’s often in the context of Cloud Unit Economics. Our practitioners define Cloud Unit Economics 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 overall. Cloud Unit Economics achieves these 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, practitioners can determine where cloud operations break even and begin to generate a profit. This is an important concept in economics overall and it’s one of the most effective ways to make data-driven business decisions regarding your cloud investment. For further details on defining, implementing, and building upon Cloud Unit Economics with your FinOps teams, please check out our playbook on implementing the Capability.

Maturity Assessment

Respondents operating at FinOps Run maturity, incorporated measuring unit costs across more areas of their business to understand the value cloud was providing. FinOps Walk and Crawl maturity was reflected in cohorts limiting their use of unit cost metrics.

Cloud Unit Economics can be implemented in many different ways, depending on the size of organization and the scale of its cloud spend. From research by our community, and according to the Cloud FinOps book, 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 to assess maturity level of how the organization is adopting unit economics.

Crawl

Cloud-only Cost-per-customer: 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, Software-as-a-Service (SaaS), Licenses-based Cost-per-customer: 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-based Cost-per-customer: Advanced teams bring 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.

Functional Activity

Do what’s right for your organization

In some cases, engineering might play a more central role in your FinOps organization, and you can leverage engineering time to produce the necessary metrics to determine measurements like Cost-per-customer. 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.

The following table maps functional input and output activities related to cloud unit economics by persona:

BUSINESS – Executives

INPUT: A CTO/ CIO / CFO should own the initiative of Unit Economics and determine scope as it relates to coverage of Products
OUTPUT: Actioning on business decisions as a result of cost metric data, define frequency of reviewing unit cost and determine benchmark thresholds

BUSINESS – Product Owner

INPUT: VP of Product / Product Owners should collaborate with Finance to determine key product metrics
OUTPUT: Support solutioning automation and identify blockers to outputting metrics, define frequency of reviewing unit cost and determine benchmark thresholds

TECHNOLOGY – Engineering and Operations

INPUT: VP Engineer collaborate with Product Owners define input requirements for metrics to best determine how to collect metric data from systems
OUTPUT: Actioning on business decisions as a result of cost metric data

FINANCE – Finance/Procurement

INPUT: Finance should collaborates with Product Owners to determine key product metrics
OUTPUT: Integrate cost allocation with cost metrics, determine if spend is increasing due to waste or due to growth in the business and determine if cost variances are ‘good’ or ‘bad’

FINOPS – FinOps

INPUT: FinOps should be aware of executive scope and identify gaps in cost allocation alignment to strategy
OUTPUT: Use data and analysis to determine if spend is increasing due to waste or due to growth in the business and determine if cost variances are ‘good’ or ‘bad’

Measure(s) of Success & KPI

Cloud Unit Economics measures of success will differ company to company.

An example KPI that could fit most cases could be how one a team stores customer data: cost-per-GB. Measuring cost-per-GB alone sets up initiatives to optimize storage costs, such as engineers figuring out a new way to further compress the data, e.g. 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.

This is one example of many. We welcome additions to build out all the possible ways to measure the efficacy of a cloud unit economics practice.

Inputs

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.

Data Ingestion & Normalization

Data ingestion and normalization in the context of FinOps represents the set of functional activities involved with processing and transforming data sets that inform cloud cost and usage.

Definition

Data ingestion and normalization in the context of FinOps represents the set of functional activities involved with processing/transforming data sets to create a queryable common repository for your cloud cost management needs. In this context, data ingestion and normalization occurs when bringing together cloud billing data, cloud usage data, cloud utilization and performance data, on-premises CMDB or ITAM data, business-specific data, and other data points from a variety of cloud providers and IT data repositories to create a collection of cost and usage information which can be queried to support and enable the FinOps Capabilities.

Effective FinOps practice requires access to regular streams of detailed usage, utilization and cost data, which can be categorized and analyzed to drive decision making. Unlike the world of on-premises data centers, there is no shortage of data on cloud usage. Cloud vendors produce massive amounts of very granular usage and cost data on which to base a FinOps practice. Monitoring platforms, security platforms, and business operations applications can also provide data that will inform on utilization, location, value and usage, oftentimes at similar levels of volume and granularity.

So while the issue many data centers experienced was a lack of detailed data, the challenge faced by cloud users is oftentimes that there is too much. An effective data ingestion and normalization strategy should strive to provide the FinOps team with the right combination of data from:

the right source systems
at the right timeliness to support the cadence of decision making
at the right level of granularity to support aggregate reporting and drill down investigation
with the appropriate standardization, augmentation, normalization, etc.

The strategy for data ingestion will be driven largely by the needs of the reporting, cost allocation and optimization reporting needs. Data required to make decisions at a business unit level will not be in need of as much detailed or granular information.

FinOps teams which manage or allocate costs at a resource level may require multiple sources of data to gather resource information for some cloud providers which don’t natively provide it.

The data ingestion and normalization challenge grows as the complexity and diversity of the data increases. The level of granularity, the consistency of cost and rate metrics, mismatches between similar or analogous services, application of various types of discounts, the application of metadata to resources and hierarchies, and many other differences between the billing and usage data provided by the cloud providers can all provide challenges, even before considering the regular change and huge volume of data provided.

Maturity Assessment

Responses showed there was a shift to supplement cloud billing data with non-cloud centric data. Cohorts taking advantage of business, performance observability and CMDB data sources were operating at a higher FinOps Walk maturity level. FinOps practitioners taking their cloud cost management to the next level by including sustainability data were operating at a FinOps Run maturity

Crawl

Match granularity of cost and usage data on incoming source files, though reporting separately
Ensure metadata being applied to hierarchy and resources is consistent across cloud providers and data sources

Walk

Ingest data from multiple data sources, normalizing cost metrics
Use of a third party FinOps platform to normalize data
Ability to create consistent reports for different clouds, possibly using different reports
Integration of performance/utilization data

Run

Consistent data lake of usage, cost, performance, utilization data
Ability to run single report with multiple clouds

Functional Activity

As someone in the FinOps team role, I will…

Determine the list of data sources required to fulfill my current reporting and operational needs
Determine the level of granularity required in each data source
Establish a data model for normalization, mapping fields from various sources to one another
Regularly and proactively validate data source content, and clearly understand when changes occur, react to them, adjust and re-document accordingly, and notify all those affected
Ensure that the data sources and resulting repository of cost and usage information is kept accurately, is appropriately sized, backed up, and managed throughout its useful lifecycle
Provide and ensure everyone with a need to access information can do so
Work with every group to determine the right metrics, measures and metadata that should be included in “official” output
Develop reporting output expectations document (update over time as maturity grows)

As someone in a Business/Product role, I will…

Provide business or product level information as required by the FinOps function to create KPI or other information required

As someone in a Finance/Procurement role, I will…

Provide access to data sources as required by the FinOps function
Ensure Finance is using the most up to date and appropriate data sources for reporting and decision making
Participate in or lead reconciliation and validation efforts to ensure invoices, usage data sources and other information map together as expected (typically monthly invoice reconciliation against usage data, and/or native cloud service provider tool data versus normalized data)

As someone in an Engineering/Operations role, I will…

Provide access to performance and usage monitoring information within the purview of Engineering for use by the FinOps data repository

As someone in an Executive role, I will…

Support the strategy for centralized data normalization, requests for access to information of various sorts as required by the FinOps function
Encourage and communicate clearly regarding the need to have a single source of cloud usage and cost truth for reporting and decision making

Measure(s) of Success & KPI

Ingest time
ETL time
cost data from multiple cloud providers queryable from a common normalized data schema
% of total cost available for reporting in normalized fashion
% of matching metadata elements

Inputs

Cloud provider billing data
Utilization data showing CPU, Memory, Disk, and/or Network utilization at a resource or resource group level
Transactional data from logs or systems which record the number or quantity of use of types of resources (often shared resources)
Value or outcome based reporting which provides data on the number of transactions or increments of value created by or represented by the operation of the systems. This information can provide the denominator for unit economics KPIs

Chargeback & Finance Integration

Chargeback and Finance Integration is about pushing spend accountability to the edges of the organization that are responsible for creating the expense.

Definition

Chargeback and Finance Integration is about pushing spend accountability to the edges of the organization that are responsible for creating the expense.

Once chargeback has been implemented and visibility given to teams, mature FinOps practitioners then integrate that data programmatically into their relevant internal reporting systems and financial management tools.

Chargeback is the focus in this capability, but Showback is a foundational part of any FinOps practice. The difference is that Chargeback sends expenses to a product or department P&L and Showback shows the charges by product or department but keeps the expenses in a centralized budget. Neither way should be considered more mature than the other, as which method used is entirely dependent on organizational accounting policy and preference.

A tagging and account strategy is vital as ways to identify costs. By either assigning a tag to a resource, or by designating a cost center that pays for resources in a certain account, practitioners can identify who is accountable for the expense incurred.

Another consideration in this capability is how to allocate shared organizational costs and commitment based discounts. Will these be held centrally or allocated based on consumption?

It is important for a centralized FinOps team to align with their finance partners to make sure that the decisions made in this capability (chargeback vs showback, tagging and accounting strategies, how to handle shared costs) can integrate with the companies IT policies and systems. The goal is to make it easy for users to be accountable for their expenses. The best way to do this is by integrating with the company’s finance tools and processes.

Maturity Assessment

FinOps practitioners using some form of automation to integrate with their Finance team to facilitate chargeback reporting for cloud costs were part of cohorts operating at a FinOps Run maturity.

Crawl

Cloud spend is allocated to teams based on estimated usage of resources.
Shared costs and discounts are held centrally due to lack of strategy on how to provide visibility and/or allocation.

Walk

Tagging strategy and/or Account strategy is in place to provide visibility into how expense is allocated
Strategy implemented on how to show and allocate shared costs/discounts

Run

Teams understand their direct and allocated shared cost portion of cloud spend based on their actual consumption.
Chargeback/Showback reporting is integrated automatically into the companies IT finance tooling

Functional Activity

As someone in a Business/Product role, I will…

Review the costs I am accountable for each month
Understand how these costs impact my budget
Have an understanding of organizational policy regarding chargeback/showback and allocation of shared costs/discounts

As someone in a Finance/FinOps role, I will…

Understand how cloud expense is generated
Ensure there is appropriate documentation on chargeback/showback policy and that operations are auditable according to company policies
Help teams reconcile their portion of expense that is allocated to them each month
Help teach teams the tagging and account policies and the importance of expense accountability

As someone in an Engineering/Operations role, I will…

Understand how cloud expense is generated for each service used
Comply with company tagging and account policies
Review costs incurred each month

As someone in an Executive role, I will…

Understand how cloud expense is generated
Review cloud expense for portions they are accountable for
Leverage this information for real time decision making

Measure(s) of Success & KPI

at least one measure of success; should be described in a context of cost; this could be an efficiency KPI or an agreed upon threshold or target.
for example:

idle resource costs will not exceed 3% of total monthly cloud spend
anomaly costs will not exceed $150/month

Inputs

Tagging and Account strategy are important for cost allocation.
Company accounting policy
Company cost center/department hierarchy

Onboarding Workloads

This capability is about establishing a cloud “front door” process to onboard brownfield and greenfield applications through financial viability and technical feasibility assessment criteria, all while setting up FinOps best practices from the start.

Definition

This capability is about establishing a cloud front door process to onboard brownfield and greenfield applications through financial viability and technical feasibility assessment criteria.

Maturity Assessment

Crawl

Ad-hoc on-demand budgeting/requisition to onboard workloads to the cloud

Walk

Budgeting process mandatory but not standardized across the Business Units / Product Teams. It considers all IT requested changes

Run

Well-defined process and guidelines including both financial viability and technical feasibility for preparation of deploying new projects/applications or migrating existing workloads to the cloud

Functional Activity

As someone in a Business/Product role, I will…

Optimize my product with new cloud capabilities to drive efficiency and agility
Develop new use cases to further innovate on the cloud

As someone in a Finance/FinOps role, I will…

Assess the financial viability of the workloads moving to the cloud
Capture and track cloud value benefits realization

As someone in an Engineering/Operations role, I will…

Assess the cloud suitability of the workloads moving to the cloud
Review the operational readiness to support the workloads on the cloud

As someone in an Executive role, I will…

Make informed decisions to prioritize workloads to move to the cloud
Provide strategic directions to reinvest the savings obtained from the workloads migrated to the cloud back to the business initiatives

Measure(s) of Success & KPI

Measurement of cost efficiency through infrastructure savings, migration and support costs
Operational resiliency improvement in service quality and security risk posture
Decrease time to market by accelerating fluidity in product and service delivery
Enable a culture of rapid experimentation to drive innovation and cloud transformation
Embed true environmental and social sustainability across the organization

Inputs

Information used that contributes to the measure(s) of success listed above are organized across the following categories:

Category : Input

Cost Efficiency

– Infrastructure cost

– Support cost

– Migration / implementation cost

Resiliency

– Service quality

– Security posture

– Operational stability

Velocity

– Developer productivity

– Release frequency

– Business agility

Innovation

– Return on innovation

– Employee experience

– Customer satisfaction

Sustainability

– Carbon footprint

– Power usage effectiveness

– Circular economy

Establishing FinOps Culture

Guidance on creating a movement to establish cultures of accountability so organizations understand that the practice of cloud cost management is about leveraging FinOps to accelerate the creation of business value.

Definition

The word “Kuleana” is Hawaiian for “Responsibility”. Kuleana encourages us to be accountable for all that we do and is the “ability to respond” to whatever is happening.

With this in mind, this capability is about creating a movement to establish cultures of accountability so that your organization understands the practice of cloud cost management is really about leveraging FinOps to accelerate the creation of business value.

An organization’s FinOps culture embraces a long term roadmap of transformation and continuous improvement across all the FinOps Domains at each stage of FinOps Maturity.

It requires finding allies in the face of opposition, winning over detractors during times of change, defining a common language, creating metrics to prove value, building enablement strategies to elevate stakeholder teams, and developing communication programs to inspire the FinOps Personas in your organization.

At its core, FinOps is a cultural movement because the practice of Finops is more than a technology solution or a checklist you hand to your teams. It’s a living, breathing way of approaching the cloud and cloud financial management made possible by the collaboration of finance, engineering and executive leadership through the FinOps Framework.

Maturity Assessment

To establish a FinOps culture, respondents operating at FinOps Walk and Run maturity had leadership buy-in along with implementing multiple other initiatives, like FinOps clear governance policies and alignment with existing adjacent frameworks

Crawl

Engineers are not familiar with what FinOps is and their role within it.
FinOps metrics are available to teams but there is no set ritual followed by engineers around the metrics.
Leadership is sold on the idea of FinOps but is not yet providing the buyin required.
Finance and engineers are only just starting to meet.

Walk

Engineers actively engage the FinOps processes, they understand the importance of FinOps within the business.
FinOps metrics are “just another operational metric” teams monitor and optimise this metric.
Leadership is actively supporting FinOps in the organisation. They make decisions on the Iron Triangle by insisting on knowing the cost impact and business value of the decision.
Engineering and Finance are aware of each other and understand what motivators drive each other.
Leadership celebrate FinOps success and celebrate/reward teams who have wins.

Run

Engineers consider financial impact during each life-cycle.
Engineers are actively looking for FinOps opportunities, reversing the flow of questions from finance to engineers more to engineers towards finance. Engineers proactively confirm budget and highlight changes that will impact costs.
FinOps team advocates with Engineering teams for investment for solid financial endeavors.
Business/Product Owners understand that their design decisions drive cost.

Functional Activity

As someone in a FinOps Practitioner role, I will…

Establish cloud cost management best practices
Establish benchmarks for stakeholder teams to use
Centralize cloud cost management in single cloud or multi-cloud environment
Create visibility and transparency to cloud cost
Align accountability to cloud users
Identify unallocated spend
Create and contribute to cloud budgets and forecasts
Create and contribute to showback to increase financial accountability
Advance communication and socialize FinOps throughout the organization

As someone in a Business/Product role, I will…

Connect product decisions with business outcomes
Predict how much cloud infrastructure will factor into feature/ product price
Guide team to make good cloud investments

As someone in a Finance role, I will…

Manage analysis and reporting of costs during growth, disproportionate cost reduction during flat/declining periods
Increase accountability for cloud cost
Increase reliance on budget and forecast models
Cost out and budget maintenance
Identify unallocated spend
Normalize spend predictability
Establish showbacks/chargebacks to increase financial accountability
Drive budget and forecast accuracy

As someone in a Procurement role, I will…

Obtain the best cloud cost rates available
Translate billing data to activity based costing
Provide visibility and enable understanding of cost per technology license and contracts

As someone in an Engineering/Operations role, I will…

Identify service or application ownership
Predict cloud costs closely enough for developing new features and products
Provide increased visibility to cloud cost to Engineering teams
Connect cloud costs and unit economics

As someone in an Executive role, I will…

Connect engineering decisions with cloud business outcomes
Increase accountability for cloud cost
Predict how cloud spend will grow as the business grows
Guide the organization’s cloud investments
Enable engineering organizations to gain more freedom to utilize newer cloud technologies and deliver solutions to market faster
Support the prioritization of FinOps objectives.

Measure(s) of Success & KPI

Engineering teams feel enabled to make cost trade-offs because they have real-time visibility to spend.
Education is available and evolving as it relates to Cloud cost management.
Active processes for FinOps knowledge sharing among teams.
Teams feel they have actionable FinOps tasks available.
There are KPI’s that quantify the use of rate-optimization constructs.
Unit Metrics are made available to track business value of cloud spend, enabling business agility.
The number of business leaders FinOps trained or certified.

Inputs

the information used that contributes to the measure(s) of success listed above; information here may include specific datasources, reports or any relevant input

FinOps & Intersecting Frameworks

This capability examines the intersection between FinOps with other standards. Widespread use of public cloud creates new challenges for traditional processes and the intention for this capability is to provide a place to capture FinOps’ interactions with existing IT and financial standards being used by your organization.

This capability examines the intersection between FinOps with other standards and frameworks used within your organization. Widespread use of public cloud creates new challenges for traditional processes and the intention for this capability is to provide a place to capture FinOps’ interactions with existing IT and financial standards being used by your organization.

Maturity Assessment

Organizations operating at a FinOps Run maturity were in cohorts that had unified processes between existing adjacent frameworks like ITSM, ITFM, PMO and ITAM and their FinOps practices. FinOps practitioners that still worked independently or had limited collaboration with personas working with other frameworks were more likely to be part of organizations operating at a FinOps Walk maturity.

Get Involved

one or more cloud providers
the types of cloud services used (compute, storage, database, etc…)
describe a combination of tooling, platform or vendor, and processes including KPIs
the industry the organization belongs to
the complexity of the organization (global enterprise, start-up, etc…)
the [FinOps personas](https://www.finops.org/framework/personas/) involved / organizational roles

Cloud Policy & Governance

Policy and Governance can be thought of as a set of statements of intent, with associated assurances of adherence.

Definition

Policy and Governance can be thought of as a set of statements of intent, with associated assurances of adherence.

A “Cloud Policy” is a clear statement of intent, describing the execution of specific cloud-related activities in accordance with a standard model designed to deliver some improvement of business value.

“Cloud Governance” is a set of processes, tooling or other guardrail solution that aims to control the activity as described by the Cloud Policy to promote the desired behaviour and outcomes.

Combining good Policy and Governance provides us with a mechanism to orchestrate and direct our Cloud FinOps Activity.

It’s possible to imagine a world in which good things happen naturally, without any attention or control being applied to them. In most business situations though, the right things will only happen if people are directed to do them, the actions and their outcomes are monitored and there are some (positive or negative) consequences arising from their actions.

We often talk about a ‘FinOps Culture’, which we see as a set of attitudes and behaviours oriented to driving business value from cloud technology, and we recognize that transitioning to this from a data centre culture is one of the key challenges of FinOps. Policy and Governance is how we establish and sustain a FinOps culture. In fact, it is the way in which all culture is established and sustained. Think of any organization with a recognizable ‘culture’ and you will see an effective Policy and Governance framework

So the simple answer to why Policy and Governance frameworks are important is that organizations cannot sustainably deliver business value from cloud without them.

Cloud policy and Governance are key components of successful Cloud FinOps. They work to align activities within Cloud to the business overall goals and strategies, control the deployment and usage of Cloud resources in order to maximise ROI. We are able to ensure our cloud costs are predictable and manageable, and we can use Cloud Policy & Governance to support the consistent adoption of best practices across the organisation, and support defence-in-depth against known threats and risks.

Maturity Assessment

Organizations with cloud governance policies implemented across all their FinOps personas were in cohorts operating at Run maturity. These policies ranged from provisioning and allocation requirements to IAM role and SME ownership policies. Responses showed most organizations had adopted some formal governance policies, with the majority being in cohorts operating their cloud cost management practices at a FinOps Walk maturity

In the early stages of cloud adoption, everything is new and everyone is a pioneer. Bit by bit the organization learns how to make the best use of cloud technology and harness it to achieve its goals. Policy & Governance is the primary mechanism for harnessing the power of cloud.

Maturity: Description: Focus

Crawl

Cloud Policy & Governance exists as part of overall business policy. Policies aim to control most significant risks to business value.
- Basic usage & rate optimization, etc as they apply to individual engineering teams and products.

Walk

Cloud Policy & Governance measures are broadened and standardized. Best practices are now being distributed and adopted across the business.
- Cross-functional collaboration. Integration with existing organizational policies and standards.

Run

Cloud Policy & Governance is now closely integrated with overall business strategy.
- All levels of business now operate in a way that is aligned with the organization’s strategy and goals.

Functional Activity

As a [FinOps Persona], I will [functional activity] so that [desired outcome] is achieved.

Measure(s) of Success

Measures of CP&G

Scope of CP&G

Crawl: Across Engineering teams

Walk: Cross-functional, across Business, Technical & Finance teams

Run: Across the organization, linking CP&G to strategic goals

Creating & Updating

Crawl: Manually, ad-hoc, largely reactive policy creation

Walk: Regular review cadence, proactive FinOps policies

Run: Ongoing automated policy compliance review, with trending

Documenting & Communicating

Crawl: Static, manually distributed content

Walk: KMS / training integrated solutions

Run: Integration with new architectural concepts to ensure currency

Monitoring for Compliance

Crawl: Manual analysis & reporting

Walk: Vendor-provided automated analytics (eg. AWS Config)

Run: Multi-cloud/enriched normalised insights & automation solution

Best Practice:

The 5 FACES of Good Cloud Policy & Governance:

Headline : Description

FOCUSED : on achieving the objectives we seek

ALIGNED : with the organisations goals, strategy and principles

CLEAR : simply stated and easy for everyone to understand

EFFICIENT : low comparative cost of implementation vs benefit

SUPPORTED : by the authority required in order to enforce it

Inputs

Governance

Governance implements Policy through:

Guidelines – that set out best practice for policy implementation and how it can be achieved. These are advisory, rather than mandatory
Guardrails – formal processes and structures that define mandatory pathways for policy-compliant action, possibly with consequences for non-compliance
Automation – processes that automate policy implementation and which therefore control how compliant actions are carried out.

Policy

If a policy is poorly conceived or expressed, of dubious authority, too broad or general to be useful in practice, or imposes a cost on the organization that is out of proportion to its benefit, it is a bad policy.
Some examples of good policy statements might be:

“Our policy is to cover more than 80% of our optimised cloud usage with discounted pricing plans”
“Our policy is to reduce wasted spend by decommissioning cloud resources that deliver no business value”

Cloud Provider Governance & Policy Resources

Management and Governance on AWS
Azure Governance
GCP Guide to Financial Governance

Cloud Providers Governance & Policy Tools

AWS – AWS Control Tower, AWS Organizations, AWS License Manager, AWS Service Catalog, AWS OpsWorks
Azure – Azure Management Groups, Azure Blueprints
GCP – Google Cloud Console

FinOps Education & Enablement

FinOps Education & Enablement allows all those participating in FinOps practices to increase the business value of cloud by accelerating FinOps adoption and training.

Definition

FinOps Education & Enablement allows all those participating in FinOps practices to increase the business value of cloud by accelerating FinOps adoption.

FinOps Education & Enablement includes:

Internal communications, events and learning experiences. These may focus on specific technical, financial or business topics or a combination of all three
Training – either function-based, technology-based, or focused on FinOps processes themselves
Initiatives aimed at improving the business value of cloud that give participants the opportunity to use the knowledge they have gained

Maturity Assessment

Respondents indicating that FinOps practices were adopted across all teams and personas were in cohorts operating at FinOps Run maturity. Organizations operating at a FinOps Walk maturity showed a combination of full and partial adoption of FinOps practices across teams with fewer personas involved

Crawl

Education occurs within specific teams/functions themselves and focuses on the specific needs of each team
Covers basic FinOps processes and principles, such as Metadata & Account Organization, Cost Allocation, Ownership & Accountability
Education is generally directed towards Usage Optimization and Rate Optimization as the main vehicles for improving business value
Team Leaders drive enablement by assigning responsibilities that challenge and develop FinOps capabilities

Walk

Education initiatives extend across teams to promote mutual understanding, purpose and collaboration
Covers a broader range of FinOps processes and practices, such as Forecasting, Managing shared costs, Budget Management
Education of FinOps Team now includes Real-time Decision-making and Performance Tracking & Benchmarking
Functional Leaders drive enablement by assigning responsibilities that cross functional boundaries and emphasise collaboration

Run

Education & Enablement extends across the enterprise to promote alignment of cloud value initiatives with organizational goals
Covers the full range of FinOps processes and practices, including those focused on establishing FinOps culture and IT asset management integration
Education & Enablement of FinOps Team is broadened to include Organizational Alignment
Executives drive enablement by assigning responsibilities that emphasize alignment with strategic goals

Functional Activity

As a [FinOps Persona], I will [functional activity] so that [desired outcome] is achieved.

Measure(s) of Success & KPI

Training materials are available to every discipline, at every level to include both generic, and company specific info
Training is proactively offered both with internal delivery as well as access to external content as applicable
Employees feel empowered and encouraged to learn about their discipline and other disciplines, and to help in coaching others
Ongoing opportunities to learn, both formal and informal, are offered consistently over time
Leadership drives empowerment by promoting skills development and on-the-job learning and encouraging a ‘fail fast’ mantra

Inputs

Best Practices & Approaches

Cross-team training and sharing of best practices
FinOps targeted training and enablement
Brown-bag/Lunch-n-Learn for cross domain training
Build your own use of Confluence, Sharepoint, etc. to create internal playbooks, wikis and other things that “work here”
Encourage collaboration and cross-fertilization of ideas across different functions
Be mindful of providing for different learning styles and needs for different individuals

FinOps Training

FinOps Foundation

Details of all FinOps training programs and materials are available at learn.finops.org

Amazon Web Services

AWS Skill Builder

Microsoft Azure

Microsoft Azure Training Portal

Google Cloud Platform

GCP Training Portal

Establishing a FinOps Decision & Accountability Structure

Learn how to define an organization’s FinOps-related roles, responsibilities, and activities to bridge operational cloud cost management gaps between teams. It outlines the people, processes and decision trees needed to tackle unexpected challenges, in addition to having them be proactively available when an organization needs to take action ahead of time.

Definition

Establishing a FinOps Decision & Accountability Structure is about capturing an organization’s FinOps-related roles, responsibilities and activities to bridge operational cloud cost management gaps between teams. These decision-making and accountability structures help cross-functional teams work out the processes and decision trees they’ll need to use to tackle challenges and resolve conflicts, in addition to having them be proactively available when they need to take action ahead of time.

Rather than having every Capability prescribe a RACI matrix (or one of the other responsibility-assignment-matrix variants), each Capability encapsulates an approachable persona-user-story format in the context of the FinOps activities need for the capability. Then we breakout responsibility-assignment into this capability.

It highlights the need for this capability in a FinOps practice, but also allows for the

Framework to remain relevant for a 20 person start-up without the need for imposing process (like RACI). At the same time, this Capability is available for larger organizations, where a RACI matrix would be implemented.

Establishing a clear FinOps Decision and Accountability Structure, such as a management team, committee, or working group, provides direction while nurturing equity and inclusivity to resolve actual or perceived power imbalances that can arise during financial decision making and collaboration. This structure should include clear lines of authority and guidelines, enabling issues to be escalated and resolved, and giving senior decision makers the opportunity to make informed decisions quickly and in a consistent manner.

Try to use existing decision making and governance mechanisms. Ensure the FinOps Decision and Accountability structure is clear and documented, including who has decision making authority versus who has an advisory role. Work out how your team structure connects to the broader governance arrangements of your agency to ensure clear reporting

lines and accountability for tasks and deliverables.

Maturity Assessment

Crawl

Simple hierarchy of decision making authority and accountability.
Limited documentation of the Decision and Accountability structure and processes.
Few controls to assist with strategy or development of a consistent approach.
The shortest valid leadership path for decision-making is identified
Define minimum viable data set for various decisions (time / quantity)
Clear cadence / time horizons for decisions are set
Mini Business Case analysis used to quantify and justify higher impact decisions

Walk

Clearly defined hierarchy of decision making authority and accountability.
Decision and accountability structure and processes are well documented, and have become standard.
Management is involved with implementing and supporting these procedures and standards.
Regular use and review of FinOps metrics to help with decision making and planning.
Well defined relationships and processes allow for strategic planning and for the organization to react and make decisions quickly and in a consistent manner.
Decision-making power driven further towards the edge of the organization empoweing individuals with context and control
Teams can correlate decisions and business goals

Run

Clear and well documented FinOps Decision and Accountability Structure relationships and processes.
Regular standardized FinOps decision making processes in place, utilizing agreed FinOps metrics.
Management can review current analytics and decide whether or not to make strategic changes.
FinOps decisions and processes are compared and benchmarked against other organizations.
Processes are in place to continuously review and improve the FinOps Decision and Accountability Structure and performance.
Allocation Metadata and hierarchy strategies more automated
Proactive and predictive decisions based on business goals

Functional Activity

Here’s a high-level look at how FinOps Personas sort their roles and responsibilities. This table uses the Responsibility Assignment Matrix (aka RACI model), organizing personas by how they might be Responsible, Accountable, Consulted, or Informed.

Measure(s) of Success & KPI

Measures of success are represented in the context of cloud costs and may include one or more key performance indicators (KPIs), describe objectives with key results (OKRs), and declare thresholds defining outliers or acceptable variance from forecasted trends.

Reduced cycle time between data, decision, forecast, outcome and analysis
Decisions are made by individuals with context and control
Clear and consistent decision making processes and ownership levels drive improved clarity for the business
Increased confidence and pace of execution
Making these decision points transparent and accountable is key to driving this improved performance.
All personas throughout the FinOps sphere of influence are involved – both within the practice and adjacent personas, dependent upon the nature of decisions being made.
Repeatable and rapid set of pathways to enable the real-time decision making, empowering the business to operate with the agility needed for their cloud operations.
Business goals combined with real-world data form basis for decision flow

Inputs

Here are known information inputs that contribute to the measure(s) of success listed above:

Decisions should be prioritized according to the impact an action will have, and that will determine the decision pace. Who decides should be someone that is highly aware of the context.
Each Capability has a different responsible personas for decision making, but the guidelines should be applicable.
Well defined impact, context, and pace scenarios based upon the organization’s lines of business, products and responsible teams