Using a standardized data model is an essential condition to achieve data governance in an enterprise. A standard data model supports data governance processes by implementing industry standards wherever possible:
- standards for contract and claims representation,
- mapping of data content with standard definitions (glossary function),
- use of code attributes instead of free text,
- mapping of standard and customized code, definition of arbitrary code hierarchies.
Standardized model structures
There are standard structures for modeling of different business processes available. For example, a standard structure for the modeling of insurance contract information in a four-level hierarchy principle:
- Level 1: General contract part for all lines of business (insurance policy).
- Level 2: Contract specific part for certain groups of lines of business (e.g. life, property etc.).
- Level 3: Line of business specific part (insured persons, insured subjects).
- Level 4: Risk-and coverage specific part (insured risks and hazards, insured sums).
Using these standard structures avoids discussions why a certain structure in the data warehouse model should be used and not another one (e.g. of course each insurance department sees its own structures as ‘standard’ relevant, and not those of other departments). See also my blog Advantages of a standard data model for insurance.
Mapping with standard definitions is documented in the model metadata where appropriate. For example, for attributes whose definition is defined in a standard glossary like ACORD insurance standard. Thereby the business definition of the attribute is clearly explained.
Usage and mapping of code attributes
The following example demonstrates a typical task in the development process of a multi-line of business DWH project:
Important policy attributes common to all lines of insurance business (e.g. policy status code, change reason code, payment mode code etc.) have to be stored in a common DWH table. Each insurance company with life and non-life insurance portfolio has at least two different operational legacy systems and departments that have grown historically and generally have little or no common structures. In the past each of these departments has developed its own data structures for reporting and analytical applications. In general, these are ‘operational data stores', which incidentally are often misleadingly called ‘data warehouse'.
The non-life insurance policies usually contain other code attributes for ‘policy status’, ‘change reason code 'and ‘payment mode code’ than life insurance policies. In many cases it is just not possible to map the code values one to one. The task now is to define a structure and value ranges for codes that are valid for both departments, life and non-life. The following requirements must be reconciled:
- Definition of universal structures and codes that enable a comprehensive evaluation at the application level. For an insurance group, this is, for example, a common consolidated view of all operational entities (OE), for our simple example of a life / non-life insurer it is a unified view on the two business branches.
- Consistent mapping of individual structures and codes of all OEs to the standardized structure and the group / company-wide standard codes.
- Additionally, the individual codes of the OE should still be preserved in the application data marts to ensure that the OEs find themselves there again and may perform evaluations in the usual manner.
Many data warehouse projects of insurance companies in the past missed these targets: for simplicity no multi-line of business DWH was implemented, instead the individual structures of the line of business specific operational data stores were copied into the DWH layer.
To use standardized code attributes wherever possible makes a lot of sense for a standard data model. The values and meaning of the code may be defined individually by each department or OE and will be mapped to the group-wide default standard codes on a meta level. This means, that the explicit values of the OE codes do not get lost in the DWH. It eliminates the need to reconcile different code values of different OEs and departments at the very beginning of a DWH development - which can significantly slow down the DWH implementation. The DWH development may be started sequentially per each OE. The mapping of OE specific code values with standard values will be done independently in a reference table on a meta level.
Achieving data governance is highly dependent on business processes that are aligned consistently within an organization. A standardized data model is still no guarantee that data governance is achieved, but an important prerequisite.
Hartmut Schroth, Business Advisor data strategies for insurance at SAS Germany. For further discussions, connect with me on LinkedIn.