Data Hub Concepts and Architecture

A central model in Anaplan that serves as the single source of truth for all transactional data. It stores and validates data from the source system, ensuring accuracy and consistency before it's used by other models.

A powerful tool that enables automation of data loading into the Data Hub and data transfer to other Anaplan models.

The process of verifying the correctness and validity of data before it's used in other models. Ensures accurate calculations and consistent results.

A model in Anaplan that accesses data from the Data Hub and uses it to perform specific analysis or planning tasks. It's often connected to the Data Hub for data updates.

The process of transferring data from the Data Hub to spoke models. This can be done manually or using automation tools.

The automated process of updating data in the Data Hub on a regular schedule (e.g., daily, weekly, monthly). Ensures the Data Hub has the latest information.

This includes lists, hierarchies, and modules that are used in various Anaplan models. Storing them in the Data Hub ensures consistency and reduces redundancy.

The primary source of data that feeds the Data Hub. Typically an enterprise-wide data warehousing system.

A module in the Data Hub that stores transactional data by time intervals (e.g., daily, weekly, monthly). It only contains transactional data and should not have any line item summaries.

A module in the Data Hub that stores metadata or attributes about data items that don't change over time, such as employee start dates or mapping information. It's independent of time.

A module in the Data Hub that aggregates data from the source system to a specific granularity (e.g., monthly, quarterly, yearly) needed by spoke models. This allows for efficient data loading.

The primary source of data that provides raw information to the Data Hub. It can be an enterprise data warehousing system, like Snowflake or Teradata.

The process of compressing data before it is transferred to Anaplan. This helps reduce the size of the data and improve efficiency.

Using Anaplan Connect to load data into Anaplan, where the data is automatically compressed during the transfer, resulting in faster and more efficient loading.

Using a web browser to load data into Anaplan, where data is not automatically compressed during the transfer. This can lead to slower loading times and potentially larger file sizes.

Modules and Views are a collection of lists, hierarchies, and modules used in Anaplan models. Storing them in the Data Hub ensures consistency and reduces redundancy across the platform.

A central model in Anaplan that serves as a single, trustworthy source for all transactional data. It ensures accuracy and consistency before transferring information to other modules.

Modules that utilize data from the Data Hub for specific analyses or planning tasks. They often connect with it for data updates.

The process of verifying data's accuracy and correctness before it's used in other models. It ensures consistent results and accurate calculations.

Keep data clean and clutter-free in the Data Hub to maintain optimal performance and make it easier for administrators to understand the stored information.

Always build lists from views within a module to leverage filters when importing data, as importing directly from lists in the Data Hub lacks filtering capabilities.

Instead of deleting and reloading data in the Data Hub, focus on creating clean data through a separate model. This approach reduces unnecessary processing time and keeps the hub optimized.

Avoid storing hierarchical lists within the Data Hub due to potential clutter and complexities. They are better suited for validation purposes only to ensure consistency across different sources.

Analytical modules should not be placed within the Data Hub, as end users generally don't interact directly with it. This separation keeps the data hub focused on its primary function: storing and validating data.

These are the lists in Anaplan that are not part of a hierarchy and simply group records. They are often called 'legends' or 'anchors' for metadata about a unique record. Examples include products, companies, and cost centers.

This practice involves combining the codes of Cost Center and Account into a single code. It's recommended to use code instead of properties for better model performance.

While properties are used for display names, they should not be defined on any other lists, including transactional lists. This helps avoid memory inflation and improves performance.

Using a combination of properties, such as date/period and transactional amount, to uniquely identify records can lead to exponential list size growth. Building a custom code for unique identification is more efficient.

Lists that contain millions of transactional IDs with several defined properties. They often require efficient data management techniques to avoid performance issues.

The strategy employed for loading data into Anaplan. Considerations include Anaplan Connect, 3rd party tools, or custom REST APIs, taking into account the company's internal expertise.

These are the lists in Anaplan that store data about a unique record, with the only property typically being a Display Name.

It is recommended to name flat lists with the suffix 'Flat' or '- Flat'. This helps to identify whether the list is part of a hierarchy or flat list.

The concept of ensuring that data in the Data Hub accurately reflects the same information present in downstream models, typically through comparison of total values.

The strategy of performing data validation primarily within the Data Hub and its associated modules, aiming to only allow validated data to be used by downstream models.

The process of transferring data from the Data Hub to spoke models, ensuring that the latest version of validated information is available for analysis and planning.

The practice of bringing over just the summarized totals (not individual transactions) from the Data Hub to the spoke model for comparison, simplifying the reconciliation process.

A technique for reconciling data by creating Anaplan pages displaying data from different models (including the Data Hub and spoke models) to visually compare totals and identify discrepancies.