Cloud Financial Management and FinOps: A 15-minute Primer

Deepak Vensi
Deepak Vensi in Community Highlight
12th May 2020

Okay, while it takes far more than 15 minutes to learn, understand, and master FinOps and its many best practices and cultural shifts, it’s nice to have one reference point for the high-level look at things. I’d like to take some time to highlight Deepak Ramchandani Vensi’s post about FinOps. For a movement like FinOps to succeed, we need more people able to explain its various parts succinctly and educationally. Nice work, Deepak! 


 

Cloud finance is a tightrope walk.

Engineers often don’t appreciate the financial burden their cloud spend represents to the company. At the same time, finance teams aren’t cloud-savvy enough to figure out how they can rein in spiralling cloud costs. 

With cloud spend forecasts predicted to surpass $330 billion by 2022, no longer can organisations and executives continue to stick to existing financial and procurement practices and let engineering teams handle their cloud spend.

Time and again we see organisations run into some pretty big cloud finance headaches:

In the worst case, this can cause exasperated directors to doubt the benefits of the cloud and pull the plug. 

But the problem is not the cloud; it’s your cloud consumption model! Your financial approach to consuming the cloud is fundamentally flawed.

In this blog I will explore FinOps, a model of cloud consumption that brings the finance team into the new world of the cloud, radically shifting how you think about cloud costs and (possibly!) saving your cloud programme from extinction!  

I’ll explore:

Why Your Finance Function Isn’t Prepared for the Cloud

When scaling the cloud, organisations put a lot of time, focus and attention into familiar disciplines such as engineering, security, governance, operations, but their finance and procurement functions are still geared for consumption of traditional on-premise IT services. 

The cloud has fundamentally shifted how organisations view technology spend. Here I’ll look at the three biggest ways cloud has done so and why this causes a problem.

1. Your finance processes are not set up to manage the shift from CapEx to OpEx

The cloud shifts your tech spend from fixed CapEx to fluid OpEx. 

Traditionally, finance and procurement teams would categorise key hardware investments as ‘fixed’ assets that depreciate over a fixed period of time until the next hardware refresh cycle (3-5 years on average). Such investments were filed under Capital Expenditure (‘CapEx’).

However, the commercial model for procuring cloud services is considered Operational Expenditure (‘OpEx’) because the cloud is consumed on-demand as a pay-as-you-go service.

Finance teams and processes are not set up to manage how this affects your bottom line, or to account for large sums of cloud spend emerging every few months. 

2. You can’t forecast tech spend as easily

Finance and procurement teams also traditionally had complete oversight of the IT services (hardware and software) being purchased. They selected suppliers, negotiated discount rates and knew exactly who was buying what. This meant they could accurately forecast and plan for tech spend. 

In a cloud world, however, these procurement responsibilities are delegated to the individual developers or teams, who procure them in a self-service fashion as and when they are needed via their cloud service provider. 

In this context, finance teams struggle to keep track of who is buying what and can no longer properly forecast technology spend. 

3. You can’t control the self-service free for all, even though it still affects you

As mentioned above, most cloud services are procured by the individual/team who needs it via a cloud marketplace from the provider. Financially, this can be a sensible way of doing things. 

But it can become a free-for-all with very limited oversight. 

The question for finance teams is how they can put guardrails in place to control spend and make sure people don’t do anything daft. Who can buy what? How can you keep track of licenses? What are the commercials? 

All of this is now outside the remit of the finance team, while still affecting them. 

Plus, when engineering teams are buying their own services, what exactly is the role of finance and procurement? They are still struggling to figure out how they fit into this more open, fluid cloud world. 

These are just some of the key challenges that traditional finance and procurement functions are left asking themselves, with some other notables ones being:

If these are questions that you find yourself asking then you aren’t the only one. 

Finance and procurement are one of many governance and control functions that are currently reinventing themselves to figure out how they can best apply their domain knowledge to the growing world of cloud computing and product-focused thinking. (As a matter of fact, my colleague Matt Davies has just written a similar article on how ITIL based Operations teams can bridge the gap to support rapid pace of change.)

This is where FinOps comes in.

What Is FinOps?

FinOps is an approach to managing and operating cloud spend by breaking down the silos between engineering, finance and procurement. FinOps is meant to drive a shift in culture in cloud financial management, akin to how DevOps and SRE have driven a cultural change in engineering.

It aims to bring together all key functions involved in planning, procuring, consuming, managing and governing cloud services in order to make the right decisions and trade-offs when consuming cloud without compromising on the consumer experience and value that cloud was meant to offer in the first place.  

It prevents spurious cloud consumption patterns and optimises cloud consumption. Ultimately, it could save a cloud program that otherwise would have been mired by spiralling costs. 

Some of the key principles of the FinOps model are:

By combining aspects of financial management, cloud operations, demand management and the core disciplines of procurement, FinOps aids organisations in driving a more efficient cloud cost management and ROI framework and aligning your cloud adoption journey to business value. 

Cloud cost management has always been a key pillar when it comes to architecting a cloud environment well. However, with cloud spend in 2020 showing no sign of stopping paired with the directly implied shift from CapEx to OpEx, doing a quarterly review of your cloud consumption is no longer enough.

The resulting benefits of moving towards a FinOps Model are:

How Do You Get Started with FinOps?

A fundamental mistake most organisations make is to consider cloud financial management and governance either as an afterthought or as a cost-saving activity.

However, at Contino, we take an engineering-first, data-led approach to FinOps. To build a successful FinOps function we recommend starting off with the following building blocks:

A Cloud Cost Control or FinOps Policy 

Just like a set of engineering standards within a development team, or an expense policy for any employee within an organisation, a Cloud Cost Control policy provides consuming teams with a control set to comply with in order to achieve the financially controlled consumption of cloud within the organisation. 

Every single employee within the organisation must read, understand and acknowledge their compliance and responsibilities when adhering to said document.

The policy should cover vital information such as:

The Cloud Cost Control policy should identify the key owners that are responsible for carrying out the policy actions (consuming teams, FinOps team, Product owner, etc.). However, it shouldn’t cover the CSP specific implementation detail in how to do so. The policy should be complemented by an engineering implementation approach on how it has been adhered to within the cloud providers being consumed.

Finally, the FinOps function should perform regular audits (see example in figure below) of how well the Cloud Cost Control policy is being adhered to within the organisation and take the necessary steps to ensure increased compliance.

Fig. Example coverage of the Cost Control Policy within an organisation

Implement Guardrails for the Cost Control Policy

Once an organisation has established a Cloud FinOps/Cost Control Policy, a key set of controls from the policy can be implemented as code-based guardrails within the foundational cloud platform implemented (i.e. Landing Zones).

These policies should be versioned, tracked and governed, allowing engineering teams to either enforce them or notify the adequate stakeholders when they have been breached (eg. the budget and alerts set, notification thresholds, enforced tagging patterns, etc). We shall cover these in an upcoming article, going into further detail on the implementation techniques and tools that organisations can use to implement and practice FinOps effectively. The implementation of these guardrails should consider:

Establish a Cloud Benefits Framework

As talked about in the ‘What is FinOps’ section, cost management is only one key pillar, with the other being the ROI and benefits of cloud consumption. 

While implementing a set of financial guardrails on consuming cloud platforms provides a cost management and reporting approach, a parallel effort is required to establish a framework that helps articulate the benefits and ROI that result from your cloud programme. 

Traditionally, business cases are loathed as the key blocker and inhibitor for experimentation. It’s the FinOps functions’ role to work with the key value streams within the business to help establish the parameters for a successful cloud business case and the benefits that an organisation intends to track for the applications/workloads/products onboarded. These could be:

Alternatively, one can choose to classify these by tangible or intangible benefits, but the key point is having a benefit framework that helps product/application teams articulate their WHY, with measurable data points that can be tracked.

The best benefits frameworks that Contino recommends are those that can map your organisational values, to business initiatives to engineering efforts. Just like the best OKRs are those that are aligned to organisational objectives, an effective cloud benefits framework is no different.

Identify Your Cost Drivers and Metrics

A fundamental part of any business is understanding your cost base and being able to put some science behind predicting any increase in operational costs that might eventually impact the bottom line. 

While any cloud cost management tool helps you identify any increase/decrease in cloud spend, the business drivers behind said fluctuations are often left unidentified.

We recommend that FinOps teams identify and list the key cost drivers that application/product teams can help attest to, such that these can be traced back to business benefits and outcomes. To further simplify the process we can narrow down the cost drivers to ultimately four factors that drives changes in the cloud service provider bill:

Any acceptable change to these drivers should be driven in turn by the business objectives of an application or product team, with an associated metric (listed in benefits framework). By forecasting how we expect these metrics to change, we can better inform our forecast cloud costs.

Fig: Based on defining cost drivers this way, we can trace any unexpected expenditure to a root cause

By assessing what the business goals of an application/product are and the planned technical implementation, teams can come to an assessment of:

Categorising these metrics by risk gives FinOps a greater ability to forecast what the future of cloud spend will look like. We typically use two categories:

Establish a Financial Trace to Your Customer Experience

Just like engineering teams use application tracing to profile, monitor, diagnose and pinpoint any application failures, FinOps teams need to be able to trace cloud spend. 

Aligning your cloud spend to the benefits and cost drivers as part of a cloud business case helps do exactly that.

A key advantage that cloud spend has compared to that of on-premise hardware assets is that one can instantly get a detailed breakdown of the services being consumed, the unit price, the duration of consumption etc., presented by an ever maturing set of cost management tools that provide a very rich data set in near-real-time.

Fig. Aligning business drivers and metrics to the cost drivers that would impact the cloud spend

A cloud business case brings together the key data points of cloud spend, benefits and cost drivers to understand the forecasted spend by an application/product, the actuals being tracked in real time and projected spend based on consumption volume or business metrics. 

It is here where the FinOps and Product teams can now start to answer key business questions that are truly game changing such as:

You can trace these back to each one of the cost drivers, and verify what has caused the consumption to vary based on the business drivers and metrics that are being measured.

Bringing It All Together

The pièce de résistance in achieving true FinOps mastery is to bring all the information captured above in a format that is tracked throughout the lifecycle of the applications and products hosted in the cloud. 

This covers the whole lifecycle from when demand was registered, through when the product is being developed, to the point when it starts serving customers and as it evolves based on customer feedback.

This means that all the key functions within your organisation (eg. a Cloud Centre of Excellence) have a key part to play in ensuring that the right processes and data is being captured throughout the product development or application development/migration lifecycle, including:

The output of bringing all of the above together can help multiple teams, including executives, in being able to make data-driven business decisions that can take into account cloud financial data, business metrics, organizational and consumer insights.

Fig. An example business case that combines Cloud spend actuals , the initial forecast, the comparison with on-prem hosting costs, the drivers to track and the business benefits/metrics.

Taking It One Step at a Time

While it’s often quite easy to try to shoot for the stars, we always recommend an organisation taking baby steps in making sure they are successfully building their in-house maturity when it comes to establishing a successful FinOps function. As a matter of fact, FinOps doesn’t have to be a dedicated function on day one, and should grow hand in hand with an organisation’s cloud maturity. 

As recommended by the FinOps foundation, starting off with the key building blocks and fundamentals practices is more important than building a dedicated team that focuses on FinOps. The FinOps maturity framework helps you identify what those baby steps should be, whilst trying to drive an organisational change that aligns one’s cloud adoption with product focused thinking.

Fig. A FinOps Maturity Framework

Additional Considerations

While the core building blocks listed above are critical in making sure you set up your FinOps function for success, there are some additional considerations that organizations have to plan for as their aspirations for cloud adoption scales:

We shall consider these in an upcoming article, where we look at how an organization can take the core foundations listed within this article in order to move towards a fully fledged FinOps function that is key part of one’s Cloud Adoption strategy.

Conclusion and Key Takeaways

Join Deepak’s upcoming webinar

Learn more about how to bring Finance and Ops together to build a common FinOps culture and practice at Deepak’s upcoming webinar. Discover key methods on creating a FinOps function for your organisation with Deepak and his colleague, Scott Shulman.

Deepak and Scott will cover:

Now that we’re building a common language…

take the discussion to our community! As people like Deepak and other FinOps experts share best practices and methodologies, and put them to work in the real world, sharing the stories and outcomes only helps our community grow. Share this piece and spread the word to colleagues who might be interested in or trying to figure out FinOps. We welcome them to join the foundation and to share what they’ve learned.