Industry foundation data model benefits

With the industry foundation data models that are included in Pega solutions, you can 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. 

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

The Pega 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 system needs the data and what to do with that data after retrieval. 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 figure illustrates the relationship between the data page, the data class, and the mechanism for retrieving the data. Data from an external system of record (SOR) is converted from a data class to the data model representation of the external SOR for that data class on the right. This process is 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 on the data page.

With this design pattern, you can 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 so that clients that access the bus can talk about to any service advertised on the bus.

The following diagram shows how the ESB defines an integration data model that every server on the bus must send and receive. Each server can have its own internal data model, which eliminates each server having to develop its own outgoing mapping logic to send to a different server and develop its own incoming mapping logic to receive responses from that server.

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

Check your knowledge with the following interaction: