The Future of Insurance

With everyone from consultants to analysts, from trade publications to software vendors, from insurtechs to FOMOs writing about the future of insurance, we started thinking we might be conspicuous by our absence. So, in the interest of living on the bleeding edge of insurance prognostication (don’t worry … we have lots of styptic), here are our modest contributions to the burgeoning breadth and bulk of literature on the topic.

Prediction #1: Some Stuff Will Change

Given the evolving nature of technology and the ever-increasing rate of change, we can expect a veritable plethora of things to become increasingly prevalent. With IoT and Big Data bombarding us with more and more information for which we have to try and find uses, we’ll figure something out. With IoT and Big Data feeding telematics devices and precipitating usage-based insurance, we’ll see more individualized rates as standard personal-lines products, in particular, become ever-more commoditized. And with GPS and insurtechs breeding the pursuit of leisure in driverless cars, there are sure to be emerging market opportunities in life insurance, if not funeral insurance.

Prediction #2: Some Stuff Will Never Change

Given the immutable nature of an industry as highly regulated yet non-standardized as insurance, technology will never be adopted as fast as the consultants, the analysts, the trade publications, the software vendors, the insurtechs, and the FOMOs say it will. State DOIs and the NAIC will reduce the number of regulations by which insurers must comply right about the time Pee Wee Herman establishes the first colony on Mars. Implementations will still have to be conducted deliberately, carefully, and expertly. And software will still need to be tested to make sure it works as well as the consultants, the analysts, the trade publications, the software vendors, the insurtechs, and the FOMOs say it will.

The Moral of the Story

The ball on which we’re all supposed to be keeping an eye is the present. We can keep the other eye on the future, of course. But there’s work to be done right now. The prognosticators will continue to make a living by prognosticating. If there weren’t a market for it, they wouldn’t do it. But the rest of us in the industry still have to do what we do in the best interests of policyholders, or we’ll all be out of business.

Who’d have thought ignoring The Next Big Thing might be the future of insurance?

The Hamster In the Black Box

Every once in a while, we like to take a look back at the insurance industry’s technical literature. It reminded us that, at a time in the not-too-distant past, it was impossible to pick up anything — trade publications, marketing collateral from vendors, reports from the analyst community, et al. — without reading about Service Oriented Architecture (SOA). It seemed as if every developer and his dog were employing and touting SOA to the nth degree.

Our exploration also led us to some architectural relatives of SOA, which we’ve listed here, in part, with their respective definitions:

  • SOA. Service Oriented Architecture is a style of software design that provides services (discrete units of functionality, accessed remotely, acted on and updated independently) to various other components through a communication protocol over a network.
  • SAP. Service Application Programming. We’re going to leave this one alone.
  • SOAP. Service Oriented Application Programming is a clean approach to software development that combines architecture, application development, and protocol programming.
  • SOUP. Service Oriented Utility Programming describes the attempt to program utility into application development; that is, to create a solution for which there is an existing problem, rather than vice versa. Utility, in this context, is sometimes used synonymously with objective.
  • SOUP TO NUTS. Service Oriented Utility Programming Tapping Objectified Neurons Under Total Secrecy is an approach to enterprise programming that’s so covert not even the people who know about it know about it. SOUP TO NUTS was also known by the abbreviation TCP: The Complete Package.

We certainly found our discoveries amusing, if not terribly enlightening. But it caused us to think a little more deeply, particularly when we found a reference to black box in reference to SOA.

What Difference Does it Make?

The reference we found defined black box as:

a device, system or object which can be viewed in terms of its inputs and outputs (or transfer characteristics), without any knowledge of its internal workings. Its implementation is “opaque” (black).

That prompted us to wonder about what seems to us to be the relative unimportance to the user or the consumer of any specific technology and/or its nature. To be more specific, we wondered what our prospects might say if we asked this in one of our introductory conversations: “If our system comprised a hamster, running on a wheel in a black box — but it was easy to use, processed your business efficiently cost-effectively, and improved your results — would you care?”

We never ask that question, of course. And we’re quite proud of our technology, its facility, and its adaptability. But it did make us think about the possibility that all of us might be better off if we focused on objectives and outcomes, rather than on techniques and technicalities.

If we did that, decision-makers might be able to view all technology as just a hamster in a black box.