Skip to main content
Verify the version tags to ensure you are consuming the intended content or, complete the latest version.

Industry foundation data model benefits

Pega's industry foundation data models allow you to leverage and extend an existing logical data model instead of building one from scratch. Pega offers industry data models for Healthcare, Communications and Media, Life Sciences, Insurance, and Financial Services. Instead of building data classes yourself, you can map the system of record properties to the data class and properties of the industry data model.

HealthCare
The above image illustrates the logical model for the member data types for the Healthcare Industry foundation.

You can embellish the industry foundation data classes to include additional properties from external systems of record as needed.

Pega's industry foundation data models apply the Separation of Concerns (SoC) design principle: Keep the business logic separate from the interface that gets the data. The business logic determines when the data is needed and what to do with that data after it has been retrieved. The interface insulates the business logic from having to know how to get the data.

In Pega Platform, data pages connect business logic and interface logic. The following image illustrates the relationship between the data page, the data class, and the mechanism for retrieving the data.

Data Page Bi-directional Mapping
This figure illustrates how data from an external System of Record (SOR) is converted from the DATA CLASS on the left to external SOR’s data model representation for that DATA CLASS on the right. This process bi-directional. On the far left is a Data Page that manages this bi-directional mapping. The Connector and Data Mapper (pre and post processing data transforms) are configured in the Data Page.
 

This design pattern allows you to change the integration rules without impacting the data model or application behavior.

Rather than directly extend the industry foundation data model, your project may mandate that you use an Enterprise Service Bus (ESB) dictated data model. An ESB aims to implement a canonical data model that allows clients who access the bus to talk to any service advertised on the bus.

Enterprise Service Bus
An Enterprise Service Bus, or ESB, defines an integration data model that every server on the bus must be able to send and receive. Each server can have its own internal data model. This eliminates each server having to develop its own outgoing mapping logic to send to a different server, plus develop its own incoming mapping logic to receive responses from that server.
 

In a situation where an ESB is used, the Pega development team does not define the canonical data model. However, the team may maintain the mapping between the canonical data model and the foundation data model.

Note: The best practice is for the Pega development team to leverage and extend the foundation data model as needed. All mappings of the external SOR properties to the properties in the Pega foundation data model should be done by the Pega development team within the Pega application using data pages.

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?

Yes
No

Want to help us improve this content?
Suggest an edit

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