[Work_Item] Add Account / Resource hierarchy attributes

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

FOCUS currently carries some, but not all, of the elements forming a multi-level Account and/or Resource hierarchy. See the following screenshot from this Google Sheet:

FOCUS implementation of those levels as of 0.5 (and still true in 1.1):

• Level 1 is already represented as BillingAccountId.
• Level 2 is not in the spec.
• Level 3 is already represented as SubAccountId.
• Level 4 is not in the spec.
• Level 5 is not in the spec.
• Level 6 is already represented as ResourceId.

Use case:

• Analyze cost and usage by Account and Resource groupings such as Resource Group and Folder.

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

Add attributes to the specification that facilitate the grouping of cost and usage by elements such as Azure Resource Group and GCP Folder.

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]

Existing data elements across existing FOCUS providers are available here. This document requires more refinement. We also need to add examples of this data.

Previous discussions:

• 102

• 301

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

Add a few columns to the specification that represents the missing levels in the above graphic. The levels and possible names:

• Level 2: SubAccount Class
• Level 3: SubAccount Group
  • It's possible that we combine Levels 2 and 3, depending on need and interest.
• Level 5: Resource Group

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]

• Richard Wang @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 Fuller @mike-finopsorg
  • APJ FOCUS User Group call 23/October attendees raised this as very important for their work.

[shawnalpay]

@richwang99 @thecloudman @mike-finopsorg

I misunderstood the purpose of #317! That item was meant to carve out descriptions of what provider-specific entities are in the existing columns of BillingAccountId and SubAccountId -- not to add new columns. I have now created this new Work Item to represent the augmentation of the Account / Resource hierarchy to include constructs like Resource Group. Please redirect your feedback here!

[ijurica]

Just a note about OCI:

• Tenancies can have child tenancies.
• You can create (sub)compartments within compartments, allowing for hierarchies that are six levels deep.

[shawnalpay]

Just a note about OCI:

• Tenancies can have child tenancies.
• You can create (sub)compartments within compartments, allowing for hierarchies that are six levels deep.

@ijurica Do you believe that it would be sufficient to present the highest level of this entities and leave the entire parent-child hierarchy to a provider-specific column, or would that be insufficient?

[jpradocueva]

Notes from Maintainers' call on November 4:

Context: This item aims to enhance transparency by adding attributes for resource and account hierarchy, enabling practitioners to organize and analyze costs in multi-account environments effectively. Level of Effort Required: Medium — Adding these attributes requires a structured approach to ensure they’re meaningful and applicable across providers.