Position Paper for OOPSLA Mid-Year Workshop on OO Technology for the Insurance and Health Care Industries.
May 13, 1998
Gary F. Anderson
IBM Insurance Research Center
Hawthorne, NY
gfa@us.ibm.com
I currently work as a software developer / IT Architect / etc. at IBM's Insurance Research Center (IRC). The IRC acts as a liaison organization between IBM's Research Division and the insurance industry. Prior to that I worked in the Research and Technology organization at Boeing Computer Services. I have been working with OO development for about 6 years with the last 2+ years centered around using Java to deploy distributed applications for the insurance industry. I tend to be more of an Application level architect rather than a 'big picture' architect, since I can't or won't give up coding.
· Java
I feel somewhat odd offering a position on the use of OO technology within the insurance industry. My work with industry clients and even some of my co-workers has made me see that OO still has a lot of inroads to make. However, I personally cannot really relate to doing any non-OO development. I would say it is the best thing since sliced bread, but I am more a fan of crunchy, rustic whole loaves.
I offered the executive summary more or less in jest, although I am a bit of a Java evangelist. Given the maturing state of the Java language and related development tools, I believe it is a suitable vehicle for developing important business applications within the insurance industry. It has some advantages over C++ in that it is a pure OO language and the large block of skills trained in C++ can be fairly easily transferred.
Although the development environment including the language is usually more important to the techies than the business people, I believe that some characteristics of Java make is very suitable to some problems the insurance industry is facing. One particular issue, which I will discuss below, is the link with the independent agent. I will put the context of the issue within my most recent and still current project at the IRC.
Many insurance companies use independent agents as a marketing channel for insurance and investment products. Typically, and independent agent will be licensed with six or seven companies. We recently partnered with a large insurance company, which wanted to strengthen their relationship with their independent agents by providing them prospects that might have a propensity to by particular products. They also wanted the prospects delivered on demand via the Internet, and wanted to limit the amount of help-desk support, which would be needed. Since the agents were all independent, it was decided that the delivery would be done via a web browser.
One of our interests was in building a reproducible solution that could be easily customized for use with other insurance customers. Therefore we chose to develop both the client side and the server side of the process with Java. The prospects are delivered to the agents via an interactive applet, which is downloaded to their browser. The server side has a Java application, which front-ends a RDBMS using JDBC. The server side may also be deployed as a servlet. Some of the reasons this architecture was chosen were:
1. Using an applet rather than a client side application eliminates the whole problem of version control for the client application.
2. Delivering via an applet gives more interactivity than using JavaScript / HTML. We were also able to leverage the security features of the Web server.
3. Using Java and JDBC on the server side made it very easy to plug-n-play with different RDBMS vendors.
The OO nature of Java made responding to changing requirements fairly easy. Part way through the project, it was decided that communication between the applet and the server needed to be encrypted. This required no more than introducing classes into the object hierarchy on each side and added a few cipher-related classes.
We are currently working with a second customer that has slightly different needs. Because of the OO nature of the applet interface, it is quite simple to substitute screen classes (the applet has a tab metaphor) to change the look and feel. Likewise, if there are different interactions needed with the Server/RDBMS, it is a simple matter to add appropriate classes.
My previous project involved deploying some technology that allowed synchronous collaboration between two or more Java applet over the Internet/Intranet. The business problem was to connect knowledge workers in a specialty claim center with industrial policyholders with real-time data sharing. The project including the underlying collaboration framework was all developed in Java. There were a number of lessons to be learned, particularly as relates to designing interfaces that are linked in real-time but are not identical because each of the collaborating parties may have different access rights to underlying information.
