Skip to content
  • Home
  • News
    • The FIBO Data Model in ER/Studio
  • Services and Solutions
    • Online Computer-based PowerDesigner training
    • SAP PowerDesigner Solutions
      • The CDM LDM Productivity model extension
    • The FIBO Data Model in ER/Studio
  • Toolbox
    • Free SAP PowerDesigner Resources
    • Speaking, Writing and Videos
      • A Pyramid of Data Models
      • The Metadata Archipelago
    • Book Reviews
    • Read widely – here are some books data modellers should take a look at
  • Blog
    • Data Modelling
    • Metadata
    • PowerDesigner
      • customising and extending
    • Data Lineage
    • Enterprise Architecture
    • ER/Studio
    • ERwin
    • Training
  • Community
  • Contact

Metadata Matters

Joined-up organisations trust their metadata

Insurance

Don’t underestimate what your modelling tool can do for you – an old tale of #PowerDesigner

April 15, 2020July 31, 2020George McGeachieLeave a comment

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.

Conceptual Data Model, data governance, Data Modeling, Data Modelling, ETL, information management, Logical Data Model, Metadata, Methodology, Requirements, Tips, ToolsDatabase, Insurance, Modeling, Modelling, PowerDesigner

Category Cloud

Books Business Rules Conceptual Data Model Conferences customising and extending Databases data governance Data Lineage Data Modeling Data Modelling Data Quality EA EDW Enterprise Architecture ER/Studio ERwin ETL information management Logical Data Model Metadata Model Extension Naming Standards Physical Data Model PowerDesigner Process Definition Requirements Tips Tools Training Uncategorized

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 1,012 other subscribers.