Designing for specialization examples
The following sample use cases illustrate approaches to specialization in Pega Platform™ applications:
Use case: Standardizing rules across organizational layers
3Phase Inc. is a large electronics manufacturer that has operated for 25 years. Over time, managing new products and replacement parts has become increasingly complex. To address this challenge, the company created a separate Inventory Management (IM) division. Currently, IM applications do not require regional specialization.
Objective
Design specialization to standardize and share product-related Rules across divisions, while enabling IM to maintain its distinct operational mission.
Discussion and recommendation
Define product Rules at the enterprise layer. Also define utilities such as product selectors at the enterprise layer. This approach enables IM and other divisions, such as Sales and Customer Service, to share standard product definitions and utilities.
IM’s mission is to ensure products and replacement parts remain in stock across regions. This mission does not apply to Sales or Customer Service divisions.
To support IM’s specialized mission, create a unique set of application rules for the IM division by using the PHA-IM-APP-[Work/Data/Int] class structure. In the future, if there is a need to specialize rules for a particular region, various approaches can be investigated, such as:
| Approach | When to use |
|---|---|
| Circumstance Rules by region name | Use when only minor differences exist between regions, such as SLAs, approval flows, or small business rule variations. |
| Pattern inheritance specialization (append region acronym to class names) | Use when you need structural separation for regional logic but still want to maintain a shared Application Layer. Suitable for scenarios where Rules differ for each entity (work/data) by region, but the reuse of common assets is required to a large extent for processing. |
| Build a new implementation application on the existing application for a specific region | When regional requirements are extensive and cannot be managed through circumstancing or inheritance. Suitable for scenarios where each region operates almost like a separate business unit with significant variations in workflows, Personas, business rules, Data Models, and integrations. |
Use case: Creating reusable layer for shared processes
GameMatch is a social media company that connects members as they play different types of games.
Setting up and running a game is the same for all games, but the rules for playing each game differ. The entire process takes place in the context of the game selected by the members. The system records each player’s moves from game launch to match completion in a database table specific to the game type.
Objective
Design a specialization model that supports shared game orchestration while allowing each the unique logic and data requirements of each game to remain separate.
Discussion and recommendation
Create a reusable built-on Application Layer for game setup and orchestration. This approach is recommended because:
- The end-to-end interaction is similar for all games.
- Each game has unique rules.
- Switching context between interactions is acceptable.
- Persisting each interaction separately is desirable.
Develop a production application for each game type with its own rules. Build each application on the reusable layer for game setup and orchestration, as shown in the following figure:
Check your knowledge with the following interaction:
このトピックは、下記のモジュールにも含まれています。
トレーニングを実施中に問題が発生した場合は、Pega Academy Support FAQsをご確認ください。