Postulates For This Journal

The following postulates form the basic ideas this journal is intended to examine and discuss:

1) Most medium to large size property & casualty insurance companies recognized the value of computer systems very early. Consequently they installed mainframe computer systems back in the early 1960's (some as far back as the 1950's.)

2) These companies are among the first victims of vendor "lock-in". Carl Shapiro and Hal Varian devote two chapters to recognizing and managing "lock-in" in their book Information Rules
.

3) Most of these companies have a system architecture which has been described as a Ball of Mud by Brian Foote and Joseph Yoder. While companies have upgraded to bigger and better mainframes, and added more programs, some of the programs that were written back in the 1960's are still in use today.

4) Most of these companies have a strong desire to modernize and improve their computer systems.

5) Most of these companies have experienced one or more failures in their attempts to modernize.

6) Software vendors who have not had experience with this industry almost invariably underestimate the complexity of the property & casualty insurance business.

7) Some excellent software components are available for purchase from vendors who do understand the property & casualty insurance industry (e.g. for rating, accounting, etc.) Integrating these into a company's overall system, however, is usually costly, time consuming and difficult.

8) Roughly half of all property & casualty insurance in the United States is sold through independent agents, each of whom represent several insurance companies. The other half is sold through insurance companies who either employ their own direct sales force, or use "exclusive" agents who represent only the one company. This journal is intended to focus on issues related to those companies who sell through the independent agency system, where each agent represents multiple companies.

9) Insurance companies, and their independent agents, need a better way to conduct business together electronically.

10) The best hope for such companies to modernize and improve their systems is to re-design their enterprise application architecture.

11) Current technology offers numerous protocols, tools and ideas on how to improve such companies' integration architecture. Insurance companies need to examine their alternatives and engage in some serious thought about which alternatives offer the best solution. For example, consider this thought experiment that Sean McGrath wrote about a year and a half ago.

From Complexity To Simplicity

Adam Bosworth's ISCO04 talk, and the numerous controversial comments it generated, are certain to advance the art and science of software development. I hope Adam gives more talks like these.

Advances in software design, like the advancement of knowledge in the field of science, require many long hours of hard work, observation, and experimentation to extract the simplicity that subsumes the complex phenomena in the world around us. The knowledge gained must then be exchanged and vigorously debated.

Consider the combined work of Nicolaus Copernicus (2/19/1473 - 5/24/1543), Tycho Brahe (12/14/1546 - 10/24/1601), Johannes Kepler (12/27/1571 - 11/15/1630), Galileo Galilei (2/15/1564 - 1/8/1642), and Isaac Newton <1/4/1546 - 10/24/1601). The work of all of them, plus many others, was required to reduce centuries of baffling complexity to the elegant simplicity of Newton's universal law of gravitation and his laws of motion. This reduction of complexity to simplicity provided the bedrock foundation for much of modern engineering, and is as valid today as it was 300 years ago.

Such advancement and improvement does not come without controversy. Along with his considerable contribution to the body of knowledge, Galileo was convicted of heresy!

Trackback Added

Haloscan commenting and trackback have been added to this blog.

Trackback protocol sounds like a good idea.

Predicting The Future...In 1954

In 1954, "Scientists from the Rand Corporation...created this model to illustrate how a 'home computer' could look in 2004....With teletype interface and the Fortran language, the computer will be easy to use."

Gotta get me one of those!

Browser Problems? Try Firefox

Try the new, free Firefox Browser from Mozilla! Some older browsers, like IE 5.0, have difficulty with lengthy blogs hosted here on blogger. There are many other reasons to switch to Firefox. Check it out.

Money Can't Buy Me...

Off and on over the past 15 years or so, I have had the opportunity to talk with people from numerous other insurance companies who were either evaluating software vendors, or who had who had forked over gobs of money to a vendor and were in the process of trying to make that software work in their organizations. One common theme has been evident: most large insurance companies have been willing to spend very big bucks to buy a modern, flexible, fully integrated computer system that is capable of replacing what they currently have.

So far as I can tell, none have been successful. This reinforces the old adage: Money can't by Love, Happiness, or Enterprise Computer Architecture.

Sean McGrath and John Gotze pointed this out, along with some of the reasons, a little over a year ago. Unfortunately, most people are more ready to listen to someone who tells them what they want to hear, and less ready to listen to someone who tells them that they need to make a significant paradigm shift. This is true of doctors, lawyers, indian chiefs, cab drivers, donut makers, and yes...even insurance executives.

You can buy a great deal of good, useful, reliable software to accomplish many of the tasks that your business needs to do. But, if you are a sizeable insurance company, you just can't buy the part that puts them all together, makes everything work in harmony, and is flexible enough to serve your business needs. You just have to take the bull by the horns, and put that together yourself.

Daydreaming With J2EE

Why is it that whenever I am working with the J2EE, my mind frequently recalls this picture of Rube Goldberg's simplified pencil sharpener?

It Doesn't Get Much Better Than This!

Sean McGrath has added another dimension to his superbly written articles: audio versions! Take a timely technical topic, put it together with a writing skill that is able to grab and keep your attention in an entertaining way, then top it off with an audio reading by the author in his engaging Irish brogue -- It doesn't get much better than this!

Try it out! If you've ever wrestled with a system integration problem, you would probably find listening to "Tightly integrated? Just say no!" is a good place to start.

What's Wrong With The ACORD XML Standard?

Many dedicated, intelligent people have donated their time and expertise to the development of the ACORD XML Standard for Property and Casualty Insurance. A good XML standard is sorely needed in this industry, and those who worked on the standard deserve the gratitude of everyone who earns their living in the Property and Casualty Insurance business.

So why hasn't this standard been more widely adopted?

It may be because of the Law of Standards first described by John Sowa in 1991. I came across the link to this Law via Sean McGrath.

Mr. Sowa states:

Whenever a major organization develops a new system as an official standard for X, the primary result is the widespread adoption of some simpler system as a de facto standard for X.

...the overwhelming majority of successful standards are clarifications and revisions of interfaces that have proved to be effective without the support of a major standards body. What has consistently failed are the "proactive" attempts to design new systems from scratch that are declared to be standard before anyone has had a chance to implement them, test them, use them, and live with them. Some new systems succeed, but most fail, and even the most successful go through several iterations before the best configuration is found. Such design iterations are best done in small research projects, not in large public committees.

Mr. Sowa lists several well known standards to illustrate this law. A few from his list:

• COBOL became the de-facto standard for business programming - instead of PL/I


• PASCAL became the de-facto standard for Academic programming - instead of Algol


• C became the de-facto standard for system programming - instead of ADA

Tim Bray's experience appears to provide further evidence of the validity of Mr. Sowa's Law of Standards:

...I’ve been convinced that standards organizations shouldn’t try to invent technology. (The W3C, which is jam-packed with super-smart people, has produced some horrible, damaging standards when they’ve tried to get too inventive.) The right role for a standards body is to wait till the implementors have deployed things and worked out the hard bits, then write down the consensus on what works and what doesn’t.

According to Mr. Sowa's observations, the work done by the ACORD XML committee was certainly not wasted. But it's main function may be to provide scaffolding and food for thought for someone to actually implement a similar but simpler design.

So...one could infer that the ACORD XML standard is very likely to result in the widespread adoption of some simpler de-facto standard....


I wonder who will be the first to "Just-Do-It"

Doing It Backwards

I believe Paul Graham's astute analysis, of why Americans make the best software and why the Japanese make the best cars, can help point to a solution to the greatest technical problem faced by insurance companies today.

Most medium to large Property and Casualty insurance companies desperately want to modernize and improve their computer systems. Most, if not all, of these companies have been frustrated in their attempts to do this. I believe the problem may be because they are trying to do it backwards.

For shorthand, I will refer to Paul's two approaches as Careful-Design and Just-Do-It. I agree with Paul's conclusion that the best software is created using the Just-Do-It method. This identifies part (but not all) of the reason insurance companies have been frustrated. Most of the projects upon which insurance companies embark in their quest to improve thier computer systems tend to use the Careful-Design method. A lot of careful, systematic planning is put into gathering requirements, spelling out specifications, etc. Many of these projects either end up failing, or at the very least, taking much longer than anticipated.

But, that's not the whole story. An insurance company's computer system is not one huge piece of software. It is a large collection of programs, most of which need to communicate with each other and with the outside world. This need to communicate, or integrate, is one of the biggest problems such systems need to deal with. How do most software projects deal with this integration problem? With the Just-Do-It method, of course!

Even when a company purchases an excellent and extremely useful piece of software, they usually spend enormous resources in the attempt to integrate it with their other systems. Usually, this is done with the Just-Do-It method. Almost invariably, this takes much longer and costs much more than it should.

I believe the integration of multiple systems, both within a company and with the outside world, is a problem that needs the Careful-Design approach. The Just-Do-It method is just not adequate here because it is not really software creation; it is infrastructure-building, and has a lot in common with other infrastructure endeavors like roads, bridges, sewers, telephone lines, etc.

The best approach I have seen so far on how to build such an integration infrastructure is the work being done by Sean McGrath with the Irish Government. His company has published a couple of excellent White Papers on the subject.

Unfortunately, most companies just don't take the time to think about investing in infrastructure. It isn't really the money. They just don't seem to understand the need. (It would require a sizeable paradigm shift in their thinking.) They want a solution to the specific problem that they are dealing with today. Whether they buy or build a new software system, when it comes to integrating it with their other systems, they want to Just-Do-It.

How To Run A Successful Insurance Company

According to Warren Buffet in his Letter to Shareholders written on February 28, 2002 (describing the results for 2001):

". . . insurers produce outstanding long-term results primarily by avoiding dumb decisions, rather than by making brilliant ones"

My First Blog Post

After reading the Blogs of several giants in the computing field for the past couple of years, I have at last decided to start my own Blog. I find that the tendency of such Blogs to stimulate creative thought is simply astonishing!

While my Blog reading has stimulated me to write numerous e-mails to co-workers, I have also allowed numerous ideas to disappear into oblivion because I failed to write them down. I found, also, that e-mail does not appear to be the ideal mechanism to maintain a searchable record of previous writings. It is my hope that this Blog will help me to overcome my inertia, while taking advantage of the unique ability of the blog-o-sphere for global exchange of ideas. It should also be a much better way of maintaining an organized record of those thoughts.

My initial plan is to focus on software development and system architecture, with emphasis on their application to the insurance industry. The unique perspective I bring to this area is a distillation of 26 years experience in insurance marketing and underwriting, 21 years programming as a hobby (using Basic, Assembler, C, C++, Java, HTML, and PHP), 4+ years as a Programmer Analyst for an insurance company (C++, Java, JSP, J2EE/Websphere), and a strong interest in finding better ways to use computer software systems to improve effectiveness and efficiency in the business of insurance.

Some of the giants in the field of software design, development, and architecture who have stimulated my thinking over the past couple of years include: Sean McGrath, Paul Graham, Tim Bray, Adam Bosworth, Paul Prescod, Frederick Brooks, and many, many others. I expect that I will continue to rely upon them, and others, to continue to stimulate my own creative juices, so I may make creative and useful contributions.