Every Anaplan model that has stayed fast for five years shares one trait: the builder decided what each module was for before building it. DISCO is the Anaplan best-practice vocabulary for that decision. It stands for Data, Inputs, System, Calculations, Outputs, and it is less a rule than a discipline: each module does one job, so the model stays readable, the calculation chain stays short, and the sparse parts stay separate from the dense parts.
This guide explains each layer, the naming convention, the line-item-level settings that matter most, and the mistakes that undo all of it.
The five layers
D: Data modules hold what arrives from outside: actuals from the GL, headcount from HR, volumes from the ERP. They are dimensioned exactly as the source is, and they contain no formulas except light type conversions. Nobody types into a Data module.
I: Inputs modules hold what people type: assumptions, drivers, overrides, adjustments. Dimensioned at the level planners actually plan, which is usually coarser than the data. Inputs are separated from calculations so you can lock them with Dynamic Cell Access, audit them, and never accidentally overwrite a formula.
S: System modules hold the structural facts about your lists: mappings (cost center to department), properties (product category, launch date), flags (is active, is open), and time properties. They are dimensioned by a single list (or by Time alone) and are the glue every LOOKUP and SUM uses. System modules make the model navigable: if you want to know how products map to categories, there is exactly one place to look.
C: Calculation modules do the work. They take Data, Inputs, and System modules and produce numbers. They are dimensioned as small as the calculation allows, and they are where all the modeling effort goes.
O: Output modules shape results for consumption: the P&L layout the CFO wants, the export format the warehouse expects, the summary feeding the New UX page. They contain references and summaries, not new logic.
Naming that enforces the structure
Prefix modules with the layer and a functional area code so the contents pane sorts itself:
DAT01 GL Actuals
DAT02 HR Headcount
INP01 Revenue Drivers
INP02 Headcount Plan
SYS01 Cost Center Properties
SYS02 Product Properties
SYS00 Time Settings
CAL01 Revenue Build
CAL02 Compensation Calc
OUT01 P&L Report
OUT02 Export to Warehouse
The numbering is cheap and the payoff is large: a new builder can find anything, and the dependency direction (D and I and S feed C, which feeds O) is visible at a glance. Formula references that go the wrong way (an Input reading from a Calculation, an Output feeding a Calculation) are immediately suspicious.
Line-item settings that decide performance
Structure gets you most of the way. Four settings at line-item level decide the rest.
Summary method. Every numeric line item defaults to Sum at every parent level of every hierarchy and at every time aggregation. That is often more summary cells than detail cells. Set summaries to None on intermediate calculation line items, and turn them on only where someone will read the aggregate. On a large calculation module this single change can halve the cell count.
Applies to. Dimension each line item only by what it needs. A tax rate that varies by country and year should not be stored in a module dimensioned by product. Use line-item-level Applies To overrides (a line item can use a subset of its module's dimensions), or move the item to a smaller module.
Line item subsets. When you need the same calculation across many line items (for example a currency conversion on every P&L line), build the logic once in a module dimensioned by the line item subset rather than writing thirty near-identical formulas.
Format. Booleans are the cheapest format; text is the most expensive. Flags should be Booleans, not text, and text should never be used as a key when a list-formatted item will do.
Formula patterns that keep calculation chains short
Aggregate with SUM, not SELECT or chains of LOOKUP. To roll revenue up to region using a mapping in a System module:
-- In CAL03 Revenue by Region, dimensioned by Region x Time
Revenue = CAL01 Revenue Build.Revenue[SUM: SYS01 Cost Center Properties.Region]
Pull attributes with LOOKUP from System modules, once.
-- In CAL01 Revenue Build, dimensioned by Product x Time
Category Price Index = INP01 Revenue Drivers.Price Index[LOOKUP: SYS02 Product Properties.Category]
Avoid daisy chains. If line item C references B which references A, and only C is ever read, consider writing C directly from A. Each intermediate line item is a full block of cells. The exception is when the intermediate is reused by several consumers; then it earns its keep.
Keep IF tests on Booleans. IF Is Active? THEN x ELSE 0 is cheaper than IF Status = "Active" THEN x ELSE 0, and text comparison is the expensive part. Compute Is Active? once in the System module.
Use time-relative functions over time-lookups. PREVIOUS(x) and CUMULATE(x) are designed for the time dimension; x[LOOKUP: Prior Period] patterns are slower and harder to read.
The module-by-module review
When we review an existing model, we walk every module and ask five questions:
- Which DISCO layer is this? If the honest answer is "two of them," split it.
- Which dimensions does it not need? Remove them.
- Which line items have summaries nobody reads? Set them to
None. - Which formulas reach across more than two modules? Simplify the chain.
- Which lists are driving size, and are they the right lists? A numbered list of real combinations can replace a cross product in Hyperblock; in Polaris the natural dimensions are usually fine.
A model that passes that review is fast, and it will still be fast after three years of enhancement, because the next builder can see where things go.
What DISCO does not solve
DISCO is a structural discipline; it does not choose your calculation engine, design your integrations, or tell you which level to plan at. On a naturally sparse model it reduces pain but does not remove it, which is the case for Polaris (see our Hyperblock or Polaris guide). And it does not help a model whose problem is that the business process it mirrors is unclear. Fix the process, then model it.
If your model has grown beyond what its original structure can carry, our Performance Optimization and Model Design and Build services start with exactly this review.