Feature overview

A way to show hierarchies in clouds (like OU), in a single view that can also provide additional information about sources and their hierarchy, and the information we have about their state.

Goals

Being able to provide the customer with information about hierarchies that are part of the

Requirements

• As a user, I want to see information about the accounts that are part of my sources and understand the relationship between them, in order to have a better understanding of the information provided by the cloud
• As a user, I want to see information about AWS OU and their relationship, in order to match my business configuration with the way the information is grouped in cost management
• As an admin, I want to be able to set up visibility of the information based on hierarchies, specifically AWS Organizational Units, so that I can define visibility based on customer hierarchies defined in AWS as OU.
• As an admin, I want to be able to see the status of the sources and the accounts related to them so I understand why I am seeing the numbers I am seeing
• As a user, i want to see what cost model is associated to each account, even if the account is part of a hierarchy inside a source, and being able to associate cost models to some element in the hierarchy (like an OU inside an AWS account).
• As a user, I want to see information about the state of each of the accounts that are part of a cloud source.

Out of Scope

• Managing hierarchies within the cloud
• Generating hierarchies that are only available in cost management.

Background and strategic fit

When Doug, Natalie and Sergio started to discuss the requirement to tell the customer when the sources have been updated we discovered that there is a need to get into more details about the structure of those sources and the accounts that are part of it.
For OpenShift, it is easy as one cluster maps one to one to a source. For AWS is more complicated as there is in fact a hierarchy of accounts (parent / children, but also up to 5 levels deep using OU). For other clouds we expect to have something similar.
Trying to show information about the state of the account was really complicated: there are different dates in when processing data: 1. the last date when AWS created the data 2. The last date when the CUR file or API was updated (After 1) 3. The last time we successfully read and used the data 4. The last time we processed the data so the information is updated.

As a result, it was clear than a new view was needed to show all of that information about sources in one place that was better suited to show the information than the cluster view in the details section or the dashboard, and hence the need for money tree

Problem

It is hard for customers to understand how things are calculated and grouped when there is not indications to understand what has been processed and how.
Cost management currently works at the account level but that doesn't reflect the real structure of the data we are receiving. For instance, many accounts in AWS will be part of the same source, even if those accounts have a complete different life cycle, as soon as they are grouped into a parent / children account because of financial reasons, we basically lose the detail information that is closer to the real problem that we are trying to solve.

Why is this important?

This fulfils requirements from two other issues:

• Data accuracy
• Showing hierarchies in the sources

In a way that shows additional information for the customer providing value.

Examples