In the broad insurance marketplace of life, health and property and casualty insurance, numerous software vendors vie to sell software to meet the business requirements of the overall insurance industry.

Because financial services and insurance in particular were heavy users of data processing, they tended to take on a large workforce that could develop programs to accomplish these myriad computing tasks. With little standardization in business processes or how the business was managed, insurance companies took a go-it-alone approach to application development. And that approach required more and more resources — human and machine — to keep up with managements' requirements for better and faster processing of information.

Major computer vendors realized the opportunity that insurance afforded them, and most companies developed insurance applications that would run on their hardware. As computing costs continued to rise, companies decided in many cases to create their own in-house programming staff to develop applications to compete with those of the major computer vendors. The rise of insurance company IT staffs growing by leaps and bounds made more than a few insurance companies recognize the financial impact that overall IT costs were having on the industry.

Although the major vendors developed applications to manage certain common functions in day-to-day operations, considerable gaps grew in how each company did business. To fix those gaps with "canned" applications, companies' internal programming staff would develop code that added to the functionality of the main program. However, having that internal staff, which was less expensive than having third parties develop the requisite customization, made a lot of insurance companies look at "build versus buy" scenarios.

With build vs. buy, insurance companies' IT staff would compete with vendors for the development of new applications. While "build my own" had a certain logic to it, insurance executives questioned the efficacy of having a major application-development staff creating custom programs. And, after all, aren't insurance companies supposed to focus on the insurance business rather than the technology business?

Enter the application

Financially, insurance companies go through an underwriting cycle that regularly goes from "soft" to "hard." Soft markets are based on competitive pressures to reduce the cost of insurance. Hard markets are the opposite, where the pressure is to generate more revenue and more profit. In a soft market, where premiums are reduced, the pressure is for companies to operate as efficiently as possible. When the insurance market enters a soft cycle, companies cut costs, reduce staff, reassess compensation and institute other cost-saving measures. The one area that long seemed to be immune from the exigencies of the financial picture was IT — with its never-ending project list of software applications and enhancements that needed to be developed.

The question managers began asking was, "Why can't we buy off-the-shelf applications to do what we need to have done? Why are we continually developing applications that require continual maintenance, upgrades and fixes?" The growth of vendor-developed applications was partly fueled by insurance company managers questioning their existing IT procurement practices and legacy systems, as well as by application developers bringing good applications to market.

Fast forward to today, when vendors who understand the insurance business and have developed applications that solve certain business issues enter a healthy market in insurance applications. Certainly insurance isn't a one-size-fits-all business. However, it is a business where most carriers address the same business problems.

Insurance companies are still engaged in a decades-long quest to retire and replace their legacy systems and applications. (Photo: Ted S. Warren/AP Photo)

The Yin and Yang of shopping third-party applications

Arguably the biggest benefit of a third-party application is that a vendor develops it specifically to address a need in the operations of an insurance company. But in reality, the biggest benefit is more likely to be in the design of the application, which has been vetted by other insurance companies and carries a level of maturity and reliability. Another benefit — and not a small one — is that it's the responsibility of the vendor to keep the application current with their clients' business. Proprietary or "homegrown" applications must be kept current, and must vie for funding to keep those in-house applications running.

At the typical insurance technology trade show, you'll find hundreds of vendors who have developed 10 times that many applications — from making insurance operations paperless to making underwriting faster and more accurate, from managing claims to processing bills and managing agents. With the advent of service-oriented architecture, vendors have reduced the costly problem of integrating systems to share and exchange data.

Although third-party applications have proven to be a vast improvement over the "build my own" approach, they aren't always the best option. While the sales rep is bragging about the latest wonder brought to market, the wizened technology pro is likely to be skeptical — because he is looking from the vantage point of a legacy system that's been functioning pretty well. Insurance companies are by nature conservative, and not necessarily ready and willing to hop onto the next breakthrough technology. Additionally, it's not always an easy fit between these innovations and their older systems.

Because insurance companies host a technology-intense business, they have a lot of experience reviewing this deluge of vendors and their applications. In other words, they have seen the busts as well as the winners. Insurance IT managers generally have a list of requirements as they go through the vendor selection and evaluation process. What insurance technology managers seek are vendors and applications that are in use in other insurance companies, and that these applications have successfully gone through various versions, upgrades and migration of current data into their domain.

Moving forward from legacy systems

In light of all this, the obvious question for many carriers is, "With what do I replace the old legacy applications?" Insurance companies are still engaged in this decades-long quest to retire and replace their legacy systems and applications. And it hasn't been easy. Some companies found a large lack of documentation, in that no one really knew the old programming languages or how the rules had been set up in their system actually worked. So the short answer is that there are many applications on the market, including some that are fairly well vetted by analysts and customers, and others that may be more compelling because they address emerging business issues.

But time marches on and companies are now at the cliff's edge: They simply must move out of the legacy environment. A possible general solution to consider is a combination of applications that will solve the problem. In many cases, the application suite, especially where it is modular by design, can deliver better overall long-term benefits than a combination of unrelated applications.

John Sarich is vice president of strategy at VUE Software. He as more than 25 years of insurance industry experience, and has closely tracked the history of technology's role in insurance. Sarich can be reached at john.sarich@vuesoftware.com.

Special Reports /

Insurance technology history: Development of applications

Related Stories

Recommended For You