Creating a Two Sided Market in Insurance using Technology

Several people including me had big hopes on Pay-Per-Mile insurance. I even categorized this innovation as an Insurance 2.0  innovation and termed it as part of the next-gen insurance model. After all , Pay-Per Mile gives the ability for carriers to track your driving usage and you as the consumer are passed down the savings. Several agencies had research published   claiming that the miles driven could reduce by 10% and a savings of $270 could be achieved. Carriers like Progressive and vendors like On Star launched their products with a lot of fanfare only to find that consumers did not really opt-in for the plan.

The problem, in my opinion, for the limited success of the product is that the benefits to consumer in pay-per-mile insurance product are not clearly articulated and more so, not proven. Knowing that there is a big brother watching you and that your costs could go either-ways (up or down depending on the usage)  makes the consumers shy off going to a pay-per-use plan. Instead a better approach for carriers could be to provide a free value added service in return for the customer's allowing the carriers to track the usage patterns. Essentially creating a two sided market where one feeds the other

So here is an example of how this could be achieved. Refer to the diagram below.

In my sample next generation insurance company model below(refer diagram), I am creating a two-sided marketplace between the Commercial Auto (Tow Truck ) and the Personal Lines Auto (Consumers). Each side is feeding the other and also deriving value by joining this new entity. Consumers -Like the ability to have an efficient tow truck dispatch capability on their cell phones. The Tow Truck carriers would not mind sharing their location data when they are shown that they get new business referrals via this technology.

Spring Roo and AppEngine

I don't really get what springsource is trying to do with the Spring Roo product. Seems like it is trying to be the Java equivalent of the RAILS/GRAILS world; Fast and quick way to develop applications.

But does the approach truly work? I don't think so.

So I decided to look under the hood and build an application. I tried the much publicized Google AppEngine/ Spring Roo Integration. While I could build the scaffolding of the application very quickly, I did not see much value in what Roo did for me. Here is what it does :
1. Builds the Object to Database connection layer with finders and getters based on just the Entity Object definitions.
2. Builds a generic GUI for Data Entry and View.

Now - if you are in the RDBMS world - there is probably some value to automatically creating the scaffolding around capturing the Data Access layer with a tool like Roo. But , if you are working with AppEngine , I dont see the value. Building the Data access layer in AppEngine is super easy already there is not much other tools can do here. You just define your objects with JDO/JPA annotations and you are done. Why would I make comprises in the choice of a programming model when I don't get much from Roo's efficiency. Note that Roo uses JPA only with No DAO layer and uses Aspects.(not everybody in the world likes Aspects including myself)

I liked the idea of building a generic gui for your object model. If this idea would work with any Object Model I create. i.e not something that was generated via SpringRoo then I would be interested in it. Since the gui is more of a testing tool for your Object Model - there is value in having such a gui as a backdoor entry to your data. But the GUI cannot be used even as a starting point for true real-world applications.

IMHO - the only way I see Spring Roo fit into my world if it targets its positioning as the "Microsoft Access for the Cloud" .Afterall , what MS access gives you is an ability to define Tables(Entities) , Edit Data Items and Report on them.  Trying to target Spring Roo as a potential Web Application development paradigm does not fly with me.