Platform

Platform

A place for Apptio product users to learn, connect, share and grow together.

 View Only

Performance Review – Tuning Assignment Ratio Tables in TBM Studio R12 

Fri December 08, 2017 11:06 AM

Ever wondered how Apptio shows you the drilled results between the top and bottom of the model? In short, it’s just a large table, which we call an “Assignment Ratio” table. Depending on your identifier hygiene this can be extremely large since all of our metric/drill math is done at that identifier level.

 

Using our handy Platform Health Check tool, I can see the below table (Please request a review of this table through your Apptio Customer Success representative)

The above tells me that 2.8 million rows are being created from the drill that combines the Application Software Infrastructure Alloc Object to the Cost Source Object. Values above 1 million are borderline high, and values above 10 million are bad. If the report shows any values over 10 million, please reach out to Apptio Support for immediate assistance.

 

Now the question is how to reduce these tables.

 

In your model,

  1. Start walking down your model through the allocation lines that support this Object (i.e, click each link between each object and look for big tables). What we are looking to identify is the intermediate allocation (table) that is causing this table to be large. 
  2. Once identified, make the necessary changes to reduce the size of the intermediary table. This likely involves things like:
    • Grouping identifiers to a meaningful level.
    • Removing the allocation line.
    • Reworking the allocation to allocate up higher in the model.

 

Common Issues:

  • Make sure to review all models created. If you make a change to the Cost model, don’t forget any subsequent models that may follow that similar strategy (budget, forecast, etc.).
  • Look out for staging objects as they can hide big tables. As called out below, 10,000 rows going to 1 row and 1 row going to 10,000 rows is the same as 10,000 rows in a one to one allocation.

 









#TBMStudio

Statistics
0 Favorited
4 Views
0 Files
0 Shares
0 Downloads

Comments

Fri February 08, 2019 09:31 AM

I'm unclear on the second common issue:

 

  • Look out for staging objects as they can hide big tables. As called out below, 10,000 rows going to 1 row and 1 row going to 10,000 rows is the same as 10,000 rows in a one to one allocation.

It sounds like you're warning against situations where you have M:1 and 1:M relationships but the math seems to imply that this situation is preferable to a similar sized M:M relationship.


#TBMStudio