In IT architecture—just as in building architecture—there are patterns that establish the nature of a problem and how it can be solved in software. When these patterns are not followed, or do not exist, programs are created that do the same thing but in vastly different ways, which leads to difficulty when replacing or integrating systems. In the excess and surplus lines world, there are many agents, general agents and carriers who transact business electronically in very different ways because we've relied on programs. Sometimes these changes cause problems and we need patterns, not (more) programs, to fix them.

To illustrate what I mean by pattern, there's a pattern called “façade” that generally describes how to wrap a complex system into a simple interface. A real-world example of a façade is the ignition for a car. The driver's simple interface is the key or key fob, and the complex system is the starter and ignition (I don't have the automotive aptitude to go beyond that). If this pattern is followed, the resulting “software” is fairly predictable in its implementation. In the case of façade, the underlying complex system is easily replaced or enhanced (anyone who has ever had a starter or ignition replaced knows what I mean). This works because the way the key (or fob) interacts with the ignition is consistent, well known and clearly documented (by the manufacturer).

Part of the issue in the E&S world is that the business and technical patterns—for agent/MGA/carrier—haven't been documented publicly (as far as I know). The result is myriad software solutions that do the same things in very different ways—and that software is hard to integrate and almost impossible to replace.