LSA Course : Class Group design
Hello,
I've been wondering what are the real impacts of separating case types into different class groups. This is not really discussed in the LSA course but I feel it's a very important design choice as it has a strong impact on long-term application maintenance.
I've encountered some LSA that have a habit of creating a new class group for each case type (And I found that it has some advantage, for archival for example). But I've also seen a project where even 2 separate applications were sharing the same Table for all their case types.
So what exactly are the cons of having separate workgroups for each case type?
I suppose it has impacts on reporting but what exactly are those impacts?
Does the "report on descendant property" doesn't work anymore? Or Is it only a question of performance because several tables are queried?
Do the "standard" reports that are found in the case manager keep on working?
Any insights on what kind of problems have been encountered when having multiple class groups would be greatly appreciated ;).
Kind regards.
Pegasystems Inc.
US
@baeyw Applications should strive to be modular, not monolithic. Modular architecture enhances maintainability and ease of deployment. Cases within an application should serve a common purpose. This is somewhat related to the "S" in the five OOP SOLID principles, i.e., Single Responsibility. The definition of "common purpose" though can vary depending on someone's role. Having two applications that write to the same class group / work pool class might be problematic from a User Experience perspective. It is not necessary to force users to switch between applications to work on inter-related case types. Pega has multiple ways to enforce who can do what with which case types within the same application - no need to switch. It is possible to have a "wrapper" application built on some application where the "wrapper" application does not define its own workpool class and class group. Instead the "wrapper" app simply inherits the built-on app's workpool class and class group. If the number of case types is large, and each case type exposes several uniquely named properties, the number of columns in the work pool table would get large. This could potentially be a concern. Regarding: "report on descendant property", Are you referring to "report on descendant class" instead? This feature works the same as it always has.
@baeyw Applications should strive to be modular, not monolithic. Modular architecture enhances maintainability and ease of deployment. Cases within an application should serve a common purpose. This is somewhat related to the "S" in the five OOP SOLID principles, i.e., Single Responsibility. The definition of "common purpose" though can vary depending on someone's role. Having two applications that write to the same class group / work pool class might be problematic from a User Experience perspective. It is not necessary to force users to switch between applications to work on inter-related case types. Pega has multiple ways to enforce who can do what with which case types within the same application - no need to switch. It is possible to have a "wrapper" application built on some application where the "wrapper" application does not define its own workpool class and class group. Instead the "wrapper" app simply inherits the built-on app's workpool class and class group. If the number of case types is large, and each case type exposes several uniquely named properties, the number of columns in the work pool table would get large. This could potentially be a concern. Regarding: "report on descendant property", Are you referring to "report on descendant class" instead? This feature works the same as it always has.
Similarly standard OOTB reports also still work fine. Those reports can be defined generically yet still filter on pxRequestor.pxCurrentWorkPool.
Pegasystems Inc.
FR
Hello @pedel,
Thanks again for your response.
Yes, I was referring to the "report on descendant class" feature.
I still have a hard time understanding why keeping cases in the same class group is the default way of doing things.
If I understood you correctly it means that basically only OOTB reports are impacted. So even if SOLID principles are followed and the application handles a single responsibility. The only "Pro" of keeping all was in the same work-pool seems to be for OOTB reports to work on the "whole" work-pool. while the list of Cons is a bit lengthier :
- Archival and purge is more difficult
- Performances for any report on the work pool for a specific case are worst.
- The risk that the table ends up with a very high number of columns because of property optimization is higher.
If I'm not missing anything critical then shouldn't the right approach in any project to separate every case type in different class groups by default except when it makes sense to keep them together?
Kind regards.
Pegasystems Inc.
US
@baeyw A "pro" of have a Class Group exist by default for a work pool class is not having to define a new Class Group and work table for every case type - the new case type gets added to the existing work pool / Class Group automatically. In customer service systems it is common to persist interactions and service items/intents in separate table optimize IO for large call centers.
Factors to consider are:
- # of case types
- How distinctive is each case type?
- Are all / many case types handled by same LOB / Business unit?
- Expected volume per case type
- Data retention / data lifecycle
Few case types; high volume; highly distinct; processed by different LOB’s unique tables
Many many case types; low volume for individual type; less distinction; processed by same LOB -> One case table
The truth will be somewhere in between. :- )
Pegasystems Inc.
FR
Thanks a lot, I'm now at least more confident (and vigilant !) for future designs.
I still believe that in most cases the risk of putting all case types "by default" in the same class group is much greater. This aspect of the design is not really "mainstream" and most of the projects I've seen or discussed with colleagues have a very poor class-group design. I think the probability of regretting "after the fact" that cases are in the same table is just higher than if they are in separate tables. This goes a bit in the direction of an LSA friend: when in doubt you just separate all case types in different tables.
I do agree and understand that it's not a one size fits all approach and of course it should be adapted to the client's need.
Thanks again for your patience and thorough explanations :D.