Number of periods for a model should not be part of ALM

[karank]

There has been numerous occasions where by my clients have asked me to reduce time duration for DEV and UAT Models . For eg. i might have 20 Yrs forecast in prod but only  5 yrs in DEV and UAT . With number of periods being part of ALM it cannot be achieved . 

It will be great if we can take it out of ALM structural change if possible 

[Misbah]

@karank 

Biggest advantage of doing this is that It will help optimizing the models within the workspace & the good amount of space can be released immediately in Dev & UAT Environments. Any other advantages that you can think of?

[karank]

@Misbah you have pretty much highlighted the single biggest advantage which is space optimisation . I get lot of clients asking me why is my DEV and UAT space same as prod ? 

Most of the time they are not happy paying same money as production space for Dev space. 

[Misbah]

@karank 

This will be nice if the number of periods (past & future) can be taken out of ALM. However you brought another topic of having all three environments having the same size - which shouldn't be the case.

Dev environment shouldn't be as big as UAT or Prod, it is recommended that it should not be more than 5 GBs even if UAT/Prod model is over 100 GB. But I agree with you that UAT environment being similar in size with Prod makes a huge impact on the overall space allocation. One way to handle it is by implementing this idea.  hence I am upvoting for it

Thanks

Misbah

[andrewtye]

I guess that the only issue might be on time ranges it might through things out, would also need to make sure that no selects for time except All Periods are going on.

[david.savarin]

One way to reach the space / memory issues on dev / uat concerning time is to allow time subsets management in the same way as other dimensions.

That way you could just reduce quickly reduce space consumption by unchecking the years not necessary in whatever environment you are.