[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. :slightly_smiling_face:

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.