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?