For many years, building computer software applications was the modus operandi in the insurance industry. "No one knows our business," was the common refrain.Since then, software vendors customized their products for the industry, and buying prepackaged software applications has become the preference.

"Insurance companies, especially the smaller companies with revenues under $5 billion, are moving much more to software packages in the last couple of years," says Marc Cecere, vice president of Forrester Research Inc., a Cambridge, Mass.-based technology and market research company.

"In the old days, the prepackaged systems were not flexible enough and they couldn't handle multiple lines of business. Now, the systems are built in a more flexible way," he says.

More recently, however, activity on the build side has grown in certain areas.

"With the advent of the Web and a whole new set of development tools, building computer software applications has become attractive again," says Rick Williams, president of Wilsure Insurance Services, an insurance agency based in Barrington, Ill.

So, the debate goes on, but the supporting arguments have changed. To be successful, insurance company leaders need to understand the new dynamics involved in the build vs. buy debate. and decide which route is best for their company. At the same time, they need to avoid the pitfalls inherent in both approaches (see "How To Avoid the Pitfalls," below).

The biggest change to the software development process in the past few years has been the introduction of a host of development tools that make building software an easier, more effective and efficient process, according to industry observers.

For example, Java 2 Platform Enterprise Edition, commonly referred to as J2EE, has emerged as a popular software-building tool. J2EE is a platform-independent, Java-centric environment used for developing, building and deploying Web-based enterprise applications online.

The J2EE platform consists of a set of services, application program interfaces (APIs) and protocols that provide the functionality for developing multi-tiered, Web-based applications.

Another relatively new tool called .NET is helping to make the computer software building process easier for insurance companies. A Microsoft operating system platform that incorporates applications and a suite of tools and services, .NET erases the boundaries between applications and the Internet, making it possible to connect users to an array of computers and services that exchange and combine objects and data.

In addition to these tools, insurance companies are also adopting new, more effective software development methods.

For example, agile software development minimizes risk by developing applications in short iterations, which typically last one to four weeks. Each interaction is a miniature software project and includes all the tasks necessary to release the mini-increment of the new functionality.

One of the most popular forms of agile development is extreme programming (XP). With XP development, system developers and users come together at each stage of the process to see where they are and to fine-tune the application.

In addition to new development tools and methods, insurance companies can also benefit by tapping offshore computer development resources.

"Using offshore development teams has radically changed the whole financial equation. The cost of building software is so much less when using these teams," Wilsure's Williams says.

"And, that just makes building so much more attractive and feasible for so many companies."

Where buying shines

While building computer applications has become easier and more attractive for insurance companies, buying is still a desirable option for certain applications, according to Forrester's Cecere.

"Many companies can get exactly what they need from a prepackaged computer software solution. In addition, he adds, many systems have become like commodities-and don't really offer companies an opportunity to differentiate themselves from their competitors by building them in-house.

"For example, why should companies spend a lot of money building a claims system when the software really won't provide any differentiation?", Cecere asks. "Automated claims is no longer a differentiator. So, why spend all the money and take all the risk of building a system, when you can do it less expensively and more efficiently by buying it?"

What's more, software vendors are now building systems that are more flexible and, as a result, can provide a greater level of customization to insurers, Cecere says.

In addition to getting a system that closely matches a company's needs, insurers still benefit from the traditional advantages associated with buying computer software, according to Matt Josefowicz, manager of the insurance group at Celent Communications Inc., a Boston-based research and consulting firm. "It's far less expensive, you get a lot more support and you usually are getting something with a proven track record," he says.

Paul Apostle, vice president of enterprise innovation at Medical Mutual of Ohio, a Cleveland-based health care insurer, understands both sides of the emerging build vs. buy debate. He doesn't view the choice as an either/or proposition, however.

"I support buying applications as a general trend because a lot of vendors are going to extreme lengths to support the customization of their products," Apostle says. "In the old days, it used to be you had to take the software out of the box-as is. Now, the vendor will tailor their products to specific company needs."

Too much functionality

Still, Apostle realizes that although many vendors will customize, buying software applications isn't always the right move.

As a matter of fact, when Medical Mutual recently decided to outfit its call center with new software, Apostle decided the insurer would be better off building its own computer applications.

After reviewing software from a number of leading vendors, he realized the pre-packaged systems all offered more than the company needed. And, all of them cost more than the company wanted to pay.

"We only required about 65% of the functionality contained in the packages," Apostle says. "But none of the vendors wanted to provide a discount to us for the parts of the packages that we wouldn't use."

For example, all of the packages offered a module that encouraged call center employees to "upsell" customers when they called in for service. At Medical Mutual, however, call center employees do not engage in cross-selling.

So, Apostle pulled together an internal team to develop the company's call center software. The team relied on J2EE development tools to build the system. "The experience gave us the chance to learn a lot about using new, more popular programming languages and techniques," says Apostle. "It was a great opportunity to start introducing my staff to new development methods."

Now, Medical Mutual's IT group has the skills to "refurbish" the company's core administration system, instead of swapping it out entirely for a new system. "We need to update our core system," says Apostle.

"With this development experience under our belts, we will be able to use JAVA tools to build new front-ends on our core system. We will be able to do all of this in-house. The core system is sound. So this will be a good alternative to going out and changing the entire system."

Back to basics

Although the build vs. buy argument has taken on new dimensions in the past few years, the fact remains that insurers need to get the basics right.

Instead of addressing the build vs. buy question early in the decision-making process, insurance companies should instead make sure they have a solid understanding of their business needs upfront.

"Before companies start to build or buy a system, they need to have a full business-oriented understanding of their requirements," says Wilsure's Williams. But it's rare that people can actually sit down and articulate their business needs. "What do they need to grow market share? What functionality is needed to operate? Companies need to be able to answer these questions before even addressing the build vs. buy choice," Williams says.

Stuart McGuigan, CIO at Boston-based Liberty Mutual Insurance Co., says a solid understanding of the company's overall business goals always drives his decisions.

"To make a build vs. buy decision, you have to really know what you want to achieve from a business perspective," says McGuigan. "You can't just look at what features you want in a system. Instead, you have to have an understanding of what the system will do for your business. If you are going to improve turnaround time for a service, who will benefit? What customer segments will be more successful?" he says.

"Having an understanding of business goals makes us more ruthless in evaluating software packages and more efficient and effective in building systems."

How to Avoid the Pitfalls

Making the decision to build or buy computer software applications is just the beginning. Once a decision has been made, insurance technology professionals have to proceed with caution.

Rick Williams, president of Wilsure Insurance Services, an insurance agency based in Barrington, Ill, says insurers need to be wary of the following pitfalls.

WHEN BUILDING.

* Do not proceed without the proper resources. "You have to make sure you have the resources required to build a system before you start a project. Whether you are using offshore resources or not, it's important to have the human resources available and the ability to manage the project from start to finish.

* Don't save testing for the last step. Often companies will build software applications and won't test the applications until the end of the development cycle. "So, the company winds up developing for 18 months and then the whole thing falls apart when they decide to test the application," he says.

WHEN BUYING.

* Be wary of making modifications to software packages. "Sometimes, companies will start to modify packages before they even know if the base package works properly. Remember, if you modify a package yourself, you have incurred all of the risks associated with developing it internally. If you are adding functionality, you should at least make sure they are modular so that you are not affecting the core of the system," he says. "You want to go for modular functionality outside of the package instead of actually trying to modify the package itself."

* Don't get stuck with vaporware. Insurance companies need to be wary of vendors that are selling systems not yet ready to be implemented. While this was a bigger problem a few years ago, technology buyers still should verify that the complete system is ready to be implemented before signing on the dotted line.

* Check out the vendor's users' group. It's best to make sure the users' group includes companies similar to your own. If the group is composed of people from different types of businesses, the future development of the software may stray from your individual needs.

John McCormack is a business writer based in Riverside, Ill.

Register or login for access to this item and much more

All Digital Insurance content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access