Creating the Next-Generation Phoenix

Mon, 28 Jan 2008 14:51:00 GMT

As I mentioned in my previous blog, the staff located in the Portland, Maine office is working diligently towards taking the Phoenix product set to the next level, (aside from those who are involved with PremiumBill.)

This is where our joint participation on this site will be important. From our standpoint, we need to do two things with Phoenix: a) keep the product viable and valuable to our installed customer base, and b) attract new customers.

The way to do this is to borrow a page from a fairly recent example in the marketplace involving Google. They acquired a privately-held company named Upstartle, who had a Web-based word processing application called Writely. What was the appeal to Google?

What Upstartle did right: They didn’t waste time and money building a product that had the same capability that already existed with Microsoft Word. Can you imagine all of the time and effort that would have been spent, and to what gain? Instead, Upstartle emphasized collaborative features – designing new, differentiating, and compelling benefits as part of a basic, no-frills word processing application.

The net result: Upstartle was able to build and market a solution in a very short period of time. I’ve never used the product myself, but Upstartle felt that collaboration features were more important in today’s world than duplicating a variety of word processing features that only a subset of customers would find useful. Google agreed and bought the company.

For us, the same trade-off exists. We’ve spent a decade and a half building our configurable policy administration system. (Adding other capability, like claims processing along the way.) If you were in our shoes, would you recommend that we spend millions of dollars (and multiple person-years in the process) re-designing and re-building what we already have, or would our time be better spent designing and building new features and capabilities?

As far as a “next-generation Phoenix” is concerned, we’re keenly aware that insurance-based processing is a complex, non-trivial undertaking. Early versions of Phoenix were not as complete as it is today, but our early-adopter customers were willing to accept less capability to have a Microsoft Windows-based system versus the “green-screen” mainframe alternative.

Today, our perception is that carriers need to conduct core business reliably – meaning that policy processing is complete and correct – gaps in functionality and shortcomings in quality are not tolerated. The pressing issues in today’s world are the needs to introduce insurance products to the market faster, where processing is extended via the Web to agents and self-service portals for customers. Along with this, connectivity to other internal or external systems is required to process subsets of policy information in specialized ways.

Our takeaway is that we should not spend significant time and effort strictly duplicating what we provided yesterday with policy processing – unless it makes sense to do so in the context of providing you with greater value. Right now, we’re in the process of proving that we can add new features and capabilities to Phoenix as well as exposing key policy processing capability Web Services (like rating).

I’m very interested in hearing what some of the challenges you have as they relate to Phoenix, and what you would like to see us provide as we move into the next-generation design and development of Phoenix. What are your key challenges with Phoenix? What processing do you deem essential for us to expose via Web Services?

Dave Moran's Software Development Blog

Creating the Next-Generation Phoenix