Announcing: Statement of Direction for Anaplan calculation engines

edited March 26 in Blog

Anaplan has just launched the new statement of direction for Anaplan Calculation Engines The full statement of direction can be read here.

What is a statement of direction

A Statement of Direction is a public guidance designed to inform our customers & prospects about our strategic direction at product level. It provides clarity and direction. A Statement of Direction highlights the key product investment areas for the applicable components, in this case the Anaplan calculation engines. Statement of Directions (SoD) are updated at least every year. It’s the intention of Anaplan to publish SoD’s for other Anaplan components as well.

Summary for SoD Anaplan Calculation Engines

This SoD provides guidance to our Anaplan customers using either Classic calculation engine and/or Polaris calculation engine. It provides insight into Anaplan’s strategic product direction for calculation engines.

Anaplan Polaris is our next-generation calculation engine for the Anaplan planning platform. It is designed from the ground up for fast, highly dimensioned calculation at scale. Polaris represents a paradigm shift in your ability to model your business planning challenges without compromise, allowing significantly greater granularity of planning for more detailed decision-making.

Anaplan Polaris has been in General Availability since 2023 and will be the primary focus of Anaplan’s development efforts for future innovation in calculation. We will be adding new functionality for calculation only in Polaris, as well as continuing to improve and refine the performance and scalability of the engine. Polaris is the foundation engine that supports our future development and innovation in AI, pre-configured Applications and data orchestration and management. We will continue to maintain and support the Classic calculation engine, which currently powers hundreds of thousands of Anaplan models in production. Many customers have successfully integrated Polaris-powered models into their operations alongside Classic, demonstrating a smooth transition path that can take place at a pace appropriate for your business.

Iver van de Zand – Anaplan Vice President Product Management

Welcome!

It looks like you're new here. Sign in or register to get started.
Sign In

Comments

  • How does this shift work against highly dense data structures? Wouldn't it still be the case that a classic model would be better space-wise vs a Polaris one? Or is it that for simple structures, small dimensions that the classic engine is 100% suitable

  • Will Polaris be readily available to use for all customers or will it continue to be an additional cost feature?

  • @andrewtye - From our analysis, even with all the workarounds for limited dimensionality in Classic models - almost all classic models are very Sparse. Yes, theoretically a model could be very dense and be more memory efficient in Classic than Polaris. We could make Polaris more efficient for very dense data - but so far we have not seen a real-world example where that is warranted. This is especially true when you consider ADO replacing the need for Data Hubs storing high volume transactional data.

    We believe that Polaris is the better engine choice for all use cases.

    @ViktorW - At the moment Polaris is only available in some tiers, however pricing and licensing is always subject to change and review in future.

  • What sort of migration/pathway is available for customers who have their platform entirely on classic (which I assume is a significant number)?

    Assuming this transition has already happened for some customers, what has been the typical level of cost/effort to make this happen?

  • Hi @luke_e - a good resource on this topic is a webinar done with Nvidia on their adoption of Polaris:

    Event recording available! Implementing with Polaris

    The first thing to say is that if Classic models are doing everything that you require, then there is absolutely no reason to migrate those models to Polaris. However, if there are missing requirements that are impossible or difficult in Classic - or compromises in the implementation of a Classic model that would not be necessary in Polaris, then considering what re-implementing that model in Polaris would look like is recommended.

    The amount of effort to migrate a Classic model will vary considerably depending on the amount of those missing requirements and the degree to which the Classic model was compromised in its implementation with workarounds for the dimensionality limits.

    We will be publishing more material on migration strategies in the next couple of weeks on Community, and further out we will look to provide more tooling and capabilities for migration where appropriate. In the mean time, the focus should be on considering Polaris for NEW models - or existing models which are not meeting the requirements of users due to dimensionality constraints in Classic.

  • Appreciate the detailed response @david.harding . Will have look at the webinar.

    Have found this link from Anapedia a good starting point to understand the differences and assess viability, but trust the upcoming content will go through more of the how-to-transition/considerations.

Welcome!

It looks like you're new here. Sign in or register to get started.
Sign In