prosperops logo

Implementing FinOps, Part 3.4: Financial Reportability As An Architectural Imperative

Originally Published April, 2024 · Last Updated May, 2024
Implementing FinOps, Part 3.4: Financial Reportability As An Architectural Imperative

In our recent blog on cross-departmental collaboration, we’ve emphasized the importance of fostering closer collaboration between finance and technology leaders by combining a regular cadence of informal, personal interactions with routine business activities such as updating budgets, etc. 

In this article, we examine the need for these teams to find opportunities to collaborate on business matters proactively to prevent the emergence of unforeseen problems in the future. Here we use the example of formalizing coordination between Finance and technology on new development projects, but leaders in both teams should constantly be on the lookout for similar opportunities to collaborate that may be equally valuable. Read on!

Breaking Through The Development Silo

In many organizations we’ve worked with, the finance department’s role in developing new technical products and services is typically confined to requesting development cost estimates and post-deployment operational cost projections for new workloads. While this approach may seem adequate initially, such limited interaction can eventually lead to issues. At the risk of oversimplification, in many cases the foundation of any given development project focuses on the most immediate imperatives, resembling a three-legged stool comprised of the following:

  • Performance
    Will the new workload provide the service intended? Will it tolerate unstable usage volumes by scaling up and down as needed? Does the architecture ensure resilience in the face of reasonably foreseeable failures in either integrated components or underlying infrastructure? 
  • Security
    Is every step being taken to ensure that the new workload is compliant with best practices to defend against data breaches and denial of service attacks? Does the architecture meet or exceed all relevant compliance requirements, minimizing regulatory risk to the enterprise and facilitating smooth compliance audits?
  • Cost
    Has an appropriate balance been struck between meeting performance and security requirements and delivering services at the minimum cost? Have different architectures been considered and have estimates been developed for operating costs given different service mixes and vendor workload placements? 

Most often, when technical teams focus on these three foundational pillars, they can be confident that they are developing solutions that will serve both their employer and their customers well. In the “three-legged” model, Finance’s role in the development process is limited to data requests concerning leg #3: “What’s it going to cost?

The Missing Leg of Project Development

Although the three-legged development model appears robust at first glance, it harbors a significant and potentially problematic oversight: Finance and the engineering team do not coordinate on the financial reporting required once the workload transitions from a development project to production. Consequently, the financial reportability of the workload has not been considered in the architectural design.

A concrete example can clarify the issues that often arise from this oversight.

Imagine a software company developing a new application to analyze customers’ financial transactions for correlations between historical spending and future buying preferences. Their clients will be large financial institutions and retailers, necessitating each deployment of the software to process vast collections of data. As part of their three-legged software development model, the team decides that containerizing key components of the new application will provide significant advantages in terms of lower costs through shared container clusters and resilience in the form of minimal reliance on any given compute node. 

However, by not involving Finance in the architecture development process, the team overlooks a critical flaw from Finance’s perspective: the inability to track the usage of shared clusters by individual customers. This lack of information makes it challenging to measure the product’s cost per customer segment, which in turn will complicate the evaluation of the company’s pricing strategy.

Both parties remain unaware of this issue until the end of the first month after the new offering’s launch into production. At that point, Finance approaches the technical teams requesting a report that breaks down costs by the customer, and the technical team suddenly realizes they have no way of providing it. 

To prevent this kind of oversight, it’s essential to introduce a fourth leg into the engineering team’s development process:

Financial Reportability. Have both Finance and executive leadership been consulted on the reporting requirements that will apply to the new workload? Have those requirements been factored into the architectural design to ensure that the costs for any shared resources can be accurately traced to the relevant business organizers? Will the technical team be able to fulfill Finance’s reporting requirements once the project has been deployed?

By integrating this fourth leg into the development process, both Finance and the Engineering team can be sure they will get what they need once new products and services hit the market. While adding this fourth leg is always a good idea for any organization, it is far from the only example of the benefits realized by formalizing proactive collaboration between Finance and Engineering. The teams should regularly meet to conduct a “post-mortem” analysis of how the organization’s financial operations have been functioning to look for any other opportunities to avoid unforeseen problems or take the business’ reporting capabilities to a higher level.

Organizations should not only encourage formal meetings but also cultivate an environment where both departments proactively participate throughout the development process, rather than getting involved in one-time interactions at the end of the month. These sessions promote a deeper understanding of the pressures and challenges each department faces, leading to a clearer comprehension of the underlying ‘whats’ and ‘whys’ behind each other’s requirements.

For more insights into FinOps and how to enhance your cloud cost management, visit our blog at ProsperOps or book a demo to understand how our FinOps experts can help you save more on the cloud.

About the writer: Rich Hoyer is a FinOps thought leader with over 27 years of experience in IT and Finance, and he is the CEO and co-founder of FinOptik, a niche cloud financial management agency.

Share

Facebook
Twitter
LinkedIn
Reddit

Get started for free

Request a Free Savings Analysis

3 out of 4 customers see at least a 50% increase in savings.

Get a deeper understanding of your current cloud spend and savings, and find out how much more you can save with ProsperOps!

Submit this form to request your free cloud savings analysis.

🌴  Join us at FinOps X:  RSVP For The 2nd Annual 8-Bit After Party!