Insurance is a complicated industry at the best of times. At one firm, it was made more complex by the Policy Entry system. A Third Party Administrator(TPA) negotiated a policy with a client, then documented the changes in a rather hefty spreadsheet. The TPA would then call the data entry clerk at Bells-Torgo Insurance and verbally relate the contents of the spreadsheet.

Corey did the rational thing and suggested, "Hey, maybe we can automate this!" It was a straightforward operation, with a clear and well understood mapping between the TPA's sheet and the Policy database. Corey wrote up a design document, which included a diagram to sum the entire thing up in a way a manager could understand.

For months, that was the last he heard of it. He assumed that his idea had simply been swallowed by the void. By the time he received a meeting invite to discuss this up on the 40th floor, where all the executives lived, he had pretty much forgotten all about it.

Corey found himself sitting in an aggressively modern (if you lived in 1979) meeting room with three high level managers.

"This is a good idea," the suit on the left said, "but I think you've forgotten how sensitive this data is. The process needs to be more complex."

"This is a good idea," the suit on the right said, "but I think your solution is too complex. We don't want developers involved with maintaining it. It should be something the DBAs support."

"This is a good idea," the suit in the middle said, "but I think you're underestimating the importance of this project. We've already allocated a $2M budget for this, and are negotiating for another million. We're going to outsource this to consultants."

The consultants flew in, devoured the entire budget- which swelled to $3.5M- and left. Like a plague of locusts, they left nothing untouched. All that remained of their trail of devastation was a 1.3GB pile: an SSIS package called "Data Integrator" and its supporting files, and a five page Word document that was their "documentation".

As it turned out, the "supporting files" were a cluster of VBScripts, COM+ components, web services, and .NET stored procedures. In fact, only about 5% of the functionality lived in the SSIS package. The DBAs had no idea how to install most of that, let alone how to support it into the future. So, grudgingly, management freed up a few dollars in their budget to get the development to install it. Since it had started with Corey's idea, the entire pile landed in his lap.

Corey started with the documentation. The consultants had helpfully provided a diagram charting out the process flow. The rest of the document sketched out some baffling design decisions and warnings. For example, the Data Integrator didn't wait for TPAs to send policy information, it randomly generated policy numbers and then asked the TPAs' systems if they had any data for those numbers. One line in particular gave Corey permanent brain damage when he tried to understand it:

The production server must have its clock reset to 12:00AM every 8 minutes. I suggest that you automate this.

Deployment day turned into deployment month, and eventually into deployment quarter. Corey figured out which scripts needed to be run when: ClockReset.vbs every 8 minutes, hastur.bat needed to run every 24 minutes (emphatically not every 30, or every 15- anything other than 25 minutes caused catastrophic failures), and so on. He went through and cleaned up a few thousand hard-coded file paths that pointed to locations on one consultant's dev machine. He discovered that a key config file was encrypted with a key no one had anymore, and so recreated it through trial and error.

Corey deployed it, eventually. It even sort of worked. About half the time, it successfully imported about half the policies it was supposed to. Since it couldn't be debugged without crashing the debugger, the only real way to fix it was to replace it wholesale, and the IT budget was officially drier than Bridgewater, Connecticut. During the rest of Corey's tenure at the company, they went with the worst of both worlds: the Data Integrator kept running as best it could, and when policies inevitably didn't make it into the system, TPAs called the service desk.

Recently, Corey heard from an old colleague still at Bells-Torgo. There's a new initiative to replace this overly complex system with something simpler. Someone found an old design document written by a former employee that seems like just what they're looking for, too.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!