The work of an insurer and intermediaries mostly takes place in the digital environment of the insurance company. This digital environment can look different for every company, because one organization has built a complete custom environment and the other use insurance applications or a combination of the two. In this blog we describe how to best use an insurance application and link it with the rest of your architecture framework.
Which insurance applications are commonly used?
Insurers and insurance agents (intermediaries) often also use standardized packages. Here are Four examples :SAP Policy Management, VERMEG Solife, Aplaza and ANVA.
These are generally good applications with many functionalities that make the work a lot easier. But what if you realize that you would rather see a functionality differently or add a functionality yourself? With these larger application systems, this is difficult and you are trapped in the package that is offered to you.
An insurance application should be a means and not the end
In fact, in many cases, entire business models are based on what an insurance application has to offer. Terminology of the application is adopted one-on-one, as well as the structure of the service, this may not be the most efficient way for your organization and this limits its distinctiveness.
This should actually be reversed. Determine the service and terminology of the company! Often a business model, it’s procedure and data are the ideal starting point. Applications are minor and are chosen to perform functions. The tricky thing is that you won’t find an insurance application that fully meets all your needs.
Abstracting the insurance application is the solution
The solution to this problem is to choose an insurance application that has the most functionality and best fits your business model, and then build an API yourself that acts as the front end. You actually use this API as your own tailor-made insurance application, without having to build the core system completely yourself. If you then want to add functionality that the standard insurance application does not offer, you can add a custom package to your architecture framework and integrate it into your API.
This way you deal smartly with what already exists, while having the flexibility of a modular system compared to using a monolith and being tied to its functionality.
The Frank!Framework helps to execute the integrations
If you have designed your own API, it must of course still be integrated with the insurance application and/or other tooling. To make this as easy as possible, you should use the Frank!Framework. This framework is already being used by the largest insurer in the Netherlands to integrate systems with each other and to ensure that applications within the entire architectural landscape are well connected. The Frank!Framework allows you to easily connect, disconnect and replace applications when necessary.
Do you want to know how The Frank! Framework works in practice?
Download our case "How WeAreFrank!, the largest insurer in the Netherlands, has been helping with the integration of hundreds of applications for more than 20 years."
