Is FOCUS expansive across all billing data?

[cnharris10]

Description

Should FOCUS encapsulate all possible billing data, inclusive of a 1 line item, $1 invoice up through a 1 cloud's billion line item cost and usage dataset?

1. Should the smallest SaaS vendor be required to implement 39 FOCUS columns (of which the mass majority are NULL?)
2. Can a SaaS vendor pick which columns they want to use? Which ones?

[kk09v]

In my mind, the question is not whether FOCUS will encapsulate all possible billing data, but rather where the line is between "in-scope" and "out-of-scope."

I believe everyone working on FOCUS was doing so with their technology (IaaS > PaaS > SaaS) bills in mind. FOCUS was not intended for the company that does the coffee service to my building nor for a construction company to bill me for the concrete they poured. However, the challenge is that everything today touches technology or is "technology enabled" today, so it makes the line fuzzy. For example, what if the concrete the construction company poured was for a data center.

Given the how the effort on 1.0 was structured, my current opinion is that IaaS, PaaS, and SaaS are in-scope. When providers of those services provide other related services, those other services should ideally be included with the understanding that those charges are included not because we think that type of work is always in-scope for FOCUS but rather because excluding those charges would lead to an inaccurate understanding of the spend with that provider.

This is not to say that billing data which is out of scope cannot be provided in FOCUS format nor that this will continue to be out of scope in future versions. With later versions, I suggest we take the horizontal squad model from 1.0 where teams took the lens of a specific type of offering (e.g. SaaS) and intentionally thought about how FOCUS would apply to those cases, offering recommendations for implementation and making any minor spec changes that may be required to support this.

[udam-f2]

One note: Even for standard SaaS and PaaS not coming from major CSP-type providers, they provide a standard single or monthly PDF invoice as billing information. This means we either need to make a distinction that FOCUS only applies to 'detailed billing data' OR relax some requirements to allow both types of cost data to be produced or converted to FOCUS.

[flanakin]

I'm all for this as long as we think about it from a practitioner perspective. I like the idea of compliance levels or maybe a "light" version of the spec that practitioners can opt for that targets only a core set of columns.

[udam-f2]

I am looking for community engagement and feedback on this topic. We have two known options here and are looking for feedback on those options and other options the group should consider.

To be a FOCUS-compatible data set, here are the current options:

1. All columns marked as required need to be provided. If those columns don't allow null, valid values must be provided. If a column is nullable, and a column or a set of columns is not relevant to a provider, all columns still must be provided with nulls for each row.

2. Relax the 'column required' requirement and introduce two levels of FOCUS-compatible data. A full/detailed data set that requires all columns and a 'basic' or 'summary' FOCUS billing data set that only requires a minimum set of columns that any provider should be able to provide a sensible value for. We have taken an initial crack at marking what columns seem to be must-haves and some others that seem like they should be considered. Please review the WIP column list for a possible basic data-set here. Please comment directly on the sheet if you have suggestions

3. If there are other options that should be evaluated, please comment below.

[cnharris10]

I'm not particularly in favor of either solution solely but I think the option around limiting a small number of required columns is the better experience for non-technical practitioners who (I presume) outnumber technical practitioners. Asking non-technical practitioners to add a majority of columns that contain only null values feels less optimal than asking fewer technical practitioners to merge schemas containing subsets of normalized columns. In the end, both solutions around merging schemas may lead to lots of columns full of null values but at least the onus falls on the smaller but technical group to implement rather than the latter group.

[thecloudman]

I believe there is a case for multiple options. Some SaaS providers have a fixed monthly bill which can be a fixed price per contract or fixed price per seat, some have fixed price with variable spending within the platform for example messaging services such as twillio or sendgrid, so to have a subset of columns would be the right way. I think it should be down to the SaaS provider to choose but we should stipulate a minimum requirement. We could at least have List Price, Pricing QTY, Usage QTY, Negotiated Discounts, Commitment Discounts, Unit price, Meter category, Pricing Category, Charge Category, ChargeSubCategory for example.

[udam-f2]

I'm attempting to summarize the open discussion topics here so we can review at the member meeting. This may not be a complete set. Please visit the spreadsheet here for the most up-to-date and complete set of comments raised by the community.

Feels like we're converging on the need for a paired-down version of FOCUS that still attempts to provide a minimum set of columns - since it would allow providers that don't necessarily provide detailed billing data to still provide their data in a format that consumers can relatively easily integrate with their detailed billing datasets (e.g. CUR, Azure billing data, BQ export etc.).

There are differing views on which columns should be included or excluded. Capturing a summary here:

Time:

• Do both billing and charge periods need to be specified? OR should one be prioritized?
• Periods are defined using a start and end column in FOCUS. Are both the start and end timestamps needed or would the start value alone be sufficient?

Cost & unit price:

• Do we need each of the cost metrics OR would providing a subset be sufficient? E.g. if only the BilledCost was provided ('cash-basis' cost).
• Should ListUnitPrice and pricing unit be included?

Usage:

• Should UsageQuantity/UsageUnit be captured in the minimum set?

Other:

• Should charge and pricing category information be captured?
• Should resource, sku / sku price, or service type information be captured?

General questions:

• Do we need to maintain transitive dependencies? Or should the language on those column definitions be updated to make exceptions for basic data sets? For example, SKUPriceId, ListUnitPrice, PricingQuantity, and others have dependencies on other columns OR are dependencies for other columns (though many are nullable as it is defined currently).

If there are other questions that should be answered or discussed, please comment below.

[udam-f2]

FOCUS Task Force 1 meeting time will be used to discuss this issue on: Tue Feb 12th at 16:00 / 4:00 pm GMT Tel Aviv, Israel: Tue 18:00 / 6:00 pm Paris, France: Tue 17:00 / 5:00 pm EST, USA: Tue 11:00 / 11:00 am PST, USA: Tue 08:00 / 8:00 am Mumbai, India: Tue 21:30 / 9:30 pm Sydney, Australia: Wed 03:00 / 3:00 am

Those who have assigned the issue to themselves as a way of showing interest in contributing (Thanks!) - please join (zoom details are in your calendar invite).

You must have a signed FOCUS CLA in order to join.

[jpradocueva]

331

[udam-f2]

The following columns have been selected as FOCUS Essential requirements per the last 2-3 discussions:

• BillingPeriodStart
• BillingPeriodEnd
• ChargeDescription
• ChargeFrequency
• ChargePeriodStart
• ChargePeriodEnd
• ChargeCategory
• BilledCost
• EffectiveCost
• InvoiceIssuerName
• BillingAccountId
• ServiceCategory
• ServiceName
• BillingCurrency
• PricingUnit
• PricingQuantity

The following have been discussed and are currently not considered an essential requirement but still need to be finalized.

• ListCost
• ProviderName
• PublisherName
• ResourceId
• SKUId
• SKUPriceId

If anyone wants to co-author updates for the settled columns above, please update on the comments on this issue. We will review the updates at the member call on Thursday (UTC).