Pro tips: Anaplan Lifecycle Management (ALM) implementation
Ahhh, the joys of reminiscing…unless you’re reminiscing about the early days of Anaplan, before Anaplan Lifecycle Management (ALM) was available and fully vetted like it is today. Back in my day — 2014 to 2020 to be exact — migrating changes in Anaplan meant just that. Migrating. Changes. Individually. Each. And. Every. One. It was a challenge.
Before ALM, my customers were always a little concerned with the concept of redevelopment because it was not (by definition) what they approved in the Non-Production environment. Sometimes, new functionality could be developed in Non-Prod, approved, redeveloped in Prod (but secured to the approvers), reapproved, and then deployed. Other times, when existing functionality was changed in significant enough a way to just create a new model, a data migration strategy was required to populate data from the “old” model into the “new” model. This, of course, had its own set of challenges.
If significant in-place model redevelopment was required, downtime would need to be scheduled with our customers, and my entire five-person team would come in on the weekend to make and validate the changes based on the business-approved Non-Prod model. Then we’d ask for validation and pray that the business-at-large would not find errors on Monday morning.
That all changed once ALM was ready to roll, and the early adopters had put it through the various flaming hoops of real-world scenario testing. So, you’re ready to make the leap?
What kinds of things should be considered when planning to implement ALM for a model?
- Time/Time ranges (does your model use them?)
- Development cycle (how frequently to have releases?)
- Segregation of duties and audit compliance controls (who needs documentation?)
Let’s dig in!
Time ranges
When considering time and time ranges in your models, it’s important to remember that these are structural elements within your model, the same as any other dimension or non-production list. With that said, it’s particularly easy to inadvertently lose data simply by rolling a model forward at year-end or changing the start or end date of a time range. Because any changes with respect to the Time Dimension will be included in a revision tag, it’s a good idea to experiment in a separate copy of your model to understand the end-state prior to making changes within your Non-Prod environment.
A good article on time/time range best practices is here: Best Practice: Time Range Application.
Development cycle
As of late 2020, time-related version settings (like switchover date, edit from, and edit to) became Production Data, which served to remove complicated interactions between normal monthly model maintenance and development work. Prior to that, the best practice was to strictly plan out deployment cycles to include one or more revision tags to “roll forward” a model’s switchover date and current period prior to starting the new development. This process was colorfully named “Back to the Future,” since the procedure required the workspace administrator to roll the model back to a state/time before the development started, sync the appropriate revision tag for the proper monthly version/time settings, and then roll the model back forward to continue development.
Even without the need to include the placeholder revision tags for monthly processes, the ability to revert model structures to a prior point in time defined by revision tags can be incredibly helpful. We’ve all experienced the scenario where a bug or other urgent change is reported that needs to be addressed. Instead of losing work or painfully scouring a model’s history for a change record to roll back to, Anaplan built on the “Back to the Future” concept to handle mid-development bug fixes. This ability to save the incomplete development state and resolve the request (and then get back to development) is described here: Save Incomplete Changes when Synchronizing in ALM. You can save your work in Dev, roll back the model, make the changes, sync to test, roll forward to where you started, and finish your development! It will become your next best friend soon enough!
Segregation of duties and audit compliance controls
Segregation of duties and audit compliance controls can also make a person crazy, however, ALM actually assists in that realm as well. Since ALM works across all workspaces in a tenancy, a user can be a workspace admin and act as a model builder in one workspace to perform development activities and be a standard end-user in the production model in a separate workspace. Here's a link to an article that explains how this works: Separation of Duties - Anaplan Technical Documentation. Development, deployment, and security can be entirely separate, allowing proper segregation of duties that may be required. In fact, Anaplan even provides a revision tag change analysis option (available beforehand and during each sync) that should satisfy audit and compliance teams requirements for details of the deployed modifications.
You may also ask if there is Application Lifecycle Management available for new UX apps; The answer is yes! It just looks a little different. There are now advanced capabilities to enable page builders to change source models associated with an app or individual page in an app, allow end users to choose between models within an app or page, and even create draft changes specific to ongoing model development to deploy later once the development is ready to sync. It’s also easy to duplicate or copy an app or page to make changes based on the initially deployed app that avoids needing to redevelop existing functionality. Remember, since new UX apps are a presentation layer that sits on top of a model, so long as the structural elements of the target models are the same, the same NUX app functionality will work from environment to environment. You can find that guide here: Application Lifecycle Management for the User Experience.
As always, Anaplan Community provides excellent opportunities for self-learning. A full set of guides on all topics ALM is available here: Application Lifecycle Management - Anaplan Technical Documentation.
Additionally, a three-part series to explain some specific key concepts around ALM is here: Application Lifecycle Management - Explained.
I also recommend taking a look at the full Application Lifecycle Management course in the Learning Center as well as the short courses available on Community:
- Anaplan User Experience (UX): Use UX Pages with Application Lifecycle Management (ALM)
- Course: Application Lifecycle Management (ALM)
Thanks for reading my blog! I hope you found it helpful. I wish you happy modeling and the best of luck in your ALM adventures!
Do you have any questions about Anaplan Lifecycle Management implementation? Leave a comment!
Check out recent Community blogs you may have missed:
- Overcoming the changing global supply chain with Anaplan
- Modeling in Anaplan with alternative tools: Part 2
- Headcount planning and attrition forecasting, enabled by Anaplan and PlanIQ
Comments
-
Get out the flux capacitor!
Oh how we struggled in those early days without syncing and all of that...
3 -
Great advice as always, Stacey! And particularly handy links, nice one-stop shop. I personally remember how painful it was in my first deployment early-2016 to copy DEV models to TEST models for business approval, and then do the math on whether it was better to manually move changes to an existing PROD or deprecate the "old" PROD and copy the TEST model to a brand new PROD model (which was admittedly easier before deep-linking was built into the platform). Either way, the answer was always "This is all wrong" and great articles like these make it easier than ever to take advantage of the progress.
Thanks for sharing!
2 -
Thank you @Stacey_Gibbens for sharing these tips on ALM implementation!
1
