Extending an industry foundation data model

Follow this process to extend an industry foundation data model:

• Obtain industry foundation data model documentation
• Obtain the data model for the system of record
• Map the system of record data model to the industry foundation data model
• Add properties to the industry foundation data model and add data classes as needed
• Maintain a data dictionary

Before you begin the mapping process, determine which parts of the data to map. For example, when producing the initial minimal lovable product (MLP), it may not be necessary to map all of the data from the source before the go-live.

The Pega Community landing page for each industry foundation data model contains an entity-relationship diagram (ERD) and data dictionary. You need these documents to help you map the industry foundation data model to the system of record data model. Acquaint yourself with the relationship of the data types, classes, and properties that the industry foundation data model provides.

For example, the Pega Customer Service data model has three main classes:

1. Pega-Interface-Account
2. Pega-Interface-Customer
3. Pega-Interface-Contact

In an industry such as banking, a customer typically has multiple accounts such as checking and savings. A customer should be able to define multiple contacts per account. Therefore, the relationship between Account and Contact is many-to-many.

Pega industry frameworks do not force the consumer of its data models to use intermediary, many-to-many association classes. Instead, in true Separation of Concerns (SoC) fashion, Pega industry frameworks hide many-to-many relationship complexity by having data consumers reference appropriately named and parameterized data pages.

Work with the enterprise architecture team at your organization to obtain a model of the system of record. This data model documentation can take the form of:

• An entity-relationship diagram
• A canonical data model (typically used ESB solutions)
• A WSDL or XSD
• A spreadsheet

Regardless of format, this documentation serves as a source for mapping the industry model to the system of record.

The next step is to map the system of record data model to the industry foundation data model. To help with this process, use a tabular format to record this information, such as a spreadsheet. The output is a reference document to use when mapping property values from the integration response to the application data structure.

During this analysis, you may find that you need new properties for the application. For example, when mapping the healthcare industry foundation data model, you may find that you need a property to store information when a claim is submitted outside of the member's home country. Record the name and class where the property resides because you will need to add it to the application data model.

Only create new data classes and properties if your application requires that data from the source system. Use the data classes and properties from the industry foundation data model as much as possible.

If you create any new properties and data classes, generate the integration rules into the organization level integration ruleset. Test each data page to ensure that the source data's mapping to the application data model is correct.

If the data mapping is not recorded, it may be difficult or impossible for another team maintaining the model to reverse the mapping if necessary. A data dictionary is especially important if two or more source data items map to one output data item (this type of relationship is called surjection). For instance, the same type of information exists in two different paths within the integration data model. Encourage your development team to document the meaning and proper use of data model properties.