Three-Step Process

The Hartford initiates a three-step process whenever it has a clearly defined business requirement, Lukas says. The first is we look at our own portfolio of software and make a judgment whether there is any of our own existing software we could customize or reuse to solve this particular business problem, he says. Repurposing its own software is the first priority for The Hartford.

The next step is to go shopping. And when a company is as big as The Hartford ($15 billion in revenue in 2001), it can usually get a good deal. Normally, if we can find software products that meet the specific business requirements were interested in, we can usually get it at a price tag that may be cheaper and with a bit less risk because were not starting from scratch, Lukas says.

And third, if none of the first two work, we build, he says. The rationale behind building relates to achieving some type of competitive advantage as a result of the technology effort, he explains, or the capability that effort will produce. Thats the formula, says Lukas.

Foulke agrees big shoppers such as MetLife can attain a favorable price when dealing with vendors. He says the fact that a company such as MetLife wants to use a particular piece of software can be beneficial for a vendor.

From where I sit, when you use the word Met in a purchasing situation, there are economies of scale you are able to bring to bear, so our unit cost is often lower because we buy so many versions, Foulke says. The other beauty of having the brand name Met is many vendors want to say, MetLife is a partner, or, MetLife uses our software. Often we are able to negotiate the price down because the vendor is able to say something like that.

Meeting Requirements

Finding the right product on the market is no easy proposition. Eyler puts it succinctly: The problem is theres just not a lot of good technology out there. There are very few really good insurance software companies that focus on this industry and can provide something off the shelf that is useable for a large, complex insurance company.

Main Street America Group is a mid-sized P&C carrier with $640 million in direct written premium. The carrier doesnt have the financial muscle to achieve price breaks like MetLife, but Canty believes it is easier to find products for carriers the size of MSAG than it is for some of the giants. Unlike Eyler, he believes there is quality technology on the market if you know what you are looking for.

Nevertheless, despite an extensive search, Canty couldnt find on the market what he wanted in a claims solution, so MSAG recently partnered with Castek to develop it, offering a carriers expertise on the claims process to a software company eager to expand its offerings.

Canty says the first step MSAG made was to send out RFPs to various vendors. We were prepared at the beginning to explore a separate vendor for claims and a separate vendor for underwriting, he says. Through the process and research, though, MSAG settled on a single vendor. We felt Castek could not only offer us development power, but support of a suite of products, he asserts.

The vendor already had a policy processing system but had yet to build a claims system. Castek was in the process of making plans to design and develop a claims system, says Canty. Normally, that might make some carriers turn and head in a different direction, but MSAG embraced the developer instead. It certainly was never our intention to go out and build one on our own, he says. What influenced us to work on this particular project was a solid partner in place, someone with really cutting-edge, up-to-date technology. Another key word for MSAG was flexibility.

Similarly, MetLife has learned it cant buy automatically every time it recognizes a need, Foulke says. We dont buy when the migration or customization of a package would be so expensive it would preclude our ability to do things like move to the next version when it came out, he says. Or over time it would cost us more time to maintain it because weve actually changed an elephant into a zebra, and weve got to throw too many hands at it because it just wasnt built for what we wanted it to do.

Venture Capital Dries Up

One of the reasons there is not enough good software available, Eyler says, is because the venture-capital stream dried up. In the past five years, we saw a lot of venture capital going into e-commerce kinds of investments that obviously didnt do so well, he points out. The venture guys will tell you they were so burned by that. When they take that into account and look at very, very long sales cycles for getting to market with a start-up software company, you just dont see a lot of money going into creating third-party software that is actually compelling for an insurance carrier.

Lukas agrees. Typically, the products on the market dont necessarily meet all our requirements, and then you start getting into the customization world and you end up in a dilemma. The more you customize it, the less likely youre going to be able to handle the maintenance and upgrades the owner of the software product provides to you.

Pure systems, such as for a companys payroll, arent going to need much customization. But if its a CRM-type solution, where your business models or requirements are different, the amount of customization you might do to the product renders the value of buying software almost negligible, says Lukas.

Eyler believes patience, such as that shown by MSAG, can make a big difference. Insurance companies need to understand how to take it easy to the extent they can be as cooperative as possible with new software vendors to give them a chance to get to market, he says.

Some insurers are partnering with offshore developers and serving as beta partners so the developers can make a product that is created around a companys actual business requirements, according to Eyler.

At Your Service

Having a plan certainly is a good idea for any company, and Lukas says the technology plan at The Hartford involves service-based architecture. Whether we build it or buy it, theres an architectural requirement we will have to have, he says. Breaking down systems into components is what allows The Hartford to adapt some of the software it already owns to another purpose. While our inventory of those components might be small today, every time we either build or buy components [the inventory] gets bigger and bigger, so the likelihood of us being able to reuse these components on new requirements gets greater and greater over time.

Foulke says MetLife also endorses reusing software solutions, but he adds you dont have to build your own solutions to be component based. A carrier must have a platform that is built on open standards and interoperability in order to repurpose software. Met is very big in the standards world to be sure we stay open, flexible, and commonly architected, Foulke says.

Interoperability is possible because the computing world has changed over the years. Systems are no longer dependent on a single operating system, a version of a browser, or whether the software was developed in Java or PowerBuilder. Things interoperate so well today, Foulke says. Thats become less of a challenge as we move forward. Its almost a bylaw with MetLife. Weve been very successful at having a common, open-standards platform where interoperability is big for us, he says.

The Right Staff

Its component structure and a flat job market are just two good reasons The Hartford is able to attract solid developers to an industry that was laughed at during the midst of the dot-com boom. Does The Hartford have trouble finding good development people? Not today, says Lukas. Two years ago I would have given you a different answer, but today the market for human capital is pretty good for us.

A couple of years ago, Eyler says, good young developers would have opted for third-party developers or consultants, not the insurance industry. But the stability offered by insurance companies is proving attractive. It is easier to attract good talent now, he says. The problem is if you look at all the projects an insurance company would be undergoing at any given time, most are going to be for maintenance and maintaining Cobalt code. Youre not going to get a good developer excited about that. They have this perception that insurance companies are boring.

Lukas doesnt see it that way. Technology is technology, he says. Of course it helps if you can offer a plan for the future. There are a lot of people hyped about this architectural direction with component parts. It doesnt necessarily matter to them that this is insurance. It matters to them that they are able to contribute in delivering an outcome that is beneficial to the company.

Although MetLife would prefer to buy, Foulke points out the company builds all the time. He says MetLife has a tremendous technology budget and a tremendous amount of programmers. We continuously look at leading-edge technology, and because we are a full-service financial firm now, not just a life insurance company, people want to come here, Foulke says. The work is interesting, the technology is leading edge, and your skills stay current.

Knowing Your Path

The problem many insurers face, Canty says, in making software decisions is they give in to others, often vendors, rather than establishing their own direction. MSAG felt its claims processes were important and wanted the software to be adapted to those processes, rather than changing the processes to match the capabilities of the software. Even before it had claims technology in place, MSAG had made a decision on its organizational structure and the processes involved.

A lot of the technology we had looked at through the RFP process had pretty much institutionalized certain processes, says Canty. They said they had flexibility, but we were not seeing the types of things built into the system we needed.

MSAG wanted to split sub-lines (partial exposures within a claim) from the high-severity lines of the claim, and it also wanted an automatic assignment feature so the system would recognize the severity of a claim and assign it to an adjuster who fit the profile for such a claim.

Our position was, if the other products dont have it yet and are being used by several companies, whats the chance of us getting that type of product into our organization within a reasonable period of time, Canty says. The chances are, we wouldnt be able to have that type of influence over the product.

Just One of the Gang

It was important MSAG not surrender any functionality when it found a new vendor, Canty says. The system used prior to Castek had split sub-lines, so MSAG insisted on that. Most of the products we looked at did not have that, Canty says. Even more troubling, though, were the doubts MSAG had about becoming part of a vendors user group. If a company has a proven claims product, you become part of a user groupa single voteand we had to make a decision on whether we would have enough influence to get that functionality built into future releases of that company, Canty says. Ultimately, MSAG decided against that route. We felt we werent going to wield that much influence in a user group to get the type of functionality we felt was preferable to our organization.

Insurers can become easily frustrated if they are part of a user group and they get outvoted on functionality issues. You sit there waiting for certain pieces to be added to the system that really have no bearing on what youre doing as an organization, Canty says. What you end up doing is compromising how your organization operates and how its structured. Instead of building a system that responds to your needs, youve got to build an organization that responds to the systems capabilities.

Mistakes Happen

No one likes to make mistakes, but they happen, and it is a wise company that takes steps to ensure mistakes wont be fatal. Part of our RFP and our due diligence process is, if we need to move away from a component we purchased, we are open architected and dont get engaged with vendors that are able to hook themselves in a way that cant be unseated, says Foulke. Its fairly easy to change horses if we have to, which by the way we dont have to very often. But because of things like the economy and some companies getting into financial trouble, sometimes thats required.

Hooking up with a partner that doesnt yet have a product on the market can be worrisome to some insurance companies, but Canty believes the fact that Castek has other proven products on the market makes it easier to commit to the vendor. We certainly understood there were risks involved, but what we got from Castek was a very honest dialog, a very honest proposal of what it could and couldnt do and what we were going to have it do, says Canty. We had some candid discussions on what type of expertise Castek could provide for us, what its technology could do, and what the things were we would have to provide. The plus side is you get a system built in your likeness, providing you with the functionality you need.

A Companys Legacy

Lukas believes The Hartfords commitment to component parts will help solve the nightmare many insurers face: What to do with the legacy system? Weve got the whole history of IT legacy applications here, he says. Our approach, as we build these component parts, is that over time well be able to start taking apart the legacy base, replacing those functions with some of the new components were building. Well gradually dissect some of those old, old legacy systems as well over a period of time.

He concedes developers have a lot of maintenance work to do, but the underlying challenge of the maintenance work is the opportunity to take the legacy systems apart and replace them with new components as they are constructed. Were not investing a whole bucket of money to rebuild all our legacy systems, says Lukas. Were doing it as a by-product of new project activity and new strategic initiatives.

The strategy fits well with the direction vendors are taking. Service-based architecture is an industry thing, says Lukas. You see many of the major software builders are building applications consistent with service-based architecture. The demands we have of buying these components are the same demands anyone else is throwing at them. Thats how theyre delivering their solutions now. They are more likely to fit in our architectural direction today than they might have been five years ago.

The Hartford spent about one-third of its IT budget on developmental projects in 2002, and Lukas says the percentage will likely be the same again this year. Were not shy about technology initiatives, but we are pretty strict that those expenses deliver value and benefits to our customer base, he says. Weve got to be pretty sure thats exactly what is happening with the product, otherwise were not going to invest the money in doing it.

Lukas says he would love it if he could get the cost of maintenance and production support down to half of his budget so more time could be spent in the strategic space that is enhancing our products, our customer service, and our ease of doing business. Its not how much you spend in total, its how you are spending it that makes the most difference.

By taking the legacy systems down, many of the maintenance costs will disappear and carriers will have more money to spend on building new systems or buying another product from a vendor, whichever direction the company chooses to travel. Its not really complicated, Lukas says: Youve figured out the strategy already.

Tips from The Trenches

Looking to build?

Have an architectural direction to follow, such as using component-based software.

Make sure you have quality developers on staff who can deliver the goods.

Dont reinvent the wheel. If theres a good product on the market, take a close look at it first. It may be cheaper to buy rather than build.

Review your inventory of software to see whether any of it can be used as a component for a different use.

Ready to go shopping?

Test the waters. Dont settle for the first vendor that walks through the door.

Make sure theres an actual product available, not just a business plan.

If there is no product yet, be certain it is a company that has demonstrated the ability to build other working products.

Dont alter the way you do business to fit the software. Determine that the software fits with your business rules.

Get something that already fits; dont go for a lot of customization. That can cost you more in the long term.

Beware of false promises. If someone tells you a capability will be a part of a future release, make sure other members of the users group wont stand in the way of what you need.