Application Lifecycle Management (ALM) is the process of managing the development lifecycle of your applications, starting from initial design to deployment. It can be broadly categorized into four stages:

1. Design: You create user stories, schema diagrams to describe models, modules, and data flows
2. Build: You create the models based on the respective user stories/ use cases, schemas etc.
3. Test: You test the model using mock data or sanitized production data for validity & functionality
4. Deployment: You deploy & introduces the production model to the end users. Generally, your production model should be separate from your test & development models

After the initial deployment, the same procedure can be followed to further enhance your model in terms of –

• Fixing issues discovered during production
• Build additional functionality to support additional business requirements

How Does Anaplan Support Application Lifecycle Management?

Workspaces

You create your models in “Workspaces”. You can either have separate workspaces for Development, Test & Production or have a single workspace subject to workspace size limit.

Model Modes

• Standard – These are development models. Model builders can have full administrative privileges to the model including structural changes provided all access/rights are provided. In “Standard” mode, model builders start building the model by implementing respective user stories/ use cases. Once, the development is complete, the model is tested with mock data or sanitized production data to check the validity & functionally of the model

• Deployed – These are Test & Production models. Unlike Standard mode, “Deployed” mode doesn’t allow any structural changes or modification to the model, hence for any redesigning or remodification, the model builder needs to make the required changes in the development model under “Standard” mode & migrate the required changes to the Target model using Revision Tags. Once, testing is completed, the model can be finally deployed & introduced to the user as “Production” model

Note: Always ensure that the Production models are in “Deployed” mode. If you disable the Deployed mode then, the model will become incompatible with previously compatible source models for synchronization

• Locked – Users & administrator have read only access to the model under “Locked” mode

• Archived – Models which are no longer used or required can be archive using “Archived” mode. This is beneficial for workspace size management, & you can unarchived an achieve model whenever it is required

Additionally, you can also change status of the model > Online vs. Offline

• Online – It can be accessed by any users who has the required access or credentials
• Offline – It can be accessed by workspace administrator only. Regular users can view the model but can’t access it

Revision tags

Revision tags are used to migrate latest structural changes from source to target model. In this case, revision tags are created in the development model (under Standard mode) & synchronize with the Production model (under Deployed mode). It’s not possible to add revision tags in production model & perform synchronization with the source model

Revision tags doesn’t work with production data; hence, production data needs to be imported using Model Settings > Source Models

What is Structural information?

Structural information includes model configuration settings & lists. Hence, the changes made to structural information are known as structural changes. You can make structural changes in Standard mode only

However, in certain cases, you can make structural changes in “Deployed” mode as well –

• Production List – It is designed to store production data which can be edited by the user within the production models. For example – in certain cases, users would like to edit list (like customer names, employee names etc.) used for day-to-day activities. Even though it can be done using revision tags, however, we also need to explore the frequency of these modifications. It is always advisable to create a production list for this kind of scenario where users are likely to edit list regularly.

Note: Production lists has significant impact on workspace allowance, hence we must ensure limited use of production list

• Production Imports – This feature provides the flexibility to configure imports within the production model. Users can import production data from either Data Hub, or from a different model or from a file

“Back to the Future”

Ok, this may sound strange, but why we are talking about the famous movie franchise “Back to the Future”? Well, as the movie involves around time travel to solve many issues, we use the same inspiration to resolve a unique synchronization issue with the Production model

Let’s say, you are working on some improvements in the development model & 95% of work has been already completed. Unexpectedly, a bug has been identified in the Production model which requires urgent fix. How will you apply the hotfix without impacting the improvements in the development model?

The issue can be resolved in 2 stages –

Stage 1: Back to the Past

• Save a new revision tag in the development model
• Note the History ID (e.g., 1706785) of the last structural change
• Next, identify the History ID (e.g., 1606758) before any changes were made in the development model & restore it (a point where development and production were identical)
• Build the necessary hotfix in the development model to fix the production bug
• Create a new revision tag in the development model & sync it with the production model
• Hotfix has been applied to Production model now

Stage 2: Back to the Future

• Once the hotfix is applied to the Production model, go back to the development model & restore History ID (e.g., 1706785)
• Complete the remaining development activities including the latest hotfix applied to the production model
• Save a new revision tag in the development model & sync it with the Production model