Jan-Frederik Wilhelm and Dr. Andreas Wandelt’s current project aims to replace an existing sales-portal of a german insurance company by reimplementing existing functionality in a maintainable fashion using current technology, with a core theme of the project trying to save, display and search data which is structured according to the VAA data model of the insurance industry. This talk is about their experience regarding the transition of a legacy model into a graph model using the latest version of Neo4J and some of its new features.

1. Adoption of a GraphDatabase in the Insurance
Sector
Jan-Frederik Wilhelm / Andreas Wandelt

2. 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
Jan-Frederik Wilhelm
Head of Department
Technical Consulting
Software Architect

3. 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

4. Redesign architecture
Main tasks:
– Renewal of data layer which is used for
replication
– Usage of former customer project:
regarded to be nearly ready

5. 10 months later …
– Remainings ??  no valid evaluation
possible
– Quality of data ?  may be poorer than
expected
 Extensive Review needed

6. Role of Neo4j
Neo4j – first experiences:
–
–
–
–
Whiteboard-friendly
Flexible
Easy „first use“
Graphical representation in Web-interface

7. 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

8. ORIGINAL DATA-MODEL (LEVEL 2)

9. RELATIONAL REPRESENTATION

10. meta data
extracted data
ID
TASKID
OBJECTDESCID
USERNAME
CHANGED
VALIDFROM
VALIDTO
GENDATE
ROOTID
ROOTCLASSDESCID
PARENTID
PARENTCLASSDESCID
CHANGESTATE
BOSID
BOSOBJECTID
BOSHISTORY
REPLICATED
BBVPLANER_PARTNERID
DATA
PARTNERNR
NAME
VORNAME
GESCHLECHT
FAMILIENSTAND
GEBURTSDATUM
STAATSANGEHOERIGKEIT
BERUF
BERUFSSTATUS
SCHEMALESS
3611
139982
GUC0000BBV
PKI5965
27.04.2010 09:48
23.04.2010 00:00
<null>
23.04.2010
3611
T000000DLV
<null>
<null>
0
AFIS.BP
102558199
<null>
27.04.2010 09:48
<null>
<?xml version="1.0" ...?><value-list><value id="Name"><![CDATA[Wilhelm]]></value>...</value-list>
102558199
WILHELM
JAN-FREDERIK
2
2
20.03.1958
<null>
921299
70

11. 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)

12. First Approach
 Identified culprit: inadequate data model
 Revival of abandoned project
– Relational approach
 Failure
– Mapping at replication time

13. 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

15. 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

16. Initial Data Import
 Extensive updates once a year
 Fast replication needed
 BatchInserter
  Spring Data Neo4J not usable

17. Introduction of Schema
 Labels in Neo4J 2.0
 Classification of nodes
 Simplification of cypher queries
 Automatic indexing of label-properties

18. Domain Mapping
 No 1:1 mapping of domain-model to
database-model
  Spring Data not usable
 Blueprints Frames unknown  not used
 Custom mapping mechanism developed
– Annotations
– Generics
– Java Reflection API

19. Indexing
P
M
P
M
messages in PM-datamodel
transformation
messages in graph-form
basic mapping
summary (i.e. key properties of a contract)
property collections
TransactionEventHandler
label indexing
single properties
Lucene
Name node-Adresse
Auer
81517
Zöller
58999
Vertragsnummer node-Adresse
0000001
23114
9990000
44539
Name Vorname m/w node-Adresse
m
Auer
Karl
81517
Zöller
Eva
w
read/write data, navigate graph
nodes, relations, properties
Data Store
Neo4J
exact search, combined search, (phonetic search)
keys, node-adresses
indexes
58999

20. Search
 Queries use
– Authorization data
– Labels
– Indexes
– structural information
 Performance-Requirements fullfilled
 All requests manageable/solvable so far

21. What‘s next?
 Fast summary of an
agent‘s portfolio
Wishlist für Neo4J
 More properties in
schema
 Validation of PMmessages
 Analysis of graph,
schema and indexes
 Analysis of the whole
portfolio
 (even) more tutorials
(Future) Benefits for project
 Reduction of work in
Host-System
 Further commitment to
new Web-UI

22. Overall results
 Fast system
 The performance for search requests is better than
demanded
 Solution is accepted by the customer – project is saved
 First productive usage of Neo4j within an insurance
company
 Usage of technology which really fits the domain-/technical
problem
 Discussions in an „interdisciplinarily“ team
 Very good support by consulting team of Neo Technology

23. Thank you for attending…

24. What‘s useful in Neo4J 2.0 (for us)
 Labels
 Try with ressources (AutoClosable
Transactions)
 New Cypher Syntax
 New Web-UI
 Not sure if 2.0: ServerBuilder, LifeCycleStuff like TransactionEventHandler,
Unmanaged Extensions, …

25. Surrounding technologies
 Apache Camel for replication
 Apache Jackrabbit for storing file-data
 Jersey for REST
– Unmanaged extension
– Client