-
2.01-11 Keep the Dimension Order consistent
Ensure the dimension order is consistent among modules. Calculations are faster if the common dimensions are in the same order as the Applies To. The size of the list is not as critical as the order Best Practices article: Dimension Order
-
2.01-06 Avoid Using Subsidiary Views
Subsidiary views are difficult to work with and audit. Try and minimise their use especially for calculation modules; create groups of calculation modules instead with like dimensionality Exceptions: 2.01-06a Display on Dashboards for analysis or filtering: Sometimes, to enhance the end user experience, attributes are…
-
1.07-02 Line Item subsets for Version Formula
Use Line Item subsets to create different numeric formulae for each version to avoid multiple Ifs Best Practice article: Line Item Subsets Demystified Decreasing the Length of Your Formulas Variance Analysis With Native Versions Made Easy
-
1.05-12 Use formulas to derive properties of the list
Based off the code of the list it should be possible to derive the attributes; Calculating the values is more efficient than storing text fields Best Practices article: Data Hubs Purpose and Peak Performance
-
1.05-10 Never delete list and reload the list as a daily occurrence
Clearing and reloading a list increases the structural changes within a model and will increase the likelihood of a of model save, thus increasing the import time. It also removes pre-allocated memory block designed to increase efficiency. Use a unique key to update to values rather than delete and re-load. Also consider…
-
1.05-03 Avoid using List Properties
List properties are the same as line items, but have many limitations, so keep it simple and have one place for calculations i.e. Module.Line Item Exceptions: * 1.05-03a Reference module line items: Where the following exceptions are used, reference module line items through a formula where possible to keep the audit trail…
-
1.05-02 Always use a code
Using codes is more efficient for loading and using lists so strive to always have a code for lists. This is especially important for numbered lists Exception: 1.05-02a Static non hierarchy lists: For simple static lists (such as Yes/No) it is OK not to have a code, but even then, Y and N can be used as codes Related to…
-
1.06-02 Don't use subsets on large lists
Lists, and subsets take up space within a model, so if you need multiple subsets of the same list, consider whether they would be better as separate lists. This is especially valid if the lists do not overlap and they are being fed from a Data hub. For overlapping subsets or if there is a need to “consolidate” the value…
-
1.03-01 Only give write access to lists when needed
Unless the end users need to edit the members of the list (e.g. add, delete), access does not need to be set. Adding roles to lists increases the memory usage, so only use when necessary. A user can edit data in a module without needing to have access to the list Best Practice article: Pre-Allocation in Lists (and Impacts…
-
1.01-01 Never use SELECT with Time
This goes against the Sustainable element of PLANS and the hard coding can cause issues when updating the timescales of the model. Modules with Time formatted items to be used as sums and lookup are the better option Exception: 1.01-01a Generic Time periods: It is OK to use SELECT with Generic Time periods such as Actual…
-
6.05-05 Use a Data hub to populate the Development Model
Use saved views within the Data Hub to populate the Development model. This allows defined data and structures to be imported to assist initial development and component testing
-
6.05-04 Keep the Development model small
Keep the Development model as small as possible. Try and only use a selection of items in the production lists to minimize the model size. Use the “create from revision” functionality as part of the set up Best Practices article: Prepare Applications for ALM
-
6.05-02 Archived Models
Compatible models (DEV, TEST or PROD) can be archived without breaking the link between them Related to Rule: 6.05-03 Model modes Best Practice article: ALM Explained—Part 2: Testing
-
6.05-03 Model modes
When restoring Archived models, restore the model to Deployed mode if this is a Production or Test model Related to Rule: 6.05-02 Archived Models
-
6.05-01 Make DEV the source for everything
DEV> Test, and DEV>Prod is more flexible; it allows multiple Test models, and Test models to be created and deleted without compromising Prod. It also supports segregation of duties Best Practice articles: ALM Explained—Part 1: Compatibility ALM Explained—Part 2: Testing
-
6.04-03 Master Dashboards
Master Dashboards will delete any personal dashboards. Techniques to minimize user disruption include creating a copy and have a migration process to move users to the new dashboards Related to Rule: 4.01-14 Enable Personal Dashboards Best Practices article: Personal Dashboards - Tips and Tricks
-
6.04-02 Switchover
After a revision, create multiple revision tags with different switchover dates prior to starting new development Best Practice article: Managing Frequent Structural Changes During Development
-
6.03-03 Keep Test models in Deployed mode
Test models should be treated as Production Models. This gives a true representation of testing and also prevents inadvertent synchronises from Test to Prod Best Practice article: ALM Explained—Part 2: Testing
-
6.03-02 Use deployed in Dev mode for additional security
Setting deployed mode for Dev models is OK and can prevent inadvertent structural changes being made outside of normal development cycles
-
6.03-01 Don't take the model out of deployed mode
Once ALM has been initiated, and Deployed mode is turned on, the Production model should NEVER be taken out of Deployed mode Exceptions: 6.03-01a Development Model creation - When copying a Production model to create the initial ALM environment, or when re-creating the DEV model as part of a “reset” 6.03-01b There are no…
-
6.02-04 Don't click and hope
Review the referenced by column of potential lists and check for hard coded formula references before checking them as production so you don't generate rollbacks Related to Rule: 6.02-02 Formula protection - Hard coding Best Practice article: ALM Explained—Part 3: Avoiding Data Loss
-
6.02-03 Review the need for Production Lists
Only lists that require amending as part of the business process, or where the lists are populated by imports should be set to production lists Best Practice article: ALM Explained—Part 3: Avoiding Data Loss
-
6.02-02 Formula protection - Hard coding
You cannot hard code a reference to an item in a production list because that member may be deleted by an end user Best Practices article: Formula Protection
-
6.02-01 Define Production lists before the first sync
Don't set all lists to production initially. Setting a list back to Structural (after a synchronize) will remove data from the existing production list even if the members are the exact same Best Practices articles: Prepare Applications for ALM ALM Explained—Part 3: Avoiding Data Loss
-
6.01-05 Dummy Test Model
Set up a "shell" model (using create from revision) that contains no production list members on which to test revisions and synchronises regularly Related to Rule: 6.01-02 Create a Revision Tag at least once a day Best Practice article: ALM Explained—Part 2: Testing
-
6.01-04 Synchronize Production regularly
Minimize the risk of sync errors by synchronizing regularly to keep Production and Development aligned Related to Rule: 6.01-02 Create a Revision Tag at least once a day Best Practice article: ALM Explained—Part 1: Compatibility
-
6.01-03 Revision documentation
If you need a broader description of revisions, create a normal list (Non Production Data) and then house the revision details in a module with other fields such as Approved date User Story, Developer, Tested date, Sign off date etc. Best Practices article: Revision Tag Documentation
-
6.01-02 Create a Revision Tag at least once a day
During periods of intense development, ensure that revision tags are created regularly and tested against a "shell" model Best Practices article: Revision Tag Best Practices
-
6.01-01 Create a Naming standard
Be consistent with how you name your revisions. It is advised to use a Major.Minor nomenclature (e.g. R1.01, R1.02, R2 etc.). Remember, the description is permanent and cannot be changed - Be careful!
-
5.07-09 Avoid using a Top Level for large lists of transaction data
Don't create a transaction list with a top level. The calculations will need to sum for all items in the list even if only a single item is added Exception: 5.07-09a Check totals: If a check total of all transactions is needed, but again using the flat attributes modules is preferable Related to Rule: 5.07-10 Add…
