Another question, Can we build model to model import processes between classic and Polaris?
@Sukh_Sandhu you had 2 questions there. One as part of the subject and another as part of body of the message.
Hi @Sukh_Sandhu From my understanding there are limitation with Polaris engine like it doesn't support FInditem etc, so I dont think we can directly move a model from Classic workspace to Polaris workspace.
Thank You All !
Really, you shouldn't "migrate" a Classic model to Polaris as the architecture of the new Polaris model should change (model more naturally vs. concatenating list members). Also, the way you create the logic should adapt to Polaris as well, the logic should look for data that is non-default vs. in Classic you just create it. In Polaris, you have to be careful/understand the fan out of the logic and create it appropriately.
Hope this helps,
@rob_marshall good point. I was more responding to the question whether you can vs whether you should. If you can elaborate on your comment "the logic should look for data that is non-default vs. in Classic you just create it". May be easier for me to understand if you can provide an example
Yes, happy to and should have done that. Also, I misspoke when I said the data should look for non-default, it should have said it should not look for non-default, but rather data that is valid. Think about a subset of employees and whether they are Active or Not Active = subset is Active. In Classic, we just create it and be done with it. Since the vast majority of employees will be Active and say you want to see the number of Non Active Employees, in Classic you create logic as Not Active. In Polaris, you may want to flip that so the non Active employees are the only ones checked in a subset.
Also, something to be careful about. Say you want to do a Count in a module. In Classic, it is very simple as you just create a line item that is hardcoded to 1. If you did that in Polaris with a module having 10 dimensions with sums turned on, you just made that MASSIVELY dense, and with the formats of line items being roughly 3x as large as the same format than Classic, you could crush the size of the model. Not saying you can't get counts in Polaris, you just have to think about how to do it differently.
Again, we don't advocate migrating models to Polaris because the engines are completely different and thus, the logic needs to be different. You can still get the same answers, just go about it differently.
Does that help?
@rob_marshall thanks. Makes sense
Heello 🙂 2 Questions:
Product Customer Hierarchy
Customer Product Hierarchy
But in Polaris you can potentially have both Customer and Products as separate dimensions in a module without requiring you to create composite lists as long as it is below a dimension index of 64
Here's some of my "personal" rules for assessment
The complexity I've experienced is that I ended up creating a lot of composite hierarches to control space consumption in Classic. In hindsight, we should have gone with Polaris at the start. Given we started in Classic, we later ended up getting Hyper Model
2. Models that require global coverage. You will generally find that the intersection of certain dimensions such as customers and products across global entities would have a high level of sparsity as both products and customers have regional scopes. E.g. a global company with 1,000 products would only sell 100 products to a specific country/region, 150 to only 2 countries, etc. The same goes with customers
3. List member life span. This is a term I just cooked up now lol. This is highly relevant for list hierarchies used in a lot of modules with time dimension. So what do I mean by this? Let's use weekly supermarket promotions like those 50% off Coca Cola soft drinks for the 1st week of May only. So the list is a promotion hierarchy. They are relatively short where majority of promotions only last less than two weeks. But the minimum time dimension you can have in Anaplan is one year. So you end up with a high level of sparsity because the list has a short life span. I've seen a similar situation with large retailers that had a habit of switching product suppliers nearly every half year to get the best bargain.
Hope this assists.
@FrankPau just noticed they have an event on 5 Dec to discuss Polaris implementation. May be a good idea for you to register
@TristanS Hi there, I appreciate the thoroughness of your response, it's much clearer to me now.
However, I've read from official Anaplan sources that the workspace choice is binding—either Polaris or Classic needs to be selected.
Also, your byte calculations are clear. But how can I anticipate the evolution of my dataset over time? Whether it will become more or less sparse in, say, x years? Once the data model is created, is it challenging or impossible to switch?
Let me attempt to answer your questions: