Best practices for IBM TRIRIGA application upgrade – Part 3
Our earlier posts focused on IBM TRIRIGA application upgrades steps adopted by ValuD. In this post, we share best practices following the actual application upgrade process.
1. Source and Target environment interaction
As mentioned in this post, ValuD recommends setting up a Source (copy of the current production environment upgraded to the 3.5.3 platform release) and a Target (clean install of 10.5.3/3.5.3) environment before starting the upgrade process. As the Source environment becomes the development environment, use it as the source for the upgrade delivery. Make your modifications – customizations that can be moved – in the Target environment.
TRIRIGA object modifications made in the Source environment will be reflected in the Target environment. ValuD also recommends that you move only the necessary custom objects (those custom objects that have dependencies on any TRIRIGA business object) from the source to the Target environment.
2. Metadata updation
Metadata refers to the building blocks of IBM TRIRIGA and include Business Objects (BO), Forms, Queries, Workflows, Navigation, Menus and forms, Lists and Security.
I. Business Objects
- Merging Rules: ValuD recommends that you understand the merging rules while applying the application upgrade. For instance, while copying a Business object over another business object fields, smart sections and associations will merge. Others like state family, field formulas and BO properties do not merge.
- BO Modifications: Identify the OOTB Business Objects in the Source environment that were modified / customized and object migrate those OOTB Business Objects from the Target that match the ones identified in the Source and archive the package. This is to ensure that the Target OOTB Business Objects are preserved, to be used if needed, at a later point.
- Modification Decisions: You can either
- Accept the Target OOTB Business Object as-is without making any modifications or
- Accept all the modifications from the Source modified OOTB Business Object or
- Identify the changes made in the Source and decide on whether to make the changes in the Target or not and document these changes
While modifying forms, ValuD recommends the following best practices:
- Always use two monitors while modifying forms as forms don’t merge. Importing a form over another will overwrite the target form.
- Reduce the risk of incorrectly importing a form by renaming those OOTB forms in the Target that have been renamed in the Source environment, before making any modifications.
- To ensure there is no break in workflow due to the upgrade process, ensure that before modifying the form you
- Determine and rename modified OOTB dependencies and
- Identify and migrate custom dependencies to the Target environment
- Use the insert row action to re-arrange fields or to add custom fields in the Target environment
- Use the Copy Tab and Copy Section functionality to reduce time and effort in recreating custom sections once again in the Target environment. For instance, you can create a tab and move all the custom sections into this custom tab and move this to the Target to blend in with the form.
ValuD recommends that you leave the Source queries intact including the look and feel of the query sections and reports. But if there are any modifications that have been made to pre-existing OOTB lease accounting queries, it is better to discuss with the stakeholders on whether to carry over such changes or not and level set the expectations accordingly.
Though you can use SIs to automate the workflow modification process, ValuD recommends that you manually change the workflow to maintain support compliance.
V. Navigation, Menu and Forms
If you made multiple navigational changes, manual modification will be required. Ideally, you should make a copy of the TRIRIGA global menu and rename or you might overwrite the OOTB menu as it has the same name. Move this renamed menu into production and make the changes manually.
Delete unwanted entries from the source environment and create a package with the remaining entries. Now import this TRIRIGA lists package into production.
Rename the security groups to avoid the risk of overwriting with the ones in the new release. Modify new sections and tabs manually in the Source environment before moving them to Target.
Our last and final post will focus on record data tips and TRIRIGA application upgrade delivery process. For more information on IBM TRIRIGA upgrade best practices, watch our webinar.