New Cube vs Scenario Type in Existing Cube

[Gaurav]

Hello,
What are the factors one should consider while deciding between whether to create new cube vs using new scenario type in existing cube for different processes like Forecast/Budgeting etc.

Will creating new scenario type would put any performance issues on existing processes (say for Actuals)?
We don't use any extensibility currently in application, and only using Consolidation (Actuals) with Account recs.

Thanks,
Gaurav

[T_Kress]

A big driving factor pushing you to a new cube or not is often, and primarily, the entity dimension.  If the forecasting and budgeting process use a different entity dimension than the one currently used for Actuals (for example, if Actuals follows legal entity and budget and forecast want to have department or cost center as their entity dim), that will automatically drive you to a new cube.

I think entity is the primary driver.  

If Budget and Forecast share the same entity dimension as Actuals, then IMHO there is not a reason to put them in their own cube.  Scenario is part of the data unit so Budget and Forecast will naturally be in their own data unit.

And resources are shared across an entire environment, not app or cube, so that is not a reason to need to separate them out.

You can also apply varying security by scenario, so security is not a reason in and of itself to go to a different cube.

Plus data movement and reporting will be far easier if Budget and Forecast are in the same cube.  Meaning your cube views can pull in Actuals, Budget and Forecast columns without having to move data between cubes.

I am curious what others think but I believe entity is the primary driver for cube(s).

[NBolinger]

Hi Gaurav,

I agree with Teresa that Entity is the most common driving factor.

A few other reasons:

• Time profile - Monthly vs Weekly or multiple calendars are assigned at the cube level
• Security - you may want to consider splitting data & processes off to separate cubes depending on the security requirements. Ex. BUs don't want corporate to see their numbers until they are final.
• Cube as a dimension - Do you have a use case that will expand into multiple? Ex. You want to create a BudgetDrivers scenario but then what happens when you want to create a FcstM1Drivers, FcstM2Drivers, FcstM3Drivers, etc.? Using a separate cube as a dimension would allow you to reuse your existing Scenarios.
• Performance - not often, but in large-scale applications I've seen some resource-intensive processes take place in separate cubes where they can vary the cube settings (Cons algorithm, Business Rules, etc.). Teresa mentioned that resources are shared so there's no "true" performance gain, but the calc/cons times would be quick in one cube and longer in the other to potentially have less impact on some end users.

Hope it helps. I'm a big proponent of having purpose-driven cubes instead of separate cubes for every process where there's only 1 scenario type active in each.

Nick