Deliver a Ruleset stack that positions all Pega Rulesets below the Rulesets introduced for the Client applications, including its Enterprise layer. Pega-provided Applications are not tested with non-Pega Rulesets in between them and the Platform Rulesets, so you risk unexpected behavior if you deliver such a Ruleset stack.
Pega Applications do Ruleset-specialize rules from Pega Platform, which would override any Ruleset-specializations you introduce in the Enterprise Layer if the Pega Application Rulesets are higher than your Enterprise Layer Rulesets. Of course, this would not be an issue if you Class-specialize in your Enterprise layer, but this isn’t always possible.
Consider having a Ruleset in your Enterprise Layer dedicated to any Ruleset-specializations required of Pega-provided rules. If you have one or more Pega Applications, scale this out to a specialization Ruleset for each Pega Application, following the same order as the Applications on the stack.
Discussion on this topic was sought from theLSA Data Excellence (Pega 8.4) webinarconducted in July 2020. The webinar and its full set of discussions that arose from it are available atLSA Data Excellence: Webinar, Questions & Answers.
@BraamCLSA I had a question that from Pega 8.6 is there a change in the way application structure/stack needs to be designed. When I say so, should we keep building rules in framework and then have implementations on top of them.
So just for an example, let’s say I have to create an application for Home Loan originations, would it be good to have a framework which would hold the rules of Originations and it would have originations for credit cards, home loans, accounts etc. or should we think of having component applications.
Pega 8.6 does not introduce any changes in the way applications need to be structured.
My guidance is to identify the potential for reuse, including through collaboration with your client stakeholders and architects. Not every Pega application delivery benefits from a Framework/Implementation model.
If you can anticipate that there are generic case types that would then be subject to regional or departmental specialisation, then Framework/Implementation is still a good pattern;
Sometimes this isn’t reasonably foreseeable when the project starts, yielding an Implementation-only first release. This Implementation should still be designed such that it could become a Framework-ike reuse layer in the future if the client’s business needs to adapt to a new opportunity.
Always Build for Change … even if you can’t see yet where the Change comes from. Use Dynamic Class Referencing, for example, allowing your Implementation-only work classes to be usable like a framework in the future.
Lastly can I recommend a CLSA webinar from @smarr on Building for Reuse which provides even more recent insights on your question about Component applications.
Don’t be so concerned about whether you use Framework/Implementation, Components or some other approach. So long as you are reuse-minded, are continually identifying reusable functionality and positioning them in in appropriate layer, you will be well setup to respond when your Client’s business needs to pivot in both expected and unexpected ways.