At a very early stage in my programming career I was profoundly influenced by a software engineer named Mohammed, or Mo to his Western friends and co-workers. Mo was an impressive and well-educated guy with half a dozen degrees, including two Ph.Ds. Given that English was not Mo's first language he often had an interesting way with words, yet you could always grasp what he meant and there never failed to be wisdom in his message.In 1986, Ronald Reagan was President, Germany was two countries, Madonna was in her "Papa Don't Preach" phase, and Mo and I were programming a system that used a network of mobile barcode readers that was positively bleeding-edge technology at the time. Our system was written in one language, the barcode readers written in another, and they would communicate via a wired network. There was a single point of failure inherent to this system: the handoff between the two code bases. Mo hated this architecture and colorfully dubbed the system a "Messy Bag o' Worms."
That lesson learned over 25 years ago is a lesson the insurance industry is learning today. When I look at the industry's current love affair with rules-based policy administration systems, I can picture my mentor Mo pitching a fit. While these solutions were revolutionary a decade ago, they have now been around long enough for their shortcomings to become apparent. Have rules (the magic elixir that enables the flexibility and configurability of today's policy administration systems) really become little more than a new kind of code? Are we now managing two code bases? Something that Mo would have hated. Have rules-based policy administration systems become the latest Bag O' Worms?
Because the rules-engines of today's administration systems have empowered the business logic layer to such an extent, they run the risk of doing more harm than good. As Shakespeare wrote in King Lear, "Striving to be better, oft we mar what's well." Certainly, rules in the hands of business users sounds like a noble idea. However, with no standardization or governance, flexibility with rules may just be too much of a good thing.
Before rules, our systems had only code. While not a perfect solution, the code was a standardized library that could be maintained by one person in one department. We knew how to tame the code beast, and at least it was contained in one place with limited access to only those "in the know." But now, every rules-based administration system uses a radically different approach when it comes to rules. Java code is the same whether it exists in Upper Manchuria or Lower Manhattan. Rules, however, can exist in a wide variety of formats and dialects. When it comes to rules, ironically, there are no rules.
One of my favorite Mo quotes was "I don't want to make a monkey wrench out of myself, but..." This usually preceded Mo explaining why your work stunk and that you needed to start from scratch. At the risk of making a monkey wrench out of myself, I have a couple observations and predictions. Despite being around for over a decade, the insurance industry is still in the very early phases of development and deployment of rules-based systems. I contend that rules 'standards' will eventually exist, resulting in a platform independent language for rules. When this happens, ACORD will take a serious interest in this type of business rule standardization across platforms and vendors. I might be in the Smoking Loon Home for Wayward and Damaged Insurance Executives by the time this occurs, but I believe it must and will happen.
Until rules are standardized, they will continue to proliferate as a new form of code, with all the problems, yet none of the control, of traditional code. The result -- nothing but a Bag O' Worms.
About the Author: Chris Doggett is founder and CEO of Adminovate. He can be reached at [email protected]