About Field Aggregation
Introduction
Field Aggregation is a "worksheet" or "insight" feature developed primarily to help you aggregate costs across your enterprise graph. Field Aggregation was designed to roll up "total cost of ownership." In fact, the feature goes further than that: you can perform a limited set of calculations on any quantifiable values (currency, decimal, integer).
In a Field Aggregation worksheet, you may be trying to answer questions such as:
"From the perspective of my business capability model, and for each capability in that model, can I get visibility into the costs associated with the systems in our data centers (applications) that deliver each of those capabilities?"
In a Field Aggregation, you will configure a "path" along which you want values to be aggregated. Presently the feature accommodates 1-hop and 2-hop paths.
- A-B aggregates values from B to A.
- A-B-C aggregates values from C to A.
In other words:
- A-B: A is assigned the result of a calculation applied to all values from its Bs.
- A-B-C: A is assigned the result of a calculation applied to all values from its Cs.
Step-by-Step
Using Field Aggregation, you can collect any quantifiable values (currency, decimal, integer) for a custom field on entity records, based on the relationship of the entity records to one of the following entities: capabilities, demands, organizations, or systems. In the field aggregation you can apply one or more of sum, average, minimum and maximum functions to the custom field values. You can also group the results by certain categories, depending on the entity.
Before you create the field aggregation, the custom field that contains the values to be aggregated must be created. You can include all of the entity records in the field aggregation or filter the entity records according to the results of a report that is based on the same entity.
For example, you can create a field aggregation that sums the values of a custom field called "Cost of development" for all of the systems that are related to the child capabilities of a capability. To include a specific capability in a field aggregation, you create a report whose query results in the specific capability, and then use the report as a filter in the field aggregation configuration. The field aggregation displays all of the child capabilities of the specific capability in the report, and provides the "Cost of development" for each system that is related to a child capability of the specific capability.
When you create a field aggregation, you specify the entity and the pathway of the relationships from the perspective entity to the entities whose custom field values you want to aggregate.
Creating a Field Aggregation
- Click Add > Insight > Field aggregation.
- Enter a name and description for the field aggregation, and then click Create. The field aggregation appears.
- To select the data:
- Click Details in the top right corner.
- Click Configure.
- In the Perspective field, select the entity.
- In the field to the right of Perspective, do one of the following:
- To include all entity records, select All.
- To filter the entity records based on a report, select the report.
- In the Pathway field, select the path of the relationships from the perspective entity to the aggregated entity.
- In the Field field, select the custom field whose values are to be aggregated in the field aggregation.
- In the field to the right of Field, select one or more of the functions to be applied to the custom field values.
- In the Group by field, select the entity field that you want to group the entity records by.
- Click Accept changes. The field aggregation displays the selected data.
- To exit the field aggregation or view its entities, click View Entities in the top left corner of the field aggregation.
Example: one "hop"
In this example, we created a hierarchy of Systems:
- System A is the parent of B
- System B is the parent of C
We configured our worksheet from a Report: where System name includes "dfisher".
It's important to notice that our Report matched each System in the hierarchy, not just the top one. We did this so we can show how each level in the hierarchy interacts with the worksheet. In order to make your worksheets easier to read, you would normally only match elements across a single hierarchical level (for example, only root Systems).
So keep in mind that this example configuration may be confusing to read unless you understand up-front that it includes descendants in a hierarchy (and only for the purpose of illustration).
Next, for each System in the hierarchy, we associated a Product. Each Product has a distinct value in an example custom field called "Decimal Currency". This example gathers those values.
- System A has a Product with value 1.11.
- System B has a Product with value 2.22.
- System C has a Product with value 3.33.
So, what does this Field Aggregation show?
- On the left, our Report captured 3 matching Systems.
- Next our graph query traversed the lines ("edges") to all related Products.
- It found 3 matching Products. One for each System.
- On each Product it found a value and summed it. (There was only one Product and one value per System.)
This is a very simple example. If we had more Products related to each System, of course the summed values would be appropriately larger.
Q: Why are we showing such a simple example here? And why hierarchical?
A: In order to illustrate one of the more difficult concepts: rollup.
More precisely, we are illustrating how the present version of Field Aggregation DOES NOT roll up automatically. It IS NOT rolling the values at C all the way up to A. It IS NOT summing B and C with A. The values are calculated distinctly. We call this "direct" (as opposed to "rolled up").
In the future, we plan for Field Aggregation to be more sophisticated regarding rollup. For the present, its important to understand that calculations are "direct".
This example is a shallow traversal. See the "two-hop" example, below, for a deeper traversal.
Example: two "hops"
In this example we use the same data as above, in the "one-hop" example.
- System A is the parent of B
- System B is the parent of C
And ...
- System A has a Product with value 1.11.
- System B has a Product with value 2.22.
- System C has a Product with value 3.33.
Notice in this configuration we have inserted a second layer of System traversal into the path.
Notice:
- B's related value now appears on A.
- C's related value now appears on B.
- C's related value does not appear and is not summed to A.
- C has no child System. Therefore no value appears on C.
Again, this is not a real-world example. You're unlikely to make a Field Aggregation like this one.
However ... you are more likely to:
- capture a large set of parent entities
- where each parent has many children
- where each child is related to many "other things"
- and where there is a need to aggregate financials ...
- from "leaf nodes" on the right-hand side
- to "ancestor nodes" on the left-hand side
This very simple example is intended to clarify how your (potentially very) complex aggregation will behave.