Planning Analytics and Object Permanence

 

Object Permanence is “the understanding that objects continue to exist even when they cannot be sensed; a fundamental concept studied in the field of developmental psychology, the subfield of psychology that addresses the development of young children’s social and mental capacities” (wikipedia.org).

 

Does How does this relate to Planning Analytics?

In every Planning Analytics model’s lifespan, new objects are continually added, and typically existing objects are not always decommissioned. This means that the total number of objects increases while some objects continue to consume valuable resources while not adding value  (since they are not or seldom used).  In other words, you’ll have objects continuing to exist while not “sensed” (not used and therefore not adding value to the model) – not very economical.

 

Taking a baseline

To remedy this situation, start by establishing a baseline. A baseline is an initial measurement of a condition that is taken at a specific point in time to be used for comparison over time looking for variations. In our case, we want to establish some baseline facts such as the total memory footprint of the model and perhaps the time it takes for the server to start up (without the aid of persistent feeders). These data points (and others) can be useful as “measurable results” to gauge the effect of any object decommissioning you do.

 

Identify the Usual Suspects

In horticulture there exists the practice of regularly pruning plants so as to stimulate new growth as well as maintain the health of the plant. You may refer to what is known as the “ 1/3 pruning rule” which involves cutting about 1/3 of wood during any pruning activity. This moderate pruning practice is a balanced approach to thinning out shrubs to stimulate new growth. The plant loses a good number of stems, usually in the top section, allowing more light and air to enter the inside of the plant.

 

While I don’t advise looking to remove 1/3 of your planning analytics model objects, I would recommend being aggressive with your cleanup (backups first of course!). To that point, I suggest beginning by creating a “profile” of your model to guide your pruning, including:

 

  • The total number of cubes (including “}” control cubes) in the model – then sort them by purpose: input, calculation, reporting, support or control. Do you have a “higher count” of a certain type of cube?
  • What are the largest cubes within the model and what is the average cube size? What is the highest number of dimensions (in any single cube)? Are there a number of cube sizes above the model’s average? There is an optimal number of dimensions any cube should have and going above that number may affect performance.
  • The total number of dimensions (including “}” control dimensions) in the model
  • What is the largest number of elements (in a single dimension) and what is the average dimension size? Could a larger dimension be aggregated with detail data available in an alternative cube and available as a drill-through?
  • The total number of processes (including “}” control processes) in the model and what is the “cube to process” ratio? Processes have a way of multiplying as requirements change and are especially difficult to sort if naming conventions have not been followed or have changed over time.

Make it an Obsession

A common belief is that all “obsessions” proceed through four stages in the same order: cue, craving, response, and reward. In a planning analytics example, you might consider the following:

 

  • The cue – perhaps a date on a calendar (an end of quarter?) or a memory consumption threshold. This causes you to notice the need for a “cleanup”.
  • The craving – this should be an agreed upon objective, such as an optimal memory footprint or acceptable server restart time; “we want a healthy, sustainable planning analytics model”.
  • The response – an actionable plan (setting a baseline, reviewing model statistics and pruning and/or decommissioning objects).
  • And the reward – this is your happy, healthy and sustainable planning analytics model!

 

Conclusion

I would highly recommend adopting a process (and yes, even making it an obsession) of routinely inspecting each planning analytics model for objects that can be reduced in size or “pruned” completely out of the model. This practice will support server stability, promote faster startup times as well as (potentially)  improve server performance.