Pretzel Logic

All of the serious players in the policy administration vendor space offer flexibility, particularly through service-oriented architecture, reports Hersh. "We're seeing a tremendous push toward componentization," he says, "but on the flip side of that is the fact all these componentized solutions are more complete than they used to be, with the exception of claims and billing, which still generally are regarded as nice to have in the policy administration system but certainly not a required component."

What benefits the carriers is the systems are both more flexible and more functional, and yet, the prices really haven't gone up. "You're getting much more for your money these days, and there are enough systems out there with modern architecture so that if [companies are] looking for a significant changeover in terms of technology, they can get that, as well," says Hersh.

Flexibility for Allstate Financial technology comes from helping the carrier's business partners create solutions that fit their needs and make it easy for their partners to work with Allstate. One example, according to Kevin Rice, senior planning consultant for Allstate Financial technology, involves getting life and annuity policy detail information. "We have one service we have fronted our policy admin systems with, and it effectively will go to the right system that holds the information and bring back the information to the producer, whether it is on a Web site or a voice-response unit," he says.

Back in 2002, Allstate Financial launched a Web site called Access-Allstate for its producer community, which ranges from proprietary agents to independent agents, broker/dealers, banks, and others the carrier does business with, explains Rice. One of the things Allstate aimed to do was to make its Web site easier for producers to use. To solve some of the related challenges, work had to be done in the back end, Rice recalls. "Because we had multiple policy administration systems–based on acquisitions we had done in the past, inherited systems, or specialized systems for a type of business–we needed to create a process that was able to pull the data in a consistent fashion so the producers got consistent answers no matter which system they came from," he says.

Among the issues Rice felt had to be addressed were: How do we get the information out? How do we do inquiries into the system? And then how do we do some transactions so we can have a consistent way to do this across all the systems?

Plenty of prep work went into the project, says Rice, including some user-experience modeling to ensure the features were relevant and useable for the producer community and to make the system as intuitive as possible.

Back in 2001, the term SOA was just moving into the mind's eye, notes Rice. "I can't remember the day I first heard 'SOA,' and I can't recall spending much time on it with the documents we were using back then," he says. "I know Web services was going through the initial hype cycle at that time. We had a lot of conversations about Web services and what it would mean to us, but SOA really wasn't something that was coined."

Allstate made what Rice calls some key bets in the process and has maintained its focus on those areas. "The first was this would be a living system that would continue to evolve and add features as it went on," he says. "We tried to do a bit of forecasting as to what features we will have to react to as time goes on." An example of such foresight is seen in Allstate's decision to build the producer Web site. The carrier decided to tie voice response units into it so producers can make a phone call and then interoperate with the administration system should they choose. "If [producers] don't have access to the Web site and don't want to talk to someone, they can at least get the information via a voice response unit 24/7 and make their world relevant," says Rice. "Folding things in and adding [components] became a regular part of what we did."

The development team also wanted to ensure the work on this project would make work on subsequent projects easier to do, continues Rice. "We tried to be aware this isn't the only project that's going to feel this way, so what we'll do for the first one is to organize it in a way so that the second one can be added on with a lot less effort," he says.

In the past, most insurance policy administration systems were totally integrated and bound to the database. "You either used their claims and billing solutions or you ended up with all kinds of data-integrity issues," says Herenstein. "Making a change to one thing required a change to everything. They were much harder to manage, which accounts for why companies ended up with duplicity of admin systems."

In Herenstein's experience, carriers would introduce a new insurance product but were unable to figure out how to change their existing policy system to manage the new product. "There were enough differences from the existing system that it was an easy solution to spend the money to buy a second administration system," he says. "Once you had two, having three or four or seven really didn't matter anymore. It drove maintenance costs up, but that was the way of the world in the old days."

In the last year, Gleberman reports his company has helped a half-dozen carriers select new processing platforms. Most of these projects were initiated with the thought of end-to-end functionality, but in all of those cases, the carriers ended up with a multivendor component solution. "Carriers are looking at vendor products and saying they like the policy administration piece but don't like, say, the billing component or the claims component," he says. "They want to know whether there is a way they can piece those components together. More so than in the past, carriers are willing to adopt multivendor solutions."

Such a strategy can be costly, acknowledges Gleberman. "Certainly, you have integration issues, and very few of the vendors already have architected what I would call a mature suite of integration interfaces," he says. "There always is some custom interface work that needs to be done on a case-by-case basis, but it's definitely coming along. A lot of vendors can point to situations where they have taken their billing solution, for example, and integrated it with other policy admin solutions. They feel comfortable they have the framework to interface efficiently."

OneBeacon has a policy administration component in which the underwriting rules engine and the user interface both stand on their own. A user could never tell the two eventually are connected through an interface, explains Herenstein. "The same is true for our claims engine," he says. "These are all connected to interfaces that make changes for us less complicated. We add things to an interface as opposed to creating an entirely new system."

Some people credit the advent of service-oriented architecture and Web services for making the interfaces couple easily. Herenstein refers to SOA as "jargon" for what in the past meant doing something in a consistent way so it could be used over and over again. "If you look at most company systems, now you will find the interface looks the same across the board," he says. "[Users] know where to go, which makes training simpler and the user experience much better."

Components don't necessarily put on the front burner the need to eliminate or simplify Allstate Financial's systems, Rice states. "For our producers, as they relate to these common and popular features, we can work to extract the complexity, but there are other pieces that drive decisions around our policy admin systems," he says. "If we do reduce [the number of systems] because of the way the systems are tied together, it wouldn't be a lot of work to move a block of business from one to the other. We have a handful of policy admin systems, and they do their jobs the way they are supposed to, so we manage them as such."

Allstate Financial also discovered a single-use component doesn't add nearly as much value as components that can be used a second or third time, according to Rice. "By putting the diligence into the component so it operates correctly, our ability to use it a second time should reduce complexity and should decrease the time to market because the testing cycle would be a lot less," he says. "We're given an advantage from being able to gain time that normally would have been spent building [components] from scratch."

When discussing integration into the policy administration system, Rice points out some of the admin systems fall into the legacy range. "At the time they were designed, they were designed for the features and functions that were relevant at that time," he says. "They still function quite well today, but they don't fit the paradigm of, for example, the World Wide Web and browser-based technology, so we use tools and techniques to bring them up into that world."

Herenstein describes componentization as a hub-and-spoke arrangement, with the hub as the central core of the architecture where components can be attached, like spokes on a tire, with a common standard. "One of the best examples of this is the ACORD interfaces for agency automation," he says. "We provide upload/download services to dozens of agency management systems, and it is plausible because they all use the same connection. If AMS decides it is going to have a new version only a few agents will get, we can add that on by just altering a small component of the interface as opposed to making big changes across everything."

The policy administration system is the generator but no longer the source for information for business users, Herenstein believes. That has freed up congestion for OneBeacon in that actuaries no longer have to run complex problems that will consume the entire administration system. "This all works because we have standard interfaces that move from one place to another," he says. "If people want to run a report, they can do whatever they like whenever they like, and it doesn't interfere with the ongoing operation where people are trying to do their servicing."

OneBeacon chose a common standard, according to Herenstein. "We're a Java shop, which gives us an open set of standards," he says. "That way, we can pick up components and plug them in." Testing new components also is done much faster. "We can plug them in and see whether they work without testing how data moves through an interface as opposed to having to start over and build things from the beginning," says Herenstein.

The next trend in policy administration systems, Hersh predicts, will be in global systems, especially for systems used by European and U.S. companies with multinational operations. Added to that will be a combination of componentization and consolidation. "For example, if you want to move all of your policy processing onto one platform but you have diverse rating needs–country by country–you might have your rating system separated from your admin system varying by country," he says. "There is a trend toward componentization, and that will allow more consolidation over fewer pieces. You may not have the same claims needs in a number of business units, but you might have the same issuance needs." He believes there are decent claims and billing systems available in the market, and that has pushed a lot of the effort toward componentization. "As more components become available as stand-alone options, I think you will see an even bigger push toward SOA and pre-integration with leading vendors," he says.

Nevertheless, the level of activity in the policy admin area is reaching a plateau, Hersh observes. "If you [compare] the number of deals with the number of carriers, some of these deals are for single lines of business, not enterprises," he says.

Gleberman always has viewed insurance as being a technology laggard, and some of the principles being widely adopted by carriers today have been around in other industries for a while. "The premise behind [componentization] is interesting because some people view it as investing in a new architecture," he says. "If we deem one of the components inefficient, we should be able to replace it. That's the theory. But in practice, it may not be that simple. It's certainly being sold as being simple. I just don't know whether in practice that's the way it's going to be."

On the life/health side, Hersh sees consolidation being done on some of the more established platforms. "The more tried-and-true solutions [are being consolidated] because the transaction volume is low but the historical data volume is huge," he says. "You have policies that have been on the books forever. There are arguments to be made for mainframe solutions for big carriers with massive consolidations."

Newer solution providers are starting to prove themselves at that scale, though, remarks Hersh. That means some of the big carriers will start to look at modern solutions as consolidation platforms, and that will drive a new wave in the life/health industry. "As long as a company out there gets to the point where it can sell policies cheaper because its administration costs are lower, that will drive sales on the life side–keeping up with the Joneses," he says.

On the property/casualty side, the emphasis will turn to administering the commercial lines. "It's a whole new wave of why people are buying," Hersh asserts. "It's not a lot of personal auto anymore. Now, it's more a question of how do you underwrite commercial lines more quickly and profitably and reduce development costs."