Simplicity in Insurance Solutions

This article on Insurance Networking News makes the case for simplicity or clarity in marketing of Insurance systems. Too much overlap in system modules, or a lack of understanding of the customer's point of view means that the way systems are described leaves the customer's decision makers confused. Faced with a business problem, they struggle to make sense of what module will address the issue.

However the same ideas presented in the article can be extended to the systems themselves. Overly "flexible" systems become overly complex, with all of the challenges that come along with that. Flexibility is normally prized, as a way of improving time to market and reducing maintenance costs (enhancements, fixes, etc). And of course reducing dependence on the vendor with the accompanying costs. However complexity in the system comes with an increase in design, testing, and training for staff. This is often missed and/or underestimated. A complex system will require significantly more testing in the implementation process - as a direct result of the complex interplay of functions within the system.

As with most things, we need to find a balance in managing flexibility versus complexity and therefore risk.

Filtering details in Master-Detail edit

I came across an article about another FetchType that may be useful in reducing the number of Detail rows loaded when paging and/or filtering the Detail List (see previous posts about Master-Detail editing and Filtering).

Hibernate has the Lazy fetch strategy, which is fairly standard. Under this strategy, Hibernate will load the Detail rows only when we first access the list. The problem is it will load all rows from the database. If we are detail with thousands of Detail rows, this could be a problem.

Hibernate also has an "Extra Lazy" fetching strategy. This will only load individual rows when they are accessed (as opposed to Lazy, which loads the entire collection). This seems to be more what we are looking for if we need to filter and paginate a List of Detail rows.

It's done at the mapping level, so it's going to require some investigation to see how this affects regular processes.

SaaS for insurance, part two

I have just read an article on the suitability of SaaS for different markets, which dovetails nicely with the previous post here.

To quote a key part:
"SaaS applications fare better in larger markets where most buyers are satisfied with the same features. You don't want to build a solution that depends on satisfying the requirements of a small, quirky market."

Exactly.

SaaS for the Insurance Industry

An article published on Insurance Networking highlighted "Security" and "Ability to Customise" the system as two main drawbacks of SaaS in the context of the insurance industry.

I agree that Security is a major problem - who hasn't dealt with IT departments that are overly concerned about allowing customer data outside the firewall? And with good reason, given some of the regulations applied in various countries.

However in terms of the second problem (Customisation), I am less convinced. If you consider Salesforce.com (used by a number of large insurers, and supports significant integration and customisation) then you could argue that the second problem (customisation) is a non-issue. Instead, I think the comment reflects the nature of smaller-to-medium-sized SaaS offerings. It is unlikely that anyone will be able to convince 37Signals to customise their software for one company. But it's equally unlikely that an application of this size this would ever be considered a "Core" system for a large insurance company.

Feedback on the article prompted a second article that points out that SaaS may be more welcome in non-core parts of the business. This is true, but misses the point of the first article - there's no-one offering (or attempting to offer?) a core policy administration system on a SaaS basis with all that implies (cloud, multi-tenancy, charging model, etc). A possible business opportunity? Surely a difficult balance of business requirements to meet while doing so!