Understanding model synchronization in Anaplan ALM

The customer response to Application Lifecycle Management (ALM) in Anaplan’s 2016.4 release has been outstanding. Within days of the launch, several customers were using ALM, and the number grows daily. Because there’s so much interest, I want to share some general thoughts (beyond what’s in the documentation) on what’s needed for ALM to synchronize models. I’ll also lay out a couple of scenarios where customers find this feature useful.

First, let’s understand what’s needed for synchronization using ALM. Synchronization between compatible models requires two conditions:

1. The two models must have a common origin. That means they both originated from the same revision—such as when one model has been copied to produce two models.
2. Only one of two the models can have structural (that is, metadata) changes after it was copied or synced.

With those two conditions met, you can sync from the model with changes to the model without changes. The rule is that the target model version must be in the revision history of the source. To put it the other way around, the source model can only have moved on from the current revision of the target. If two models have a common origin but metadata is changed in both, then syncing is not possible.

That’s one reason why it’s a best practice to keep a production or test model in deployed mode at all times.

ALM is especially helpful when a production application is split into multiple actual models. Let’s explore this synchronization capability in one of two scenarios:

• Split models. Our largest customers often use a split production model. In these cases, the customer would like to have a single model but chooses not to, to improve performance because of the model’s size. In a split model, the metadata is identical across the set of split models. ALM sync can update all of the models from a single development model or update one production model from another. The revision tags in the production models will confirm that they all are at the same stage. Before ALM, changes required manual updates and downtime of the production application.
• Similar models. In some cases, customers have a set of similar models, and adapt them to be the same with respect to metadata. This enables them to maintain them in a single development model. The conversion to achieve a common development model can be a complex job. A major consumer packaged goods (CPG) customer does this: they have a separate model for each geographic market because user activities in each market vary and market-specific dashboards are required. They have to implement all required dashboards (and navigation paths, and other criteria) in the single development model, then carefully set up user roles, role-based access to modules and dashboards, and market-specific navigation paths to ensure that each user sees only what they need. Once that’s done, they can then sync from the development model to the market-specific production models.

In both these scenarios, all of the big hierarchies of the model would be set as production lists, and would be imported into the production models from a data hub—effectively, master data. The development model would use cut-down versions of these lists to keep the model small—usually, very much smaller than the production models.

I hope this clarifies the power of, and strategy behind, our implementation of ALM and specifically the model synchronization feature.