The Planual Rises

It’s time. 

For the last 18 months, we have been working hard to fully understand how the Anaplan engine works, what the associated best practices should be, and how they should be put together in a digestible format.

It’s 4:11 p.m. I am in a very hot Pier 29 building in San Francisco, standing in front of an expectant audience of CPX delegates.

The Planual is launched, to an appropriate fanfare!

We knew there was a demand for the content and the buzz at the conference was fantastic and rewarding; the limited-edition hard copy was in high demand and we soon ran out. 

"Where can I get a copy?” was a commonly heard question. In reference to the content, people said it’s awesome, amazing, wonderful, and a tremendous resource for all Anaplanners! One attendee said, “It’s great to have all the guidelines, principles, and best practices in one place.” Yet another said, “I can’t wait to get it into the hands of every one of our model builders.” We couldn’t have said it better ourselves!

Thank you, it is much appreciated.

Today, I wanted to take this opportunity to add a little extra colour to some of the key guidelines, to further help your understanding of the ethos behind the PLANS standard.

The Planual: 10 Guidelines for Pioneering Model Builders

Just Because You Can, Doesn’t Mean You Should

This is my personal stock phrase and the downside of Anaplan’s flexibility. There are many different ways one can build in Anaplan, but many of these ways work against the strengths of the Anaplan engine. Before building, I recommend you critically consider what you are trying to achieve and what appropriate structures and formula expressions are needed.

Calculate Once, Reference Many Times

One of the differentiators with the Anaplan engine is that all calculations are performed on opening (full calculation), and generally, subsequent changes are processed selectively—only updating what is needed. This, along with the utilization of the server’s many processors, is how Anaplan calculates so fast at scale. Often within models, the same calculation is needed multiple times (e.g. CODE(ITEM(‘P2 Products’)) or START()). Rather than repeat the calculation expression within each formula, it is much more efficient to refer to the calculation so we can free up processing threads for other tasks. Also, long chains of dependencies limit the ability of the engine parallel process (or multi-thread).

Simple is Better Than Complex

Calling to mind Tim Peters—The Zen of Python—Anaplan is one of the easiest planning models to work with, and although it is capable of performing complex calculations, that does not mean that the structures and formulas need to be complicated. Breaking formulas and structures up allows the engine to “breathe” and makes the most of the calculation modes described above. It is also much easier to understand and amend if the model is kept as simple as possible. I have lost count of the number of times I have heard, “Oh, I didn’t realize it was as simple as that” when proposing a solution. Remember, there are no prizes for creating formulas in Excel that fall of the bottom of the formula editor!

More About Formula Structure:

• • Formula Structure for Performance

Only Calculate What You Need To

It sounds simple, but often we see more calculations being performed than necessary. The two biggest culprits are over-dimensionalizing and summary options. 

Over-dimensionalizing: I refer to this as using the “appropriate dimensions.” What this means is that you need to look at each expression in a formula and decide what dimensions apply to that expression. If this differs from the module ‘Applies to,’ the expression (and possibly the whole line item) should be moved to a separate module. The same applies when looking at the data itself; ask yourself, “How do my users need to see this data?” and “What dimensionality do I really need?”

Summary options: One of the best ways to improve performance (and reduce model size) comes from turning off summary options. Referencing above where I mentioned the full calculation mode, parents or summaries will have to calculate, to some degree, every time the data on a child member changes. Within multi-dimensional calculations, the volume of calculations soon adds up, and these cannot be run in parallel because of the dependency of the calculation. So, by default, turn off the summary options and only turn them on when you actually need them.

More About Calculations:

• • Reduce Calculations for Better Performance

Sparsity is Not Your Enemy

I am not going to repeat everything that I wrote in my two-part blog series on the Truth About Sparsity, but suffice it to say that Anaplan is multi-dimensional, so we should look to model multi-dimensionally. Referring to the first point above, that doesn’t mean you can, should, or will have huge multi-dimensional modules everywhere, but one should critically consider the trade-offs between size, flexibility, maintenance, and performance. We need to take a balanced approach. The blog goes into much more detail on these points.

More About Sparsity:

• • The Truth About Sparsity: Part 1
  • The Truth About Sparsity: Part 2

Big and Fast is Better Than Small and Slow

This links to the point above. Some of the worst-performing models we see are the smallest.  Working against the natural patterns of Anaplan can and will make models smaller but at the expense of performance and sustainability. Small models with complex structures also often require a great deal of maintenance.

Booleans are Great, Text is Bad

Hopefully, by now, you have heard the message that Anaplan (and computers in general) are not optimized to deal with text structures. Booleans are the most efficient structure we can use as they take up hardly any space, allowing us to create multi-dimensional structures (see the point about sparsity above). Although we need to use some text within our models, please try to minimize its use.

More About Formula Optimization:

• • Formula Optimization in Anaplan

Text Joins are Worse

Limit the number of text joins. If you have to join text together, create the joins in the smallest possible lists. Also aim to create as many concatenations in the source data, rather than within Anaplan (again, just because you can, doesn’t mean you should). Anaplan is not an ETL tool (Extract, Transform and Load). Finally, often the use of text joins for FINDITEM formula can be avoided using multiple LOOKUPs or SUMs.

Don’t Let Exceptions Overcomplicate the Model

Use a phased approach to build the core functionality first.  Exceptions are just that— exceptions. They will need to be modeled differently, yes, but not at the expense of overcomplicating and detracting from the main model functionality. It is often better to highlight exceptions and let users manage them directly, rather than create a series of complex rules that still don’t quite get there.

SUMs and LOOKUPs are Great, but Not Together

Using SUM and LOOKUP are key to transforming data between modules. Once you have understood the differences, they are very easy and powerful to use. However, although Anaplan can deal with SUM and LOOKUP within the same expression, often this results in a very large intermediate calculation in memory that can cause performance issues. It is better to split the calculations out and do the SUM(s) first and then the LOOKUP(s). Referring back to the second point (calculate once, reference many times), we often see the same elements repeated in formulas (as well as elsewhere in the model), so splitting out the two elements gives a much better model performance.

I hope this explains a little more about the key guidelines that underpin PLANS. We will continue to evolve the standard, and we welcome any feedback you may have. Please leave your comments below.

Happy modeling!