Skip to main content

Extending an industry foundation data model

Use the following process to extend an industry foundation data model in your Pega Platform™ application:

  • Obtain documentation about the industry foundation data model.
  • 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 minimum lovable product (MLP), it may not be necessary to map all of the data from the source before go-live.

Obtaining industry foundation data model documentation

The Pega Community landing page for each industry foundation data model contains an entity-relationship diagram (ERD) and a data dictionary. You need these documents to help you map the industry foundation data model to the system of record data model. Familiarize yourself with the relationships between 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 for each 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.

Obtaining the data model from the system of record

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 for Enterprise Service Bus (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.

Mapping the system of record data model to the industry foundation data model

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 that you can 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 might need a property to store information when a claim submission comes from outside the home country of the member. Record the name and class where the property resides because later you will need to add it to the application data model.

Adding data classes and properties

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 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.

Tip: Over time, web service and rest service definitions can change. Use rulesets to maintain versions of integration rules. As a best practice, allow the center of excellence to manage and deploy these rules to development environments.

Maintaining a data dictionary

If you do not record the data mapping, it might be difficult or impossible for another team that maintains 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.
 

Check your knowledge with the following interaction:


This Topic is available in the following Module:

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice