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