Working with Guidewire Cloud Updates
The insurance market is constantly growing. So, it’s vital for insurance companies to keep up to date with the market to remain competitive. With the arrival of the Guidewire Cloud offer, new functionalities are added to the software package on a regular basis to enable insurers to benefit from the latest technology. Guidewire has applied the upgrade principle since the Flaine version. This method is quicker, easier to adopt and less likely to break existing functionality in the application than the previous upgrade process. Insurers benefiting from the Cloud offer are obliged to update on a regular basis (contractual agreement with Guidewire).
GFT works with insurers from start to finish to help them understand this upgrade process, maximize the benefits of new features, reduce the risk of regressions and increase the speed of installation. To achieve this, GFT recommends following these guidelines for maximizing added value while minimizing the cost and risk of upgrading:
1. Prepare the target branch of code to receive the upgrade. This step is not included in the Guidewire guide, but it is important to ensure that the upgrade takes place without error. It avoids certain problems or backtracking when Guidewire produces the updated code branch. For example, temporarily removing all changes made in the gitignore by the insurer ensures that certain key components of the upgrade are not missed. This ensures that everything is in hand when Guidewire delivers the branch. It’s also a good idea to have as many automated unit tests (GUnit) as possible configured on the automatic build in TeamCity. This is a good time to correct certain tests that have been put aside for lack of time.
2. Start the update process with Guidewire. Once the source branch is ready, you can start updating the code. Using a Guidewire Community ticket, Guidewire will create and upload the upgraded branch containing the new version of the client code. Guidewire is also responsible for ensuring that any compilation or automated testing errors are resolved before passing the branch on to the customer. Depending on the number of lines of business and the level of modification in the customer code, Guidewire’s delivery time varies between 1 and 3 weeks. In some cases, adjustments have to be made by Guidewire after the branch has been delivered to the customer for the first time.
3. Identify the changes brought by the update (Phase 1). Together with the insurer, GFT can analyze what is being introduced and potentially plan to activate some of the features in the short/medium/long term, depending on the insurer’s needs. In order to adopt an update quickly, it is not recommended to adopt immediately the functionalities that are delivered. It is preferable to plan the activation of more complex functionalities via other independent micro-projects. Some of these features may require technical adjustments to suit the insurer’s current needs and/or change management for product users. It is also important to review the changes made to the Guidewire Cloud Standards to see if there are any technical debts to be expected in the coming months to comply with the latest Guidewire requirements. This analysis step can be carried out in parallel with the previous step.
4. Identify the changes brought by the update (Phase 2). Once the code has been delivered by Guidewire, it is important to visualize all the changes in the code. Although this step is not mentioned in the Guidewire guide, it does allow you to target certain significant technical impacts. Here are just a few examples:
a. Changes to the data model: Guidewire discloses in the Diff Report only certain changes of the removal or renaming type. Additions of entities, fields, values and even data type changes are not explicitly mentioned in the update guide. GFT can group together all these changes and share them with the various players impacted by the data. These include DataHub teams, Cloud Data Access teams, external services and reporting applications that consume GFT data. That’s why it’s a good idea to anticipate changes and warn all parties potentially impacted by them.
b. Changes to integration services: Any changes to integration mechanisms must be taken into account, especially if they affect services currently consumed by the insurer. To name just a few, these include the Integration Gateway, Cloud API, SOAP services, authentication mechanisms and so on. To anticipate any problems with external services, it is important to review these changes with an experienced architect/developer.
c. Visual changes: Some changes such as wording, logo, color, theme may have been incorporated in the update of a new version of the application. In some cases, appropriate communication of the change may be required, depending on the insurer’s policies.
5. Adjust the application according to the changes made: After analyzing all the changes made by the update, it is sometimes necessary to make certain modifications to the code. These may include initializing new configuration parameters to ensure that the application functions correctly, adjusting visual components to align with the insurer’s needs, updating web service contracts with external applications, etc.
6. Test the new version and ensure non-regression. As part of quality assurance, a non-regression test phase is carried out. Depending on the changes identified and reported in the previous steps, this enables the focus of the tests carried out by the QA team to be adjusted.
GFT has several experienced professionals certified in all Guidewire Cloud versions. Thanks to our expertise in insurance and Cloud development, we know how to support insurers in carrying out their Guidewire Cloud upgrade with added value for the customer. We always ensure that we deliver quality solutions that exceed Guidewire’s expectations, so that insurers benefit from the best advice and solutions for their needs.
