In the Inform Phase, we create and use the tags and labels, the account or project hierarchy, and other billing constructs to allocate cloud cost to the business units so that engineers and leadership have a near-real-time view of their cloud usage. The Inform Phase makes use of the FinOps Principles number 3: "Everyone takes ownership for their cloud usage", and number 4: "FinOps reports should be accessible and timely".

Our goal is to deliver reliable and consistent reports and to work with the key stakeholders to build trust in the numbers presented. We accomplish that by using a common language and well-documented cost metrics. and by catering the reports to the viewer. Different people within the organization have different needs. For example, a Finance person may want to see monthly Actuals versus Forecast on a company level while an engineering leader wants to see how his team is performing toward KPI goals and if there were any cost spikes.

When building a cloud cost reporting infrastructure you will need to consider that cost numbers may have different meanings. For example, Gross cost may be used when engineers forecast their workloads while Net cost is used to compare actual spend with the budget and can also be used for invoice reconciliation. Another view of cost data is fully amortized cost. This is when the upfront cost of prepayment products is apportioned to workloads over the course of the lease duration. There is also a blended cost. This is when some of the workloads have prepayment savings applied while others don't, and the cost is averaged out between them.

Many businesses also use a Special Projects view, where the cost of strategic initiatives is tracked separately as these have high visibility. Talk to key stakeholders and ask them what is missing and what they need from a successful cloud cost visualization tool.

Tagging and labeling is metadata that is attached to cloud resources and will be a key enabler of allocating cloud cost to business units. The FinOps team will need to build a tagging taxonomy that provides a consistent way of categorizing workloads. For example, an account or project may have multiple environments like production, development, and testing and may also host multiple applications. Tagging helps to identify and assign costs to the correct owners.

Having a tagging taxonomy does not guarantee that engineers will always tag their resources. The FinOps team will need to deal with untagged resources but also untaggable resources. Examples of costs that do not support tagging are network costs, support charges, software licensing charges, third-party monitoring and management charges, taxes, but also discounts and credits.

To handle untagged resources and untaggable resources, apportion the cost of resources that don't have tags to existing workloads based on the workload's total cost. Let's build an example where we have two workloads one with 1,000 Dollars and another with 2,000 Dollars monthly spend and we have 300 Dollars of untagged monthly cost. In this case, we apportion 100 Dollars to the first and 200 Dollars to the second workload.

From my experience, a key challenge here will be that executives, leadership, and Finance may view the business differently from the way engineers look at the cloud. For example, leadership may look at the business in terms of ecosystems or their view of ownership could follow the organizational hierarchy. Specifically, they may want to see cloud spend in terms of projects or departments, something that may not directly exist within the tagging taxonomy. For these situations, the FinOps team needs to build additional groupings that map tags to how the business operates.

Your business may also have workloads in different clouds or within data centers. When considering a tagging taxonomy the FinOps team will need to build standards that work across different environments. Cloud providers have different tagging limitations where a lowest common denominator approach will be necessary to support tags across multiple clouds.

While allocating cloud cost to business owners is one thing, this is not necessarily how the business pays the actual cloud bill. To simplify the purchase order process, businesses often elect to have a single business unit pay the entire cloud bill. The business may then choose to apportion or allocate cloud spend to the individual business units incurring the cost.

The simplest method is called Showback, where the business unit's budget doesn't get impacted, but the business units see how much they are spending in the cloud. A slightly more sophisticated method is Chargeback, where the business units are assigned budgets and their spend counts toward their budget. The latter incentivizes leadership and engineers to reduce cloud spend if the saved budget can be reassigned to other projects.

When building key performance indicators make sure to reach out to business stakeholders as they may already be tracking KPIs internally. Automate these metrics through reports and show trending over time. This will allow leadership and engineers to see the effect of code or workload changes on the business. Not all changes may improve cost. For example, a better customer experience may require additional cloud resources. The goal is to provide visibility and track performance over time.

When we look at how businesses spend their revenue, about half goes to paying for their employees, and a large portion of the other half goes to offices and operations, things like facilities and maintenance. Only a small portion of a business's revenue goes to innovation, the type of projects that give the business a competitive advantage.

Cloud spend is typically within that small portion carved out for innovation. This means forecasting cloud spend too low will eventually take funds away from special projects already in flight and forecasting cloud spend too high will keep funds away from potential new special projects. This makes accurate cloud forecasting the single most important thing we can do to help with innovation.

The FinOps team will need to work with executives and leadership and explain that the engineering leaders know their workloads best and have the most insight into planned changes, and we will need their direct input when it comes to forecasting cloud spend.

While forecasting works best decentralized with the engineering leaders, aggregation of forecast data and financial forecasting of cloud spend is best done centrally by the FinOps team. The FinOps team will need to work closely with the Finance team to collect detailed requirements around the specific reporting needs Finance has. For example, Finance may need an annual forecast at the end of a fiscal year, but they may also need quarterly so-called true-up forecasts to capture incremental roadmap changes.

Let's shift gears a little. When looking at cloud cost, this is usually a move from Capital Expenditures or CapEx to Operating Expenses or OpEx. Capital Expenditures are typically fixed assets such as buildings or machinery while Operating Expenses are typically an ongoing cost for running a business or product. For example, an office building owned by a business is a Capital Expenditure and needs to be depreciated over time, while electricity and maintenance are Operating Expenses that will show on the company's annual fiscal report.

Finance may have special requirements for capitalizing cloud cost, essentially moving it from OpEx to CapEx. For example developing internal-use software, prepayment products, and employee training can sometimes be capitalized as long-term assets are amortized over a time period. You will need to reach out to the Finance team to learn their requirements for these processes as these may affect tagging and allocation of cloud cost.

As always we start small and make incremental progress using the Crawl, Walk, Run approach. For example, when we are just getting started, a good first step is to use tagging to help identify workload owners so we can either use Showback or Chargeback. Once successful we can provide a more complete financial view apportioning untagged and untaggable resources and amortizing prepayment products. And once we accomplish that, we can look into cloud forecasting, building KPIs, or automated runaway spend detection. 

To summarize the FinOps Inform Phase: We use tagging and other metadata to allocate cloud cost to owners by building reliable and consistent reports that are well understood, trusted, and accepted throughout the organization. Financial numbers will use different rates like Gross, Net, Amortized, or Blended. We build KPIs that tie business results to cloud usage. And we use the Crawl, Walk, Run approach to gradually build these capabilities.

Please note: this lecture references materials from:

• FinOps Framework by FinOps Foundation