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.
Adoption of a Graph Database in the Insurance Sector - Jan-Frederik Wilhelm & Dr. Andreas Wandelt @ GraphConnect London 2013
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
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
14.
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
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