Source: versicherungswirtschaft-heute.de
Almost all insurers are currently investing three-digit millions in the conversion of their application landscape. The reason for this is that existing self-developed inventory management and damage systems are getting old and cannot meet current requirements for flexibility, running costs or innovative ability. The legacy systems are mostly replaced by standard software from the market, which is often extensively adapted to the needs of the insurer. At the end of the migration project, some of the legacy applications that were still programmed in COBOL will be replaced by software that was developed in a future-proof programming language. A guest post .
In parallel to the replacement of the legacy systems, most insurers are also pushing ahead with their cloud strategy and want to migrate their systems to the cloud or obtain functionalities from the cloud “SaaS” from third parties. This should save costs and improve scalability.
The architecture of the application and infrastructure landscape needs to be adapted
On closer inspection, however, the high expectations are not fulfilled with this procedure. With the introduction of standard software, the largely BiPRO-compliant business process standards of the manufacturer are adopted, but the basic architecture of the application and infrastructure landscape is not changed. Ultimately, only old applications are replaced by new ones and one or the other application is no longer operated in the company’s own data center, but in the cloud.
The classic architecture of front-end, middleware and back-end remains unchanged, but the desired improvements in terms of scalability and flexibility cannot be realized with this. The hoped-for cost savings are usually not achieved either because the purchased standard software is extensively adapted, which leads to increased costs for further development and operation, and secondly, extensive batch runs and complicated job networks drive the costs for the cloud into the Height.
Development of a state-of-the-art architecture and implementation of microservices
An alternative approach is the development of a state-of-the-art architecture that follows a decentralized service-oriented approach and increasingly focuses on the definition and implementation of microservices. For this purpose, the necessary functionalities such as tariffing, commission or claims management must first be identified and described, for example with the help of a functional architecture map (capability map) or along the customer journey.
The next step is to consider how the corresponding services are provided. One possibility is the in-house development, whereby either existing software is adapted or the functionalities are reprogrammed. The second variant is the use of standard software. Thirdly, technical services can be obtained from the market as software as a service (SaaS). It must be decided in each individual case which of the three options is best suited for which service. It makes sense to develop the individual design of front ends for agents and customers on the basis of quickly changing microservices, while classic, stable and automatable backend processes can be mapped using adapted standard software.
In the case of self-developed or standard software, the insurance company must clarify where the applications are operated. For the time being, the company’s own data center is still available, and a private or public cloud can also be used. When deciding on a cloud service provider, possible risks, such as ensuring data protection, a possible vendor lock-in and regulatory requirements must be examined and assessed. A multi-vendor strategy makes sense to minimize risk, in order to ensure the greatest possible flexibility when changing providers or outsourcing models, for example to comply with stricter regulatory guidelines.
A challenge with this approach is to orchestrate the various decentralized (micro) services between your own data center, the various clouds and the SaaS service providers. For this purpose, the services are connected to each other via an integration layer and corresponding API gateways and controlled and monitored using a cloud management platform. It also determines where which data is kept and evaluated, for example, for analytics, since the data may be distributed across different cloud providers and your own data center.
For most insurers, both appropriate sourcing models and consistent orientation towards (micro) services are new territory, but ultimately the requirements of digitization can only be implemented with a modern architecture.
