Extensive system integration successfully completed after the largest Dutch takeover in the insurance market

In 2017, two large Dutch insurance companies jointly announced that one had completed the acquisition of the other. The parent company is a listed financial services provider that offers products and services in the field of insurance, pensions and banking activities. More than six million private and business customers in the Netherlands use these products and services. Legally, the acquisition may have been a done deal, but in terms of system integration the adventure was only just beginning. WeAreFrank!'s Jeroen Jansen van Rosendaal, who was closely involved in the system integration, takes us through this extensive project.

Purpose of the integration project 

I worked together with the internal organization of the acquiring party and the lead architect who was responsible for setting up a new enterprise architecture in the field of document management and carrying out the associated system integration. He set out the broad outlines for the future and I translated this into solutions for the present. The ultimate goal was the seamless integration of the digital archives of both insurance companies. You cannot achieve this in one big step. For such a large integration project, this is not only unfeasible, but also unaffordable. That is why we divided the system integration into different phases and interim solutions in order to achieve the goal.

Differences between the two corporate organizations 

Both insurance companies are corporate organizations, each with their own IT organization and their own way of working. Where the acquiring party worked in a fairly structured manner, mainly with purchased applications, the acquired insurance company had built its own solutions with the help of various developers. There was also a clear cultural difference: at the acquired organization, the business focused mainly on the development and linking of applications. On the one hand, this is fine, but on the other hand, it is also difficult when setting up a good IT architecture. Demand-driven development leads to a lot of customization. This created a diverse IT landscape with little structure, where we perhaps saw too much structure and too little freedom at the acquiring insurance company.

System integration: the steps taken

The integration of the two business systems could take place in two ways:

1. We build a completely new archive, which means that all systems have to be reconnected to this new archive.
2. We work with a flexible intermediate layer to integrate both archives with each other and other systems.

Option 1 would be very time-consuming and expensive. In addition, both insurance companies worked with standard packages that could not be adapted to a new archive. That is why we started with option 2: the implementation of the Frank!Framework as an integration tool. This framework formed the basis for the system integration and is an open source framework based on Java. This allows you to create customized connections based on low code (configuration) relatively easily. Another advantage is the associated management module, which gives administrators insight into the status of the connections and data.

What is the Frank!Framework?

The first step in our integration plan was to migrate the archives of the acquired insurance company to the new solution. Of course, this was done after making analyses on how we could best achieve our final goal. We actually wanted to phase out the archive completely, but certain data, linked to pension insurance, for example, must be kept for 30 years according to the regulations. That is why we were forced to connect the old archive to the new environment in order to retain that information.

We rebuilt the services that ran on the old archive in the Frank!Framework that runs in the landscape of the acquiring insurance company. A replication mechanism was used to transfer old documents, so that a copy of the old archive was placed in the new archive. In this way, we did not have to change much in the systems themselves, but mainly in the communication between the systems.

We had the ‘customers’ (business applications) work on both archives for a while, because it is impossible to transfer all customers at once. That is why we used both archive locations for the services. This also gives us space to clean up some things at the back end. Ultimately, some customers were taken over by the acquiring insurance company and others were phased out. This is how we progressed step by step with the integration.

The result

For the end users, the system now looks the same as before, only at the back end some extra steps are taken to retrieve the correct information. Our framework works there as an intermediate layer, to which all the different customers are connected. In this way, you still get the correct information with well-defined services. Via the Frank!Framework as an intermediate layer, customers of the acquired insurance company now automatically end up in the new archive. The old archive is only available for searching.

Navigator project

Another interesting and necessary subproject that we have completed is building the Navigator. Within the acquired party, end users worked with a solution with which they could, for example, drag an e-mail to a similar application. They then added manual data to it and this information was stored in the archive. At the acquiring insurance company, these processes were much more automated with OCR software (Optical Character Recognition) and scanning. This difference in business processes had to be resolved before we could start using the new archive solution.

We realized the Navigator within 9 sprints of 2 weeks and within time and budget.

After various alternatives and parties were considered, WeAreFrank! was chosen to realize this project. We realized the Navigator within 9 sprints of 2 weeks and within time and budget. We offered such flexibility that we actually created the product that was needed and not the product that was initially specified.

The Navigator is the integration component for incoming mail flows, e-mails, web forms and scanned mail. It is the user interface that enables end users to easily manage documents: add data, assign categories, perform checks and validate information. It was essential that this solution was built, otherwise the acquiring insurance company would not be able to go live with the new archive.

Advantages of a flexible integration layer

In the environment of the acquired organization, there was a strong dependency on technicians and programmers. You often do not have insight into how data flows and connections run and then it can take a long time before a problem is solved. Moreover, this dependency means that when you set up a new solution and the standards change, you have to implement the adjustment in all components that are affected. With the Frank!Framework that we have now set up, that functional layer is decoupled from the technical layer. The big advantage for administrators is that with an upgrade or other changes, all components are automatically included. You no longer have to enter and test everything separately, which saves you a lot of work and time. As an administrator, you have much more control with the framework. Other advantages include the following:

1. For the construction of the new solution, we were able to work much faster with these standard components. We did not have to think about the technical configuration: during the implementation, for example, we could reuse code snippets. Furthermore, we were able to test and debug automatically and in a uniform manner.
2. With the Frank!Framework, administrators have access to all resources that are used. You have insight into logs and settings per application and can check the configuration. But you also have an overview of all adapters, performances and data flows. At a glance, it is clear to administrators where the problem lies, for example, a slow application, so that they can solve it themselves and only occasionally need to call in the help of a developer.

Extensive system integration completed

The entire environment is now live, the system integration has been completed and all applications have now been completely transferred. There is no longer any infrastructure from the acquired insurance company, as all systems now run within the infrastructure of the acquiring organization. We managed the integration project for a short period after delivery, but have now transferred it. I think that typifies WeAreFrank!: even after completing a project, we still feel responsible and we are there for you if you run into problems. All in all, it was a very successful, intensive and educational collaboration, in which we achieved a great result.

Even after completing a project, we still feel responsible and we are there for you if you run into problems.