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.

Before I continue, I want to absolve the software vendors of culpability here. Unless the industry creates patterns, they are left to invent (and re-invent) without patterns, and I'm sure most vendors agree that they'd rather avoid doing so. It's our responsibility as an industry to establish and publish the patterns we need so vendors can build consistent software across the industry. I think vendors would warmly welcome this because they can then focus on innovative ways to implement the patterns instead of inventing the same things repetitively.

The Agency/GA Integration Pattern

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

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

The easiest and most accurate means is through direct integration. However, having both Transformation Station and TransactNOW is completely cost-prohibitive for a GA (since they were really built for carrier integration and carriers have more margin to work with). Email is very ineffective, leading to data re-typing (ugh). Automated form readers are effective and span agency systems, but they require quite a bit of coding and don't work for many forms (especially hand-written forms). Not to mention, the implementations are not consistent so they can't just replace one with the other.

So then, what's the pattern?

In its simplest form, the pattern begins with the interaction:

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

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

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

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

Patterns are one of the building blocks upon which systems are built. With industry patterns, such as the agency/GA integration pattern, systems can be built that meet the needs of the industry by specifying the things that matter to all parties while freeing the vendors to figure out creative ways to make software to meet the requirements of the pattern. Without patterns, the industry gets many programs doing the same kinds of things but in very different ways.

Want to continue reading?
Become a Free PropertyCasualty360 Digital Reader

Your access to unlimited PropertyCasualty360 content isn’t changing.
Once you are an ALM digital member, you’ll receive:

  • Breaking insurance news and analysis, on-site and via our newsletters and custom alerts
  • Weekly Insurance Speak podcast featuring exclusive interviews with industry leaders
  • Educational webcasts, white papers, and ebooks from industry thought leaders
  • Critical converage of the employee benefits and financial advisory markets on our other ALM sites, BenefitsPRO and ThinkAdvisor
NOT FOR REPRINT

© 2024 ALM Global, LLC, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to [email protected]. For more information visit Asset & Logo Licensing.