Chickens, Eggs, and Language

In the insurance industry, which is highly regulated but stubbornly non-standard, we seem to spend a lot of time explaining ourselves, don’t we? Do you ever wonder why? We have a theory:

We think it’s because of human nature.

As human beings, we’re not terribly interested in smallest, slowest, oldest, least capable, or most common. Give us bigger, faster, newer, most powerful, and avant-garde and we’ll be there every time. And so it is we find ourselves having to explain terms like insurtech, innovation, and disruption.

Words Matter

The insurance industry has been using technology for decades — from the mainframes of the 1940s to the databases of the 1960s, from Univac to IBM, from COBOL to Java, from client/server networks to the cloud. Insurance may not have been the first industry to adopt it. But adopt it we did. In that context, insurtech is just another term for what has always been insurance technology.

And pardon us for saying so, but — while the insurance industry is gradually adopting technologies available to all industries (AI, robotics, machine learning, and telematics) — there hasn’t been any new processing technology to speak of in insurance for at least a decade. And even if there were, we wouldn’t know what to do with it yet, given the nature of technology adoption and the (justifiably) conservative nature of the insurance industry.

We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run. (Amara’s Law)

Give Us Our Change

And then we have innovation and disruption. We don’t mean to make light of this war of withering words. But in circumstances like these, we have to leave room for a little humor, don’t we? If not humor, at least a little curiosity. So, here’s an experiment you can try at the next conference you attend:

Walk into the session entitled, “Disruptive Innovation in InsurTech”. Let everyone in the room off the hook by not asking them to define insurtech. Give them the benefit of the doubt and presume their perspectives on disruption are positive; that is, they generally assume disruption to have a positive outcome, rather than a calamitous one. Then ask them if they can tell you how innovation and disruption are different from change.

In the ensuring silence, tell them you’d like your change back.

We Have Work To Do

Our facetious levity notwithstanding, there’s serious work to be done in the insurance industry. So, rather than trying to decide which came first — the chicken or the egg; insurtech or constructive pragmatism; innovation or change where it’s needed; disruption or calm, shared progress — maybe we should talk about what needs doing right now.

We have no idea what tomorrow’s jargon will be. But we’re positive insurers have to do business today.

Let’s put our faith in practical experience and plain language to get it done.

Options Are No Longer Optional

Are system configurations and product development sciences or arts? Depending on your perspective, they could be either or both. We’re not sure. But we are sure your technology should afford you the right to choose. Here’s our perspective:

Y2K was almost 20 years ago. What’s that got to do with anything? Much. The myriad computer-scientific achievements of Y2K’s post-compliance period defined the sub-industry we now know as insurance technology. And insurance technology’s come a long way in a short time.

A Brief Look Back

The last few years of the ’90s saw insurers catching wind of business potential for the Internet. Few had appropriate strategies. Fewer still began to develop them. But once they caught on, since the ‘Net accommodated systems that could handle high volumes of data, many insurers did precisely what you’d expect: They began tweaking their mainframes to make them accessible — and able to transmit data and transactions — via the ‘Net.

Fitting their mainframes with Web-based front ends, marketers and programmers joined forces to create things with big names like enterprise resource planning systems (ERP). With Y2K looming, mainframe-to-Web connection programs then bred other terms like knowledge mining and data mining to make us think we were doing something more significant than getting out what we’d put in. Then came the realization that we could say the trusty old mainframe provided security, large amounts of storage, and the capability of handling large numbers of sophisticated transactions.

But the mainframe’s days were numbered. Out of the increasingly limited procedural languages of COBOL, ForTran, DB2, and others came the lexicon of declarative query languages like SQL, JavaScript, and the programming equivalent of Esperanto — XML — that permitted greater functional literacy. And even those terms already sound ancient.

A Long Look Ahead

The late science-fiction writer, Arthur C. Clarke, wrote: “Any sufficiently advanced technology is indistinguishable from magic.” We’re not sure insurance technology has advanced to that point just yet. But with its combination of computer science and artistic configurability, it’s getting close.

No longer the exclusive domain of IT people, we’re rapidly approaching the point at which any BA in any insurance company will have the option to install and configure software — which will provide the option to develop and configure products and lines of business.

The options might not be magical. But they’re plentiful. And they’re no longer optional.

Say What You Mean

If we were given the choice of eliminating one word from the language, it might be proprietary. Aside from the fact that it could mean as many things as there are people who want to consider whatever it is they want to consider proprietary, the term is particularly problematic when it’s applied to data.

In the insurance industry, to cite just one example, system replacements are nightmares in part because of the data they contain. First that data has to be converted; that is, the data from System A has to be changed into a format that plays nice with System B. Then the data has to be normalized; that is, it has to be organized into columns (attributes) and tables (relations) to reduce redundancy and improve integrity. After that, it has to be standardized; that is, similar data in dissimilar formats has to be changed to a common format that enhances the comparison process. So, North might change to a value of N or n, without overwriting the original format: North.

Are We Nuts?

Albert Einstein once said, “In theory, theory and practice are the same. In practice, they’re different.” Given that, it might be safest to consider the possibility of one common data language for all insurance systems, companies, and transactions to be more theory than practice … at least for now. And it would almost certainly require the elimination of proprietary as it pertains to insurance data. (Proprietary should not be confused with private. Proprietary is a bugaboo and a detriment. Privacy is a necessity and an asset.)

Speaking of theory, what if someone developed an English-like, WYSIWYG language for creating and deploying business rules in your software? What if that language minimized data-entry and service-staff requirements? And what if that language enabled your data to say what it means and mean what it says?

The very suggestion might be nuts. But it can’t be any nuttier than the proprietary means by which the insurance industry has historically treated, converted, normalized, and standardized data.

One last question: What if that language were more practice than theory right now?

Independence Day

What do you expect when you work with a software vendor?

That’s not a rhetorical question.

When you decide to work with — to enter into a mutually binding contractual obligation with — a software vendor, you have a set of expectations. Regardless of whether you state or document all of those expectations, you have them. You’re human. Expecting is what we humans do.

Contrary to the prevailing wisdom, relationships between companies and software vendors don’t always fail because of technical issues. They don’t always fail because the implementation went south or because the software didn’t do what it was supposed to do. They do sometimes fail because both parties neglected to fully and clearly express their expectations.

Here’s the Middle Ground

Strangely enough, every company and every software vendor should share at least one expectation: Both parties should expect the company to be as independent of the vendor as the company wants to be. Whether the company wants the software to count beans, to book appointments, to monitor inventory, to track orders in restaurants, to monitor mileage and maintenance for fleet cars, or to administer policies, claims, and billing, the company and the vendor should want the company to be dependent on and beholden to the vendor — only as long as and only to the degree the company wants to be.

Software licenses and SaaS subscriptions don’t come with handcuffs … at least they shouldn’t. At the very least they should come with a key to unlock any such handcuffs. They should come with a clear roadmap showing you how to get to that key when you want it. And they should come with a clear indication of the vendor’s commitment to being with you at every step of your way to that key.

Travel Confidently

Is that a pipe dream? You won’t know till you talk to the vendor. And you shouldn’t stop talking to the vendor until you do know.

The day you contract your new software might not be Independence Day. But it should be the first day of your journey to the independence you expect.