Mobility’s Legacy

More and more property and casualty insurance companies seem to be dipping their corporate toes into the smart phone or tablet world, by developing and providing applications – or ‘Apps’ – that run on iPhone, iPad, Blackberry and/or Android devices. These Apps typically provide the consumer with functionality ranging from simple checklists of what to do in case of an automobile accident, all the way to the ability to make policy change requests.

It seems a week doesn’t go by without another company launching a new App. This prompts the obvious question for those companies that haven’t yet developed such a tool: Is there a risk of getting ‘left behind’? Which leads to a second question: Will my legacy system hamper my ability to develop an App?

It is too early to say definitively whether Apps are going to have a significant impact on consumer satisfaction, consumer loyalty, industry efficiency or relationships with the broker community. One thing is certain: the demand for a mobile computing environment/lifestyle is accelerating.

Assuming, therefore, that every P&C insurance company should at least consider and develop a mobile channel strategy (even if the resultant decision is to do nothing), companies using legacy systems will also have to consider the impact of the legacy system(s) on such a strategy.

Legacy Systems and Mobile Tech

So what does having a legacy system do to the development of a smart phone App? Does it make it more difficult? Impossible? Have no impact? The answer is, as you would expect to hear from a good consultant, it depends.

The functionality of currently existing Apps seems to fall into four different types:

1) Pure Insurance

Items like filing a first notice of loss (FNOL), obtaining payment information, reviewing coverage information and making policy changes.

2) Related to Insurance

Items like company and broker contact information, preferred repair shop locations and contact information.

3) Complementary to Insurance

Items such as applications that help you store photographs of your artwork and furnishings, inventory checklists, accident safety checklists and vacation checklists.

4) Unrelated to Insurance

The sky is the limit here.

Of these four types of functionality, only the first (pure insurance) requires direct access to policy management, claims or billing systems. This means the majority of the four types of information/services provided by an App do not require any access to a legacy system.

In other words, it is entirely possible to develop a smart phone App that can have great appeal to the consumer without access to a legacy system.

An excellent example of this is ‘Chrome’ from ANPAC (American National Property and Casualty).

ANPAC insures specialty cars: custom cars, Hot Rods, replicas and so on. They have developed an App allowing anyone (not just a policyholder) to view price guides and other Blue Book information, locate and get directions to car shows, load photographs of their custom car and create road trip journals, complete with photographs taken during special trips one can take in a custom Hot Rod.

ANPAC advertises its insurance program, but it’s subtle. It just quietly provides product information, rather than in-your-face advertising. Critically, the App is exactly the sort of thing a car enthusiast would use on a regular basis. So, although the presentation of the product information is subtle, it is also frequent. Chrome is an excellent example of an App that has a huge potential for success for the company, for both product promotion and for branding and all without accessing any legacy systems.

Linking Mobility to Legacy

But suppose you do want to access your legacy systems. Suppose you want to create an App that is a FNOL reporting system, or a billing inquiry system or coverage inquiry system.

Such an App makes two basic demands of a legacy system. The App has to be able to find and retrieve data from the legacy system(s), and it has to provide and update data to the legacy system.

The problem is, of course, making the legacy system do that. To a large extent, this is similar to the single-entry, multiple-company interface (SEMCI) challenge that has dogged the industry for years, in that it requires two very different systems to be able to talk to each other. The good news is that, unlike SEMCI, which has been hampered not only by technology but also by business issues, the smart phone-to-legacy systems link is purely a technical challenge. There is no requirement to follow industry-imposed standards, no requirement to create a one-size-fit-all environment — it’s a matter of every company for itself.

There are (at least) two methods of changing legacy systems so that they can talk to smart phones.

The first is to attach a ‘front end’ to the legacy system. Such a front end would understand the complexities of the legacy system and would aggregate data that the smart phone needs onto a server, presenting the data, most likely in XML form, to the smart phone when called. Similarly, the smart phone would deposit data to the server and the front-end system would update the legacy system as required.

One advantage to this approach is that, since most of the work is done on the front end, there is limited need to open the Pandora’s box of code in the legacy system. Additionally, the front end can ‘front’ more than one system. So if a company has multiple legacy systems, the front end can extract data from multiple systems – auto information from one, perhaps, and habitational information from another, for example. If a company does not wish to develop such a system from scratch, several systems are available that can be used as a front end. For example, NexExchange from Brovada is such a product.

To be clear, this is work – and lots of it. But it’s still significantly less work, risk and cost than a wholesale system replacement.

Another option is to change the legacy system into a Services Oriented Architecture (SOA). Many examples exist of insurance companies modifying their legacy systems to an SOA. Through this architecture, a company can make its applications and databases available as ‘services’ to be consumed by other systems, systems such as smart phones.

Legacy systems particularly lend themselves to such changes, since they tend to have multiple – but basically similar – areas of code than can be consolidated. For example, most legacy systems have completely separate code structures for ‘create,’ ‘update’ and ‘inquiry’ transactions, but fundamentally they are all doing many of the same things. All three of those transactions would read the database to see if a policy was present. All three do different things once the read has occurred, but why have three areas of code that read the database? Simply – and I use that term loosely, since it is complex – have a single ‘service’ that reads the database, and have each of the three transactions call or consume that service.

Other Issues

Of course there is far more to consider when thinking of making a smart phone work with a legacy system. Issues surrounding security, latency and confidentiality, to name just a few, are important and need to be addressed. But this is the case no matter what type of back office system a company uses.

Can a smart phone and a legacy system co-exist? We would say a resounding yes.