How is a typical environment setup in Anaplan for SDLC?

sravangupta

I am interested to understand how a typical environment for Software Dev lifecycle needs to be setup in Anaplan? Do we have different workspaces for Dev, Test and Production or is that carried out in a single workspace with models for dev, test and prod. What are the pros and cons for either approaches?

Harsha

hi @sravangupta ,

 

Below links help you with this.

https://help.anaplan.com/anapedia/Content/ALM/Application_Lifecycle_Management_Overview.html?_ga=2.53767912.1786799711.1587354802-2036463251.1564554197

 

Application Lifecycle Management (ALM) (313) 

 

Thanks,

Harsha

aditya

Having different workspaces for dev and test environments is based the requirement and roles.

That is optional 

But all Dev and test environments  can also be in a single workspace 

 

Hope this will help

Thanks

Aditya

 

ujourney

SDLC is really important, and this should be included in any RFP.

Ultimately, it depends upon how your company is using your workspace(s), how much workspace size in your tenant, what the current use cases look like (honeycomb), and what roles and parts of the organization your various user groups come from.

I would recommend one inviolable rule - purchase enough space for a staging environment that can perfectly replicate your production environment. If you are just starting your Anaplan journey this may be in a single Workspace, but make sure you have enough room for full copies of your prod models to test with. Test exact (or as close as possible) copies of your production environment for changes before pushing to production. It seems simple, but so many issues come out of testing in models disparate to the production model (testing in the dev model only), or pushing to production without the end user providing only narrow test case signoff. Model owners from the business need to have a thorough checklist of standard production push items to review, and ensure no unintended consequences occur within the overall model along with the specific upgrade test case signoff in UAT before moving to production.

Typically I like to break out my Workspaces into the following structure, which is not always an option for one reason or another so take this as one suggestion. You also may have this replicated multiple times across your tenant for specific use cases, and user bases within your organization:

Sandbox/Training = Smaller allocated size, helps to include date rules in the naming convention, because sys admins will want to periodically clean up this workspace regularly. It's a low effort to blast out a com saying all models that start with yyyy.mm-yyyy.mm will be archived unless notified (automate it preferably). Then it's simple enough to rename the prefix of the models that are granted exceptions to keep track of the next cycle. Rule-based archiving & copying would be a nice feature to have in Anaplan via UI or API, but not currently available.

Data Hubs = All DH models of the same type (DEV, Test/Staging, Production) should be kept in one Workspace. The user group tends to be small only admins/integration, and testing occurs within the same limited user base. I say DH models of the same type because your organization may have sensitive data that may not be shared across admins within a given organization's CoE. So, for example, you may want to put all of your HR Data Hubs in a separate HR Data Hub Workspace.

Development = Dev model(s) here, typically these models do not need to have full production lists to build out model functionality and are smaller than your Test/Staging or Production models.

Test/Staging = Pull Rev Tags in from your Dev Workspace and models. I like running a full copy of production here as the best way to test, and I practically stage my Prod environment. So this means having at least 1 Workspace = in size to your Production Workspaces. Ideally 1 for every Prod Workspace, but you don't necessarily need that and it can be cost-prohibitive. By staging for my Prod Workspace I don't mean a copy the model into production like you would in an initial release situation, but if all of your integrations are running into your test workspace with a recent update of Production master and transactional data there is relatively little that should surprise you when you pull the changes into production. It can be a pain sometimes to get source data refreshed into the various source system test environments or data warehouse for all of your integrations, and there is normally coordination that needs to happen within an organization to accomplish this but it's well worth it for a defect free pull to production.

Production = Only Prod models here, and pull revision tags only from your Test Models in the Test/Staging Workspace

I hope this helps, and feel free to point out errors or things that have worked better for you.