Problem

The Apptio model, traditionally, is configured with objects that drive dollars to other objects in order to allow for ease of drilling into data to support reports and thereby providing full transparency into applications, business services, projects etc.  Unfortunately, these drills lead to unnecessary levels of granularity supported by connected objects, which is not always necessary for true cost transparency.  In some scenarios, dollars need to pass through a component to show total cost.  Furthermore, while allocation lines are necessary for a majority of Apptio configuration, it can greatly increase the drill calculation times on the environment across different months. So, how can we show these indirect, non-discretionary costs without negatively affecting the health of your Apptio environment?  

Resolution

In order to resolve the calculation times and expensive drill month over month, we want to break the drill path and still maintain accurate object cost.   This can be accomplished by deleting the allocation line and utilizing a function called LookupObjectUnitValue.

LookupObjectUnitValue, which can be further understood here, https://tbmcouncil.jiveon.com/docs/DOC-4974, is a function that finds the value of a unit for an object to weight one cost driver against the calculated cost in another part of a model.   Making this change will not only allow true cost to flow to other objects but will also lessen the drill times in the model.

Scenario

Scenario 1:

I have a set of supporting applications that I would like to cost out as they support my business applications that I will be reporting on in the dashboards.

Below shows how the example is modeled in order to separate Database Supporting Applications from the Actual Database Application, allowing one to use a LookupObjectUnitValue into the Database Apps Object to break the drill path and save calculation time while getting the same result. A client used a similar modeling basis and was able to lessen a 22-hour calculation period to 8 hours, a more than halved difference.

Below is where the LookupObjectUnitValue was utilized to drive the new stand alone object Data Apps Reallocation.

As can be seen, costs are now driven into the Database Apps Reallocation by the LookupObjectUnitValue function to pull the cost from the original Database Apps object and is now flowing into the Applications object.

The following is a modeled example from the v12 Cost Metrics View – a more holistic view of the drill break.

Breaking the drill path in this manner is important for two main reasons:

1.      Significantly cut performance times allows for cheaper drills within the product.
2.      Reports are intentionally limited when drilled to omit any detail not considered pertinent to the spend in focus. For example, drilling into an application’s cost will show you only the direct cost of those applications  rather than the Supporting Apps (e.g. Database) associated costs within the drill.  This will improve efficiency by eliminating an expensive many-to-many allocation while eliminating potentially misleading spend (We’re interested in the Labor Cost of my Payroll Application…not the labor cost of the Oracle DB that supports it.)