At most insurance companies, especially the largest and oldest, data is extremely disorganized. Many carriers have five or more policy admin systems due to acquisitions. Critical data is stored in legacy mainframe databases without an API and may be accessible only via a database string. The schemas of core datasets use column names like “field A,” “field B” and “field C” rather than easy-to-understand column names.

Innovating on this disorganized foundation is nearly impossible. But it’s also urgently necessary. There are two paths out of this chaos: building a custom data architecture entirely from scratch or building on top of an “opinionated” data model provided by a technical partner (described below).

Insurance CIOs and CUOs historically have opted to build from scratch, and it’s hard to blame them. Underwriting organizations differentiate their offering in the market through unique knowledge, processes and rating methodologies. These practices inevitably generate unique data and dependencies. That unique data, while critically important, makes up a small fraction of the total volume of data an organization needs to manage.

The 10 percent of your data that makes you special does not mean you need a 100 percent custom architecture. In fact, much of the data that an insurance company manages is quite similar in form to that managed by other organizations like them and should be handled in very similar ways. To solve data disorganization, insurance companies need a data model that can quickly bring the 90 percent of their data that is undifferentiated into a manageable structure, so that they can focus on the unique 10 percent of their data that demands flexibility.

Take a risk score, for example. The score itself and the three-to-four unique characteristics that inform it may be the most important aspects of a company’s underwriting data. But the majority of the fields that relate to the risk score (unique identifiers, time stamps, metadata) as well as the relationships that need to be drawn (policies, total insured value, premium) are very similar to how any other carrier would think about their data.

But the importance of that small fraction of unique data has been used by implementation partners to sell entirely custom infrastructure builds.

A custom data architecture takes tens of millions of dollars to build. Why? Most of the money spent goes to salaries for the external implementation partners who build it and who, of course, charge by the hour.

Let’s take a look at the alternative: an opinionated established data model provided by a technical partner.

Such a data model provides an architectural template in the form of software built over years of testing across customers, lines of business and markets. It will include integrations to common databases, ETL (extract, transform, load) functions to standardize and align data from disparate sources, and suggested rules to ensure the right teams and individuals can securely access relevant data when and how they need it. It should also include functionality to capture usage patterns in preparation for AI applications.

A technical partner that provides the data model will package learnings and best practices in the form of software. That software allows customer IT teams to extract and leverage data they already own but do not yet derive value from, and focus on their core differentiation, rather than reinventing the wheel for their own deployment.

This allows the IT and business teams of a company to bypass much of the discovery and costly mistakes that others in their industry have already made and take advantage of data engineering work that has already been done hundreds of times already.

The last decade has seen a dramatic improvement in capability and reduction in cost of data engineering technology. With streaming pipelines, every data source is individually scalable. Entire workloads can be duplicated, extended and scaled up to meet the needs of a new organization or line of business, thanks to cloud compute and containerization (isolated, portable cloud application packaging).Combined with battle-hardened conventional data tooling to integrate legacy systems, data architectures leveraging the best of new and old tech can be spun up today in just a few clicks.

A data model doesn’t need to cover every workload on Day 1 to be effective. It provides a flexible and extensible starting point, so that the differentiated data systems that set an organization apart from its competition can be seamlessly integrated while allowing IT teams to pick and choose functionality to cover the rest of their needs.

Building on an established model saves time at the outset of any data modernization project. Those time savings are magnified later, when extending and building in new functionality. Structure in a data model accelerates time to value and helps quickly modernize the majority of a company’s data. But if that structure is overly rigid, it becomes difficult to build anything on top of it. Too much structure can stifle innovation downstream if it doesn’t allow for the easy integration of new data sources, processes and tools.

For example, as the data practice of an organization becomes more sophisticated over time, the way that company calculates critical metrics may incorporate new data sources. When first built, a proprietary score might only calculate fields that exist at the account level, and so the score itself would be integrated into the data architecture at the account level. But the new data sources incorporated to make that score more insightful might exist in different locations in the schema, which can change the best place in the architecture to integrate the score itself.

In a highly structured, custom-built architecture, simply moving the calculated field will be a months-long process. You have to bring back the external implementation partner and refactor a large portion of the build, meaning this minor change will need to be bundled into a much larger group of changes in order to be economically viable.

When building on an easily extensible model from a software provider, it can be as simple as configuring a new calculated field without even requiring new code.

This example is characteristic of the fundamental flaw in waterfall-style custom data architectures. The 10 percent of unique data that differentiates an insurance company will inevitably change because that company will inevitably change its decision-making processes to stay competitive. A from-scratch build handed off by an external implementation team can take years to deliver and is built to support the business as it existed when the project began. And once handed off, a fully custom architecture is difficult to change and rarely supports dynamic changes that can keep up with the pace of innovation.

A balanced, opinionated data model developed specifically for insurance by a technical partner who understands the industry and its data patterns is effectively a shortcut to modernity. An underwriting organization can quickly and easily bring its data into a modern baseline in weeks on a structured template for the undifferentiated data that will not change. Then it can get to work building the specialized data processes that make the organization unique.

The model provides a foundation upon which that company can continue to quickly and easily innovate at the speed of its own business.