One of the key IT systems for any insurance broker will be the Quotations system, where they record details of all of the insurance companies they represent, the types of risk they might cover, all their customers, all the risks the customers would like to have covered, all the possible questions they could ask them to assess risk, all the answers they received, and the resulting quotes. In a commercial insurance broker, those quotations could be very large and complicated.

About 15 years ago, one such insurance broker’s quotations database had been designed to handle any product, any type of client, and any risk they might want to cover, without requiring any structural changes to the database or much change to the user interface. It was what we call a ‘metadata-driven’ database.

This was good for the business because they focused their attention on defining their requirements, and it was good for some of the developers because all they had to do was turn those requirements into data to store in tables – there were a lot of code tables, “question” tables, and “answer” tables. This knowledge was good for job retention.

However, the database design was not good for anybody who had to get data out of the database, perhaps to print out a quotation – to extract the right data you had to look up all sorts of code values to find the right words to use for labels, and the right data to extract.

So, they decided to extract the data from that database into another database that would make it easier for someone to look at or report on the data. Their data modelling tool was PowerDesigner (then owned by Sybase). For the nerds among you it was version 11 – SAP have recently issued version 16.7; under the numbering system Sybase used we’d probably be up to 26 or so.

Modelling and building the new database was not the biggest concern they had, their biggest headache was describing how to convert the quotations data into the new format in such a way that the developers could build it and the testers could test it. They also need to be able to migrate some of that data to their Policy Management system, and develop messages for their messaging infrastructure but I won’t talk about that, this tale is long enough already.

One day, the project team were surprised to see the head of the company’s Information Architecture team, who most of them knew at least by sight, come into their office and sit down at a PC in the corner. He sat there for two weeks beavering away on, well, something. Nobody would tell the project team what he was doing, so they assumed it was something hush-hush that needed to be done away from the rest of his team. All very mysterious 😊.

At the end of the two weeks, the outcome of his sweat and toil was revealed – it was an Access database. Please, don’t groan, especially if you can guess what’s coming next.

The Access database was, admittedly, an amazing thing – it was designed to hold the Physical Data Model of the Quotations database, as well as the Conceptual Data Model representing the business data, the Physical Data Model for the new database, and the links between those models. It could import the data models initially, but all modelling changes had to be entered manually. The database generated the specifications to tell the developers the rules for moving the data between the two databases.

Applying the changes was a bit tedious, as the team had to make the model changes in PowerDesigner first, then make them again in the Access database, and there was nothing visual about that database, no ERDs to look at, just lots of metadata. The modelling work was slowed down considerably.

I can hear your thoughts already, you’re wondering “What’s the point of this long ramble, is it another dig at Access databases?”.

I’ll leave you to figure that one for yourself, just let me tell you one interesting fact.

PowerDesigner version 11 already supported everything the Access database did – nobody had investigated the capabilities of their existing tool.