Configuration not Code
Insurance software that makes anyone in the business a potential developer
By Martin Stewart : 11th of December 2018
Ever felt like your insurance software is like a gym membership? January 1st, like so many others you start off with the best of intentions, consult an expert who gives you a customised program in the form of source code so that you can perform the essential customisation you need to stay fit.
But, as you may have experienced, left to your own devices, change is difficult. Subsequent product releases become almost impossible as your team don’t not have the in-depth understanding of how the new product code works. This means they hack around existing code rather than make the cleanest change possible, and your form suffers. The end result is that you don’t take upgrades and don’t benefit from your ongoing gym membership – I mean, license fees.
Now, this may not matter to you if you only ever plan to make very minimal changes, your competitors are asleep or you plan to build a custom solution want the flexibility to write new code for every change.
But most insurance companies are looking for a solution that sits in the middle between a fully custom solution and an off the shelf package. The complexity of their product range and the need for systems reliability means they need something secure and stable, but flexible enough to cope with hundreds of product options, provide dashboards and support complex process flows for many different user groups.
With the right solution the majority of the requirements may be delivered with the initial implementation but as your needs changes then in order to keep up it would be a whole lot easier (and cheaper) if your product team were all coders. Instead you’ll still need to reach out to your vendor for help, and that comes at a cost. For instance, it used to cost one client over $500,000 each time we set up a business portal for a new Group fund. This was when large parts of our solutions were still custom coded.
I say, used to, because now our client can add a Group fund themselves in a week or two without even talking to us. The secret is being able to configure for change , and not have to code.
What does ‘configure not code’ really mean?
Code usually means writing Java code for internal processing and JavaScript, HTML and CSS for a dynamic web front-end user interface. When we talk about configuration, it means being able to change how the system behaves by simply setting rules, parameters or variables, rather than having to modify the code base.
Because you no longer need an in-depth knowledge of the code base, configuration can be done by people who don’t have experience in coding the base product. Instead it can be done by people who have a better understanding of the business’s needs and an intimate knowledge of how the system is used. For example, an Underwriter is able to update the underwriting rules and a Product Manager can alter premium pricing.
It also means:
- Configuration changes can be tested immediately, as no new deployment is needed.
- In many cases changes can be done directly in production avoiding the overheads and delays inherent in a new release.
- Because there are no code changes, and hence no new build of the runtime code there is no need to perform a system wide regression test.
- The impact of configuration changes are tightly restricted. For example, adding and setting the options for a user or distribution channel will only impact the one user or channel. This is very different to code changes where it is possible a developer can make a change that inadvertently affects almost any part of the system.
Besides the ease and speed of changes, the greatest benefit of configuration for an insurer is that changes do not impact the quality and robustness of the code base. A ‘product’ code base is always going to be more solid than code that has been altered by one-off customizations. This is because with a configured software solution, the exact, same product code base is shared by all clients, so it is not only tested by you, but by every client before being deployed into production.
What can be configured?
Depending on the software you choose, there are a number of elements you can choose to have configured, from business rules to user interfaces:
- Business rules – all rules that will be executed by the rules engine. These are for all forms and most business processes, i.e. workflow decisions.
- Parameter tables – e.g. postcodes, premium rates, and available options. These are used by the rules to calculate premiums, display options, and validate the data entered.
- Properties – the technical options that select what data table, module or ruleset is executed.
- Channel and User settings - these allow a business person to set up and maintain a scheme/channel/corporate/group and to create and set options for a user.
- User dashboards - select which of many ‘widgets’ appear on a page and then for each pick from dozens of options.
- Document designs - Make document template and drag and drop the data elements that will appear on it.
- Background processing – to set what jobs will run and when. Examples include purging temporary files, sending out renewals, and processing queued items like sending out emails.
When does configuration work best?
I mentioned how we managed to save one client a cool half a million dollars through configuration each time they deployed a new business solution for a super fund.
Now, you probably won’t realise these sort of savings if you plan to buy an off-the-shelf solution and make few changes.
Configuration may also not be for you if you’re building a fully custom solution. Engineering the system upfront to provide a robust base that supports full configuration will add a lot to your initial system build costs and you may not recover this unless you do lots of subsequent changes.
But where it makes a huge difference for our clients, like many insurance companies, is where there are a lot of similar but different scenarios, or complex products with a large range of options which would be difficult to code individually.
For example, one client has over 250 Group corporate schemes which are loosely based on the same base products but with each one a little different. We added the first 10, and they have been able to add the rest themselves without any new code required. Another client set the approval permissions and limits for each user so they can show they are meeting their compliance requirements. They set these for each Underwriter so they can demonstrate to APRA the Underwriters are only approving applications within the limits they are qualified to approve
So, where in your business would you like to see your business staff being able to directly configure your systems?