Application Lifecycle Management better known as ALM enables the process of managing multiple models all connected through one source. ALM was introduced approximately 3 years back and changed the way we managed our development, testing and production environments. Prior to ALM you would need to replicate changes in all three models however ALMs 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 article will discuss the following:
Pre-requisites for ALM
During 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 (more on model modes soon).
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.
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
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.
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
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.
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.
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 re map 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 half way 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:
Create latest revision tag in development model (R2)
Restore development model to latest synchronised revision tag (R1)
Develop Hot Fix in development model
Create revision tag (R3) and synchronise to production
Restore development model back to R2
Re implement Hot Fix Development
Continue with current sprint development
Create revision tag (R4) and synchronise to production
*** Steps source: Anaplan Community
*** Diagram source: Anaplan Community