This article is part of a series on Polaris best practices. Click here for more Community content or visit Anapedia for detailed technical guidance.
In this article, we’ll focus on understanding the blueprint columns in Polaris in more detail, and how we can use them to optimize formulas.
Polaris Blueprint Insights
When model building in Polaris, it’s important to note the interplay between the Polaris blueprint columns. Specifically, we’ll review the cell count, populated cell count, calculation complexity, and calculation effort columns and discuss what you should be thinking about as you’re model building in Polaris. A best practice of model building is to develop in a small model, while keeping in mind what the fully loaded model will look like. These blueprint insights allow for the optimization of formulas early and often throughout the development cycle.
In the above example, we have a module calculating a weekly demand forecast, by account, by product. In blueprint view, we see this module is dimensioned by the lowest level SKU and account lists at the week level. Relative to total cell count, the populated cell count is low for most of these line items. However, there is one that is fairly large. The Growth Rate % line item has a large one-to-many result, as well as a large calculation effort.
This development model is very small. There are only 429 SKUs and 151 accounts across 2 years of data. But with the high calculation complexity and the high calculation effort on this line item, imagine if the fully loaded model had 700,000 SKUs or 5-10 years of data.
As the volume of data increases, this high calculation complexity will result in a much larger populated cell count and memory use, potentially affecting performance.
When optimizing formulas, be sure to ask yourself these questions:
- Does it make sense to calculate the value across all dimensions?
- How can I reduce the scope of the formulas before calculating the results?
Optimizing formulas for Populated Cell Count
Polaris knows when a line is populated and only performs calculations for populated cells while ignoring empty space from a calculation standpoint. Taking advantage of this opens an important opportunity to optimize your formulas based on which cells will be calculated.
Using the business knowledge gained through project kick off and user stories, you can build in a way that informs the engine about relationships that Anaplan does not inherently know. This results in scoping the formulas to optimize space and performance in Polaris.
Examples of this might be:
- Salespeople only cover their region or set of accounts.
- Accounts only sell a subset of products.
- Projects may only be active for specific time periods.
If we take our example from above and change the formula to reference a line item that shows valid products by account*, we optimize this formula, so it only does math where it needs to. The populated cell count, memory used, calculation complexity, and the calculation effort are all reduced substantially because we’re only calculating a growth rate for products that are valid for the account.
*Note: and ideally these types of validations are being imported rather than calculated live.
Remember, keeping an eye on calculation effort, populated cell count, and calculation complexity while developing can inform your model optimization before there is a problem. And, as a best practice, only calculate where necessary!
Video links
This concept is also explained in the following videos:
……………..
Authors:
Anaplan’s Theresa Reid (@TheresaR), Architecture and Performance Director; Stephen Rituper (@Stephen), Sr. Director, OEG; and Terry Archsmith (@TerryA), Sr. Director, Platform Training.
