Beyond the Bill: Scopes, Technology Categories, and Where This Course Fits
~20 min read · Text + interactive
By the end of this lesson, you can…
- Explain why "Technology Value" isn't a fifth FinOps Domain, and place it correctly inside the Framework's existing Scopes and Technology Categories elements.
- Distinguish this course's job from Quantify Business Value's job, without re-learning the Understand/Quantify/Optimize/Manage vocabulary.
- Name all five FinOps Technology Categories and explain why this course covers four of them.
- Describe what a FinOps Scope is and why the Foundation formalized it as a core Framework element.
- Recognize Executive Strategy Alignment and Intersecting Disciplines as the two headline additions in the 2026 Framework update, and what each one actually changes.
"Technology Value" Isn't a Fifth Domain
The FinOps Framework organizes everything a practice does into four Domains, and none of them is called "Technology Value":
Understand Usage & Cost
Gather, categorize, and report on how the organization actually uses technology.
Quantify Business Value
Connect usage and cost to budgets, forecasts, and unit economics — the KPIs leadership reads.
Optimize Usage & Cost
Ensure resources are used only when valuable, and purchased at the lowest acceptable cost.
Manage the FinOps Practice
Keep people, process, and technology aligned — governance, education, and continuous improvement.
"FinOps Certified: Technology Value" is the Foundation's own certification path, and it's built across two other Framework elements entirely: Scopes and Technology Categories. Both of those cut across all four Domains above — you still Understand, Quantify, Optimize, and Manage a SaaS portfolio or a data center, exactly like you do public cloud. What changes isn't the loop. It's what you're running the loop against.
How This Differs From Quantify Business Value
If you've taken Practitioner, Week 3's Quantify Business Value domain already taught you to forecast, budget, and build unit economics — but it did that almost entirely against cloud spend, because that's where the worked examples came from. Nothing in that domain's own definition restricts it to cloud; it's just that most FinOps content, this platform's Practitioner course included, treats "FinOps" and "public cloud" as synonyms.
This course doesn't re-teach forecasting or budgeting mechanics. It takes the same discipline and points it at spend that was never cloud to begin with:
| Quantify Business Value (Practitioner, Week 3) | This course | |
|---|---|---|
| What it forecasts/budgets | Cloud spend against a growth or usage curve | SaaS renewals, data-center capex cycles, data-platform credit burn |
| Unit economics example | Cost per API call, cost per customer | License Utilization Rate, TCO per workload, cost per query |
| Assumes | You already know Understand/Quantify/Optimize/Manage | You already know Understand/Quantify/Optimize/Manage, plus this course's own vocabulary each week |
Most practitioners need both. Few need only one.
The Five FinOps Technology Categories
Technology Categories are the Framework's way of naming the different types of technology spend an organization carries — each with its own procurement model, pricing construct, and cost-visibility problem. As of the 2026 Framework, there are five:
- Public Cloud
- AWS, Azure, GCP, OCI — resource-based, pay-as-you-go billing you already know from Practitioner and FOCUS.
- SaaS
- Software-as-a-Service: Salesforce, Workday, Slack, and every other seat- or subscription-priced tool procured outside a central cloud account.
- Data Center
- Owned or colocated on-prem infrastructure — capex-driven, with none of cloud's pay-as-you-go elasticity.
- Data Cloud Platforms
- Consumption-priced data and analytics platforms — Snowflake, Databricks, BigQuery — billed in credits, DBUs, or slots rather than provisioned resources.
- AI
- Token- and inference-priced AI spend, with its own risk and experimentation profile. Out of scope for this course — see this platform's AI Value course.
This course covers the first four. AI gets its own dedicated course because its cost drivers (token pricing, GPU scarcity, experimentation-heavy budgets) don't fit cleanly next to the other four's steadier procurement patterns — trying to cover all five in six weeks would shortchange every one of them.
What a FinOps Scope Is, and Why 2025 Added It
A FinOps Scope is a defined segment of spending — across any Technology Category — aligned to a business construct like a product, cost center, or environment. It's the thing that gives a number a reason to exist: not "we spend $340,000/month on the tracking platform," but "we spend $340,000/month on the tracking platform, and it's judged against on-time delivery rate."
Before 2025, the Framework had Domains, Capabilities, and Personas, but no formal construct for saying which slice of spend, mapped to which outcome, engages which of those. The Foundation added Scopes as a core Framework element in 2025 specifically to close that gap — and it's what makes it possible to apply the same rigor to a SaaS renewal that you'd apply to a cloud commitment, because both can now be defined as a Scope with the same shape: a business construct, the Personas involved, the Capabilities in play, and the KPIs that define success. Week 2 builds one of these end to end, using public cloud as the reference case since you already know its playbook.
The 2026 Update: Two Things Worth Knowing Now
Two more additions landed in the 2026 Framework update. You'll use the first one directly in Week 6; the second one is context for the rest of this course.
01Executive Strategy Alignment
A new capability inside Manage the FinOps Practice, formalizing FinOps as a strategic partner to leadership rather than an operational reporting function. It covers connecting spend to strategic priorities, supporting multi-year investment and vendor decisions, facilitating cost/speed/quality trade-offs across competing initiatives, and giving executives real decision support instead of a retrospective cost report.
02Intersecting Disciplines
A capability recognizing that FinOps doesn't own every allied function it touches — IT Asset Management, IT Financial Management, Software Asset Management, IT Security, Enterprise Architecture, and Sustainability among them. Rather than treating these as competing silos, the 2026 Framework treats them as functions FinOps coordinates with, each keeping its own ownership.
Quick Check: Which Element Does This Belong To?
Is that the right fix? If not, where does this material actually live in the Framework?
Reveal my answer
No — and this course's whole first section exists to correct exactly this instinct. Technology Value isn't a Domain at all; it's the Foundation's certification path across two existing Framework elements — Scopes and Technology Categories — that already sit underneath all four Domains. SaaS and data-center work don't need a new place to live in the Framework. They need a Scope (this course's core tool) that names the business outcome, and a Technology Category (SaaS, data center, or data cloud platforms) that names the procurement and pricing model in play. Understand, Quantify, Optimize, and Manage all still apply — you're running the same four Domains against a different Technology Category, not inventing a fifth.
Exercise: Build a One-Page Scope Inventory
The case study: Northfield Logistics, a mid-size logistics company, is a fictional composite used throughout this course to keep every exercise concrete. Here's a rough map of where its money goes across the four Technology Categories this course covers.
| Category | What it actually is | Rough scale | Who currently owns it |
|---|---|---|---|
| Public cloud | AWS-hosted shipment-tracking platform: real-time GPS ingestion, customer-facing ETAs | ~$340,000/mo | Engineering |
| SaaS | Salesforce, Workday, Slack, Zoom, Asana, Monday.com, and roughly 40 more tools nobody has fully inventoried | ~$115,000/mo (estimated) | No single owner — spread across Sales Ops, HR, and individual team budgets |
| Data center | Two owned facilities running the warehouse management system (WMS) behind pick, pack, and ship | Several server racks per site | Facilities + a small on-prem infrastructure team |
| Data cloud platform | Snowflake pipelines feeding the route-optimization model used for fuel and driver-hour planning | Dozens of active pipelines | Data Engineering |
For each of the four rows, name the one business outcome that Scope should be judged against — not a cost target, an outcome. Then reveal to compare your answers.
Your own deliverable: build this same one-page table for your own organization (or keep using Northfield Logistics if you don't have a real one handy) — every Technology Category with real money behind it, mapped to the business outcome it should be judged against.
Reflection
Pick one non-cloud technology cost at your own company — a SaaS tool, a data center, or a data platform bill. If someone asked you today what business outcome it should be judged against, could you answer in one sentence? If not, that gap is exactly what a Scope is for.
Putting it together
Technology Value isn't a new Domain to learn — it's the same Understand/Quantify/Optimize/Manage loop from Practitioner, aimed at Technology Categories most FinOps content skips. Scopes are the construct that gives any of those categories a business reason to exist, formalized as a core Framework element in 2025. Executive Strategy Alignment and Intersecting Disciplines, both new in 2026, round out how this material connects upward to leadership and sideways to allied teams. Week 2 puts Scopes to work for real, using public cloud — the category you already know — as the reference pattern for every category that follows.
Week 2: Writing a FinOps Scope
The anatomy of a Scope, using public cloud as the reference case, plus how Scope ownership shifts as spend moves from engineering-run cloud into procurement-run SaaS or facilities-run data center.