CLSA Community Meetup: Design & Architecture: Anti-patterns, Best Practices and cautionary tales (January 2023)
In this event conducted on January 23-25 2023, Rob Ammon (@ammor), @JoshSultanik and @AnthonyKirkham shared their experiences, cautions, and guidance from having reviewed hundreds of Pega applications.
Under the spotlight are the highest impact design and implementation problems observed, and what they recommend you can do instead to design and deliver scalable, secure and performant Pega applications that are truly built for change.
Watch here the replay of the first session in the event, featuring Rob and Josh. Verbal Q&A from both sessions have been included in the replay. A more comprehensive list of Q&A from the event will be published soon.
- Slides in this presentation
- Linked In: Pega CLSA Community group
- Data Excellence CLSA Community Meetup (July 2020): elaborating on implementing Object-Oriented Designs in Pega
- TechTalk: DevOps and Unit Testing Best Practices from the field (kudos: Ivan Anikanov @aniki and @AnthonyKirkham )
- Pega Marketplace: Peer Review component (kudos: Kirill Marinichev @MARIK1 )
Questions & Answers
- Implementations, Frameworks and Reuse layers
- Object-Oriented Design
- Old Pega vs New Pega
... with more to come!
Implementations, Frameworks and Reuse layers
|What are the scenarios when we need to create a Framework layer?||
Avoid creating a Framework layer "just in case".
If you can generalize the requirements for multiple business scenarios - specifically the case and work processing, providing thoughtful extension points - this is a good candidate.
The classic use case is a standardized workflow performable by different lines of business that have slightly different requirements.
Another scenario is data storage for regional implementations layers or SaaS applications.
|What is the difference between an Enterprise layer and a Framework layer?||
Use an Enterprise Reuse layer when the components are granular and shared across the organization.
Use a Framework layer when there is intended reuse across multiple specific implementations including complex workflows.
Both Frameworks and Enterprise layers attract the considerations needed to provide reusable capability to layers that build on them.
|Must an Implementation layer be built from a Framework layer?||
It is not mandatory to build a Framework and an Implementation layer. That is, an Implementation layer can be built with no Framework layer.
If you do have both a Framework and Implementation layer, then they should have their own rulesets, classes, and application.
|Does the Framework always need to be an independent application?||
Yes, it does.
The Framework rulesets must be associated only with the Framework application. The Implementation application then builds upon the Framework application.
|What if we know that there will be multiple applications in the organization from the beginning?||
Design for extension.
Identify extension points in an otherwise common process, and also some of the Object-Oriented themes from this session.
Also consider where the reuse layer should reside. For example, if you have a Customer Service application and a Platform application, a Framework built upon Customer Service wouldn't provide value to Platform implementations across the organization.
|How do we handle a situation where we start with an Implementation application that we later identify could be used as a Framework?||
Refactor the generalizable portions of the Implementation into a new Framework layer.
Having the Implementation application assume the role of a Framework application results in coupling of peer applications.
|Should we place the data classes in the Enterprise layer?||
Although it depends on the situation, putting all data classes in the Enterprise layer can make it a huge dependency.
One alternative is to create data classes in finer-grained components that can be added to an application when needed.
|Can Frameworks help if my organization operates in different countries, each with restrictions on where the data is stored?||
If you build an application that requires physical data segregation (that is, separate databases/schemas) as well as having country specific reuirements, the infrastructure may need to be hosted separately which would mean multiple implementation layers.
Build out the extensible and configurable functionality in the Framework layer, and any country-specifics at the Implementation layers for each country.
|What best practices can help us minimize the impact of other teams making changes to the Framework layer that our Implementation is built on?||Consider reducing the lifetime of your branches by merging frequently. This reduces the volume of merge conflicts and helps you discover breaking changes sooner.|
|What is the recommendation if we still have Frameworks and Implementations from earlier development?||
Assessing your Framework needs is an ongoing process, regardless of what version you started work on, or whether the work was done by another team.
If you find that Framework is not providing intended value, consider consolidating it into the corresponding Implementation.
If I have a data class defined in a reuse layer, should I create a subclass for it in the Implementation layer?
For example: Org-Data-Party <---- Org-ImplLayer-Data-Party
This is recommended.
Let's say you do not create a corresponding Implementation layer class and - at some point in the future - you need to define implementation specific behaviour for that class. Adding that rule in a Framework class - but residing in an Implementation layer ruleset - is poor design, "mixes" the layers, and defeats the purpose of having layers in the first place.
Creating the class after the initial development means updating any instantiation processes to use the appropriate class (Dynamic referencing!) as well as updating any previously created cases. Save yourself a headache in the future and build out the corresponding Implementation layer data classes at the start of Implementation development.
Building a Framework - and then effectively utilizing it - takes planning and work. It cannot just be an afterthought.
Java developers can mark behaviour as "private" to control their access.
All rules in Pega are available for reuse. Can we forbid the usage rules that exist to implement part of another feature?
There is not an equivalent concept of "private" access to rules in Pega.
Leverage encapsulation, composition and delegation of concerns to encourage appropriate usage of rules for the types of data your application uses.
What is the best data design to use when properties are reusable across case types?
|Compose your case type data model using data classes so that each case type can selectively include relevant properties and behaviour for the types of data your case type uses.|
|To keep work and data classes self-contained, do they need to be in separate rulesets?||Classes do not need to reside in dedicated rulesets. There should be separation between layers though. The Applies To class's ruleset should match the ruleset of the rule.|
|Is Savable Data Page capable of adding new data object? Or do I need to use Obj-Save in an Activity?||Yes. A Savable Data Page is editable, so stage the content of the Savable Data Page the same as you would stage a clipboard page prior to calling Obj-Save (that is, without key values), and - for a class where Pega is the system of record - the "Database save" action in the Savable Data Page will create a new record.|
|Is it advised to use Data Pages instead of Obj-* methods while dealing with transaction data?||
Definitely evaluate if you can achieve your use case with Data Pages first.
Obj-* methods are limited to Activity rules; Data pages can be used in many different use cases and nicely encapsulate the retrieval logic.
|What is the latest, best practice approach for saving data instances?||
|For data classes in the CustomerData schema that have no BLOB, how can we use Field Level Auditing?||Field Level Auditing has been re-architected in Pega Infinity. The Pega Infinity implementation uses in-memory comparisons of the instance-to-save and most-recently-saved instance, regardless of whether the instance is saved to a BLOB column or not.|
|Whats the role of layer cake in the Constellation UI?||The choice of UI architecture does not change the role of the layer cake. The layer cake still defines the structure of the application and the enterprise.|
|When I create a landing page in Constellation UI, do I have an option to save it in a particular layer?||
Branch Development Preferences - when developing in Branches - is the strongest influence you can apply to direct rules authored in App Studio into the relevant ruleset.
Brian Pageau (@pageb) wrote a great blog post on the topic: How branch development works in Pega App Studio