MODLR vs Anaplan & TM1
IBM Planning Analytics (built on TM1), Anaplan and MODLR are often discussed together - all three provide a structured environment for financial and operational planning that scales beyond what a spreadsheet can do. They differ significantly in architecture and philosophy. This page is reference material rather than a sales pitch: useful if you've worked with TM1 or Anaplan before, or if you ever need to explain MODLR to someone who has.
The three platforms at a glance
| IBM Planning Analytics (TM1) | Anaplan | MODLR | |
|---|---|---|---|
| Origin | Released 1983 as TM/1; acquired via Applix and Cognos by IBM in 2007; rebranded Planning Analytics in 2016 | Founded 2006 by ex-Adaytum/Cognos team; cloud-native from inception | Founded 2014 by an ex-TM1 consultant; cloud-native, inspired heavily by TM1's engine philosophy |
| Calculation engine | In-memory OLAP cube engine with rules and feeders | Hyperblock engine (Classic for dense, Polaris for sparse) | In-memory cube engine with formulas, feeders and invalidations |
| Deployment | On-premises or IBM SaaS (PAoC) | Cloud-native, multitenant SaaS | Cloud-native, single-tenanted instances |
| Modelling unit | Cubes built from dimensions | Modules built from line items and lists | Cubes built from dimensions |
| Sparsity handling | Strong native handling | Classic engine struggles with sparsity; Polaris engine designed for it | Strong native handling; empty cells aren't stored |
| ETL approach | TurboIntegrator (in-process scripting) | Anaplan Connect, Data Integrations, third-party connectors | In-process JavaScript Processes, plus a Visual Process Editor |
| Excel integration | Planning Analytics for Excel (PAfE), formerly Perspectives | Limited - XL Connect and an add-in with reduced capabilities | MODLR for Excel, with a full live connection, formulas and write-back |
MODLR's lineage
MODLR is heavily inspired by TM1, and the influence shows in specific places: the cube-and-dimension model, where calculations apply at the Cube level rather than the cell level; feeders and invalidations, the same concept TM1 introduced to manage sparsity in calculated cubes (see below for where the implementation differs); in-process ETL, with MODLR's pre(), begin(), data(), end() Process structure mirroring TurboIntegrator's prolog/metadata/data/epilog pattern; rules-style calculation, where TM1 cube rules and MODLR cube formulas serve the same purpose; and an Excel-first philosophy, with CubeGet/CubeSet/CubeSend paralleling TM1's DBRW/DBR/SUBNM.
The intent isn't imitation - it's that the engineering choices TM1 made for performance and modelling power were sound, and MODLR adopted the parts that worked while modernising the rest.
Where MODLR diverges from TM1
Cloud-native architecture
TM1 predates SaaS by decades. Even with Planning Analytics on Cloud, the underlying architecture is still a multi-tier client-server design - Architect, Performance Modeler, Workspace, PAfE and other components, sometimes accessed via remote desktop. MODLR is cloud-native throughout: Gateway is a single web application, and every modelling and administration task happens through it, with no on-premises option and no separate desktop tools. For administrators, that means no SSL certificate management, no manual server upgrades, and no OS maintenance.
Dimensions and Hierarchies are separated
In TM1, a dimension can hold both leaf elements and consolidation elements directly, with hierarchies added later as a feature that exists somewhat alongside the original element model. In MODLR, Dimensions hold only leaf elements - consolidation elements live exclusively inside Hierarchies, so the same leaf element can appear in any number of Hierarchies without duplication. Rebuilding or restructuring a Hierarchy never risks the underlying element list: Dimensions are what exists, Hierarchies are how it rolls up.
Automatic feeders
In TM1, every rule that creates a derived value needs a hand-written feeder statement in a separate FEEDERS; section:
['Revenue'] = N: ['Units Sold'] * ['Price'];
FEEDERS;
['Units Sold'] => ['Revenue'];The MODLR equivalent is the formula alone - the feeder is derived automatically by analysing the formula's structure:
["Revenue"] = ["Units Sold"] * [Δ"Price"](The Δ marks Price as still invalidating Revenue on change, without generating a feeder from it - see Feeders, Invalidations and Rules.)
This matters because manually-written feeders are one of the most common sources of bugs in TM1 models: underfeeding (a missing or too-narrow feeder leaves calculated cells that should exist simply absent, often invisible until someone notices a wrong number weeks later), overfeeding (a too-broad feeder creates cells that don't need to exist, inflating size and slowing calculation, often invisible until the cube gets noticeably large or slow), and drift (a rule gets updated to reference a new measure but the matching feeder doesn't, or a feeder gets copied from one rule to another without adjusting it). In MODLR, that entire class of bug can't occur, because the feeder can't be out of sync with a formula it's derived from - the only decision left is which feeders to disable for performance, not which feeders to remember to write.
A built-in datastore
Every MODLR instance ships with an Internal Datastore, preconfigured as a datasource - immediate relational storage for staging data, lookup tables, or transactional detail that doesn't belong in a Cube. TM1 has no equivalent; relational storage means connecting to an external database via TurboIntegrator's ODBC support, set up separately.
Aliases instead of attributes
TM1 has both aliases and attributes; MODLR has only Aliases. Where TM1 might use an attribute to store an account's currency or a product's category, MODLR uses an Alias, a small lookup Cube, or a Table instead - one less concept to learn, at the cost of a deliberate choice about where an element property lives.
Workviews instead of views
A TM1 view is a tabular slice with one set of selected elements per dimension. A MODLR Workview goes further: each Dimension on rows or columns can carry multiple sets, so a single Workview can combine entirely different selections of the same Dimension on the same axis - a block of monthly Actuals with one set of measures, a block of annual Budget with different measures, and a variance column with custom calculations, all from the same underlying Cube.
Server scripting
TM1 uses TurboIntegrator's own scripting language. MODLR Processes are written in JavaScript, giving access to familiar syntax and the wider JavaScript ecosystem, alongside a Visual Process Editor for assembling Processes from connected nodes without code - something with no direct TM1 equivalent.
No replications
TM1 has a built-in replication feature for syncing data between servers. MODLR has no equivalent concept - instead, the Internal Datastore acts as the intermediary when data needs to move between instances: one instance writes to it, the other reads from it.
Where MODLR diverges from Anaplan
Cubes versus modules
Anaplan has no cubes in the classical multidimensional sense - it organises data into modules of line items (measures) defined against lists (dimensions), and each line item can have its own dimensionality even within the same module. MODLR follows the cube model, like TM1: a Cube has a fixed set of Dimensions, and every cell is addressed by one element from each. Anaplan's per-line-item dimensionality can feel more flexible for processes that don't fit a uniform dimensional structure; the cube model is more predictable, since knowing a Cube's Dimensions tells you exactly what every cell looks like, which keeps formulas, integrations and reporting uniform.
Sparsity
Anaplan's original Classic engine is optimised for dense data and historically struggled with very sparse models; the Polaris engine was introduced specifically to address that, and customers now choose between engines per workspace. MODLR handles sparsity natively in a single engine - empty cells aren't stored, and traversal only walks populated space - with no equivalent choice to make.
Cube size limits
Anaplan workspaces have a hard cell limit (historically around 8 billion cells per workspace, varying by tier); models that outgrow it have to be split across workspaces and connected via Anaplan's data integration features. MODLR Cubes have no hard cell limit beyond the memory available to the instance, which can be resized through Gateway.
Excel integration
Anaplan's Excel add-in is functionally limited, reflecting a philosophy that treats Excel as a secondary interface to Anaplan's own web UI. MODLR treats Excel as a first-class interface - live cube reads and writes, CubeGet/CubeSend, opening MODLR Workviews directly inside Excel, drilling and tracing calculations from a cell, and stripping formulas to produce static workbooks for distribution. See MODLR for Excel.
Deployment model
Anaplan is multitenant SaaS, with customers sharing infrastructure under logical separation. MODLR is single-tenanted: each customer's Instance runs on dedicated infrastructure, trading some operational efficiency for isolation - a customer's data, performance and update timing are independent of everyone else's.
Customisation philosophy
Anaplan markets itself as low-code and business-user-friendly, which means complex models often have to fit Anaplan's conventions to stay manageable. MODLR sits closer to TM1 on this spectrum - full JavaScript scripting for Processes and no requirement to fit a particular convention - trading a steeper learning curve for more flexibility.
Translating concepts between platforms
TM1 to MODLR
| TM1 concept | MODLR equivalent | Notes |
|---|---|---|
| Server | Instance | |
| Database / Application | Model | |
| Cube | Cube | Same concept |
| Dimension | Dimension | MODLR dimensions hold leaf elements only |
| Hierarchy | Hierarchy | Same concept; required for any roll-up |
| Element | Element | |
| Alias | Alias | Same concept |
| Attribute | Alias, lookup cube, or table | No direct equivalent |
| View | Workview | Workviews support multiple sets per axis |
| Subset | Set (in a Workview) | Defined per-Workview, per-axis |
| Rules | Cube formulas | Same concept |
| Feeder | Feeder | Same concept; automatic in MODLR |
| TurboIntegrator process | Process | JavaScript instead of TI scripting |
| Chore | Schedule | |
| Replication | Internal Datastore as intermediary | No direct replication feature |
| TM1 Web / PAW | Gateway and Applications | |
| PAfE / Perspectives | MODLR for Excel | Similar philosophy and capabilities |
| (none) | MODLR for PowerPoint | No TM1 equivalent |
Anaplan to MODLR
| Anaplan concept | MODLR equivalent | Notes |
|---|---|---|
| Workspace | Instance | |
| Model | Model | |
| Module | Cube | Different data model - MODLR cubes have fixed dimensionality |
| Line item | Element of the Measures dimension | |
| List | Dimension | |
| List item | Element | |
| Subset | Hierarchy or Set | Depends on use |
| Time (built-in) | Time-type dimension with System.Dimension.Time | |
| Versions (built-in) | Scenario-type dimension | Built explicitly rather than a built-in primitive |
| Action | Process | |
| Process | Process or Schedule | Anaplan "processes" are sequences of actions |
| Dashboard | Card or Dashboard (in an Application) | |
| Page (Anaplan UX) | Screen (in an Application) | |
| ALM | No direct equivalent | Custom packaging and import via Gateway |
Choosing between platforms
Each platform has genuine strengths, and the differences are mostly about friction and fit rather than raw capability:
- IBM Planning Analytics (TM1) suits large enterprises with complex modelling needs and IT support available to manage a multi-tier architecture, or an existing TM1 investment. It remains one of the most powerful pure modelling engines in the category.
- Anaplan suits organisations that want connected planning across multiple business functions with relatively standard processes, where business-user accessibility matters more than deep modelling flexibility, and where fitting the organisation's process to Anaplan's conventions is acceptable.
- MODLR suits organisations that want TM1-style modelling power in a fully cloud-native environment, with direct Excel integration and a single unified web interface - typically teams that find TM1's tooling cumbersome or Anaplan's flexibility too constrained.
The three platforms overlap substantially, and most organisations could implement a working planning solution on any of them.