Enterprise layer reuse
We have started a Pega CRM project and are thinking about how we should go about reuse of the enterprise layer.
At the moment we have two platforms. Let’s call them Default and FLP. Default is the one we started off with 4 years ago and FLP is the one where we are planning to build our lending applications on. The Default one is still running 6.2 and FLP is running 7.2.1, and we haven’t kept the enterprise layers on the two platforms in sync. There is therefore no reuse of rules between these platforms.
When we now are going to establish a new CRM platform running 7.2.2, we would like to reuse our enterprise layer that is on the FLP platform. And in the future we want to keep the enterprise layer on FLP and CRM in sync. What is the best practice for this? What do other customers do to solve this issue?
***Updated by moderator: Lochan to remove proprietary information; move post from PSC to Lead System Architects forum***
Updated: 9 Feb 2017 6:27 EST
Pegasystems Inc.
IN
Hello!
I found this discussion over at the Lead System Architects forum: Framework + Impl Layers or Impl Layer on Top of Impl Layer?
I will be moving your post into the Lead System Architects forum so that your question might get the attention of other LSAs.
Regards,
Pegasystems Inc.
US
When dealing with an Enterprise layer we recommend defining an Application rule that contains every Enterprise layer-worthy ruleset. That Application should be versioned in the same manner that Pega generates releases, namely, major, minor, and maintenance level (ML) versions.
We also recommend that a “divide-and-conquer” approach be used that involves creating multiple specialized rulesets that contain related functionality as opposed to lumping unrelated functionality into the same monolithic ruleset. This, again, is similar to what Pega does.
As opposed to storing logos and other images in the <Org> ruleset, consider placing them in a ruleset named <Org>StaticContent.
Certain rulesets could be specialized to purely contain safe-whenever-used “utility” rules. For example you could have a RemoveWorkParty Data Transform that simply accepts a PartyRole parameter and removes .pyWorkParty(param.PartyRole). This is useful as a flow action post-transform followed by calling the OOTB addWorkObjectParty Activity for the same Party Role. This avoids the “party already exists” error. Similarly the same ruleset could contain an AddNewParty Activity with a PartyRole parameter. This would be useful as a flow action pre-transform. The Activity would check to see if “.pyWorkParty(“ + param.PartyRole + “)” already exists. If so it would immediately exit. If not, the Activity would call addWorkObjectParty telling it to use the NewParty transform.
When dealing with an Enterprise layer we recommend defining an Application rule that contains every Enterprise layer-worthy ruleset. That Application should be versioned in the same manner that Pega generates releases, namely, major, minor, and maintenance level (ML) versions.
We also recommend that a “divide-and-conquer” approach be used that involves creating multiple specialized rulesets that contain related functionality as opposed to lumping unrelated functionality into the same monolithic ruleset. This, again, is similar to what Pega does.
As opposed to storing logos and other images in the <Org> ruleset, consider placing them in a ruleset named <Org>StaticContent.
Certain rulesets could be specialized to purely contain safe-whenever-used “utility” rules. For example you could have a RemoveWorkParty Data Transform that simply accepts a PartyRole parameter and removes .pyWorkParty(param.PartyRole). This is useful as a flow action post-transform followed by calling the OOTB addWorkObjectParty Activity for the same Party Role. This avoids the “party already exists” error. Similarly the same ruleset could contain an AddNewParty Activity with a PartyRole parameter. This would be useful as a flow action pre-transform. The Activity would check to see if “.pyWorkParty(“ + param.PartyRole + “)” already exists. If so it would immediately exit. If not, the Activity would call addWorkObjectParty telling it to use the NewParty transform.
Another area where specialized rulesets makes sense is Integration. As opposed to placing every Enterprise-wide Connector within the <Org>Int ruleset, consider placing related Connectors in the same specially-named ruleset. “Related” can mean the Connectors interface the same service endpoint. Think of that endpoint as if the interfaced services were, instead, implemented in Pega - those services being part of the same Service Package.
Dealing with Integration changes can either be complex or “safe” depending on the nature of the change. If the change involves merely adding data fields leaving everything else the same, the newer version would be safe to consume. However if there are changes to the data model, such changes would at a minimum require a new mapping data transform and perhaps could impact the mapped-to Data class.
Bottom line, Enterprise-level change complexity can range from benign to complex/highly-impactful. The more rules are categorized and documented according to their dependencies/impact, the easier it will be to manage changes. Low-to-no impact rulesets could be released early and perhaps be made available to earlier versions.