Quick reference guide for ALM
Quick reference guide on check points to be considered before going ahead with Application Life Cycle (ALM)
- Answer
- Frequency of Sync up or Releases - Get an alignment with business users, model builders, PMO & IT team on how frequently the changes in DEV will be synched to PRD (Ex: Every week on Friday at 5pm PST).
- Dev/Test User List - Create a list of users to get access to DEV and TEST instances. Usually only model builders have access to DEV and QA/UAT testers get access to TEST instance.
- Data Volume - Decide on the data volume for DEV/TEST instances. (Ex: If PRD has 3-5 years of data then DEV/TEST just need 3-4 quarters of data). There should not be any real sensitive data (Employee Salary, Commisions etc) in DEV/TEST instances.
- Production Lists - Decide on the LISTS which will be populated directly in PRD. Usually these are the master data which needs daily/weekly refresh (Ex: Department, Legal Entity, GL's etc.,)
- Commit
- All changes will be made in DEV and deployed to PRD. Get a commitment from business users, model builders & IT team that PRD instance will always be in Deployed mode. All new changes will be made in DEV instance and moved to PRD.
- Change Tracker Module - Create a new list 'Revision Tag' and with it create a module to track the changes moved from DEV to PRD. The values in list 'Revision Tag' should match with ALM REVISION TAG. The module should be populated before each REVISION TAG is created. The module should have fields to capture HISTORY ID, CHANGE DATE, CHANGED BY, APPROVED BY, REVISION SUMMARY along with Revision Tag.
- Finalize
- How many instances (Dev, Test & PRD)? - Finalize if we need just 2 instances (one for DEV/TEST and one for PRD) or 3 separate instances for DEV, TEST & PRD. In exceptional cases, enterprise customers go with additional instances for SAND BOX and GOLDEN CLIENT.
- Model Builders & Admin: Decide on the list of model builders & Admins who has to be trained and certified before getting access to DEV.
6