[Work_Item] Document and add initial support for SaaS-centric concepts

[shawnalpay]

1. Problem Statement *

Describe the problem, issue, use case, or opportunity that this work item addresses.
Include practitioner quotes illustrating real examples a) of questions being asked by practitioners and b) value unlocked by answering these questions, if available.

• What is the problem?: Explain the context and why it needs resolution.
• Impact: Describe how the problem affects users, systems, or the project.

The FOCUS specification, so far, has chiefly been engineered to support cost and usage data as it is generated by cloud service providers (CSP) such as AWS, Azure, GCP, and OCI. There is a rich landscape of software-as-a-service (SaaS) providers in the FinOps landscape whose billing models differ in various ways from CSPs -- and as currently constructed, FOCUS does not yet provide an onramp for those SaaS providers (unless they presumably create a host of custom columns to support their concepts).

2. Objective *

State the objective of this work item. What outcome is expected?

• Success Criteria: Define how success will be measured (e.g. metrics and KPIs).

Analyze a set of major SaaS providers and determine the common SaaS-centric concepts that could be implemented in a future version of the spec. Time permitting, we would then attempt to augment the specification to establish an MVP of those concepts within that release, with further support added in future releases.

3. Supporting Documentation *

Include links to supporting documents such as:

• Data Examples: [Link to data or relevant files; DO NOT share proprietary information]
• Related Use Cases or Discussion Documents: [Link to discussion]
• PRs or Other References: [Link to relevant references]

Related issue: #337

Documentation TBD

4. Proposed Solution / Approach

Outline any proposed solutions, approaches, or potential paths forward. Do not submit detailed solutions; please keep suggestions high-level.

• Initial Ideas: Describe potential solution paths, tools, or technologies.
• Considerations: Include any constraints, dependencies, or risks.
• Feasibility: Include any information that helps quantify feasibility, such as perceived level of effort to augment the spec, or existing fields in current data generator exports.
• Benchmarks: Are there established best practices for solving this problem available to practitioners today (e.g. mappings from existing CSP exports that are widely used)?

We propose performing a time-boxed analysis of SaaS concepts that will generate a set of recommendations of SaaS-centric concepts to be implemented in a future release. If there is time, we would then initiate that work and establish an MVP of SaaS-centric concepts in that release, to be fleshed out further in future releases (similar to how FOCUS 0.5 established an MVP for CSP-centric concepts).

5. Epic or Theme Association

This section will be completed by the Maintainers.

• Epic: [Epic Name]
• Theme: [Theme Name, if applicable]

TBD

6. Stakeholders *

List the main stakeholders for this issue.

• Primary Stakeholder: [Name/Role]
• Other Involved Parties: [Names/Roles]

TBD

[mike-finopsorg]

APJ FOCUS User Group call 23/October attendees raised this as highly desired.

[shawnalpay]

Thanks everyone for participating in today’s SaaS ideation discussion! I did my best to capture the live discussion in this doc.

Some topics for consideration before we meet again:

• What do we mean when we say SaaS?
  • What is the definition of SaaS we’ll carry forward in this discussion? (Thanks for that, Michael; very important subject to define.)
• What are the providers we wish to analyze for our MVP?
  • This should be a blend of highest competence (i.e. one of us works for that provider), core competence (i.e. one of us uses that provider extensively), and others (i.e. one of us feels this provider is important to consider for an MVP).
• What is the full list of billing models we might consider for our MVP?
  • We brainstormed a list, and it’s in the doc — but we should all think about the list and be prepared to discuss again.
• What is the minimum viable product for v1 support of SaaS concepts?
  • At this stage, let’s make sure we understand the full landscape at a high level — but we can’t boil the ocean in a single release.

We agreed to the following action items:

• Define what “SaaS” means.
• Define the MVP set of SaaS providers to analyze.
  • We have neither the time nor the resources to analyze them all, of course. Deciding which to include will be an inherently subjective exercise — but let’s use a mixture of our core competencies and materiality to determine which to include for v1.
• Define the billing models.
  • We did a great job of starting to sketch these out in today’s call, but we need to start hardening these definitions for the purposes of the next action item.
• Define the intersection of billing models and providers.
  • I have created a matrix skeleton in this Google Sheet (screenshot below). I hesitate for us to go too far with this without more properly defining the models — but feel free to start filling it in, and it could serve as a good discussion artifact for our next meeting.
• For the MVP set of SaaS providers, perform a gap analysis of what concepts are disregarded if those providers tried to implement FOCUS today.
  • This is probably the biggest effort, and we’ll want to break these up and assign per person (and competency).

Please put your hand up if you can own any of these! I can only help keep this topic on rails; I am not someone who possesses core competency here. 🙂

The last thing I’ll say is: at this stage, let’s stay focused on concepts, not execution. This is a big topic with lots of potential rabbit holes, so let’s try to stay high-level and avoid the “how” until we’re aligned on the “what”.

I will sync with the team to determine which TF will absorb this topic and let you all know ASAP. In the meantime, let me know if you have any questions or feedback. Thanks!

[jpradocueva]

Documents

• Ideation document
• SaaS Invoice Issuer Question
• Billing model and Provider Matrix

[jpradocueva]

Action Items from TF-2 call on Oct 23:

• [#616] Riley @rileyjenk : Develop initial taxonomy of SaaS billing models and provider list.
• [#616] Irena @ijurica : Define parameters and attributes relevant to SaaS billing models for FOCUS adaptation.
• [#616] Team: Facilitate outreach to high-priority SaaS providers, including Datadog, Twilio, and GitHub, to validate model applicability and gather additional requirements.

Action Items from TF-2 call on Oct 30:

• [#616] Riley @rileyjenk : Draft examples of “flat fee” and “commit with overage” models, including SaaS provider contexts.
• [#616] Irena @ijurica : Review and update the commitment matrix with feedback from this meeting.
• [#616] Andrew @aqu-erp : Gather examples of usage-based and tiered billing models from additional SaaS providers.

[jpradocueva]

Action Items from Members' call on Oct 31:

• [#616] All TF2 members: Review and comment on the proposed billing matrix.
• [#616] Shawn @shawnalpay : Lead the addition of further SaaS-specific billing examples for the matrix.

[jpradocueva]

Notes from the Maintainers' call on November 4:

Context: The task expands the specification to include SaaS services, a growing area in FinOps. SaaS billing and usage data have unique characteristics that require tailored support in the spec.
Level of Effort Required: Very High — Supporting SaaS in the spec involves substantial adjustments to account for varied billing and usage models, which differ significantly from IaaS and PaaS.

[jpradocueva]

Comments extracted from the TF-2 minutes on November 6:

List of Commitment Attributes

Commitment Model

• Context: The Commitment Model addresses the nature of the commitment made by the customer, such as "burn-down" (where a specific amount is used up over time) or "build-up" (where charges accrue based on usage).
• Discussion Summary: The group agreed on defining different commitment models, particularly burn-down, build-up, and perpetual, to represent the diverse approaches SaaS providers use for commitments. They discussed the applicability of these models across various SaaS offerings.
• Agreement: The team decided that these commitment types should be documented and included as options within FOCUS, though with flexibility for providers to select models that best represent their business practices.

Commitment Interval

• Context: Commitment Interval refers to the recurring time frame over which commitments are evaluated, such as hourly, monthly, or yearly.
• Discussion Summary: Participants discussed aligning the commitment interval with billing periods and the potential need for customization to handle SaaS-specific billing cycles.
• Agreement: The group agreed to support multiple commitment intervals, potentially including flexible and variable options to address different SaaS billing cadences.

Commitment Reconciliation

• Context: This term relates to reconciling any remaining or unused commitment at the end of an interval. Examples include unused units or incurred true-up charges.
• Discussion Summary: The discussion focused on the need to handle unused amounts for burn-down models and true-up costs for build-up models. Some members raised the idea of representing this reconciliation in the FOCUS data set to improve clarity.
• Agreement: Consensus was that FOCUS should offer guidance on handling these scenarios but not mandate specific reconciliation processes.

Purchasing/Acquisition Attributes

Purchasing Model

• Context: The purchasing model captures the types of transactions, such as pay-as-you-go, flat fees, or hybrid models.
• Discussion Summary: The group identified specific SaaS purchasing models, emphasizing the need to differentiate between standard models like flat fees and more complex structures that combine multiple components (e.g., pay-as-you-go plus flat fee).
• Agreement: FOCUS should document these variations in purchasing models, offering clear definitions that SaaS providers can reference.

Commitment/Discount Accessibility

• Context: This attribute reflects whether a commitment or discount is publicly available or only accessible through negotiation.
• Discussion Summary: Members discussed including a method to flag whether a discount or commitment is standard or customized, supporting better transparency for users.
• Agreement: The attribute will be optional but defined within FOCUS to allow providers to indicate if a commitment or discount is restricted.

Commitment Renewal Mechanism

• Context: This defines whether a commitment renews automatically, manually, or under specific conditions.
• Discussion Summary: Participants discussed scenarios like automatic renewal at the end of a term versus manual renewal based on customer needs. They also mentioned instances where renewals may come with adjusted terms or upcharges.
• Agreement: The renewal mechanism will be included as a descriptive attribute, providing clarity on whether commitments automatically renew or require intervention.

Non-currency Commitment Support (e.g., Tokens)

• Context: Some SaaS providers use tokens or other non-currency units to represent commitment, with exchange rates that link tokens to actual usage or spend.
• Discussion Summary: The conversation centered around the need to document non-currency commitments, particularly in cases where providers use tokens as commitment units. There was also discussion on how these tokens might be exchanged or applied across various SKUs.
• Agreement: FOCUS will document non-currency commitments and explore options for exchange ratios, while considering optional fields to track tokens without overwhelming users who do not need this functionality.

Pricing Attributes

Pricing Model

• Context: This includes various pricing structures used by SaaS providers, such as tiered, seat-based, or dynamic models.
• Discussion Summary: The group discussed the diversity of SaaS pricing models and whether these models need further categorization or refinement within FOCUS. Participants suggested revisiting current categories to ensure they fully represent SaaS structures.
• Agreement: The FOCUS specification will expand and clarify available pricing models, allowing for SaaS-specific options like tiered and seat-based pricing.

Tiered Pricing Support

• Context: Some SaaS services offer pricing that varies based on usage tiers, encouraging greater use through volume discounts.
• Discussion Summary: Tiered pricing was highlighted as an important pricing model, especially for SaaS offerings that benefit from economies of scale.
• Agreement: The team agreed to include support for tiered pricing within FOCUS.

Free-tier Support

• Context: Free tiers offer customers a limited amount of service without charge, common in SaaS as an introductory or trial model.
• Discussion Summary: Members discussed how to track free-tier usage within FOCUS, noting that some free-tier metrics may still require tracking if they impact cost or usage limits.
• Agreement: Free-tier support will be added as an optional field, with guidance on how to report usage and costs if a user surpasses the free-tier limits.

Invoicing Attributes

Invoicing Models

• Context: This concept relates to the different approaches for invoicing, such as billing by usage, periodic flat fees, or mixed methods.
• Discussion Summary: The discussion explored how SaaS invoicing models often differ from traditional CSP models, especially when involving third-party marketplaces.
• Agreement: Invoicing models will be documented to allow SaaS providers to clarify their invoicing methods, with flexibility to support varied invoicing structures.

Other

Billing Dataset Granularity

• Context: This refers to the level of detail available in the billing dataset, which can vary significantly between high-level summaries and detailed usage records.
• Discussion Summary: The team discussed the importance of allowing flexible granularity levels, given the varying needs of SaaS providers and customers. Participants noted that overly granular data could lead to excessive complexity, while insufficient granularity might limit cost transparency.
• Agreement: FOCUS will provide guidance on dataset granularity, recommending best practices for providers but not enforcing a strict standard.

[jpradocueva]

Action Items from the TF-2 call on November 6:

• [#616] Irena @ijurica : Develop a proposal for adding SaaS-specific commitment and pricing models, focusing on optionality to avoid complexity.
• [#616] Andrew @aqu-erp : Investigate token-based usage models in SaaS billing and draft initial documentation for potential integration into FOCUS.
• [#616] Riley @rileyjenk : Review and refine definitions for billing intervals, commitment types, and renewal mechanisms, focusing on alignment with SaaS practices.

[jpradocueva]

Comments from the Members' call on November 7:

#616: Task Force 2 concentrated on SaaS-related concepts, focusing on pricing and purchasing models. The work includes defining attributes and values for SaaS items to improve data alignment in FOCUS.
Billing Model Provider Matrix (· Spreadsheet: 24.10.23 Billing Model Provider Matrix): This spreadsheet outlines various attributes, such as price models, purchasing models, and commitment structures for SaaS billing. TF-2 discussed further detailing these attributes and prioritizing specific properties for an MVP (Minimum Viable Product) scope in v1.2. They agreed to finalize a subset of attributes for the initial release and carry over the remaining elements.

Action Items:

[#616] Irena and TF-2 Members: Refine and prioritize the billing model attributes and confirm an MVP subset for SaaS concepts.

[jpradocueva]

Action Items from the TF-2 call on November 20:

• [#616] Chris @cnharris10 : Review Datadog’s attributes for marketplace exclusions and update the spreadsheet.
• [#616] Irena @ijurica : Confirm definitions for "minimum fee" and "automatic renewal" and follow up with Riley for clarification.
• [#616] Irena @ijurica : Update the spreadsheet for the OCI use case.
• [#616] Shawn @shawnalpay : Update the summary document with definitions and categorize attributes needing refinement.
• [#616] Michael @mike-finopsorg : Update the spreadsheet for GitHub and Microsoft 365 use cases
• [#616] Riley @rileyjenk : Update the spreadsheet for Domo use case
• [#616] Larry @ljadvey : Update the spreadsheet for Twilio use case
• [#616] George @gparker-at-sf : Update the spreadsheet for Salesforce use case
• [#616] All members: Provide feedback on SaaS provider attributes for Twilio, Domo, Salesforce, and OCI.

[jpradocueva]

Action Items from the Members' call on November 21:

• [#616] Shawn @shawnalpay : Assign a task force to address SaaS support requirements and attributes.

[jpradocueva]

Summary from the Maintainers' call on Nov 25

Context:
This work item involves introducing and defining SaaS-centric concepts, enabling the specification to handle SaaS-related billing data effectively.
Maintainers Assigned: (SaaS-related expertise).
Chris, Michael, Riley Tim Wright, Zach
Task Force Assigned:
Task Force 3 (TF3).

[jpradocueva]

SaaS Properties Overview from the TF-3 call on Nov 29:

Please note that only FOCUS members can access this SaaS Properties Overview.

[jpradocueva]

Action items from TF-3 all on Nov 29:

• Commitment Model: [#616] Michael: Draft initial definitions for commitment models and circulate them for review.
• Commitment Interval: [#616] Irena: Propose updated definitions and examples for commitment intervals.
• Purchasing Model: Assign [#616] Michael to draft updates to the schema, incorporating new purchasing models.
• Negotiated Discount Category: [#616] Irena to propose documentation strategies for negotiated discounts in the schema.
• Commitment Replenishment (Top-Up) Support Flag: Assign [#616] Michael to gather examples from providers to assess the relevance of top-up mechanisms.
• Commitment Renewal Mechanism: [#616] All members to review current provider capabilities for renewal options.
• Non-Currency Commitment Support (:e.g., Tokens): Assign [#616] Irena to evaluate whether token support should be included in the FOCUS schema.
• Non-Currency Commitment Category: Assign [#616] Michael to propose documentation updates for non-currency commitment categories.
• SKU Usage Ratio (Exchange Rate): Assign [#616] All members to review and refine descriptions for SKU usage ratio fields.
• Commitment – SKU Applicability: Assign [#616] Michael to draft updates reflecting SKU applicability in the schema.
• SKU – Commitment Eligibility: Assign [#616] Irena to propose updates on SKU commitment eligibility for the next review.
• Pricing Model: [#616] Michael: Update the pricing model schema to include examples and ensure alignment with related attributes.
• FOCUS: Pricing Category: [#616] All members: Review and confirm subcategories for tiered and committed pricing.
• Tiered Pricing Support: [#616] Irena: Propose examples and schema updates for tiered pricing.
• Free-Tier Support: [#616] Michael: Draft a proposal for documenting free-tier models and their relevance.
• Minimum-Fee Support: [#616] Irena: Propose updates to distinguish minimum-fee models from other pricing attributes.
• Block Pricing Support: [#616] All members: Provide examples of block pricing to refine definitions.
• Invoicing Model: [#616] Irena: Propose schema updates to include invoicing model classifications.
• Payment Option: [#616] Michael: Draft definitions and examples for each payment option.
• Billing Interval: [#616] Irena: Propose updates to clarify the relationship between billing intervals and billing dataset granularity.
• Billing Period Start: [#616] Michael: Draft descriptions and examples for billing period start scenarios.
• Unit Prices & SKUs Availability: [#616] Irena: Propose updates to ensure unit price availability is clearly documented in the schema.
• Commitment Quantity & Billing Dataset: [#616] Michael: Draft schema updates to capture commitment quantities effectively.
• Billing Dataset Granularity: [#616] Irena: Propose updates to clarify billing dataset granularity and its relationship to commitment intervals.
• Commitment Interval-Related Concerns: [#616] All members: Review and propose solutions for aligning commitment intervals with dataset granularity.

Ignore for Now

• Commitment Reconciliation: [#616] Irena: Propose updates to the schema to document reconciliation mechanisms explicitly.
• Billing Method: [#616] Michael: Propose schema updates to clarify billing method classifications.
• Token – SKU Usage Ratio (Exchange Rate): [#616] All members: Provide examples from providers that support token-based commitments.
• Token – Billing Currency Purchase Ratio (Exchange Rate): [#616] Irena: Draft schema updates to address multi-currency scenarios.
• FOCUS: Commitment Discount Unit: [#616] Michael: Propose schema updates to clarify commitment discount unit definitions.

[jpradocueva]

Action Items from the Members' call on December 5:

• [#616] Volunteer: Draft documentation outlining SaaS-centric concepts and share with the group for review.
• [#616] Michael @flanakin : Continue discussions with GitHub and other SaaS providers to gather input on billing structures and attributes.
• [#616] Irena @ijurica : Ensure alignment of SaaS updates with ongoing work items, including [Work_Item] Add SKU and SKU Price properties (e.g. term, tier, SKU region) #619 (SKU properties) and [Work_Item] Define change management principles to determine backwards compatibility #643 (compatibility principles).
• [#616] All members: Review the draft documentation and provide feedback during the next TF3 meeting.
• [#616] Chris @cnharris10 : Develop a proposal for introducing optional columns for SaaS-specific attributes in future updates.

[jpradocueva]

Action Items from the TF-3 call on December 6:

• [#616] Chris: Analyze 3-5 vendors or internal examples where the FOCUS specification does not fully address their pricing models.
  Capture details of the vendors' pricing models to highlight gaps in the current specification.
• [#616] Riley: Select 3-4 vendors and convert their billing data as closely as possible to the FOCUS specification.
  Identify and flag any requirements that are not currently supported by the FOCUS spec.
• [#616] George: Follow a similar approach to Riley’s by identifying gaps in supported scenarios, particularly focusing on Salesforce-related use cases.
  Provide three high-priority use cases relevant to Salesforce or similar vendors.
• [#616 ] Todd and Chris: Collaborate to analyze Datadog-specific billing data, particularly focusing on:
  Indirect billing through marketplaces like AWS, Google, and Azure.
  Datadog’s own marketplace and its vendor billing models (e.g., seat-based, usage-based, flat fees).
  Focus on invoice reconciliation and identifying 8 key columns needed for this purpose.
  Highlight any gaps or unique requirements in the context of Datadog’s billing structures.
• [#616] All members: Review the shared spreadsheet and flag critical gaps in data representation.

[jpradocueva]

Action Items from the Maintainers' call on December 9:

• [#616] SaaS representatives to bring focused data samples for reconciliation discussions.
• [#616] Chris @cnharris10 to refine survey questions and coordinate with SaaS representatives to gather sample data.
• [#616] Riley @rileyjenk to explore reconciliation mechanisms between SaaS and CSP data sources.

[jpradocueva]

Action Items from the Task Force 3 call on December 13:

• [#616] Riley @rileyjenk and George @gparker-at-sf : To draft an example of non-monetary billing units for SaaS providers (e.g., Snowflake, Domo) and explore their integration into the schema.
• [#616] Alex @ahullah /Todd @toddkblake : Create and share a first draft of simplified contractual commitment metadata examples.
• [#616] Tim @timwright2000 : To review existing CSP reconciliation mechanisms and provide insights on aligning SaaS reconciliation processes with them.
• [#616] Tim @timwright2000 : Provide a description of how subscription payments are currently handled in GCP’s detailed export, including metadata, amortization processes, and data structures.
• [#616] Chris @cnharris10 : To draft a simplified narrative describing key SaaS billing concepts and how they map to the schema
• [#616] All Members: Review and provide feedback asynchronously on Slack regarding use case scenarios and example drafts shared before the next meeting.

[jpradocueva]

Action Items from the Maintainers' call on December 16:

• [#616] Riley @rileyjenk : to bring examples of token-based quantities across providers
• [#616] Chris @cnharris10 , Todd @toddkblake (Datadog): Provide contract-based examples to illustrate different burn-down and burn-up views.