Every line of code written today is a financial commitment made for tomorrow. Yet, most FinOps for enterprise initiatives treat cloud costs like a mystery to be solved at the end of the month. Recently, BBD’s MServ team hosted a workshop at Converge Africa where we delved into how companies can anticipate cloud spend. Through BBD’s cost savings framework, we found that in one case study, the client could save up to 33% on their cloud spend.
An ARC approach to cloud cost forecasting, observability, and control
If you’re waiting for the bill to arrive before you start managing it, you’ve already lost the battle. Real efficiency isn’t found in better reporting; it’s engineered into your architecture. For many enterprises, the initial promise of the cloud (such as unlimited scalability and pay-as-you-go efficiency), has been replaced by the shock of a monthly bill that only seems to move in one direction. In response, the FinOps framework has become the standard go-to for regaining control, and more specifically for BBD, the ARC framework: Reveal, Anticipate, and Control.
However, a common frustration is emerging: many organisations have adopted FinOps practices, implemented expensive dashboards, and appointed dedicated cost analysts, yet their cloud spend continues to climb. The reason is simple: most FinOps for enterprise initiatives are finance-led, focusing on after-the-fact reporting.
The real drivers of cloud spend don’t live in spreadsheets; they live in architecture, code, scaling models, and operational behaviour. To move from passive reporting to active value creation, organisations must pivot toward proactive FinOps engineering.
What is the key to managing enterprise cloud costs?
FinOps fails because it relies on finance teams tracking bills after they arrive. Real cloud efficiency is an engineering problem, not an accounting one. By shifting from passive spreadsheets to proactive FinOps engineering, organisations can stop treating cloud costs like a monthly mystery and start designing cost-aware systems from the very first line of code.
Moving beyond spreadsheets
FinOps only delivers sustained value when it is led by engineering, not just finance. The ARC framework shifts the focus from accounting to action:
- Reveal: Using cloud usage monitoring and observability to surface not just costs, but the technical drivers behind them
- Anticipate: Forecasting spend based on engineering signals and upcoming architectural changes, rather than historical billing data alone
- Control: Implementing automated guardrails and technical policies that prevent bill shock before it occurs
Why engineering-led FinOps delivers more value
Traditional FinOps often breaks down because it treats cost as a late-stage accounting problem. Finance-led models show where money was spent, but they cannot explain why a system was expensive to run. Engineering-led FinOps embeds cost awareness directly into software engineering decisions.
A FinOps engineering approach recognises that architectural choices represent the highest point of leverage for cost optimisation:
- Stateless vs. Stateful design: Stateless architectures are significantly cheaper to scale because they allow for the use of spot instances and aggressive cloud autoscaling without the complexity of data persistence
- Monoliths vs. Microservices: While microservices offer agility, they can introduce a network tax and management overhead. If a distributed architecture isn’t required for scale, it might be an unnecessary driver of spend
- Data Access Patterns: Designing for efficient storage tiers and minimising cross-region data transfer is a technical decision with massive financial implications
Observability: The bridge to business value
To truly succeed, you need a cloud-based monitoring system that connects data engineering signals to financial outcomes. By moving from monthly bills to near-real-time feedback, engineers can identify high-cost code paths or runaway workloads before waste compounds. This allows the business to measure unit economics, such as cost per transaction, cost per active customer, or cost per API call.
Automation and guardrails that prevent cost drift
The Control element of the ARC framework is best achieved through automation. By using Infrastructure-as-Code (IaC), teams can bake discipline into their deployment pipelines via:
- Policy-based controls: Automatically preventing the creation of over-sized or unapproved resource types
- Automated clean up: Scripted processes that delete unattached storage or orphaned snapshots
- CI/CD cost checks: Using tools to estimate the cost impact of a pull request before it is merged
Aligning cloud spend with outcomes
Cloud costs are no longer simply a finance problem. Real savings and value-alignment come from design-time decisions, intelligent automation, and tight feedback loops. While a FinOps framework provides the structure, it is the engineering execution that provides the results. By shifting the leadership of your FinOps strategy to the teams building the technology, businesses can transform cloud spend from an unpredictable overhead into a predictable, high-value investment.
Ready to stop reacting to your cloud bill and start engineering for value? Partner with BBD’s MServ team to implement the ARC framework and turn your cloud infrastructure into a strategic advantage. Contact BBD today to learn how our engineering-led FinOps approach can optimise your spend.
