Standard software with a freshness guarantee

As we boldly and simply state on our website, adesso insurance solutions GmbH develops “evolutionary standard software for the insurance industry.” But what do the terms “standard software” and “evolutionary” actually mean? If you were to read a definition of it on Wikipedia, you would discover the following:

“Software systems are understood to be standard software if they cover a clearly defined area of application and can be acquired as ready-made products. In contrast, individual software is developed for use by a specific customer or company.”

“In the Anglosphere, evolution (from the Latin evolvere, or ‘roll out’) is primarily associated with biological evolution. This is understood as including the gradual change — from generation to generation — in the inherited traits of a population of living organisms and those of other organic structures (e.g., viruses).

Similar, but Not Identical

Let’s start with standard software: The term “standard software” is understood by many, but often in very different ways. At adesso insurance solutions, standard software means a ready-made product for a clearly defined area of application. For example, in|sure Health Policy was developed for the purpose of administering health insurance contracts. This was then immediately available for use in the special insurance inventory administration area of application. Though this is more or less accurate, it only describes the status of the software and may not cover the needs of our customers in their entirety. So what is my point?

Developing standard software means so much more than simply building a software that has everything ready-made for the area of application and can be immediately used by the customer. This also specifically means that the insurance company’s individual requirements for the software may not be met at all, or only through “modifying” the standard software. Such a modification of the standard software may result in it not being able to receive updates, as the requirements developed in-house hinder its manipulation. Insurance companies have a very similar way of operating, but it’s not the same for all of them. About 90% of all functionality and business process requirements are the same for all insurers and do not have to be planned individually. The remaining 10% distinguish the insurers from each other, whether they concern functionality, the application, or in the reproduction of specific specialist structures.

Now, let’s take another step back. What do insurance companies actually expect from new software systems? Most of them are looking for a system that:

• has state-of-the-art technology
• has the typical standard processes for the domain in question
• can be enhanced by additional, established individual features/processes
• does not have to be disposed of after 30 years
• has a good cost structure

No Disposable Products: Software Should Be Sustainable Too

In other words, a state-of-the-art technology that is flexible and is dynamically designed for the current market situation. It should contain as much of the standard software as possible and also enable free space for individual implementation. Furthermore, the system should be sustainable and long-lasting – which means that it should be operated by the customer without any foreseeable need for it to be swapped out again.

Now we are also slowly approaching the concept of evolution.

In the development of an architecture that is suitable for these systems, you often run into issues with achieving the right degree between standard, customization, and evolution, also referred to as the freshness guarantee. State-of-the-art software systems with a claim to long service life have to adhere to a clearly defined architectural model from the beginning. This means that at least all standard processes are identified for every domain. Once that’s done, you need to utilize industry expertise and close communication with the insurance company in order to identify which issues can typically be customized. If all of the issues have been determined, it is now possible for you to build a standard software with defined customization options.

So that the software always “remains fresh” (in other words, can be “evolved” or developed iteratively), however, and thus addresses the insurance company’s requirements, the market, and current legislation, updates are necessary for both the standard and the customizations. Software updates due to changes in legislation or the optimization of standard features may not reject, overwrite or erroneously influence the insurer’s implemented customizations. Here, the issue of release capable software comes into play, one of the most important architectural characteristics for evolution capability. Release capable standard software essentially has all the typical processes and features of an application area, and contains defined variation points that are either highly developed by the insurance company, or are enhanced in their function. With this understanding of an evolutionary standard software, four essential benefits emerge:

The standard maps everything that is typically used in industry processes.

• With calculable costs, delivery and maintenance occurs via the software manufacturer.
• The variation points provide the option of enhancing the standard in such a way that insurance companies can replicate individual strengths in the software and continue to make use of them.
• The release capability has the unique benefit of not enabling customizations to be rejected or manipulated when updating the standard.

Constant Dialogue for the Optimal Standard

The configuration of the in|sure Ecosphere’s system architecture — which contains all of the aspects described above — lays the foundation for a technical freshness originating from the standard, one that is paired with the single insurer’s individual strengths. The fact that our customers are utilizing the same standard system in their offices of course also has the benefit that optimizations and modifications of the standard can be discussed and actively co-designed in forums with partners. This is how we as a software manufacturer maintain a dialogue with our customers, and together with them can continuously develop or refresh the standard. And since our customers all receive the standard that’s identical to the code, they can thus count on having solutions for everyone that have been worked on together with us, to the same extent and from the same source.

Now, I have written a lot about standard software and how our software architecture covers the needs of the insurance market, including a technical freshness. There is however another aspect to the freshness. In terms of technology, most of the systems that we replace are quite old. The status of technology that was completely innovative 30 years ago and enabled the automation of electronic data processing, has since become outdated.

As a result, another challenge emerges for the software architecture: It must be possible to refresh the system technology on a regular basis so that a new migration of the data inventory isn’t necessary, and of course, without this having any impact on the operation of the business itself. In this context, you’ll need to use sound judgement with regard to the term “on a regular basis,” as not every new technology becomes established on the market and possesses the same service life.

The in|sure Ecosphere meets these requirements perfectly, as its modular nature enables parts of the software to be continuously subject to a technology review and update. Technical freshness ultimately ensures that a software system doesn’t have to be replaced, and can instead continue to be used. As is the case with technical freshness, we as software manufacturers are not alone in this regard. It also requires collaboration with our customers, as the insurer must always be on the move in order to achieve the goal described above.

Now we have everything we need: a standard software that covers all the processes of a defined area of application, but that also enables leeway for customization — one that is also release capable and thus requires very little maintenance. The collaboration between the manufacturer of the standard software and the insurer ensures technical evolution, and technical freshness is guaranteed by the standard software manufacturer and their work with our customers. In addition to a well-thought-out software architecture, the evolution capability is also shaped by this collaboration with the customer, as one can see how the freshness guarantee is not only a privilege of in|sure Ecosphere, but also an obligation that the customer must share. The interactions and cooperation with our customers constitute an important success factor for making the freshness guarantee concept not just part of our marketing, but a reality as well.

Would you like to learn how the software from adesso insurance solutions helps insurance companies to digitalize? Then please contact our expert Karsten Schmitt, Head of Business Development.