Industry foundation data model benefits

With the industry foundation data models included in Pega software, 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. Rather than 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 also 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: maintain the business logic separately from the interface that retrieves the data. The business logic determines when the system needs the data and what actions to take with that data after retrieval. The interface protects the business logic from needing to understand how to retrieve the data. 

In Pega Platform™, data pages link business logic and interface logic. The following figure shows the relationship between the data page, the data class, and the mechanism for retrieving the data. Data from an external system of record (SOR) changes 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 handles 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. 

Instead of directly extending the industry foundation data model, your project might require that you use an Enterprise Service Bus (ESB) dictated data model. An ESB aims to implement a canonical data model so that clients accessing the bus can communicate with any service advertised on the bus. 

The following diagram illustrates how the ESB defines an integration data model that every server on the bus must send and receive. Each server can maintain its own internal data model, which removes the need for each server 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 scenario with an ESB in use, the Pega development team does not establish the canonical data model. However, the team might handle the mapping between the canonical data model and the foundation data model. 

Check your knowledge with the following interaction: