Modeling with concurrent developers

Generally, modeling in Anaplan is straightforward when there is only one developer owning all the changes within a model. However, as your user base grows, so do the number of use cases and requests for enhancements. This means several developers may be developing functionality within the same Anaplan model concurrently. How do you minimize the impact to production models when there are a number of changes being released by multiple developers?

When we encountered this challenge, to remain agile we had to develop a process in order to quickly release new functionality to our users, but have enough controls in place to minimize downstream impacts and disruptions. The key was developing a framework that was adopted by the team to ensure anything released went through the relevant reviews and approvals. Below I share our process when it comes to modeling with concurrent developers.

Our development framework

Our development framework is represented in the diagram below. Each box depicts a different model in the development lifecycle. In summary, developers can freely make changes to the development model and sync this to the UAT model for testing. Only UAT and CAB-approved changes are then added into the pre-production mode to be synced to the production model. It is important to re-develop these changes in a pre-prod as UAT models contain a lot of unfinalized development, and cannot be synced directly to prod.

1. DEV = Development Model (standard, offline model)
   • Used for development of functionality, structural changes, and unit testing, and generally contained less production data to minimize model size.
   • Once a developer was happy with the changes, this would be synced via ALM to the UAT model.
2. UAT = User Acceptance Testing Model (deployed, online model)
   • UAT models are generally a more recent copy of the production model so that changes were tested with the most relevant production data. Our UAT model was linked up with the testing environment of other systems to easily test downstream system impact.
   • Once in the UAT model, the changes would be peer-reviewed by another developer. This is a technical review to check if changes have been developed most efficiently and to model standards.
   • After the change has passed tech review, it goes to the end user for testing and sign-off.
   • All changes that have been UAT approved and are expected to have downstream impacts will go to the Change Advisory Board (CAB), where system owners evaluate and approve the expected impacts of the change.
3. PRE-PROD = Pre-production Model (standard, offline model)
   • The pre-prod model is a copy of the production model two weeks before the scheduled deployment date.
   • Developers carefully re-develop changes into pre-prod, complete unit tests and production data variance checks to ensure that the outcome and impacts of the change is expected. It also gives a chance for developers to test against the most up-to-date production data.
4. PROD = Production Model (deployed, online model)
   • During the deployment window, changes from pre-prod will be synced to prod via ALM with variance checks and any production data changes.
   • End users will need to do a Production Verification Test (PVT) following deployment to check that the change is working as expected in prod.

This framework does require double development, but it works for our organization and allows us to deliver new functionality quickly.

Have you had challenges developing in Anaplan with larger teams? Add your tips in the comment section below!

---

About the author: Julie Le

Julie Le is a Certified Master Analanner and has over five years of experience in Anaplan involving large-scale implementations and teams.