Adoption of a Graph-

Database in the Insurance

SectorJan-Frederik Wilhelm / Andreas Wandelt

Intelligent Solution Services AG

~ 50 employees

Base of operations: Marzling (near Munich)

Project teams: at HQ or onsite at customer location

Latest success: inSign (innovation award)

Dr. Andreas Wandelt

Head of Department

Technical Consulting

Jan-Frederik Wilhelm

Software Architect

Project „Bay4all“

What is this project dealing with?

– Critical sales system of an (bavarian)

insurance company

– 10 years old

– Weak spots:

Poor Performance

High maintenance cost

Redevelopment of system/architecture

Redesign architecture

Main tasks:

– Renewal of data layer which is used for

replication

– Usage of former customer project:

regarded to be nearly ready

10 months later …

– Remainings ?? no valid evaluation

possible

– Quality of data ? may be poorer than

expected

Extensive Review needed

Role of Neo4j

Neo4j – first experiences:

– Whiteboard-friendly

– Flexible

– Easy „first use“

– Graphical representation in Web-interface

Proof of Concept

Two candidates:

– Neo4j

– ObjectDB

Several obstacles for Neo4j:

– Existing IBM DB2 landscape

– Conservative insurance industry vs. Cutting edge-technology

– Unknown world of NoSQL-databases

– Startup

ORIGINAL DATA-MODEL (LEVEL 2)

RELATIONAL REPRESENTATION

ID 3611

TASKID 139982

OBJECTDESCID GUC0000BBV

USERNAME PKI5965

CHANGED 27.04.2010 09:48

VALIDFROM 23.04.2010 00:00

VALIDTO <null>

GENDATE 23.04.2010

ROOTID 3611

ROOTCLASSDESCID T000000DLV

PARENTID <null>

PARENTCLASSDESCID <null>

CHANGESTATE 0

BOSID AFIS.BP

BOSOBJECTID 102558199

BOSHISTORY <null>

REPLICATED 27.04.2010 09:48

BBVPLANER_PARTNERID <null>

DATA <?xml version="1.0" ...?><value-list><value id="Name"><![CDATA[Wilhelm]]></value>...</value-list>

PARTNERNR 102558199

NAME WILHELM

VORNAME JAN-FREDERIK

GESCHLECHT 2

FAMILIENSTAND 2

GEBURTSDATUM 20.03.1958

STAATSANGEHOERIGKEIT <null>

BERUF 921299

BERUFSSTATUS 70

me

ta d

ata

ext

ract

ed

dat

a

SCHEMALESS

Data-Model

Used throughout the system

(replication, persistence, UI-code, …)

Separate data-model for faster selections

(by nightly replication)

Authorization

extraction into tables – used by joins

(by nightly replication)

First Approach

Identified culprit: inadequate data model

Revival of abandoned project

– Relational approach

Failure

– Mapping at replication time

Basic Idea

Don‘t map (too) early

Don‘t lose content

Don‘t lose info about structure

Simplify the model where possible

Create a copy of the host-data?

Use the PM-data and map later

Basic Idea – Graph Database?

Four levels of abstraction in model

– One graph per abstraction layer

– Connections between the layers! (IS_A)

– Using levels like classes in the OO-mindset

Authorization data

– In same database

– Linked to domain nodes

Reuse of existing replication mechanisms

Initial Data Import

Extensive updates once a year

Fast replication needed

BatchInserter

Spring Data Neo4J not usable

Introduction of Schema

Labels in Neo4J 2.0

Classification of nodes

Simplification of cypher queries

Automatic indexing of label-properties

Domain Mapping

No 1:1 mapping of domain-model todatabase-model

Spring Data not usable

Blueprints Frames unknown not used

Custom mapping mechanism developed

– Annotations

– Generics

– Java Reflection API

Data Store

Indexing

Neo4J

P

M

transformationmessages in PM-datamodel

P

M

messages in graph-form

summary (i.e. key properties of a contract) basic mapping

Lucene

indexes

property collectionsTransactionEventHandler

single propertieslabel indexing

mVorname m/wName node-Adresse

w

Auer

Zöller

Karl

Eva

81517

58999

node-AdresseVertragsnummer

0000001

9990000

23114

44539

node-AdresseName

Auer

Zöller

81517

58999

exact search, combined search, (phonetic search)

keys, node-adresses

read/write data, navigate graph

nodes, relations, properties

Search

Queries use

– Authorization data

– Labels

– Indexes

– structural information

Performance-Requirements fullfilled

All requests manageable/solvable so far

What‘s next?

(Future) Benefits for project

Fast summary of an

agent‘s portfolio

Validation of PM-

messages

Analysis of the whole

portfolio

Reduction of work in

Host-System

Wishlist für Neo4J

More properties in

schema

Analysis of graph,

schema and indexes

(even) more tutorials

Further commitment to

new Web-UI

Overall results

Fast system

The performance for search requests is better thandemanded

Solution is accepted by the customer – project is saved

First productive usage of Neo4j within an insurancecompany

Usage of technology which really fits the domain-/technicalproblem

Discussions in an „interdisciplinarily“ team

Very good support by consulting team of Neo Technology

Thank you for attending…

What‘s useful in Neo4J 2.0 (for us)

Labels

Try with ressources (AutoClosableTransactions)

New Cypher Syntax

New Web-UI

Not sure if 2.0: ServerBuilder, LifeCycle-Stuff like TransactionEventHandler, Unmanaged Extensions, …

Surrounding technologies

Apache Camel for replication

Apache Jackrabbit for storing file-data

Jersey for REST

– Unmanaged extension

– Client