What Constitutes Your Infrastructure?

According to dictionary.com, infrastructure is defined as:

  1. The basic, underlying framework or features of a system or organization
  2. The fundamental facilities and systems serving a country, city, or area, as transportation and communication systems, power plants, and schools.

The insurance industry typically considers infrastructure to mean the technological architectures within which hardware and software are purchased, deployed, run, and maintained.

Considering the fact that we couldn’t find any people in that definition — and since we haven’t reached the point at which AI and RPA enable hardware to purchase and install itself or software to program and implement itself — we think it’s a little narrow. Nor does it allow for the fact that software enables people to contribute to their organizations intellectually, as opposed to menially and mechanically, by automating menial, repetitively mechanical processes.

Infrastructure v2

We think we can (and should) give infrastructure a broader, more all-encompassing definition. Something more like this:

The resources, human, financial, and technological, by which the enterprise constitutes, operates, and sustains itself.

If we choose to define infrastructure that way (life is about choices), a number of productively beneficial things will happen:

  • We’ll define requirements for hardware and software more completely and accurately because we won’t forget the people who have to use the hardware and software we procure and deploy.
  • We’ll be more likely to procure the hardware and software that will be most beneficial their respective organizations because we won’t forget the people who have to use the hardware and software we procure and deploy.
  • We’ll achieve more favorable outcomes because we won’t forget the people who have to define, procure, and use the hardware and software we procure and deploy.

One More Thing

The notion of people, product, process used to be so popular there were graphics and videos created to promote it. What happened? We don’t have any intentions of selling products short — ours or anyone else’s. But the idea of products without people to buy, use, and benefit from them is curious and shortsighted at best.

“The bots are coming! The bots are coming!” has become the latter-day equivalent of “The sky is falling.” We know the bots are coming. They’re inevitable. They’re even beneficial. But the activities they perform are programmed — by people. They’re not the result of spontaneous, inventive, electronic ingenuity.

We don’t have to broaden or our horizons all that much to make sure our definition of infrastructure is adequately inclusive. All we have to do is include people.

That’s just one more thing. But that one more thing is the most important element in the definition.

Let’s do it.

People, product, process image © videoblocks.com.

Build vs. Buy … Still?

The insurance industry’s debate over whether it’s better to build systems or to buy them dates back almost 3,772 years to the reign of King Hammurabi in Babylon. Within the Code of Hammurabi, the first written insurance policy was inscribed into a Babylonian obelisk. It indemnified debtors against re-paying loans if some personal catastrophe made recompense impossible.

After the Babylonian Treasury had underwritten a number of risks and needed a way to administer them, Avil Kush, the kingdom’s CFO, CTO, COO, and CWW (chief worry wart) arrived at the palace to discuss the matter with the King:

Avil: Your Majesty, since the bar chart hasn’t been invented yet, we must build enormous columns of rocks with which to keep track of our premiums and claims.

Hammurabi: Wadda you, nuts? Why would be build it ourselves? Call Nargal-sar-ussur at Marduk Megasystems and have him implement it.

Okay. None of that actually happened. But the debate rages on. We think we can settle it once and for all.

Two Questions

To decide whether it’s better for insurers to build or buy their systems, we need to answer two questions:

  1. How do we define better? We won’t presume to answer that question. But we will suggest the perennial challenges of profitability, compounded by the changing nature of system requirements, might make it a little daunting for insurers to define better as DIY.
  2. As an insurer, would you rather be in the insurance business or the technology business? We won’t presume to answer that question, either. But we will state (proudly, if we may) that we put 22 percent of our annual revenue back into continual development and refinement of our product suite. That kind of investment on an annual basis might be a tough nut for insurance company shareholders, stakeholders, and employees to swallow.

To cite another ancient king, the resolutions of this dilemma might not require Solomon.

Leave It to the Pros

We can’t speak for everyone in the insurance technology vendor community. But it’s a fairly safe bet most of them don’t write insurance on themselves. It’s equally fair to imagine there are numerous good reasons for that. By the same logic, then, it’s probably better, short term and long, for insurers to buy their systems, rather than to build them.

If nothing else, it seems like an astute division of labor, with or without stone columns.

Software as Job Security

We’ve never conducted any kind of formal or official poll on this. But we’re willing to bet that if we asked most insurers and their employees if they considered their software to be an asset to their organizations and their people — or some kind of threat or liability — the majority would say the latter. Notwithstanding our own (hurt) feelings, that’s just not right. And vendors may be as much or more responsible for those sentiments as insurers.

What if, on the other hand, insurers considered their software to be an unconditional asset? And what if, rather than a threat of a liability, their people viewed the company’s software as helping them to make more valuable contributions to the organization? What if they saw the software, in fact, as a source of job security, helping them to make more valuable contributions to the organization, thereby increasing their value, their longevity, and their satisfaction? Would that be some kind of a pipedream? It shouldn’t be.

Higher Table Stakes

Insurance technology has advanced to the point at which configurability is an entry card. If their software doesn’t come with configuration tools, vendors won’t get a seat at the table, let alone be in the game. Those configurations tools free the people in IT departments to create business value — assess technologies, align IT with business goals, develop and maintain resilient, secure infrastructures. Given the rate at which configuration tools continue to advance, it’s not hard to imagine a day in which any BA can install any core-processing software in any insurance company. Another pipedream? Don’t be so sure.

The efficiencies enabled by software already reduce redundant data entry, while the portals provided by software allow increasing degrees of self-service and reduce the need for heavily staffed customer service departments. And if those efficiencies reduce the need for people to perform mundane, menial, and administrative tasks (they do), that means those same people can contribute more value to their organizations in higher-level, revenue-generating, risk-managing, and loss-mitigating positions. Call that a pipedream if you like. But it’s as inevitable as it is desirable.

Here It Comes

That sensation you feel is the rush of progress. The pipedreams are over. The future is here. And it brought reality with it.

Get ready, or get left behind.