The Anaplan Equation: Balancing Power, Performance, and Costs & how does it compare to other technologies

After discussing Anaplan with a client interested in implementing it for their planning processes, I decided to conduct thorough research on the platform. Initially, I was quite impressed by the polished demos and webinars, which highlighted Anaplan’s flexibility, real-time calculations, and its intuitive Excel-like interface. However, I’ve discovered that there are considerations beneath the surface that whoever is implementing should be familiar with.
This blog post, informed by the Anaplan Community, technical documentation, personal observations, and client experiences, aims to provide a balanced view of Anaplan’s strengths and trade-offs. I encourage you to read this comprehensive blog post if you’re considering implementing the Anaplan platform and technology.

Anaplan stands out as a leading cloud-based Enterprise Performance Management (EPM) platform. It is celebrated for its flexibility, real-time calculation capabilities, and Excel like user-friendly interface. Powered by its patented Hyperblock engine, Anaplan allows for interconnected models and dynamic scenario planning, making it an ideal solution for finance, supply chain, and workforce planning. A significant selling point is its focus on business ownership, which enables end-users, such as finance professionals or business analysts, to modify models with minimal IT involvement, enhancing agility in fast-paced environments.

However, this advantage comes with certain trade-offs that organisations must carefully consider. The computational intensity of the Hyperblock engine may lead to performance bottlenecks, particularly in large or complex models. Additionally, costs can escalate significantly. Furthermore, while business ownership empowers users, it also introduces governance risks when changes are made in production environments, particularly within the standard Development (DEV), Quality Assurance (QA), and Production (PROD) landscapes.

In this comprehensive deep dive, I will explore these considerations based on extensive research and insights from the Anaplan Community, technical documentation, personal observations, and client stories. This aim is to provide a balanced perspective on Anaplan’s capabilities and challenges. The blog includes many citations, making it a valuable resource for any company or team considering the implementation of Anaplan

The Hyperblock Engine: Power and Performance Trade-Offs

Real-Time Capabilities and Flexibility

In complex planning scenarios with sophisticated reporting requirements, reaching 10 quintillion potential cells is not very difficult. Smart design can accommodate this scale, but doing so comes with trade-offs and high computational costs. Notably, most demos only showcase several thousand cells; however, in many scenarios, you will end up working with trillions and more of potential cells.

Polaris is optimised for sparse data sets, where many cells are empty, making it ideal for large-scale planning scenarios with high dimensionality. However, this optimisation comes at a cost; while classic mode allocates 8 bytes per cell, Polaris allocates 24 bytes per cell. To illustrate, in another in-memory Database platform, the SAP HANA, both INTEGER and BIGINT or DOUBLE types also take up between 4 and 8 bytes. This difference explains why Anaplan’s hardware costs can be 3 to 6 times higher for the same number of records.

It’s important to highlight that we are discussing in-memory storage, but real-time calculations tend to be more CPU-intensive. This is often referred to as a “Fan-Out” effect, where a single cell triggers a cascade of calculations across numerous interlinked models. Therefore, the demand on hardware will be significantly higher compared to other platforms, which would also explain higher costs.

Performance Bottlenecks

Despite its strengths, the Hyperblock engine can experience performance bottlenecks, particularly with complex models.
Some additional bottlenecks include:

Dimensional Impact

Using native Time and Versions creates more blocks than custom lists, further impacting performance and forcing trade-offs between flexibility and performance due to the nature of Hyperblock engine calculations.

Cost Implications

The computational intensity of Hyperblock, particularly for large models, can drive up infrastructure demands, potentially leading to higher costs. For example, a model with trillions of cell combinations may require significant resources, impacting the total cost of ownership (TCO). Community insights suggest that optimising model design—such as minimising block counts or using Polaris for sparse data—can help mitigate costs, but these optimisations require expertise and careful planning.

As previously mentioned, a comparative record count on SAP HANA infrastructure could cost 3 to 6 times less in memory, although CPU costs may be a lot higher due to the real-time recalculations in Anaplan. As I like to say, it’s challenging to escape the physics. Therefore, there is a cost associated with real-time calculations, especially for large models.

Real-Time Interlinked Models – Is That Really What Collaborative Planning Teams Want?

Anaplan’s real-time interlinked models are a major selling point, offering instant synchronisation of updates, such as sales forecast adjustments, across financial budgets, workforce plans, sales strategies, and supply chain operations. This feature promotes collaboration and agility for fast-moving teams. As explained above, it comes at a cost to the hardware. More importantly, the relentless pace of updates can also disrupt workflows, leaving users feeling overwhelmed and less in control as plans change unexpectedly.

Based on our experience and real-world projects, many collaborative planning teams prefer stability over constant real-time changes. They tend to favour controlled updates with clear cut-offs and ownership of source or the so called “drivers” data like sales volume or headcount. When underlying drivers fluctuate without their control, it can undermine their sense of responsibility for plans and budgets. While real-time visibility may seem appealing at first glance, it is not suitable for everyone. Organisations need to carefully evaluate whether the benefits of real-time interlinked models outweigh the associated complexity, costs, and whether they truly align with the needs of collaborative planning teams.

The Double-Edged Sword of Business Ownership

Empowering End-Users

One of the main selling points of Anaplan is the ability for business to manage the system. This feature allows end-users to modify models, reports, and inputs, which reduces reliance on IT and enables rapid responses to changing business needs. This capability is especially valuable in dynamic environments where planning requirements evolve quickly. Anaplan’s accelerated templates offer a good starting point; however, customisation is crucial since no two companies have identical processes. Tailoring the models ensures they align with specific business requirements.

Risks in Production Environments

Permitting end-users to make changes directly in production environments caries a significant governance risks to the overall landscape compared with a standard system landscape with Development (DEV), Quality Assurance (QA) and Production (PROD).

Governance Mechanisms

Anaplan addresses these risks through its Application Lifecycle Management (ALM) features, which provide structured governance across environments:

• Segregation of Duties: ALM separates roles, ensuring that only authorised users can make changes in the PROD environment.
• Change Control: ALM supports a process for reviewing and approving changes before deployment, utilising revision tags to ensure synchronisation.
• Access Control: Administrators can lock production model structures to restrict changes to production lists and models
• Auditability: ALM APIs allow for tracking and exporting changes to meet compliance requirements.

However, effective governance demands resources and expertise which would question whether business ownership will be the best model for effective long-term planning solution. Organisations lacking a Center of Excellence (CoE) or another group department with strong processes may find it challenging to enforce standardisation, which increases the risk of disperse and likely chaotic models & inputs.

Data Entry Limitations: Leaf vs. Parent Levels

By default, Anaplan restricts data entry to leaf levels in hierarchies. This means that users cannot directly input data at parent levels, which are calculated aggregations of child data. This limitation can complicate planning processes when high-level inputs are needed, such as entering a total budget at the department level rather than at the individual team level.

Anaplan has a functionality called breakback that allows users to input data at parent or total levels. This data is then distributed to child levels based on predefined rules, such as proportional allocation. However, it only works with balanced hierarchies. This is why there are community requests and questions of how to convert unbalanced or ragged hierarchies into balanced ones.

The most significant limitation is that users cannot input data across multiple line items at the same time. For example, in a region-based hierarchy consisting of continents, sub-regions, countries, and cities, users cannot enter data at multiple levels at the same time. The same limitation applies to a multi-level Income Statement, including net profit, gross profit, cost of goods sold (CoGS), operational costs, etc. While a skilled architect may find different workarounds to address this issue, these solutions often fall outside standard functionality and may lead to increased maintenance, performance impacts, and ultimately higher overall costs.

Formula Constraints: Lookups and Mapping Modules

Anaplan’s Lookup Limitation

Anaplan’s formula capabilities are robust but encounter limitations when working with hierarchical data. The Lookup function, which retrieves data from one module to another based on a mapping, is designed to function with leaf members of a hierarchy. It cannot directly reference parent members, creating significant constraints for models that require cross-level analysis (as detailed in this Community Post). For example, if a user needs to reference a parent-level total (e.g., a department budget) in a formula, the Lookup function will return zero or fail unless the parent is explicitly mapped to its children in a balanced hierarchy or through another mapping module.

While other planning platforms may face similar challenges with referencing parent members from other models, this issue becomes more problematic due to the limitations on the input / data entry on multi-level hierarchies discussed in the previous section.

Another function with similar constraint is SUM.

Mapping Modules as a Workaround

To overcome the Lookup limitation, developers often create mapping modules. A mapping module is an additional module that maps members from one list (e.g., a parent list) to another (e.g., a child list), facilitating indirect referencing of parent-level data. For example, a mapping module might look like this:

The mapping module enables formulas to aggregate child data to the parent level via SUM function, which can then be used in Lookups. However, mapping modules add complexity to the design and increase maintenance point and impacting performance. Also SUM and LOOKUP should be used separately as it has significant performance impact.

Final Thoughts on Anaplan

Anaplan is a highly appealing product for planning and it captivates business users accustomed to spreadsheets like Excel and Google Sheets. However, important considerations beneath its impressive surface need to be accounted for:

SAP Analytics Cloud: A Structured Alternative

Why Consider SAC?

While Anaplan is known for its flexibility, its performance and governance challenges may not be suitable for all organisations, particularly those with complex models or rigorous governance practices. SAP Analytics Cloud (SAC) presents a compelling alternative, utilising on-demand efficient calculations, accelerated templates, and an attractive user-based public cloud licensing model. With Decision Inc.’s subscription-based, on-demand development and support, we are confident that we can deliver a lower total cost of ownership (TCO).

Performance Advantages

Unlike Anaplan’s real-time engine, SAC employs an in-memory database with on-demand recalculations. This approach reduces computational demands on CPU and memory, making it particularly effective for large models where potentially trillions of combinations could overwhelm Anaplan’s engine. SAC’s methodology ensures faster performance and lower resource usage.

Accelerated Templates and Customisation

At Decision Inc., we have extensive experience with SAC projects and have developed a variety of accelerated templates. We are committed to further investing in expanding our offerings based on industry best practices to provide a structured starting point for planning models. These templates can be tailored to meet specific needs, ensuring consistency and scalability while mitigating the complexity often associated with Anaplan’s highly flexible templates. This balance allows for efficient customisation without risking chaos or budget overruns during implementation.

Subscription – Based Support & Rapid Change Management

Decision Inc. offers subscription plans for SAC that include ongoing support and rapid change management—ideal for dynamic environments. Our expert-managed updates reduce the risk of errors from end-user changes in production, providing a controlled alternative to Anaplan’s business ownership model. This approach lowers the TCO by minimising governance overhead and optimising resources for their primary responsibilities.