During a typical implementation, it’s common to have multiple model builders build use cases and accomplish tasks simultaneously. During this critical time in the project, it’s important to plan for a key component that may be overlooked—keeping the model clean and tidy.
Keeping a model clean has multiple benefits, including:
Performance—the cleaner the model, the better it will perform.
Scalability—a well-built model results in more functionality. Additionally, model builders will be able to add new features faster because they will be able to understand what has been built and where objects/data are located.
Maintenance—a logically-built model will flow correctly and be easier to understand, supporting new model builder interactions and enabling the client to understand how the model was built.
Four Golden Rules:
Before we get started, there are Four Golden Rules that should always be followed:
Delete all unused objects: While this seems obvious, it is often overlooked, especially during the development sprints. Model builders will create new calculation modules, create lists they think they might need, and build actions to move data around, etc.— and then end up going in a different direction. By not deleting these unused objects right away, model opening performance suffers because the model is building objects that are not needed. Additionally, by leaving these objects in the model, other model builders can be confused and mistakenly use them for their model building tasks. If an object is no longer needed, please delete them immediately as it is harder to remember if it is actually needed at the end of the sprint or project.
Use section dividers to break up objects: Creating section dividers really helps the model builder understand what business process the objects relate to—whether the objects are lists, actions, modules, or even line items within a module. A word of caution on the dividers within a module, please make sure you don’t use emoticons or special characters (just use the Style) as the emoticons could have an adverse effect on data integration, especially Extract Transform and Load (ETL) tools. Additionally, make sure you remember to change the format to No Data.
Use the Notes section within Anaplan to document that object: Notes are very important and can be entered on Lists, Actions, and Modules, as well as Line Items. Some might think it is too cumbersome to use the notes for line items, but this can save a lot of time and hardship if a line item is used for a filter in a view. Unfortunately, when a line item is being used for a filter in a view, the Referenced By is blank, and model builders believe the line can be easily deleted.
Develop a naming convention: Having a naming convention is key as it helps model builders understand what a certain word or phrase means—for example, Load vs. Build on actions. Typically, Load means you are loading data from an outside source, while Build can mean you are building a hierarchy. Additionally, having naming conventions on Modules, Line Items, and even Subsets is key in understanding what the module is being used for, line item formats, or what list the subset is defined on. Find more information on naming conventions in Community.
Other Guidelines
In addition to the Four Golden Rules, what else should you think about? For your convenience, we’ve created a user-friendly guide (attached) that breaks down the major areas of a model: Lists, Actions, Modules, and Line Items. Within each section, we’ve answered frequently asked questions and provided a quick-reference to find more details in the Planual. This is not an all-encompassing list, but it will cover about 90% of the performance issues we commonly see.
When Should This happen?
Reviewing the model should happen early and often! This should not be a one-time exercise. Rather, this should be part of the project schedule, whether it be weekly or prior to the next sprint commencing. Why? First, it is much easier to review smaller amounts of development than reviewing a giant model. And in this regard, it is much easier to make updates/changes because the model has not been fully built, and therefore, you are potentially impacting fewer objects.
Second, this is an excellent way to learn and teach model builders the correct way of building. Remember, just because you can, doesn’t mean you should.
Lastly, this is a great way of showing other model builders what has been built and where the logic lives. In doing this, the logic will not be duplicated in multiple modules, allowing model builders to know where to find it. At the end of the day, you want to strive for peak model performance, scalability, and understandability. By following this guide, you’ll be well on your way!
... View more
