Application Lifecycle Management
Share
Application Lifecycle Management (ALM)
ALM enables the process of managing multiple models all connected through one source.
ALM enables the process of managing multiple models all connected through one source. ALM’s powerful functionality allows changes in the development model to easily synchronise to testing and production environments. ALM also benefits auditability and segregation of duties. This hints article will cover the following:
Pre-requisites for ALM
During the initial development of a model ALM functionality is not required. Once the project hits UAT this is when ALM can really add value. Any further developments will then be required to run an ALM Sync. When enabling ALM you first need to ‘ready’ the current development model.
- Set production lists
- Set production imports
Production data is operational data that changes often during day-to-day business operations. Structural information can’t be edited when a model is in deployed mode.
You cannot use a SELECT formula on a production list (unless selecting the Top Level Item). In this case, you need to use a Lookup Module and LOOKUP formula.

Model Copy
Once the development model is prepared for ALM a copy or copies of the development model should be taken and named TEST – XXXXXX and/or PROD – XXXXXX. The model mode must be set to deployed mode. There are two ways to copy a model:
- Manage Models
- Copy Model From Revision
Copying a model using Manage Models will copy both Structural Data and Production Data items. Copying Model from Revision will copy all Structural Data but leave Production lists unpopulated. This is beneficial when you want create a new model from scratch and ensure there is no legacy data.

Model Mode
For reference there are four types of model modes:
- Standard – provides full access to model data, including structural information
- Deployed – blocks any modifications from being made to a model’s structural information
- Locked – read-only for all users, including Workspace Administrators
- Archived – store the model in Anaplan without it contributing to the workspace allowance

ALM Synchronisation
Synchronising development to test/production models involves a number of steps. After a build has been completed in the development model a revision tag needs to be created. A revision tag is a snapshot of the models structural information at a point in time. This revision tag can then be synced to any compatible target models.
Naming conventions are important to help manage large number of revisions within a model. A good approach is to name revisions 1.0, 1.1, 1.2 etc.
1. indicates a major revision to the model
1.1 indicates a minor revision to the model
It is also suggested a simple revision module is maintained within the development model to house specific details; Description of Revision, Date, Model History ID and Developer at a minimum.
To synchronise a target model to a source model you need to navigate to manage models screen and select the target model. Click the compare sync option.
The compare sync will locate any compatible source models to the target model. Select the revision tag you wish to synchronise to and navigate through the Anaplan wizard steps.






Source Mapping
Certain model builds require model to model imports. A good example would be the interaction between a data hub and a finance model. The data hub houses source system data along with maintaining structures. This is then imported into a target model.
When a model to model import is created the source models tab is updated in the target model (finance model in this instance). This screen displays all source models which point to an action in the target model.
This tab also allows you to remap the source model. In instances where you have a DEV Data Hub and DEV Finance model and then create ALM compatible copies, the source mapping requires a remap from DEV – Data Hub to PROD – Data Hub in the target production model.




Back to the Future Methodology
Once ALM is fully implemented any updates to the production model can only be made through an ALM synchronisation. A very likely scenario to occur is during a future sprint is a Hot Fix to the production environment. As you’re halfway through a sprint (development) you only want to synchronise the Hot Fix to production and not your current developments that haven’t been tested yet. You will need to use Back to the Future Methodology to do so.
For this functionality It is important to note the Model History ID for each revision tag (R1). This is captured in our revisions detail module (as described in above section ALM Synchronisation).
When a Hot Fix is required follow below steps:
Steps source: Anaplan Community
Follow Bedford on socials
Keep up-to-date with all things Anaplan and Bedford.

