Following on from part 1 of this blog series, we’ll next look at how the demo is constructed, the Bluemix services we used, and how they interact with each other. As mentioned previously, there are several IBM services in use alongside our own Diffusion Cloud service –  IBM’s Tradeoff Analytics, IBM’s Streaming Analytics, and IBM’s Cloudant product.

The demo video, from part 1, relies on some basic services for user and profile management, with most of the processing and analytics taken care of by the policy comparison backend.

Service Interaction

The various services are each used to deliver a specific piece of functionality, delivering a true realtime, usage based insurance app.

1. Cloudant is used to store customer profile information, and available insurance policies.
2. Tradeoff Analytics is used to compare user profiles with available insurance policies according to the requirements of an available insurer.
3. Streaming Analytics is used to apply realtime factors to the insurance policy – such as location, weather or traffic.

Data Data Data!

In the absence of inside-information about the insurance industry I decided to combine two public sources of information.

The first source is the US Census Bureau’s ZIP Code Tabulation Areas (ZCTAs) Cartographic Boundary Shapefiles. That’s a mouthful for sure. At a high level, the US postal office’s ZIP codes are designed to designate a collection of roads for delivery of letters. ZIP codes are not coherent cartographic boundaries! The US Census Bureau, however, needed a convenient way of managing demographic data and designed the ZCTA as a way of conveniently breaking down the USA for demographic purposes. For further information and to download please visit this link.

The second source is the Austin, Texas, Police Department crime statistics for 2015. I use this to help “weight” the risk factor for a car driving in and around Austin TX. For source data visit this link and for Texas motor vehicle stats visit this link.

To define a risk factor for Austin area ZIP codes I used the open source QGIS tool to edit the embedded ZCTA file (see below). I added a “IRISKPCT” field to the “layer” and proceeded to define a risk for each Austin ZIP code. In the absence of crime stats for a particular neighboring ZIP code I assumed a risk based upon population density and whether the area is predominantly used as a thoroughfare. The Java Control Client assumes a default 70% risk for any area I neglect to define.

TIP: You can define additional shapes “on top” of the existing ZIP code boundaries. I defined a circle around Dripping Springs TX to increase the risk factor for that town. The possibilities are endless 🙂

Diffusion Cloud

These various services and their output can be rendered useless without realtime sensor data, contextual information, and user actions reliably transferred to/from the cloud. This must be achieved even when the driver is in areas of network congestion or poor network coverage.

That’s where Diffusion Cloud comes in. We’re using it here to ensure that user experience and app functionality are maintained even when the network is working against you (we’ve all been there!).

Some of the key features offered – and described during the demo video – include:

• Ultra-low latency between endpoints
• Realtime updates with JSON delivered using a bandwidth efficient binary protocol (CBOR)
• Optimized data delivery for mobile devices and networks
• Reliable reconnection, so devices gracefully manage service outages
• Lower mobile data plan costs using Diffusion’s delta streaming

All with none of the overhead of REST! btw… checkout our JSON Efficiency Live Demo

There are various other factors and data sources that can be easily combined to enhance the pricing algorithm, rewarding drivers for safer driving habits.

In the final part of this blog series we’ll see exactly how these services are brought together and how simple it is to add realtime messaging from Diffusion to efficiently distribute data between the app and backend.