Criteria for developing using multiple Models vs set of modules in a single model

Great question, one that will get you a different answer from everyone that responds, I'm sure. These are the best kind of questions.

Here's some thoughts for you to consider:

Summary: Generally, I like to see the first implementation of Anaplan as simple as possible, and in one model. That almost always means scaling the use-case down to something very manageable. Maybe just one of the use cases you mention above. This gives your users confidence that Anaplan can work, can scale, and can be connected to everything else. But whatever you do, make sure you implement the Anaplan Way, or at least a SCRUM-like process to manage the workload. This will keep your project in scope while managing expectations.

Detail questions you can ask yourself about architectural strategy:

How many users are there for each use case? More users means more roles and concurrency to deal with.
Is the data reusable? The more reusable the data the easier it is to rationalize separated models.
Is there a lot of data integration that needs to be automated? If so, consider a data hub (separate model and workspace)
Do you need a dev/qa/prod workflow? This will almost guarantee the need to separate the models. If for no other reason than ALM is model only migration (not object level)
How many modelers are there? if you will have many modelers you will need to be very organized if you build things out in one model. Might be easier to separate them and connect them as part of the overall process workflow.
In thinking about UAT, how many different stakeholders are there? UAT is harder when your test scripts have to be role based, as part of a singular model.

Just some ideas for you to think about. I'm sure you'll get lots of advice here.

Keep the conversation going! Let us know if any of these ideas need more detail.

Thank you @JaredDolich for your response and the guideline questions. I am putting my answers inline to the questions for your reference. I have a couple questions at the end.

How many users are there for each use case? More users means more roles and concurrency to deal with.

shekhar> The number of users are fixed for all use cases, about 5

Is the data reusable? The more reusable the data the easier it is to rationalize separated models.

Is there a lot of data integration that needs to be automated? If so, consider a data hub (separate model and workspace)

shekhar> Yes, the data is re-usable, so we are implementing a data-hub.

Do you need a dev/qa/prod workflow? This will almost guarantee the need to separate the models. If for no other reason than ALM is model only migration (not object level)

Shekhar> Yes, we need a dev(sandbox) and prod. We are using ALM. We will have a model in our sandbox and promote it to prod. Just one model in production though. Is this ok?

Does this mean, the versioning support is at the level of a model?

How many modelers are there? if you will have many modelers you will need to be very organized if you build things out in one model. Might be easier to separate them and connect them as part of the overall process workflow.

shekhar> We have 2 modellers, if they are in lockstep, then can we manage using a single model ?

In thinking about UAT, how many different stakeholders are there? UAT is harder when your test scripts have to be role based, as part of a singular model.

shekhar> We have an existing model in Excel, so the UAT is to compare the outputs from Anaplan modules with the outputs of the Excel model

Thanks,

Shekhar

This is just my opinion and I'll admit there are a lot of things to consider; but, given the limited number of users and modelers it seems easier to implement the whole thing in one model. The only exception might be the transaction data - the data hub but there are a few questions you may want to answer before deciding.

One model reasoning:

If this is the client's first model, you want to keep it as simple as possible.
A quick solution to the spreadsheet you mentioned will give your client confidence that Anaplan is an effective platform to build these applications.
Data integration introduces a lot of complexity so if you start adding a lot of models be prepared for all kinds of challenges, especially ones related to ALM. Just think about the master data - how you'll keep the hierarchies in sync. You'll have to build a lot of audit modules / views.
By having one model, all your line items can be formulated, meaning you don't need an import action to be run to bring in data.
If you're determined to use ALM out of the gate, follow @DavidSmith ALM advice by creating a daily routine to promote changes. Otherwise, wait until you go through your first sprint review, as part of UAT. Also, keep your action list cleaned up. If you don't need an action, get rid of it. Document all the actions you want to keep and identify the source of your data in the comment section.
Again, this is just my opinion, and I'm not at all familiar with your use-case or client, but if you feel you can build the transaction modules into your model (vs a data hub) I would do it since this is your first application. If the transaction data can be reused at different dimensional levels for applications on your roadmap, then it may make sense to build the data hub now. Just remember, the more models you add the more complexity and the more time it's going to take to make it production ready.
Oh, yes, the ALM migration is at the model level. Branching is not available yet. You cannot select individual objects to promote (although I know Anaplan is looking at how this could be done).

Hi @JaredDolich

Thank you once again for your detailed note.

Ok, we will do a data hub and implement the components (members, revenue, ...) in another model. FYI, we are using Anaplan for our company, it is not for a client.

Please see my notes inline.

If this is the client's first model, you want to keep it as simple as possible.

shekhar> Yes, it is simpler as we can directly reference the line items from another module.

A quick solution to the spreadsheet you mentioned will give your client confidence that Anaplan is an effective platform to build these applications.

shekhar> Yes, Our test plan is to compare to the result in Anaplan with the results in the spreadsheet.

Data integration introduces a lot of complexity so if you start adding a lot of models be prepared for all kinds of challenges, especially ones related to ALM. Just think about the master data - how you'll keep the hierarchies in sync. You'll have to build a lot of audit modules / views.

shekhar> Ok, we are using our well defined dimensions and defining our hierarchies. Thanks for the note on audit modules, I will add this to our unit tests.

By having one model, all your line items can be formulated, meaning you don't need an import action to be run to bring in data.

shekhar> Yes, especially when we are developing modifying the line items

If you're determined to use ALM out of the gate, follow @DavidSmith ALM advice by creating a daily routine to promote changes. Otherwise, wait until you go through your first sprint review, as part of UAT. Also, keep your action list cleaned up. If you don't need an action, get rid of it. Document all the actions you want to keep and identify the source of your data in the comment section.

shekhar> Thank you for the ALM pointer to follow David Smith, I am going through the Planual and his articles.

Again, this is just my opinion, and I'm not at all familiar with your use-case or client, but if you feel you can build the transaction modules into your model (vs a data hub) I would do it since this is your first application. If the transaction data can be reused at different dimensional levels for applications on your roadmap, then it may make sense to build the data hub now.

shekhar> We are prototyping on using the data from a data hub in our calculations in a core model. We have a data pipeline that is getting the data from our data warehouse into the data hub a a regular cadence.

Just remember, the more models you add the more complexity and the more time it's going to take to make it production ready.

shekhar> Yes, we will limit it to two models, one data hub and the other core calculations.

Oh, yes, the ALM migration is at the model level. Branching is not available yet. You cannot select individual objects to promote (although I know Anaplan is looking at how this could be done).

shekhar> Ok, thanks for the note. We will plan on promoting the entire model to production

Thank you very much for the guidance, appreciate your time

Regards,

Shekhar

https://community.anaplan.com/t5/Best-Practices/Data-Hubs-Purpose-and-Peak-Performance/ta-p/48866

Sounds great!

Forgive me for being prescriptive, but for the data hub make absolutely sure you follow @rob_marshall famous article about how to build those transaction modules.

Quite possibly the best article yet written for Anaplan. I wish I would have known these concepts a long time ago!

@kavinkumar also has a good article on keeping your models clean which I really like.

https://community.anaplan.com/t5/Best-Practices/Best-Practices-for-Model-Cleanup-in-Anaplan/ta-p/56066

Good luck. Please keep the conversation going by letting me know how it's going.

I always learn something new and I'm always curious about how people like to solve their use cases.

Thanks again @JaredDolich !

Really appreciate you giving me such wonderful pointers. I went through the ALM one by David Smith and we feel we are in a good place now. I am also going through the data hub one by Rob M.

Quick question on ALM. Is ALM primarily meant for promoting models from Dev to Prod in the same workspace? Is it a good practice to keep dev and prod models in the same workspace?

Thank you,

Shekhar

Another awesome question! I had the exact same question about 6 months ago about whether ALM could be deployed across workspaces.

The answer is yes! It's not entirely intuitive but it can be done.

This allows you partition your tenant into multiple workspaces when you really feel the extra security is needed.

In your case, I would deploy ALM in the same workspace so you don't over complicate your environment right away.

In my opinion, the most important thing is to succeed at implementing your solution. The brilliance of Anaplan is that there is no "right way" but there are good ways and not-so-good ways.

But even not-so-good ways are okay as long as it meets the user-requirements. Plus, you can can always optimize your solution later.

All part of the learning journey and what makes you a brilliant Anaplan modeler.

Great work!

Here are some additional conversations about ALM across workspaces:

Conversation 1 (this one has lots of master anaplanners weighing in, including @DavidSmith )
Converstation 2 (this one has @Misbah and @rob_marshall commenting - good one for moving to a different workspace)

Thank you @JaredDolich for your recommendation to do it in one workspace. We will keep it simple,

I will go through the the conversations that you have provided.

Thank you,

Shekhar

Hi @JaredDolich

Quick question on "Audit modules/ views".

In our of earlier conversations, you had mentioned the concept of audit modules.

"Data integration introduces a lot of complexity so if you start adding a lot of models be prepared for all kinds of challenges, especially ones related to ALM. Just think about the master data - how you'll keep the hierarchies in sync. You'll have to build a lot of audit modules / views."

Can you provide a provide a pointer or elaborate a bit on how to develop audit modules.

Thanks,

Shekhar

https://community.anaplan.com/t5/On-Demand-Courses/Validating-Data-in-a-Hub/ta-p/63604

I was hoping we would get to this topic.

The short answer is that you need to quickly identify bad or missing data before it makes it to your spoke application.

For master data, this might be a new product or location list item that hasn't been included in your list yet - we call these "bad codes".
For transactions, you might get a record that is missing data or has data inappropriately formatted.

This can get pretty advanced so I would highly suggest you watch this short video first, posted by @L.A.Foster and @Bob-Bachynsky . This video is part of the L2 Modeling certification and I can't recommend this certification enough if you don't already have it. Pulls everything together very nicely.

Your job with audit modules is to build a saved view that filters these transactions out so an administrator can address them BEFORE it gets to the spoke application. The video link above will get you started but I'm sure you can imagine how this can get complicated because there are many conditions that can lead to a bad record - new, obsolete, renamed. It gets even harder when you have to map list items to other list items. Whew! I guess this is why it's recommended that one person be dedicated to data integration!