For most of the last decade, the standard Anaplan architecture had a Data Hub model at its center: a dedicated Anaplan model that received raw data from source systems, cleaned and mapped it, held the master hierarchies, and fed the planning ("spoke") models. It was a sensible pattern for the tooling of its time. It is not the pattern we would build today. This post describes the reference architecture we now recommend, with Anaplan Data Orchestrator at the center, and how it fits with Snowflake, SAP, and Salesforce.
Why the Data Hub became a problem
The Data Hub took on three jobs that Anaplan models were never ideal for:
- Transformation. Cleaning, mapping, and restating source data with Anaplan formulas, maintained by model builders, invisible to the data team.
- Master data management. Becoming the de facto source of truth for hierarchies, because it was the only place that had a complete, governed version.
- Distribution. Fanning data out to spokes through exports and imports, usually scheduled with Anaplan Connect scripts on a server someone had to maintain.
Each job grew. Hubs of several hundred modules are common. They consume workspace, need their own performance tuning, and put the organization's data plumbing in the hands of the people who should be building planning logic.
The reference architecture
SAP S/4HANA Salesforce HR system Files / other
| | | |
+--------+--------+--------+--------+---------+--------+
| |
v v
Anaplan Data Orchestrator Snowflake (or your warehouse)
- prebuilt connectors - enterprise data, history
- mapping, filters, joins - master data / hierarchies
- scheduling, run history - curated planning views
| ^ |
| +----------<----------+ (ADO reads curated views)
v
+------------------+------------------+------------------+
| Demand Planning | FP&A / IFP | Workforce | Anaplan models
| (Polaris) | (Hyperblock) | (Hyperblock) |
+------------------+------------------+------------------+
|
v
CloudWorks / ADO exports -> warehouse, BI, downstream systems
The roles are explicit:
- Source systems are sources. Nothing is keyed into Anaplan that originates elsewhere.
- The warehouse (Snowflake in most of our engagements, but the pattern holds for BigQuery, Databricks, or Azure Synapse) holds history, master data, and curated planning-ready views. The data team owns it.
- Anaplan Data Orchestrator is the integration layer: connectors to the sources that do not go through the warehouse, transformation for Anaplan-specific shaping, scheduling, and the run history that tells you what loaded and when.
- Planning models are planning models. Each sits on the engine that suits its density, and none of them transforms data it did not create.
- Outbound flows go through CloudWorks or Data Orchestrator exports back to the warehouse, where BI and downstream systems pick them up.
Where master data lives
This is the decision that most determines whether the architecture works. Our rule: hierarchies are mastered in exactly one place, and it is never a planning model.
- If the ERP owns the chart of accounts and cost center hierarchy, it is the master; the warehouse carries a copy, Data Orchestrator loads Anaplan from it.
- If the sales organization structure is in Salesforce, Salesforce is the master for territories and reps.
- Planning-only structures (scenario lists, planning product groups that do not exist in the ERP) live in a System module in the planning model that owns them, and are exported to the warehouse so BI can use them.
Anaplan's role in master data is to consume hierarchies and to surface the exceptions (an unmapped cost center, a product with no category) on a page someone owns. The hub model that used to be the master becomes unnecessary once this is explicit.
Source-specific notes
SAP. Use the Data Orchestrator SAP connector for the objects it covers; for complex extractions (custom tables, BW queries), land the data in the warehouse first through your existing SAP integration and have Data Orchestrator read the curated view. Do not rebuild your SAP extraction layer inside Anaplan's tooling.
Salesforce. Opportunity and pipeline data changes constantly. Load it daily (or more often) at the grain the model plans at, and keep the full history in the warehouse, not in Anaplan. Push forecast and quota outputs back to Salesforce through an export flow so sales sees the plan where they work.
Snowflake. Create a dedicated schema of planning views that present data exactly as Anaplan imports want it (one row per list item or per cell, with stable keys). Data Orchestrator and CloudWorks read those views. When a model needs a new field, the change is a view change, owned by the data team, with no Anaplan structural work.
Engine placement
The diagram shows Demand Planning on Polaris and FP&A on Hyperblock. That is the typical split: naturally sparse operational models on Polaris, dense financial models on Hyperblock, with Data Orchestrator moving the aggregated demand output into finance. Our Hyperblock or Polaris guide explains how to decide.
Migration path from a Data Hub
- Inventory every hub import, export, and transformation (who consumes it, how often, what it does).
- Reassign each responsibility to the warehouse, Data Orchestrator, or a planning model's System module.
- Stand up the warehouse views for one spoke model and build its Data Orchestrator pipelines in parallel with the hub feed.
- Reconcile for two planning cycles; cut the spoke over; repeat per spoke.
- Archive the hub when nothing reads from it.
The full checklist, with a decision matrix for Data Orchestrator versus CloudWorks versus Anaplan Connect, is in our integration tooling tutorial.
What you get
Planning models that are smaller, faster, and owned by planners. A data layer owned by the data team with proper lineage. Hierarchies that agree across finance, sales, and operations because they come from one place. And an integration layer with a run history you can actually read when the CFO asks why Tuesday's numbers look wrong.
If you are planning a move off a Data Hub, or designing a new Anaplan estate, our Anaplan Data Integration Services begin with an architecture assessment. Contact us to talk it through.