BLUEPRINT BULLETIN
ARCHITECT FACTORY
Release Date: 12/08/2020 Updated
Prepared by: Peter Fugere
Severity: Medium
Extensibility
Summary: All applications should use extensibility even if the business case is not obvious This decision allows for future growth and expansion by customers.
Purpose: Too many applications are made using single cubes for financial data, and when changes are required it results in significant rework. If the client insists on using a single cube, the consultant should require sign off, as the costs of rework from this decision are significant.
Key Recommendations:
All applications should be designed to use extensibility. Specifically, they should use multiple cubes and create breaks in dimensions when possible.
This benefits the client in multiple ways –
- Performance
- Flexibility – The multiple cube approach gives clients the ability to make changes to the design for new dimensions, added models or changes for performance.
The application will perform better when using extensibility. Consolidation times by entity will be quicker as multithreading allows the base entities to be processed in parallel and move very quickly. As the consolation moves up to the top it slows down significantly.
There are two primary reasons for this:
- The data set for parent entities is naturally denser.
- There are fewer entities therefore resulting in fewer threads of consolidation.
By using extensibility, smaller data units can be designed for the parent entities. This dramatically improves consolidation times.
With large members UD dimensions there is an opportunity for invalid data cells to get populated from poorly written rules or to allow end users to load zeros.
Typical symptoms of application design problems or memory configuration problems is almost certainly due to a server which is too busy swapping data units in and out of memory.
Customers may attempt to stop a running report by ending the execution of the client, restarting the client, and launching another report. This does not stop the server from pursuing its original query, but instead results in an even longer queue of activity requested of the already overloaded OneStream server.
Extensibility allows for flexibility by providing a way to add dimensions or new members without impacting the entire user base. Changing the dimensions on the cube will require dropping the tables for the cube and creating a complete rebuild. This is especially problematic if the data is actuals, as all history of loading and workflow sign off could be lost. The data will likely need to be reconciled again and will require some significant re-work.
Correct design example
Using the extensibility power of cubes more effectively in the design we can avoid this type of an issue. Start with breaking up the dimensions by group –
Corp - Corporate Summary Cost Centers, by Group
Hist – Historical Cost Centers no longer active
CC1 – Logical grouping of cost centers
CC2… - and so on…
Each cube now would only have the cost centers required for each entity. Not only does it solve the performance issues, but it will simplify navigation for each user as they will only see the cost centers they need by entity.
Each data unit queried would be smaller and perform faster. The more we can break down the Cost Center dimension, the better.
There are times when you might have a valid reason for not using extensibility:
- There is only one entity hierarchy and it cannot be broken, this is a rare exception
- The cube is for admin functions
- No consolidation
- Limited users
The cube has a special purpose, like capturing only text, or used for a special report
