en | de



In 2000 the LVM designed a new software system for the sales staff in its agencies. The system's core functions were those of a customer relationship management system, namely client acquisition and general management of client data. It was decided to implement the system in Java - on the server side as well as on the client side. The client was developed as a thin client using the Java Swing library. The implementation was done in such a way, that views are defined on the client side, but are populated and controlled exclusively on the server side. Therefore, there is neither business nor application logic on the client.

The individual business applications within the software - e.g. the product application and the collections application - are integrated within the client user interface and are connected by back-end calls. Currently the system is released as a monolith, which causes strong dependencies between development teams. Parts of the system's business logic are reused within other batch, web (REST) and message driven applications.

The system has been growing steadily over the last years. Most noteworthy are the addition of contract and claims applications for the back-office staff. Today the system is the central working tool for many employees, both in administration and in the field. More legacy applications will be migrated into this system in the future.

Currently, a study of alternative user interface technologies is being conducted to find out which of them might best fit the needs of the LVM. Focus has been put on browser-based user interfaces, because native user interface libraries would impede the ability to switch platforms in the future. At present, the LVM uses a desktop operating system which is based on Ubuntu.

The alternative client architectures "single-page application" (SPA) and "resource-oriented client architecture" (RoCA) were examined in more detail. A single-page application renders HTML on the client side, a RoCA application does this on the server side. There are other architectures using server side rendering of HTML, like stateful component-based systems (e.g. Java Server Faces). These architectures are based on a non-persistent session state, which reduces scalability and obstructs the adoption of cloud technologies. Because of these disadvantages, stateful architectures were dismissed as viable options.

To perform a more detailed examination, the companies innoq (RoCA) and thinktecture (SPA) were commissioned to each develop a prototype application. The underlying requirements and use cases are described further below.

innoQ developers

thinktecture developers

Purpose of the publication on github

The implementation of both prototypes has been completed by now. We decided to make them publicly available to initiate a debate about the pros and cons of both architectures.

Some of our questions and points of discussion:

General set-up

Primarily, we wanted concentrate on the client side of the architecture. This is why we provided the business back-end as a collection of RESTful mock services.

The application should confine itself to the predefined LVM infrastructure. Therefore it was sufficient to support only one specific browser, namely Firefox.

Business requirements

Business requirements

The application ought to be centered around the customer, similar to a CRM. By this we mean that the application should present all the relevant information pertaining to one customer. From this customer summary the user should be able to navigate to the different insurance products, while still being able to see the customer's general data.

The sub-applications - e.g. the claims and the contract application - often have business dependencies among each other. This is why the architecture should enable the effortless interaction between sub-applications. It should, for example, be possible to navigate from an insurance contract to each of its associated claims or to display claim data in an insurance contract summary view.

By integrating different business sub-applications, the application as a whole obtains a better usability and offers more comfort to the user. Beside the customer centered sub-applications there are also several independent applications - like a financial calculator - which should also be easily accessible. A loose UI integration would be sufficient for these applications.

The user interface has to present intricate input forms with many attributes and several nesting levels (1:n:m). The challenge lies in presenting these complex structures in a simple and comprehensible way, while still maintaining a maximum of usability.

While working on a business process - like drawing up an insurance offer - the sales rep may always be interrupted by a customer - on the phone or in person. Therefore, the user should be able to put aside the current process, serve the client, and then resume the former business process.

It should also be possible to work on several forms in parallel, for example to present different insurance alternatives to a client. The transition between forms ought to be quick and straightforward. There should also be an overview of all open forms.

Technical requirements

Insurance applications - in particular those for the back-office staff - have a lot of form data which is entered by the user. Usually, form data is filled in manually, validated automatically against a set of business rules and then stored persistently. In some cases wizards are used to guide the user's input. The prototypes should implement these elaborate and sometimes complex input forms.

The back-office use cases are primarily process oriented and are initiated from the user's personal task list. This is why we chose use cases centered around data forms, wizards and a task list. The use cases are described in the next paragraph.

In a process oriented workflow the user typically calls up his task list (postbox) and opens a single task. A task has a reference - for example a contract or a claim - to which the user can navigate, to perform the actual business process. After the user has finished, the reference is closed and the task list is displayed again. The process-chain can have multiple elements (for example task -> contract -> claim), which should be implemented by the prototypes.

Form fields sometimes have business dependencies: when a form field, which contributes to the insurance premium, is changed, all result fields have to be cleared, for example. This should be done on the client side.

Having a large and growing monolithic system we want the new system to be modular: Single sub-applications (claims, contracts, task list) should be operated and deployed separately from each other.

Integration between applications should still be possible, through a simple link or through embedded components.

Components should be reusable: for example, a component to select an occupation should only be developed once, and then be reused in different contexts.

We want to be able to produce a large number of user interface views with a consistent look and feel. For this reason a uniform layout with centrally provided gui components should be implemented. These components should be straightforward to use and easy to extend.

The application will also be used in the field and should therefore be able to deal with low bandwidth and high latency while still delivering a satisfying user experience (ux).

The browser will be the future platform for most of our applications and therefore native browser functions, like forward and backward navigation, browser tabs and permanent URLs should be used.

Use cases

The following use cases cover the most fundamental requirements for the new system. They have to be implemented in separate modules: customer search and customer summary (frame application), task list (modular application), business letter (wizard), occupation search (modular component) and claims (modular application).

Use case 1: "Customer conversation with first notice of claim"

The sales rep opens a dialogue to search for the customer by his name and further criteria. A customer is chosen from the search result list and the related customer summary view is opened. It contains general information pertaining to the customer, like a contact history, insurance quotes, applications and contracts.

A new insurance quote is brought up by pressing a button. The address and date of birth of the current customer are preassigned. The user initiates the premium computation, which brings up an error dialogue containing multiple messages. The user can navigate from each error message to the corresponding erroneous field.

The customer's occupation is selected by using the aforementioned occupation search component.

The user saves the quote and copies it. Now two quotes are opened up simultaneously.

In the meantime, another customer is opened up by a search based on one of his contract numbers. A notice of claim pertaining to the second customer's contract is recorded. Afterwards, the first customer is brought up again. All active business processes of this customer - i.e. the two insurance quotes - are closed. A notification about unsaved data is presented to the user.

Use case 2: "Integration and interaction between applications"

The user's task list is opened and shows a list of all entries. Each entry can contain a reference (e.g. claim or contract). If the entry has a reference the user can navigate to the corresponding application. When the application is closed, the task list will be displayed, again.

Use case 3: "Wizard"

Within the contract application a business letter can be composed using a wizard-based user interface. All the necessary information (document selection, recipient selection, summary) is collected step by step.


To be able to start the prototypes, the repository of the back-end mock-services and the repositories of each architecture are needed. There are readme files in all the repositories which contain instructions on how to install and start the applications.


RoCA applications:

SPA applications

which contains::