Identifiers in Apptio serve multiple purposes and understanding how they work will help solve some of the most difficult modeling performance problems.

Essentially an identifier supports the level of data granularity you report on, slice by, trend by or allocate by. When viewing this from a performance perspective this is one of the greatest allies to tuning your Apptio project. Below are some areas we typically focus on in our performance reviews.

1. Make your identifier as consistent as possible over time
   1. If your identifier changes every month, you are causing 12 times the amount of work when reporting over time. With this malformed identifier you are creating a single row each month that has no context to the prior month. An efficient identifier should be 1 row for all months as it relates to that modeled metric. Below is an example of a malformed identifier that has an “Amount” column appended into it and the subsequent efficient identifier, which produces the same results.

   2. Malformed

      Identifier Formula = Cost Center&&Amount

      Identifier	Jan	Feb	Mar
      CC1-10	10
      CC1-20		20
      CC1-30			30

       

   3. Efficient

      Identifier Formula = Cost Center

      Identifier	Jan	Feb	Mar
      CC1	10	20	30

2. Find the balance between reporting and allocating with an identifier
   1. Typically these two operations require different levels of granularity. Challenge what you are likely required to report on based on the allocations supporting the object. Does it make sense or provide value to have an identifier that is “ticket ID” for the Tickets object if its only being used to pass costs to the Applications object based on ticket type or severity level? By grouping down this typically large dataset to ticket type, you’ll support the allocation strategy, give you a meaningful level of reporting, and make your model perform substantially better.
3. Does your allocation make sense as a Many:Many
   1. Since the allocation uses identifiers, there are times when you may create a many to many relationship when this is truly not needed. For example, we see this in Labor -> Time Tracking -> Projects. A typical use case should be 1 person -> many activities -> 1 projects. Unfortunately we often see these joins as all Many:Many which doesn’t make sense and implies an issue with the identifier.

Common Issues:

• Appending Amount, Date or using Month(), Row() functions as part of the identifier. This is typically done to get “various” out of the report.
• The Cost Source Identifier includes Journal Line Detail, which by design, is unique every month. Because of this, you may run into item 1 as described above. This is generally not a problem if your data volumes are smaller, but as they grow it might start to cause issues. We have alternative approaches to support this level of granularity if it is impacting your modeling and drill performance.

Please reach out to Apptio support if you need assistance with any of the above issues.