应用程序生命周期管理(ALM)可以使您对Anaplan用例的治理,开发和维护。你现在可以work with ALM features in Anaplan’s User Experience (UX)to manage the lifecycle of your pages alongside that of your models.

使用UX,您现在在应用程序中构建页面。应用程序在分析数据和计划时包含用户所需的所有不同页面。页面连接到型号。页面显示来自其源模型的数据,但并不是仪表板的方式的一部分。运行模型同步时,页面不与ALM同步。

我们已经开发了功能的路线图,使您能够在ALM工作流程中使用应用程序和页面。第一阶段已完成。

UX ALM paradigm compared to model-sync ALM

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:一个页面仅一次从一个源模型显示数据,并且页面上的所有卡都显示了同一模型的数据。但是,将多个模型与页面相关联的能力使您可以在源模型之间切换作为ALM工作流程的一部分。当您切换到新的源模型时,将在您的页面上显示的数据及其卡片更新。

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

the visualization below, theConnected Planning Xperience生产右边的页面有一个图像,文字,KPI和网格卡片s, which is accessible to users of the two associated生产楷模。在左侧,页面的草稿状态已连接到developmentmodel and has additionalchart and grid卡片s saved ready for publishing after the ALM model sync process.

UX ALM flow.png

UX features to use support ALMprocesses

These features enable ALM processes today:

UX ALM process today

在第一阶段支持的示例用例

发展和生产模型

开发和许多生产模型 Development, test, and production models
例子

财务开发人员

Finance Prod

财务开发人员

金融产品欧盟

Finance Prod NA

财务开发人员

Finance Test

Finance Prod

支持的?

是的

Changes can be made againstDevand published against产品准备就绪时

是的

Changes can be made againstDevand published against all产品models when ready

Partially

Changes cannot be published toTest没有出版产品at the same time. The app or page with all draft changes can be duplicated and repointed at Test until this is natively supported.

Work with draft pages and production models

This example walks you through theprocess to create and update pages在一个应用程序模型同步更新。

这个过程有三个阶段:

  1. Create your app and associated models.

  2. Make app changes based on the development model.

  3. Synchronize and publish your changes.

Create your app and associated models

使用页面创建您的应用程序将ALM流中的模型与这些页面相关联

在this example, we have one app, two pages, and three models (Dev Model,产品模型a, and产品模型b)与每个页面关联。

UX ALM flow diagram 1.png

Make app changes based on the development model

创建新的草稿页面andsave unpublished changes到页based 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.

UX ALM flow diagram 2.png

Synchronize and publish

同步模型更改来自development model to the production models and then发布new draft pages and unpublished changesin published pages一旦您同步开发和生产模型,最终用户就可以使用这些新的应用程序组件和更改。

UX ALM流程图3.PNG

在ALM模型同步过程之后,所有模型均在新版本(V2)中最新。根据发布过程,应用程序页面是最新的。请注意,中间页在下图中仍然是蓝色的,因为我们没有对此页面进行任何更改。

UX ALM flow diagram 4.png

在开发,测试和生产工作流程中使用测试模型

此示例描述了UX ALM功能如何支持testmodels in the lifecycle.

当前的UX ALM功能支持一个页面的一个草稿和一个已发布的版本。尚无法将页面的不同版本发布给不同的相关模型(也就是说Testand产品)。

例子configuration:考虑使用页面的应用与开发和生产模型关联的配置。

UX ALM流程图5.PNG

Make the necessary changes to your app and pages against the Dev model in draft form.

UX ALM flow diagram 6.png

  1. Duplicate the app(更改草案也是重复的)

  2. 重复后,更新关联models of the new test app fromDevand产品toTest

  3. Synchronize changes来自Dev模型到Testmodel

  4. Publish the draft and unpublished changes made to the pages in the duplicated app

    UX ALM flow diagram 7.png

  5. 在vite 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

  6. 同步模型更改to the production model。

  7. Publish the page changes in the original app associated withDevand产品

    UX ALM flow diagram 8.png

  8. Delete the duplicate app

    UX ALM flow diagram 9.png

本文中的内容尚未针对所有ANAPLAN实施进行评估,也可能不建议您针对您的具体情况进行评估。
Please consult your internal administrators prior to applying any of the ideas or steps in this article.
Comments

@sprenderThanks for compiling this. I am looking forward to the Implementation of Future Road map for New UX. However I have a few queries:

  1. Why can't I just Duplicate the app - call it Prod App and change the source Model of this Prod App. Why the need for additional step of duplicating the Dev app and pushing the changes from duplicated Dev app and later deleting it? How is it considered to be best practice?
  2. Also when I make any structural change in a model I never used to worry what all dashboard can this have an impact upon. For example changing the logic of my filters. Now with this approach I will have to make sure that I know what all pages are getting impacted and delete those pages and replace it with newer ones. What if I miss any one of the pages?

@Misbahthanks for the feedback.

  1. 您仍然可以使用这种方法,在许多情况下,这是最有意义的。如果您只是在更新几页,请将您的我的页面保留在应用程序中,或者想保留固定的URL,则可以使用第二种方法。
  2. 不确定我完全理解这一点,但是如上所述,如果您在用例中有效,则可以使用重复的应用方法。

@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".

当前,需要手动跟踪Anaplan UX中制作的DEV应用程序页面的修改,并且首先需要删除产品页面,然后从Dev App中移动。

I think this is what@Misbah打算使用点2。在Anaplan UX中,每个页面构建器都需要手动签名和跟踪对页面进行的每项修改,以了解需要将哪些页面推入产品。

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:

  1. Make available the historical log of changes in Anaplan UX apps: currently it is not possible to identify who has done and when the modifications to the pages in an Anaplan UX app. It should be possible also to give the opportunity the "Restore to ID" action (similar to the classic historical log).
  2. Create a similar system of "revision tags" for Anaplan UX apps and the tool of the comparisons between different revision tags. this way it will be easy to identify which pages were "touched".
  3. Create the possibility to put a PROD Anaplan UX app in "Deployed mode". this way the page-builders will not be able to make any modifications directly in PROD app and the integrity of the apps will be assured.
  4. 消除了删除Prod应用程序中的页面的需求,以便能够从Dev App中复制它们。这样,当将一个页面从开发人员推到prod时,使用开发人员进行的修改将“更新”,并且将维护“ prod”页面内部ID。

谢谢,

Alex

你好@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和4-阶段2包括应用程序模式的概念,该模式将围绕草稿和发布版本引入更正式的过程 - 这将消除删除产品应用程序以使用新版本更新它们的需求。

I hope this helps

谢谢,Chris

@sprender@chrism

在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 )

@Alexpavel感谢您详细说明这一点

你好@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?

谢谢,

Chris

你好@chrism,

很高兴知道您正在为新的UX应用程序创作历史记录!

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.

谢谢,

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.

谢谢!

great point@Hayk。目前我清单页面模块是什么used in the notes section. Agree their needs to be a easier way to identify where modules are being used in Apps.

在此线程上标记,以了解ALM如何进步的应用程序。我认为,当前的单个应用程序 /页面链接到多个模型的范例在其当前状态上令人困惑。我认为,遵循类似于模型ALM范式的内容必须更容易,在该内容中,您同步将更改从开发/prod推动到UAT/prod等。理想地按页面或整个应用程序同步。

版本历史记录
Last update:
12-02-202009:23 AM
更新者:
About the Author
贡献者