OEG Best Practice: The importance of building and maintaining a clean model
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.
Author Rob Marshall.
Comments
-
Another great best practice article. Thank you.
- I like the idea of stressing the importance of a COE, or having someone enforce the standards when there is more than one modeler developing at the same time. While it's easier if there's a separation between the modeler and data integration modeler, there are still some overlaps. I guess this is where teamwork really comes in to keep the model clean.Good opportunity for teamwork and leadership.
- To avoid toaster time, or penalty box, as some call it, in production, using ALM is a wise and sound choice to test structural changes.
- However, from my experience, ALM can also be problematic if object level changes are required which is typically the case with multiple modelers. In this case I've seen teams portion out windows of time for each modeler and/or they use Slack to inform others that during such-and-such a time they will be making changes to such-and-such model/module.
- Lastly, you mentioned using the notes. For actions, I have found that documenting the import "source" in the notes is really helpful. While I can sort of tell from the import data sources it's a lot easier if it's documented.
@rob_marshall I can't wait until you write the data integration Planual!
4 -
Good comments and I agree about the CoE in how they can help, but this article is really about during the project, getting everyone on the same page and not waiting until UAT to review the model. Do it early and often and what to look for.
1 -
Where is the 6th one? Couldn't find it🤔. Let me guess, is it TIMESUM or RANK or RANKCUMULATE or CUMULATE. Too many guesses.
3 -
1
-
Great and must needed post @rob_marshall ,
I would say we should avoid having to do a model cleanup - because as mentioned is a tedious task - and instead incorporate these best practices while building the model.Of course, we don't always work on creating new models and often work on models created by other modelers and that's when following the model cleanup process becomes critical.
In my experience, we can have a model that hasn't been maintained for a couple of years, and when we decide to start the cleanup process we feel paralyzed because of the number of obsolete or redundant objects that we fear deleting because of the possible effect on production, not having Notes or documentation exacerbates the problem. As a result, we keep pushing the cleanup task down the priority list and the model performance suffers.So my most important takeaway from the article is... start by following modeling best practice and incorporate the cleanup in the modeling process, Then do the cleanup early and often. Rinse and repeat.
2 -
Well written @einas.ibrahim - best way is to prevent the need for model cleanup in the first place.
0 -
@einas.ibrahim I've found that if a model has been around for a couple of years it's probably been bolted onto several times and doesn't conform too well to best practice. Time to strip it down and start all over again. Bit like with a car, is the cost to do the repair worth it vs the cost to just buy a new one.
Separately something that we've started doing is having someone that might've been deep into a project on their next to be that "best practice guru" who can be on the project and can do the review of activity but without the stress of doing the development in of itself.
1 -
You are describing a COE lead or a Solution Architect. This is one of their main responsibilities.
Have you tried to convince a client to overhaul an old model? I have, and it doesn't end well 😀
I believe there are different situations of models that require maintenance or fine-tuning, and the solution to "clean and maintain" these models will vary. This article is a good guide.0
