In IT architecture—just as in building architecture—there arepatterns that establish the nature of a problem and how it can besolved in software. When these patterns are not followed, or do notexist, programs are created that do the same thing but in vastlydifferent ways, which leads to difficulty when replacing orintegrating systems. In the excess and surplus lines world, thereare many agents, general agents and carriers who transact businesselectronically in very different ways because we've relied onprograms. Sometimes these changes cause problems and we needpatterns, 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 intoa simple interface. A real-world example of a façade is theignition for a car. The driver's simple interface is the key or keyfob, and the complex system is the starter and ignition (I don'thave the automotive aptitude to go beyond that). If this pattern isfollowed, the resulting “software” is fairly predictable in itsimplementation. In the case of façade, the underlying complexsystem is easily replaced or enhanced (anyone who has ever had astarter or ignition replaced knows what I mean). This works becausethe 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 andtechnical patterns—for agent/MGA/carrier—haven't been documentedpublicly (as far as I know). The result is myriad softwaresolutions that do the same things in very different ways—and thatsoftware is hard to integrate and almost impossible to replace.

Before I continue, I want to absolve the software vendors ofculpability here. Unless the industry creates patterns, they areleft to invent (and re-invent) without patterns, and I'm sure mostvendors agree that they'd rather avoid doing so. It's ourresponsibility as an industry to establish and publish the patternswe need so vendors can build consistent software across theindustry. I think vendors would warmly welcome this because theycan then focus on innovative ways to implement the patterns insteadof inventing the same things repetitively.

The Agency/GA Integration Pattern

Here's an example of what I mean. There is no documented patternfor sharing data between general agents (MGAs, brokers,wholesalers) and agencies. As it turns out, there are at leastthree distinct ways to handle this kind of integration:

1. Email—yeah, it's not really integration, butit's the most prevalent form of information sharing (sue me forstretching the definition of both “data” and “integration”).
2. Agency management system directintegration—here there are at least two options:Transformation Station and TransactNOW (both work differently, bythe way).
3. Automated form reading—PDFs are read andconverted to XML messages that are fed into GA systems. I know oftwo solutions that each work differently.

The easiest and most accurate means is throughdirect integration. However, having both Transformation Station andTransactNOW is completely cost-prohibitive for a GA (since theywere really built for carrier integration and carriers have moremargin to work with). Email is very ineffective, leading to datare-typing (ugh). Automated form readers are effective and spanagency systems, but they require quite a bit of coding and don'twork for many forms (especially hand-written forms). Not tomention, the implementations are not consistent so they can't justreplace one with the other.

So then, what's the pattern?

In its simplest form, the pattern begins with theinteraction:

From there, the façade technical pattern can be applied (thatfaçade works here is a coincidence) by abstracting the details ofthe AMS or GA system from the way in which they're communicatedwith.

Notice a few things about this ad-hoc (i.e., I'm not saying thisis everything, just an example) pattern:

1. No technology is specified. All we know isthat the façade encapsulates the system.
2. No messaging is noted (between thefacades)—this is required (see ACORD).
3. The services details are omitted (butrequired). Again, this should be specified once the basic patternis brought to design level.
4. Other details are required. For example, inthe description for the pattern I'd note that the façadeimplementations must be open—i.e., they can talk to one anotherregardless of technology (e.g., Web services).

If such a pattern had existed, software vendors would've knownthe “rules,” which are created by the industry, for the industry(the insurance industry that is). Once implemented, we could mixand match the implementations and communicate freely between thepartners. Think of the façades between the AMS systems and the GAlike the key of the car—just turn the key and it starts(hopefully). If a car owner wants to replace the starter orignition (i.e., the AMS system or GA system), they don't have tohave a new key or learn a new way of starting the car. That is oneadvantage to patterns over programs: Users know the “rules,” whichare consistent and predictable across implementations.

Patterns are one of the building blocks upon which systems arebuilt. With industry patterns, such as the agency/GA integrationpattern, systems can be built that meet the needs of the industryby specifying the things that matter to all parties while freeingthe vendors to figure out creative ways to make software to meetthe requirements of the pattern. Without patterns, the industrygets many programs doing the same kinds of things but in verydifferent ways.