Application Lifecycle Management (ALM) enables your governance, development, and maintenance of Anaplan use cases. You can nowwork with ALM features in Anaplan’s User Experience (UX)to manage the lifecycle of your pages alongside that of your models.
With the UX, you now build pages inside apps. Apps contain all the different pages users need when analyzing data and planning. Pages connect to models. A page displays data from its source model, but is not a part of the model in the way a dashboard is. Pages do not sync with ALM when you run a model sync.
We’ve developed a roadmap of features to enable you to work with your apps and pages throughout the ALM workflow. Phase one is now complete.
ALM for models requires separate models for each lifecycle phase (for example: development, test, and production); changes made in development are promoted through the lifecycle via themodel-synchronization functionality.
The vision forUX ALMis to only require a single app to support multiple lifecycle phases.This video visualizes the conceptand demonstrates the new functionality:
Note:A single page only displays data from one source model at a time and all the cards on a page display data from the same model. However, the ability to associate multiple models with a page enables you to switch between source models as part of an ALM workflow. When you switch to a new source model, the data that displays on your page and its cards updates.
You can make changes to draft pages based on data from your development model, then publish your changes to end users after you synchronize your development and production models
Inthe visualization below, theConnected Planning Xperiencepage on the right in production has animage, text, KPI, and gridcards, which is accessible to users of the two associatedproductionmodels. On the left, the page’s draft state is connected to thedevelopmentmodel and has additionalchart and gridcards saved ready for publishing after the ALM model sync process.
These features enable ALM processes today:
Draft pagesenable you to create, build, and save new pages to publish later.
Previewenables you to view changes to your page as you go, before you publish.
Change source modelchanges the source model from which the page displays data.
Multiple source modelsenable you to associate models from across the application lifecycle (development, test, production) to a single page.
Switch between associated modelsenables users with access to multiple associated models to choose their source model.
Duplicate appcopies a complete app.
Duplicate pagecopies a page.
Move pagemoves a page from one app to another.
Page access controlrestricts access to a page via the roles assigned in the source model(s) the page connects to.
Development and production models |
Development and many production models | Development, test, and production models | |
Example |
Finance Dev Finance Prod |
Finance Dev Finance Prod EU Finance Prod NA |
Finance Dev Finance Test Finance Prod |
Supported? |
Yes Changes can be made againstDevand published againstProdwhen ready |
Yes Changes can be made againstDevand published against allProdmodels when ready |
Partially Changes cannot be published toTestwithout being published toProdat the same time. The app or page with all draft changes can be duplicated and repointed at Test until this is natively supported. |
This example walks you through theprocess to create and update pages在一个应用程序模型同步更新。
There are three stages to this process:
Create your app and associated models.
Make app changes based on the development model.
Synchronize and publish your changes.
Create your app and associated models
Create your app with pages andassociate the models in your ALM flow with those pages.
In this example, we have one app, two pages, and three models (Dev Model,Prod Model A, andProd Model B) associated with each page.
Make app changes based on the development model
Create new draft pagesandsave unpublished changesto pagesbased on structural changes to the development model (shown in green below). These drafts and unpublished changes are not visible to end users until they are published.It'snot necessary to create another app to make changes against the development model before you publish them to end users.
Synchronize and publish
Synchronize model changesfrom the development model to the production models and thenpublishnew draft pages and unpublished changesin published pages.Once you synchronize your development and production model, end users can use these new app components and changes.
After the ALM model synchronization process, all models are up to date in a new version (v2). The app pages are up to date based on the publish process. Note the middle page is still blue in the diagram below because we did not make any changes to this page.
This example describes how the UX ALM functionality can supporttestmodels in the lifecycle.
The current UX ALM functionality supports one draft and one published version of a page. It is not yet possible to publish different versions of the page to different associated models (that isTestandProd).
Example configuration: Consider this configuration where an app with pages is associated with a development and production model.
Make the necessary changes to your app and pages against the Dev model in draft form.
Duplicate the app(the draft changes are also duplicated).
Once duplicated, update the associatedmodels of the new test app fromDevandProdtoTest.
Synchronize changesfrom theDevmodel to theTestmodel.
Publish the draft and unpublished changes made to the pages in the duplicated app.
Invite users to test.
Once the page changes are published and the pages have been associated with the Test model, users can be directed at the test app to test the latest changes to the app and model before they are published in the original app.
Synchronize model changes to the production model.
Publish the page changes in the original app associated withDevandProd.
Delete the duplicate app.
@sprenderThanks for compiling this. I am looking forward to the Implementation of Future Road map for New UX. However I have a few queries:
@Misbahthanks for the feedback.
@sprenderthanks for this article that explains how to manage the apps and pages in Anaplan UX.
I think the purpose of the ALM of the Anaplan NewUX should be to fill in the gap between how currently the classic dashboards are managed and the apps and pages in Anaplan UX.
Currently, any small modifications made in DEV model in classic dashboards (filters, column widths, formatting, Content flags - security, etc..) I am sure it will be pushed to PROD model at the next push using the classic ALM. Any classic dashboard modification is considered as "structural change".
Currently, the modifications in DEV apps pages made in Anaplan UX need to be manually traced and the PROD pages need to be first deleted and then moved from the DEV app.
I think this is what@Misbah2点。在Anaplan用户体验,每个page-builder needs to manually sign and trace for every modification that has been done to the pages in order to know which pages need to be pushed into PROD.
Below, some of the gaps between the managing of the "classic dashboards" and Anaplan UX that I hope will be addressed and solved in Anaplan UX:
Thanks,
Alex
Hi@alexpavel,
Thanks for your input. I am working on this project with@sprenderand hopefully I can give you some reassurance.
1 and 2 - We have plans for a history/version log in Phase 2 - we’ll be sure to incorporate your feedback. We also have plans to highlight to page builders where draft versions exist so changes can more easily be tracked down.
3 and 4 - Phase 2 includes the concept of App Modes which will introduce a more formal process around draft and published versions of pages - this will eliminate the need to delete prod apps to update them with a new version.
I hope this helps
Thanks, Chris
In both these approaches either a page within the PROD APP or the entire PROD APP needs to be deleted but I have a query who is going to do that? I mean I as a consultant wouldn't be having access to Prod Models and hence wouldn't be able to make that change. Are we expecting clients to make that change?
(Edit -@DavidSmith@rob_marshallFYI )
@alexpavelThanks for elaborating on that point
Hi@Misbah,
I believe the current permissions behaviour is similar to the model synchronisation capability of ALM, ie. the user performing the model synchronisation needs to be a workspace administrator of both the source and target models. Maybe you could send me a message and we could start a conversation about the implications of that current requirement?
Thanks,
Chris
Hi@ChrisM,
great to know you're working on history log for New UX apps!
However what complicates our team's life more than all mentioned is that you cannot see if a module is used somewhere in the app.
Imagine doing an audit and seeing a module, which should be optimized/removed. In classic UX you could see if the module is populated on a dashboard and know if users can access it and what you'll need to revise after changes. In New UX you have to go through whole app to check if a module is populated to understand the impact of the change.
Are there any plans to introduce something similar for apps? It may be an additional column like "published in App" with the names of the page/worksheet in it.
Thanks,
Haik
Is there any way to apply page-level changes in bulk in NUX? I have a small (14-page) app that I would like to update to using two modules per page as described above - currently that's 15 clicks per page to make these changes. I also would like bulk changes for Manage This App > Manage Models, as when copying an app and changing the model, it's painful to have to click through two dropdown boxes per page to make changes.
Thanks!
great point@Hayk. Currently I'm listing out what page a module is used in the notes section. Agree their needs to be a easier way to identify where modules are being used in Apps.
Tagging onto this thread to keep up to date on how ALM is progressing for apps. I think the current paradigm for having a single app / page linked to multiple models is confusing in its current state. In my opinion, it would be must easier to follow something similar to the model ALM paradigm, where you sync to push changes from Dev to UAT/Prod, etc. Ideally syncing page by page or the entire app.