At SelectQuote Insurance, adding a new carrier was a process that took many months. There were many reasons for this, but they were not good reasons in my piece of the puzzle. I was designing software that would take a sold policy in XML format and send off to the insurance carrier to fulfill. Each carrier did things slightly differently, but I wanted to reuse code across all of them. Here is how I approached this problem:
Different carriers had some different requirements. A few wanted near real-time notification of a sold policy, but most did not. Most preferred a file delivered on the schedule. Due to real time communications not being a requirement, a message queue was not needed.
I wanted to do my part such that it would be a purely administration task to add new carrier for my piece. No more expensive one-off development for the hand-off made at the time of sale. So, I needed to identify the parts that would vary and break them out from the simple server that processed these sales requests. I would put anything carrier specific into config files that could easily be modified by non-programmers.
My worker thread would call into other modules that had more carrier specific knowledge. Each of these modules had its own config file for the carrier specific pieces. There was a data access object that can send any carrier specific SQL code to pull the cases that need to be processed. There was a requester object that would make requests which resulted in a response of the XML that needed to be passed to the carrier.
I performed some simple validation on this XML, again this could vary by carrier. Then, depending on requirements, a file would be written and uploaded or a web service would be called. Both these functions were hidden behind one facade. The decision of which path to use was made at runtime based on the config file.
The actual server that processed all this work implemented as an MBean server. This allowed it to expose its functions through the Java Management eXtensions. This eliminated the need to code a separate GUI. JConsole comes packaged with the Java Development Kit, this tool can be used to connect to any MBean server. Do it this way, and there is a simple GUI already in place.
Through these exposed functions, all the aforementioned configurations could be changed. The MBean server allowed for persisting changes back to the property config files. Also, the means of e-mailing developers if a failure occurred was exposed here, along with which accounts would be notified.
There were probably good reasons why others' development took several months or longer whenever a new carrier had to be added or changed. But there was no reason why my piece should take this long. After this change my involvement in adding the new carrier was usually just a day or two to oversee things and normally I needed to do nothing. By designing the software correctly upfront I made what was previously a development effort a simple exercise for the administrator.
Different carriers had some different requirements. A few wanted near real-time notification of a sold policy, but most did not. Most preferred a file delivered on the schedule. Due to real time communications not being a requirement, a message queue was not needed.
I wanted to do my part such that it would be a purely administration task to add new carrier for my piece. No more expensive one-off development for the hand-off made at the time of sale. So, I needed to identify the parts that would vary and break them out from the simple server that processed these sales requests. I would put anything carrier specific into config files that could easily be modified by non-programmers.
My worker thread would call into other modules that had more carrier specific knowledge. Each of these modules had its own config file for the carrier specific pieces. There was a data access object that can send any carrier specific SQL code to pull the cases that need to be processed. There was a requester object that would make requests which resulted in a response of the XML that needed to be passed to the carrier.
I performed some simple validation on this XML, again this could vary by carrier. Then, depending on requirements, a file would be written and uploaded or a web service would be called. Both these functions were hidden behind one facade. The decision of which path to use was made at runtime based on the config file.
The actual server that processed all this work implemented as an MBean server. This allowed it to expose its functions through the Java Management eXtensions. This eliminated the need to code a separate GUI. JConsole comes packaged with the Java Development Kit, this tool can be used to connect to any MBean server. Do it this way, and there is a simple GUI already in place.
Through these exposed functions, all the aforementioned configurations could be changed. The MBean server allowed for persisting changes back to the property config files. Also, the means of e-mailing developers if a failure occurred was exposed here, along with which accounts would be notified.
There were probably good reasons why others' development took several months or longer whenever a new carrier had to be added or changed. But there was no reason why my piece should take this long. After this change my involvement in adding the new carrier was usually just a day or two to oversee things and normally I needed to do nothing. By designing the software correctly upfront I made what was previously a development effort a simple exercise for the administrator.
Post a Comment