Time to Tidy: No More Mess in Your Models
As winter is now behind us and the annual process of “spring cleaning” begins, I find that it is a good reminder to not only clean and organize my house, but also to clean another area that most likely needs some organization: my Anaplan models. The beauty of Anaplan’s platform is that it gives the model builder an extremely powerful tool that can be customized exactly the way the model builder would like. Oftentimes, I am either so anxious to produce the result I want (or under such a tight deadline), that I forgo best practices and “clean” model building for quick delivery instead. Similar to how I may not dust in every corner or clean every nook during the winter months, I find myself with “dirty” Anaplan models that could use a nice deep cleaning and organizing.
Thankfully, Anaplan has a guide on how a “clean” model should look and function. These practices enhance the sustainability and auditability of the model, while simultaneously increasing the model’s performance. It’s called the D.I.S.C.O. methodology. This handy acronym stands for Data, Input, System, Calculation, and Output. Each word represents a certain function (or responsibility) that each module with an Anaplan model should perform. The D.I.S.C.O. methodology provides an overview of how data should flow between modules and how your model map should look.
The general data flow between the D.I.S.C.O. modules.
At a high level the individual types of modules perform the following functions:
- Data modules: Serve as targets for any data inbound from sources other than the model. These could be data loads from a data hub model, loads from other models or manual or automated loads from another system like your CRM or ERP.
- Input modules: These modules collect information input from the end users of the model, they could drive mappings, calculations, filters, etc.
- System modules: System modules hold fairly static data points, mappings that are defined by the Workspace Administrators, or standard calculations that rarely (if ever) change. A good example is a time management module which includes functions that do not change between modules, such as PERIOD(START()). By storing calculations like this in a single module, Anaplan only needs to calculate the function once and can reference it wherever it is needed.
- Calculation modules: These are the heart of the Anaplan model. They serve as the meeting point of Data, Input, and System modules, where it all comes together to produce the desired outcomes. The heavy lifting of formulas and functions is performed in these modules.
- Output modules: Last, but certainly not least, the Output modules take information from the Data, Input, System, and Calculation modules to produce reporting for dashboards and other models to reference in import actions. Output modules should usually only have incoming streams from other modules, as they are the final result of all of the other modules’ hard work.
While the D.I.S.C.O. methodology is typically referenced and considered when starting a model build, it’s no less applicable or important in the later stages of a model’s lifecycle. Even the best-made models will collect dust and dirt over time, in the form of redundant calculations and convoluted data flows.
As I clean my models this spring, I‘d like to share a few quick tips I will be using in the process:
Develop a system to tag each module to a specific purpose within D.I.S.C.O.
If I haven’t already, I’ll develop a system to tag each module to a specific purpose within D.I.S.C.O. It’s user choice here—you could use Anaplan’s notes feature, data tags, module names, or functional areas. I’ve found that organizing modules into D.I.S.C.O. functional areas helps me keep them organized. I also prefix my modules with DAT/INP/SYS/CAL/OUT and number them to make finding and referencing them much easier.
If you can’t make sense of it in ~15 seconds, your model is most likely not adhering to the D.I.S.C.O. methodology
Once you’ve organized your modules, take a look at your model map. If you can’t make sense of it in ~15 seconds, your model is most likely not adhering to the D.I.S.C.O. methodology, and likely has multiple modules performing the same calculations, deprecated modules, or the same data living in multiple places. A few questions I ask myself are:
- Do my modules flow logically from left to right (e.g. Data/Input/System on the left, Calc in the middle, and Output to the right?) Are there modules to the right of my Output modules that are Data, Input, System, Calculation?
- Do I have modules referencing output modules?
- Are there arrows going both ways between modules?
- Can I pick a line item on an Output module and easily follow it all the way back to the beginning of the calculation and data source?
As the above screenshot illustrates with Data in red, System in Yellow, Calculation in Purple, Input in Green, and Output in Orange.
The easiest way to begin is to address any Output modules that are referenced by other modules
Next, I’ll reduce module size and unused cells. The easiest way to begin is to address any Output modules that are referenced by other modules. Once I clean those references up and move the calculations to a Calculation module, any Output modules that are not used on a dashboard and Calculation modules that do not have any modules using them as references are quick wins to delete and reduce my model’s size.
Redundant formulas are also quick model size and performance wins
Redundant formulas are also quick model size and performance wins to consolidate to a single calculation module or move to a system module. An example would be to search for PERIOD() functions. If you are calculating the time period on multiple modules, that can be done on a single line item in a time system module and then referenced as needed by each module that needs the period. Not only does this remove the redundant line items and reduce model size, but it also increases the model’s performance, as it now only needs to calculate the time period once.
Model performance can be increased by removing line item summaries
Since Calculation modules are not intended to be displayed to end users, model performance can be increased by removing line item summaries on Calculation modules that are not needed downstream in Output modules.
More About Model Building:
With spring in full bloom, it is a great reminder to not only clean up your house/apartment/flat but also your Anaplan models. Of course, these tips should not be used to “clean” your models once a year, but rather a guide for ongoing model building, and constantly reviewed on a regular basis. Hopefully, you found something useful in this article.
Happy Model Building!
Joey Morisette is a Business Operations Manager on Anaplan’s internal Center of Excellence team known as “Anaplan on Anaplan.” Previously, Joey worked at an Anaplan customer where he led the development and implementation of the Anaplan platform.
Comments
-
Get out that glitter ball and D.I.S.C.O.
3 -
Great mention about the using the Model Map. Its an underutilized tool.
1 -
Thanks for sharing this.
One comment: The naming conventions with prefix DATxx, CALxx, etc... would really make sense if you could use this as the 'technical name'. Besides this we require a 'functional name' when the module is published on a dashboard. Otherwise you need to hide the module name all the time (or can live with those techie names).
1 -
@****.kaandorp , that's a great point. there are many ways to tag the modules, certainly if the module names are important for your user experience you could organize using DISCO using the data tags functionality, notes etc. something that only WSAs can see.
1 -
2022 and still useful!
0
