Designing a Jedox solution that lasts: small cubes, clean splits, real discovery

· Jedox

Your cube design is also your security model, your performance profile and your upgrade path. How I design Jedox systems that survive - smaller purpose-built cubes, input split from output, and a discovery phase that pays off.

I have never seen a team regret having one cube too many. The one cube that tries to do everything causes regrets every time.

I have written before about the Jedox Design System - the report and UI side of building things that look and feel right. This post is about the layer underneath: how to design the system itself. The cubes, the dimensions, the rules, the loads. Because your cube design is not just a modelling choice - it is also your security model, your performance profile and your upgrade path. Most teams find this out a year or more into production. The goal of this post is that you find it out earlier.

Discovery is the design phase in disguise

Before a single cube exists, the most important work of the whole project happens: understanding the client. On this I do not compromise: discovery is where the expensive decisions get made, not a warm-up. In Jedox, the costly choices are structural: which dimensions exist, at what grain, in which cubes. Once a Version or CostCenter dimension is wired into cubes, rules, Integrator loads and fifty reports, changing it is a re-implementation, not a tweak. Discovery is the only moment those decisions are still cheap.

What a real discovery looks like:

Discovery is done when four artefacts exist and are signed: process maps as they will run in the new world, the dimension model on paper, a ranked report catalogue, and a data contract per source with a named owner. Skipping this does not save time - it relocates the cost to UAT with a 10x markup.

More smaller cubes beat one big cube

The single biggest design decision, and the one people get wrong most confidently: how much goes in one cube. The monster cube fails on four fronts at once.

Look at how Jedox itself builds: the prebuilt models (Integrated Financial Planning, Cost Center, Profit Center) are federations of small cubes feeding a P&L cube. Copy that shape.

My design test: write one sentence stating what business question the cube answers and who writes to it. If the sentence needs "and" twice, split the cube. And if a dimension sits on "~" for most of a measure group, that measure group belongs somewhere else.

Split input from output

Input cubes are for entering data, reporting cubes are for reading it, and an Integrator job moves the data between them.

Raw input cubes (planner entry, actuals at load grain) and reporting cubes have opposite requirements. Input wants writeback, splashing, cell locking and fine-grained security. Reporting wants dense precalculated aggregates, heavy logic frozen into stored values, and read-mostly caching. Mix them and every writeback invalidates the calculation cache for every reader, and month-end grinds while two hundred planners splash against the same cube the board pack reads from.

The pattern that works is a chain: source extract, then a staging cube at source grain (no rules, no user access), then an input cube at planning grain, then a reporting cube with precalculated results. Each hop is one Integrator job with a rowcount reconciliation, and every job is rerunnable without double-counting (use Update or Insert mode - a rerun on Add mode silently doubles your actuals, and nobody notices until reconciliation).

One real cost: the split introduces latency. Users can see stale reporting data between syncs, so write the refresh contract down - "staging to reporting runs on save, max 60 seconds lag" - or users will silently make decisions on old numbers.

Dimensions: fewer, shared, and deliberately chosen

A dimension is a maintenance commitment for the life of the model. An attribute can be changed at any time.

Rules light, batch heavy

Jedox rules calculate on read. That is wonderful for sparse cell-level maths - price times quantity, KPI ratios, version blending, a lookup of three driver values - and a serious performance problem for anything dense. The rule engine documentation is refreshingly honest: the fallback engine at 10-100 microseconds per cell means a 10-billion-cell area "could take 10 days".

So my default is boring and firm: does this number need to change the instant a user types? If no, it belongs in an Integrator job, not in a rule. Currency-translated actuals, allocations, materialised aggregations - precalculate them into stored values overnight. The fastest rule is the one you precalculated last night. (I have written more on this in rules versus stored values and writing efficient rules.)

Two patterns worth stealing from Jedox's own models:

Design for the reorganisation that is coming

The business will reorganise, usually about 18 months in. Whether that is a Tuesday or a project depends on decisions you make now:

The quiet design features

Three things that rarely make it into design documents and always make it into year-two regrets:

The design rules, in short

Run a discovery that ends in signed artefacts. Build several small, single-purpose cubes that share conformed dimensions. Split input from reporting with an explicit refresh contract. Keep rules for what must react instantly and batch everything else. Externalise every assumption into settings cubes. Store at base level so hierarchies stay disposable. And choose names carefully, because in practice they are permanent.

Design like this and the system bends when the business changes instead of breaking. It also sets up the next decision every project faces, whether to adopt standard content or build custom. I cover that in a separate post.

Back to all posts