Anaplan ALM introduces the capability to synchronize structural changes between Anaplan Models, effectively allowing clients to have a Source Model (i.e. Development Environment) and multiple Target Models (i.e. Test and Production Environments). There can only be one Source Model, and all structural changes, with the exception of Production Lists (more below) must be made in the Source Model then deployed to the Target Models using the Anaplan Compare & Sync Process.
By supporting multiple environments (models) clients can develop new functionality without any risk to the Production environment (model). As with Anaplan, which is a modeling tool, a ‘blank’ slate that requires clients to build their models (applications) from scratch the requirement for multiple environments, at least Development and Production takes on a greater emphasis as a single unintentional or unexpected model change in Production could have broad reaching implications; including loss of data and incorrect calculations.
How it works;
Implementing ALM is relatively simple, and is initiated by copying your model which creates an Anaplan reference between the two models. Once the model is copied, one model needs to be identified as the Source model, (Development environment) and one as the Target model which can be Test, Production or some other defined environment. There can be multiple Target models.
4 Things you need to Know
First, once the Source Model is defined it must always be the Source Model, meaning all structural changes must occur in this model otherwise the models will become incompatible and no longer Sync. Once the ‘Production Model’ is defined it should not be changed as this will be the only model containing Production Data. Anaplan recommends setting Target models to Deployed mode which prevents any structural changes.
Second, define Production Lists which are the only lists that can be updated in Target Models. At a minimum this includes any lists with list properties that contain data requiring frequent updates and lists that are updated by end users, for example using a Create Action
Third, the changes in the Source Model that will be synced to the Target Models must be defined by creating ‘Revision Tags’, which are nothing more than a ‘Point in Time’ snapshot of the structures of the Source model. For example, if I create a Revision Tag today the sync would include ALL model changes up to that ‘point in time’ of that Revision Tag. You cannot individually select which model changes you would like to migrate to production. The primary issue is if you have multiple developers working simultaneously on the same model, you cannot tell Anaplan to only sync the changes made by one developer and not the other – ALL changes will be synced. This requires very careful and diligent planning or alternatively ‘considering’ breaking models apart to facilitate ALM – neither is really a good option.
Fourth, keep in mind the Anaplan License rules apply to all Environments; Development, Test, Production etc. are counted against your workspace and though the concept of ‘Production’ Lists allows reducing the model sizes in non – Production Environments it does require diligence in planning and testing.
Released in December 2016, ALM still contains a number of software defects that will prevent source and target models from synchronizing. If you are going to implement ALM, it is suggested you fully understand the functionality, defects and plan & design model(s) accordingly.