[Work_Item] Denote provider entities represented in Billing Account and Sub Account

[flanakin]

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.

Different providers have different "types" of entities that may be needed to represent the BillingAccountId/Name and SubAccoundId/Name. Some providers even have multiple values that may be used. For example, Microsoft has 3 different types of entities that could be used for BillingAccountId depending on the type of agreement.

Use cases:

• Understanding what type of entity the billing account or sub account is.

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).

Create provider-specific "type" columns that describe what BillingAccountId and SubAccountId are.

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]

See Microsoft BillingAccountType, SubAccountType (documentation, PR #287).

Potential BillingAccountType values:

• "Management Account" (AWS)
• "Billing Account" (GCP)
• "Billing Account" (Microsoft EA)
• "Billing Profile" (Microsoft MCA/MPA)
• "Subscription" (Microsoft MOSA)

Potential SubAccountType values:

• "Member Account" (AWS)
• "Project" (GCP)
• "Subscription" (Microsoft)
• "Compartment" (OCI)

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)?

Following the ResourceId and ReosurceType pattern, add new BillingAccountType and SubAccountType columns.

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]

• Primary stakeholder: Michael Flanakin, Product Manager

Do you want to see this column in FOCUS?

Give it a 👍 below ↴

Comments are welcome and encouraged!

[mike-finopsorg]

While this will lead to a lot of duplicated data, I do see some major benefits in having values that users are likely to be looking for and it builds the association to the Billing/Sub Account.

[marc-perreaut]

Maybe I don't understand well, but would the values of columns BillingAccountType and SubAccountType be always the same for a given provider?
If yes, I find it not efficient from a data perspective.
Maybe there could be something outside the FOCUS dataset, like a manifest, to enable the documentation of the mapping between provider's data and FOCUS columns.

[flanakin]

@marc-perreaut Not necessarily. Specifically, BillingAccountType for Microsoft EA would be "Billing Account" and for MCA would be "Billing Profile". That's why I proposed adding this. It's trying to address the confusion where BillingAccountId does not refer to a "billing account".

With respect to SubAccountType, there's a question that pops up from time to time about whether that should be a subscription or a resource group in Azure. This would drive that clarity, but I'm 100% with you regarding it being the same value. I mainly included it for completeness and to force the conversation about how we want to handle it.

[thecloudman]

I think SubAccountType would be valuable if we move away from, for example Azure, SubscriptionName which changes to SubAccountName. Google have Project and AWS have Account as constructs for billing rollups. If the column SubAccontName is used across all three providers it would help to have a SubAccountType to specify Subscription, Account or Project?

[jpradocueva]

Agreed to move it to release v1.1 during Members meeting on April 25.

[shawnalpay]

EDIT 10.24: I have removed all the commentary I had previously provided in this post because I misunderstood the scope of this Work Item. I have moved that commentary over to newly-created Work Item #618. Apologies for the confusion!

[richwang99]

Resource Group in Azure is a critical information for cost allocation. Although it is not a billable item by itself, we use it together with Azure policy to enforce the tag of all resources within the resource group.
Some resources may have the same name, but belong to different resource groups. So Resource Group name will be essential.

[mike-finopsorg]

APJ FOCUS User Group call 23/October attendees raised this as very important for their work.

[shawnalpay]

I have updated my comment from yesterday to reflect the conversation we had around this topic in the Oct 23 APJ FUG call. The FOCUS project team will discuss further in an upcoming call. Thanks @thecloudman and @richwang99 for sharing your thoughts!

[jpradocueva]

Notes from the Maintainers' call on November 4:

Context: This task aims to enhance the billing structure by adding attributes that describe provider entities in billing accounts and sub-accounts, aiding practitioners in tracking and understanding multi-account setups.
Level of Effort Required: Low — The task primarily involves adding new columns to the existing model, which is a simple structural adjustment.
Level of Impact: Medium – Adding provider entity descriptions improves transparency and traceability, particularly in multi-account setups, enhancing the ability of practitioners to manage and report costs across complex account structures.

[jpradocueva]

Summary from the Maintainers' call on Nov 25

Context:
This work item focuses on specifying how provider entities (e.g., billing accounts and sub-accounts) should be represented in the FOCUS dataset.
Maintainers Assigned:
To be confirmed.
Task Force Assigned:
Task Force 2 (TF2).

Next Steps from the TF-2 call on November 27:

• [#317] Michael @flanakin : Prepare a list of current terms used by Azure, including any relevant hierarchies, to clarify the mapping of Billing Account and Sub Account IDs.
• [#317] David: Provide GCP’s equivalent terms and structures, including any tiered hierarchies or regional variations.
• [#317] Irena @ijurica : Research OCI’s use of tenancies and child tenancies to determine how they map to these fields.
• [#317] Karl @kk09v : Share industry best practices or standards for billing hierarchies and account structures, drawing parallels with non-cloud industries where applicable.
• [#317] Task Force: Add this discussion to the agenda for the next TF2 meeting to validate the approach and collect additional feedback.
• [#317] All Members: Review existing definitions and provide feedback on gaps or potential inconsistencies by the end of the week.
• [#317] Rob: Host a poll in the user group to gather practitioner input on the importance of adding these descriptors and their preferred format (metadata vs. new columns, mandatory vs optional).

[ijurica]

@flanakin Just a note that Google also has the concept of a Parent Billing Account and Subaccount.
Tim or David could probably share a bit more insights on this when the time comes.

[jpradocueva]

Action Items from TF-2 call on December 4:

• [#317] Michael @flanakin : Update the PR based on the poll results by mid-January (e.g., January 7) to allow for discussion during the TF-2 meeting.
• [#317] Michael @flanakin : Discuss the updated PR during the TF-2 meeting, and then present it and seek approval at the Members Meeting by January 23 (beginning of the Interim Consistency Review).

[jpradocueva]

Action Items from the Maintainers' call on December 16:

• [#317] Michael @flanakin : Update the proposal based on the results of the earlier poll and discussion.