The customer

Zurich Group Germany is part of the globally active Zurich Insurance Group. It is one of the leading insurance companies in the indemnity and life insurance business in Germany. Zurich offers insurance, pension and risk management solutions.

Initial situation and challenge

The team Actuarial Practice at Zurich develops actuarial software for sales systems and portfolio management in the life insurance sector.

For lack of a better English word, experts for domain-specific languages like Markus Voelter often use the German word “Fachlichkeit” to describe the requirements within the frame of reference in a scenario like this. The word Fachlichkeit unites the knowledge, expertise, rules and constraints of a business or profession.

The main task of the team Actuarial Practice is to implement new products in life insurance while taking regulatory and administrative issues into account. This involves designing the required functionalities and mathematical procedures in detail based on contract and product data, which are then implemented as C code.

Timely provision of the actuarial software for integration into the surrounding systems, intertwined with the agile way of working, is one of the central aspects for the entire product development process.

itemis was tasked with finding out which parts of the software development process could be optimized. Furthermore, itemis was to develop a solution to ensure a faster provision of the actuarial software.

Approach and eureka effect

First, we observed and analyzed the internal processes. It became clear that time-consuming, manual steps during implementation were slowing down the development of new insurance products.

Zurich's business analysts defined the functional logic in a Microsoft Word document. This was done in the form of pseudo code that was not very homogeneous (from a formal point of view). An external service provider was commissioned to implement the function logic in C code.

The development of the actuarial software, along the steps of conception, implementation and test, takes place in a series of iterations. Test results identify potential for adjustments in the technical details and the actuarial functionalities.

The external programming required a period of several days, depending on the scope of changes. This delay in the provision of the executable code blatantly interrupted the work rhythm in software development.

Zurich therefore needed a solution for the implementation process that had the legacy code as a basis. Re-developing the computing core was not an option.

The approach had to take into account that existing functions usually have to be adapted for a functional release and not developed from scratch. This requirement resulted from the scope of already integrated products and the actuarial logic. Adaptations to the software interface are regularly part of the scope of change.

Functional logic in a Microsoft Word document
Functional logic in a Microsoft Word document
Function model in the MPS Editor
Function model in the MPS Editor

Solution

Since Microsoft Word was already in use, it suggested itself that the new editor was required to be used in a similarly intuitive way, but with much better support for the business analysts’ work.

With the Function Modeling Editor (FuMo Editor), we developed a dedicated tool that is familiar with the domain concepts and the established "language" of Zurich.

Against the background of historically grown legacy code, a review of the computing core was necessary. We first manually analyzed and unified the approximately 200,000 lines of legacy code. The goal of this action was to be able to translate patterns into simpler concepts of a possible target language.

The challenge was to guarantee the given functionality. We were able to meet this requirement, based on Zurich's existing test base, through extensive testing.

The developed domain specific language (DSL) is based on the familiar Word notation. The tool parses the old C code and translates it into the "FuMo" language using pattern recognition. We used this functionality to convert the existing system of function models into the domain-specific language of the FuMo editor.

In the further development, C code is generated again from the FuMo language after the adjustments done by the business analyst. The generated code is immediately available and can be tested immediately.

The FuMo editor is based on the Meta Programming System (MPS). MPS is a Language Workbench that we have used very successfully in recent years to create domain-specific languages for non-programmers.

The great advantage of MPS is that there is no restriction on the notation of data. Data can be defined and visualized in any conceivable form, for example as text, table, graph or with actuarial characters. This allows business analysts to describe their functions in the language and notation they are accustomed to.

Similarly to the development environment (IDE) a software developer uses, the FuMo editor offers the user a wealth of functions. These make work much easier and prevent errors.

The FuMo Editor …

  • recognizes errors of syntax and semantics and reports them to the user,
  • recognizes already existing functions, methods and variables and offers auto-completion,
  • navigates to other rules on command,
  • ensures type safety and
  • enables automated refactorings.
A code generator completes the functionality of the editor. At the click of a mouse, it generates immediately testable C code from the previously described function. The time-consuming and cost-intensive detour via the external service provider could be eliminated.

Customer advantage/customer benefit

The immediate provision of source code following conceptual activities significantly accelerates the development cycle.

The possibility to test directly makes all errors - both technical as well as errors concerning, again, Fachlichkeit - quickly visible and allow prompt improvements. In addition, the generated code has a very high degree of consistency and formality. This is particularly advantageous when the code is used in debug mode - i.e. within the development cycles.

Any error handling with regards to Fachlichkeit has been greatly simplified; IT-specific errors are now generally eliminated.

During the development phase of a release, manual code implementation, which used to take up to four weeks, is no longer necessary. Scheduling bottlenecks during the development of the computing core have been eliminated.