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

@shekharnaik 

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.

@shekharnaik 

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). 

@shekharnaik 

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.

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

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.

@shekharnaik 

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)