Chapter 1: Introduction to Connected Planning and Anaplan Architecture

Welcome to the Anaplan Technical Handbook. If you are reading this, you are likely moving beyond basic end-user tasks and stepping into the shoes of a Model Builder. Whether you are building financial forecasts, sales quotas, or supply chain models, understanding the "why" and "how" of Anaplan’s architecture is the difference between a model that runs and a model that scales.

What is Connected Planning?

In many organizations, data lives in silos. The Finance team has one spreadsheet, the Sales team has another, and HR is working off a completely different headcount file. When Sales updates their forecast, Finance doesn't see it until the next monthly review. This is the "disconnected planning" trap.

Connected Planning is the bridge between these silos. It is the process of linking people, data, and plans across an entire enterprise. When you change an assumption in a sales model, the impact should cascade automatically into the financial budget, the inventory requirements, and the headcount planning—all in real-time.

"Connected Planning isn’t just about having all your data in one place; it’s about ensuring that a change in one cell triggers a ripple effect that maintains integrity across the entire organization."

The Anaplan Architecture: Under the Hood

To build effective models, you must understand how Anaplan processes data. Unlike traditional relational databases (like SQL) or flat-file spreadsheets, Anaplan utilizes a proprietary Hyperblock® engine.

1. The Hyperblock Engine

The Hyperblock is an in-memory, multi-dimensional calculation engine. Because data is stored in-memory, Anaplan performs complex calculations—that would crash a standard Excel workbook—in milliseconds.

2. The Core Components

Think of your Anaplan model as a hierarchy of components:

• Models: The workspace container where data, logic, and users reside.
• Modules: The "workbenches" where you define dimensions and perform calculations.
• Lists: The structural backbone (e.g., Products, Employees, Time).
• Line Items: The "formulas" or data points within a module.

Building Your First Module: A Practical Example

In a traditional database, you might write a complex

JOIN

Imagine you want to calculate Total Revenue.

• Dimension A: Time (Month)
• Dimension B: Products (List)
• Line Item: Sales Volume
• Line Item: Unit Price
• Line Item: Total Revenue (Formula:
  text

  Sales Volume * Unit Price

  )

In Anaplan, the formula is simple because the engine understands the relationship between dimensions. You don't need a

VLOOKUP

JOIN

anaplan
// Calculating Revenue in a Module dimensioned by Product and Time
Total Revenue = Sales Volume * Unit Price

If you add a third dimension, like "Region," the formula remains identical. Anaplan automatically applies the calculation across every intersection of the three dimensions. This is known as automatic multidimensionality.

Best Practices for Architecture Design

When you start building, it is tempting to create one giant "Super Module." Resist this urge. A bloated model becomes slow and impossible to audit. Follow these architectural pillars:

1. The DISCO Methodology

Professional Anaplan architects use the DISCO framework to organize their models:

• D - Data: Import raw data here. Do not perform calculations in these modules.
• I - Input: Where end-users enter assumptions (e.g., price overrides, growth rates).
• S - Systems: Modules that hold structural metadata (e.g., mapping lists to attributes).
• C - Calculations: The engine room. This is where your heavy math lives.
• O - Output: Reporting modules specifically designed for Dashboards (User Interface).

2. Keep Formulas Simple

If your formula is longer than two lines, you are probably doing too much. Break complex calculations into smaller, named line items. This makes debugging much easier.

Bad Practice:

anaplan
Revenue = (Units * Price) * (1 - Discount) * (1 + Tax)

Good Practice (Modular):

anaplan
// Line Item 1: Gross Sales = Units * Price
// Line Item 2: Net Sales = Gross Sales * (1 - Discount)
// Line Item 3: Final Revenue = Net Sales * (1 + Tax)

Real-World Example: Sales Quota Planning

Let’s look at a scenario where a company wants to set quotas for 500 sales reps across 10 regions.

The Old Way: The Sales Ops manager emails 10 Excel files to regional directors. They fill them out, email them back, and the manager manually pastes them into a master file. Errors occur, and the versioning becomes a nightmare.

The Anaplan Way:

1. List: Create a 'Sales Rep' list.
2. Module: Create a 'Quota Planning' module dimensioned by 'Sales Rep' and 'Time'.
3. Security: Use 'Dynamic Cell Access' to ensure each Regional Director can only edit the rows assigned to their specific territory.
4. Result: As soon as a Director enters a number, the Finance team sees the impact on the company-wide revenue forecast.

Practical Tips for Beginners

• Naming Conventions: Develop a strict naming convention from Day 1. Use prefixes like
  text

  DAT01

  ,
  text

  INP02

  , or
  text

  CALC03

  to identify which category of the DISCO framework a module belongs to.
• Documentation: Anaplan doesn't have a "comments" feature inside formulas. Create a dedicated "Documentation" module where you describe the logic behind your complex calculations. Your future self will thank you.
• Test with Small Data: Before you load 5 million rows of data, build your logic using a list of 5 items. If it works there, it will work at scale.
• Sparse Data: Understand how Anaplan treats zeros. If a cell is empty, Anaplan doesn't store it, saving memory. Try to keep your models "sparse" by filtering out irrelevant combinations.

Summary and Next Steps

You now understand that Anaplan is not just a spreadsheet in the cloud; it is a multidimensional planning powerhouse. By leveraging the Hyperblock and organizing your models using the DISCO framework, you are already ahead of the curve.

In the next chapter, we will dive deep into List Management and Time Settings, which are the true foundations upon which all your models will be built.

Quick Quiz for the Road:

1. Why is it better to break one complex formula into three separate line items?
2. Which part of the DISCO methodology would you use to store a list of Employee IDs and their hire dates?

Take a moment to navigate your workspace and try to categorize your current modules into the DISCO framework!