FINEOS : Is Low Code/No Code the Modern Day Stone Soup?

AddThis Sharing Buttons

Share to LinkedInLinkedInShare to TwitterTwitterShare to FacebookFacebookShare to Email AppEmail App

I was at the 2021 InsureTech Connect(ITC) show in Las Vegas, NV.It was a great opportunity to see people and company presentations in person, and FINEOS was a foundational sponsor for the newGroup Tech Connectevent at the show.(I was impressed with howITC worked very hard to have a safe event given Covid concerns and successfully walked the line between safety and getting business done, in my opinion.)

I have a lot of observations on what I saw there which I will share in follow on articles but there was one trend that really concerned me and that was the over-emphasis on tech and a lesser emphasis on the business of insurance. I know this seems odd since we were at the InsureTechConnect,but I feel it's important to look at technology in the context of the business sector it supports.  I'm afraid we may lose the true value that knowledgeableinsurtech vendors bring to the table. With all the cool advances in UX tech, mobility, machine learning, encryption etc., it's easy to forget the technology is never more important than the business it supports.

The right low code/no code approach

At the show, I had conversations with andreceived product demos from several low code/no-code vendors that do work in the insurance space along with insurtech startups and established insurance software vendors. Some were in the context of trying to position themselves as potential ancillary partnerships as they are not planning to enter the core insurance space but could provide help with UX , custom workflow and other types of extensions. This "technology add-on" approach made a lot of sense as there are often a lot of customer specific UX and workflow requests from insurers that are on the edge of scope and distracting to an industry focused core system vendor. Insurers can avoid creating new legacy application issues down the road, using low code/no code solutions in tandem with the core system's own configuration tools. This requires coordination with the core systems roadmap to avoid building true leverageable core system capabilities in the low code/no code layer.

Other vendors showed me highly configurable low code platforms where they and their customers had the beginningsof a core system, usually personal line auto/home P&C. This can make sense for very lightweight insurance products in small lines of business or for very small companies that are looking for a better tool for their build strategy. This mix and match approach to a solutionis not generally well suited for scalable core system development and are not different than the 4GL tools insurers looked to in the 90s such as PowerBuilder,and the push to use Microsoft Visual Basic in early 2000s.

Across almost every interaction I had, the underlying message was that the given technology discussed was transformational and it is a simple matter to add in the insurance IP (intellectual property) with a few SMEs (Subject Matter Experts) in an agile, rapid development environment (Patent Pending.) To be fair to insurtech companies that really are small startups in bootstrap mode, that's how they all start and that's perfectly ok. What's concerning is the idea the equation of IP + SME + no code/low code = a long-term business model for vertical insurance software companies. However, I'm concerned that some carriers thinkingto build their own core system with this equation may not be aware that they're really participating in making the modern day version of stone soup.

Modern Day Stone Soup

There is a European folk tale called Stone Soup where the clever traveler comes to a small village with a poor harvest that can't afford to host the traveler.The likeable conman pulls out his empty pot, fills it with water and puts a stone in the pot to make stone soup.  The intrigued villagers each contribute something to the stone soupto improve the taste and by the end of the story, the pot is full of the villagers'food and everyone enjoys the stone soup. The conman goes onto the next village where the scene is reenacted but the soup is different wherever he stops based on what the village has to offer to the soup.

In a lot of ways, modern insurance software low-code fast config projects seem like a retelling of stone soup.If an insurer really wants to start with a blank slate and build an insurance core system based on the latest low-code tool, they are going to spend a lot of time writing extensions and micro-services outside that tool to do the business of insurance, especially in areas like Employee Benefits and Absence Management. They will effectively createa new bespoke system in the hope that the tool vendor will remain around in the long term to support their legacy system in the making.

A better, long-term strategy for success is to work with a core software vendor that has an active product roadmap and a regular release cadence for market driven updates as well as updates that support current customer asks. Most insurers are dealing with legacy core system cleanup issues, and it is smart to look for ways to avoid creating another future legacy system problem, but the answer is not to use new tools to create what are effectively future legacy bespoke systems. I recommend the recentFINEOS whitepaper on Buy vs Buildfor anyone who is considering that path.

It's important to keep up with new tools and techniques for digital extensions and ecosystem connections but more important to have the strong foundation of a purpose-built core system that meets the parameters of your business.