Separate Application for Consolidation and Planning

[RamuV]

Hi All,

Does anyone have the Consolidation and Planning in separate applications?

If so, what are the reasons for having them separate or what are the challenges.

[Henning]

Hi Ramu, are you considering this option? Do you mind sharing your reasons for exploring this? Maybe the community can help you better if you elaborate (if applicable).

Splitting planning and consolidation into two separate applications is typically not done. Using the same application ensures that you have all of your data in the same place and you can just report on it from a single source of truth. Splitting this into separate applications means you can no longer do that (easily) and need to set up data connections to move the data between applications for things such as scenario variance reporting, or seeding your forecasts with your actuals. You also increase your maintenance effort as someone needs to maintain two instead of one application (keeping your metadata in synch, etc.)

[RamuV]

Multiple reasons-
Huge data size, millions of records added every period.
Longer processing times on the SQL DB
For file based loads, one app ha sonly one harvest folder, this has been an issue as well.
Larger Data Units
Scalability issues, Performance issues when Consolidations and Planning tasks are running in parallel.

I believe even in OneStream book, they give an example of retail company with data volumes in millions of records and how splitting the application is recommended. I understand its theoretical but we do not see any benefits of having them both together in our current setup.
Also, we do not see any extensibility really being used.

I have few more factors as well, happy to discuss if anyone has really done the split or considered doing it.

[Henning]

The reasons you outline point towards a different instance (environment) rather than a different application, if separating the solution is desired. Two applications on the same instance share the servers and resources.

Millions of data records each period are being handled by customers in single applications, but of course each use case is unique (security, audit, process, data model, reporting / data storing requirements,...).

There are customers out there with a split, fingers crossed someone shares her / his reasons and experience.

[RamuV]

Thank you for your prompt responses, Henning!

Looking forward for more insights on the app separation.

[JackLacava]

---

@RamuV wrote:

Larger Data Units [...]
Also, we do not see any extensibility really being used.

---

I'm sure the other problems are real, but this is typically the root of most performance issues. Using extensibility properly, one should be able to split data across cubes and scenario types in ways that will keep DUs small and performance snappy (assuming decent rules). There is nothing linking the size of DUs in an Actual scenario to the size of DUs in a Planning scenario in a different Cube. The data tables will get big, but then it's kinda of a SQL Server problem that can be dealt with.

My fear is that the number of records will likely continue to be an issue even when splitting apps, OneStream is not an ERP. I would check whether those records might be a result of excessive explosion during import or calculation, and if there are ways to aggregate some of them through BiBlend instead (pre-cube-load, or even leaving them outside the cube altogether). If the problem is the volume of data, splitting apps is likely not a long-term solution.

[chul]

Hi Ramu - I suggest speaking with your appropriate OneStream contact (if you're a customer, your Customer Success Manager and if you're a partner, your Partner Development Manager) to discuss this. You could possibly set up a reference call with one of our customers who've implemented this to understand the drivers behind it along with the important question of "if you had a do-over opportunity, would you do it the same way".

A red flag in your comments, large data units with no extensibility, tells me that the foundational setup of their application isn't optimal.

[RamuV]

Thank you Jack and Chul, for the feedback.

The points I mentioned are few of the considerations, which might have the work arounds,  there are many other factors I am considering.

I will take into account your feedback to start with , its just I was looking for anyone who has actually done it and discuss the pros/cons and the reasons/challenges to go with it.

[egoodwin]

The primary reason I've had for separate applications (not separate environments) as mentioned was the need for a separate Time dimension in each application. For example, you plan at a weekly level, but consolidate at a monthly level.  Even then, I would strongly consider varying the input frequency by Scenario and set up your Time dimension to the lowest level of granularity.