I grew up in a small town in New Hampshire. We were Massachusetts transplants, and my father viewed the family’s move north as his opportunity to transform from city guy to gentleman farmer. So, we went native. We got animals—horses, cattle and turkeys—along with the requisite farm equipment. And having all these farm resources meant that we, or actually my mother, had to go to the local seed and feed store to buy the stuff that kept the Carney farm operating—grain, tractor parts and pitchforks—all of which was no doubt pretty foreign to a woman who grew up in Cambridge, Massachusetts. Even though it was nearly 40 years ago, I won’t forget the first visit to the feed store.
“Hap,” the feed storeowner, was one of those craggy New Hampshire characters who, while spare in the number of words spoken, never failed to get the point across. Somewhat ironically, he had a son who was an aspiring artist, and in the middle of a field out back of the feed business, there was a wooden structure. It wasn’t a building or a sign; in fact, it seemed to have no purpose at all.
When my mother asked just what that thing in the field was, Hap was quick to tell her that it was a “hurricane watcher” ... and went on to explain that if she saw it fall over, she’d probably be in the middle of a hurricane. Hap knew that this indulgence to his artist son not only served no purpose, but was actually a nuisance when it was time mow around it. With a little sardonic wit, he was able to position at least a little value for it as a disaster indicator.
So what does this hurricane watcher have to do with insurance? Recently, I’ve been talking to variety of roles both inside and outside carrier walls to learn about how carrier application architectures impact how people get their job done. What’s become clear in these conversations is that while the legacy architecture can make things easier for IT to control and manage, that same architecture certainly might not do much to make it easy for people who had to use the systems under it. Some of these architectures were dictating how people worked in the business, meaning it was the employees who had to adapt to accommodate the carrier architecture, rather than the other way around.
Like Hap’s artsy offspring, a lot of insurance applications were built 10, 20 or 30 years ago by the craftspeople in insurance IT shops. The applications, like the wooden ornament in the field, produced a lot of pride in these software artisans, and they probably marveled over the beauty of the code. But the application utility—the ability to satisfy the wants and needs of the business, employees, agents and policyholders—clearly diminished over time or existed as something that primarily served the needs of ITs.
As a result, contact center staffs spend a lot of time answering questions from policyholders and agents about bills because the systems couldn’t adapt to the needs of the business. Finance couldn’t accurately measure the cost to issue a new policy or produce a bill, and marketing was limited not by regulators, but by their own internal systems even for enhancements to existing products, never mind new kinds of products or ways to help agents sell more policies.
It’s enticing to think about the creation process because we want to protect the application developers who we depend on to maintain our systems; or, as Ara Trembly recently posted, because internally developed software creates a competitive advantage. But as I’ve heard from the field, it’s also easy to create systems that are “hurricane watchers.”
Ellen Carney is a senior analyst with
Readers are encouraged to respond to Ellen using the “Add Your Comments” box below. She also can be reached at
The opinions of bloggers on
