The CLSA Architecture Application Build exam consists of 3 to 6 questions of varying complexity which evaluates the ability of a candidate to develop and architect solutions using the PEGA platform. Please refer to the Exam preparation guide for further details.
A question from a retired exam scenario is attached to this post. You are encouraged to work through this question by collaborating in this discussion thread. A solution will not be provided.
No. In this exam scenario there are a total of 6 questions, each varying in complexity level. Case Design and process flow only cover a portion of the overall capabilities of the PEGA Platform. Since it is a 3 day exam, only a subset of the overall capabilities are tested. Please refer to the Exam Preparation guide for possible areas in which questions will cover.
Attached you can find a brief document and a migration package (renamed from .jar to .zip in order to upload it).
I couldn't dedicate to it 7 straight hours so i worked on the scenario here and there when i had free time. I think it took me about 8 hours or so. One challenging aspect is to decide how much implementation include in the package. I feel like striking the right balance between available time and clarity is going to be difficult.
Is it going to be a confrontation between the examiners and the examinee before evaluation is made? I feel like some point may be hard to communicate otherwise.
Please note that the submited package has some glaring "bad practice", like open ruleset, no checkout enabled and unjistified warning. In the real exam i would release closed ruleset with checkout enabled and a few resolved or justified warnings just to communicate that this is an aspect being considered and not forgotten
This is a good effort. The one thing that might be questioned is that you are recommending different applications for each sport. At its heart the Wagering application manages contests that involve a sport but does the sport itself dramatically make a difference as far as how to manage a contest? Could circumstancing the case type rule on the selected sport suffice? Or perhaps would using pattern inheritance against the case type class, e.g., -Sport, be sufficient? A completely separate application typically means a different set of users are being supported.
@pedel Is there any cons of using pattern inheritance or circumstancing approach. I really can't think of any with the pattern inheritance. Circumstancing get difficult to manage if a number of rules required specialization is high.
Circumstancing does become cumbersome if overused. It is fine to use circumstancing for a small number of specializations such as the way Pega specializes SQL Functions for different databases when necessary. A benefit of using circumstancing is that avoids having to define new classes.
When you have a LOT of specializations for the same thing, different types of rules especially, it is easier to manage them using pattern-inheritance.
I'm curious about the level of implementation expected. I essentially created my case types, defined their parent/child relationships, and added stages and steps into the lifecycle. I put a comment on each step to explain what it does in detail for clarity. I edited the flow rules independently in several cases to implement requirements that couldn't be done on the case workflow tab -- such as decision shapes, integrators, etc. I created only a few properties as required to save some SLA rules that demonstrate critical functionality -- for example, I used an SLA on a flow to advance the stage to "close" the ability for a contestant to make selections.
Should an implementation include anything beyond this? Do we need to mock up wireframe views or is something like a collect information step called "Select Participants" fine?
Thanks for taking the time to provide a well thought out solution.
Judging by your description above, you have provided the appropriate level of implementation required for this particular question assuming that the stages, steps and flows are sufficiently documented to communicate the functionality. This case design question would have been overly challenging to implement a fully functional solution considering there are several additional questions to answer. Some candidates submitted solutions which attempted to implement a fully functional application. This was not warranted for this question and came at the expense of not fully answering the other exam questions.
Please keep in mind however, that other exam scenarios may require you to create a functioning application. This will be indicated in the deliverable section of the question.
We attempt to set the level of implementation required in consideration with the overall challenge level of all questions in the exam. For example, this exam had 6 questions therefore it was not suitable to require a fully functional solution. Other exam scenarios have 3 or 4 questions, therefore we may indicate that a functioning application would be required. This is indicated in the deliverable section of the question therefore please read this section carefully to determine the level of implementation required.
General comments on your documented solution are that it was well documented and clearly displayed the thought process which supported your design particularly in the areas of cases. A quick estimate on your score for the design question would be 90%. Some comments are:
- Excellent consideration of the cases as this is the main challenge. The discussion was focused on that while also expanding to cover the additional areas to consider.
- You have documented the data objects, however it is difficult to visualize what the relationships would be between the data objects / cases and how they would satisfy the reporting requirements. A simple diagram indicating the high level relationships between the data objects / cases may help, and it would break up the wordiness.
- Some decisions were not convincing, such as the placement of the Selections case under the Enrollment case.
I want to emphasize the following point which should be mentioned for the benefit of other exam candidates (which doesn't apply to this submitted design as it was very well done) : Too often, candidates will generate a design in their head, implement it and just document their provided solution without providing the full rationale to support their design. This would lead to a poor score for the design question as it does not give the grader any indication on the scope of the candidates consideration when determining an optimal solution.
As James stated, it is not necessary for your design to be ideal to score well. Proof that viable alternatives were considered provides an indication that you could be "well on your way" to discovering the ideal solution.
Building a solution that is not well thought out can be counter-productive depending on the amount of refactoring needed to "turn it around".
Regarding design, modeling the "real world" typically leads to the best outcomes - that why it is called object oriented programming/modelling.
A real sporting Tournament starts and ends, has players, etc.. Every Contest that involves the same real Tournament does not need to fetch the Tournament’s data - a model representing a real Tournament only needs to do that once. In reality, there is a Many-to-Many (M:M) relationship between Contests and Tournaments.
A Tournament does not need to know about Contestants except through the data that the Contestant enters about that Tournament in relation to a Contest. Data entry can be accomplished using a customized portal. A case is not necessary, but data entry enforcement is.
Tournament ( Sub case of Contest) – Each contest have 1 or more tournaments
Enrollment (sub case of Tournament) – Each Tournament can have 1 or more contestants- We have guidelines that Contestants can register one week before each tournament, Auto approved if registered within 2 days before tournament, Contestants will be notified the list of players 4 days before the tournament.
Selection– is a sub process in Enrollment case type.
However, there is no requirement explicitly stated that same contestant should participate in all Tournaments for the contest. Also, Contestant enrollment is dependent on the first Tournament start date. As I understand that we are focused to build the MLP first, but we may have to think in advance about the application needs to be extended as feature requirements grows…
What happens if we have the reporting requirements in the future to publish the list of contestants and their team of players along with Tournaments by end of each contest.
What happens if there are requirements to add/modify the contestants in the feature for each tournament?
What happens if there are SLA requirements for each contestant to pick their players before the start date of each Tournament.
Here is what I visualized, so feature requirements could be easier to implement rather than redesign.
Constest – Contest Manager
Tournament – Contest Manager
Enrollment/Contestants – Contest Manager will approve the contestants, Contestants will pick their players during the selection process.
Recently I received the following proposed solution for the Wagering Application. I received this proposal from a CLSA Candidate Preparing to Take the CLSA Application Build Exam. I am presenting it here so I can share my feedback with other CLSA candidates:
Recommend Design Approach.
The best case design solution in my opinion is to have a parent Contest case that spins off a Tournament subcase for every Tournament approved by the Contestant Manager. In addition, an Enrollment case would spin off as subcase for each Contest.
Key Influencing Factors:
Reporting needs related to Each of the Tournament.
Can easily handle Extensibility & Specialization for other sporting events.
Using Dependency Management processing can be easily controlled between Contest(Parent) and Tournament & Enrollment (Sub cases) cases.
Enrollment process can be different for other sporting needs, Having it as a sub-cases would help resolve the issue.
Class-based security offers more options for security refinement using multiple cases.
Data security increased as subcases only contain data pertinent to their case
General Assumptions: Application would be extended for other sporting needs very soon and is a key requirement.
Design(s) Considered But Rejected:
1. Each Tournament can be part of the Same case processing using a Split-for-Each approach. However Security needs & Extensibility for other sporting needs will be complex with only limited options.
2. Enrollment can be part of the Main case and we can use Split-for-Join approach.
Recommend Design Approach Detail
The list of tournaments and their start dates is received by the Contest case, Contest Manager determines the tournaments included in the contest.
A week before the First Tournament a Case step type is used to spin off a Tournament & Enrollment sub-cases and send email to Contestants informing of Enrollment.
Contest case will spin-off additional sub-cases based on the list of approved tournaments and corresponding dates.
Case Designer-configured Data Propagation is used to send Start Date Information into each spun-off Enrollment and Tournament case.
Within the Case Designer, Tournament & Enrollment cases are configured as “Do not lock parent case” which allows Multiple contests run simultaneously, independent of one another.
Golfers Information is retrieved from each Tournament case.
A day before the first tournament Enrollment is closed and the case is resolved.
End of each tournament, results indicating the money earned by all golfers will be retrieved and info will be shared with contestants and resolve individual tournament case.
Once all tournaments related to the same sporting event for the year end. The parent contest case will resolve.
Why a sub case approach makes sense:
Both Tournament and Enrollment cases will be resolved before Parent Contest case can be resolved.
The reporting needs of the Context and Each of the tournament can be easily handled and offers better performance.
Security restrictions between each of the cases can be easily handled.
Option to Specialization for other sporting events.
Sub-cases allow pure parallel processing since tournaments cases from other events may be accessed using a separate requestor without any Issues.
Alternate Solution #1
As opposed to spinning off a subcase for each Tournament in a Contest case, a Split-for-Each shape can be used to spin-off a sub-process.
All Data i.e., regarding Tournaments, Golfers, Contestants is readily available.
All Data belongs to the same case and is accessible for reports.
Tournament-specific data propagation is configured via the Split-for-Each shape.
There is no need for case-to-case Data Propagation.
Since no 2 tournaments of the same sport occur at the same time, locking would not be a problem for the current sport(golf).
Enrollment too can be a Sub Process using Split-for-Join approach.
Primarily because of extensibility and security restrictions in one approach and flexibility in the other I choose the other approach over the same-case approach.
My recommended solution meets today’s needs at no extra cost. Over time, this simpler-to-maintain design will lead to cost savings. Extensibility, Specialization and Security flexibility is both simplified and maximized.
The following is a simple diagram of how I understand the Case Structure for this proposed solution:
Contest Parent Case (Parent Case)
Tournament (Sub Case) Per Selected Tournament
Enrollment (Sub Case) Per Contestant
This is a valid design approach. However it has one minor disadvantage. Duplicate Tournament cases would be necessary for each Contest that involves the same Tournament. For example, if two separate Contests managed by two separate Contest Managers select the same Tournament (say, "The 2019 Safeway Open Napa, CA - USA") then that Tournament would be represented as two separate subcases as follows:
Contest 1 (C-1) (Parent Case) (Managed by Contest Manager 1)
Tournament (T-1) (Sub-Case) ("The 2019 Safeway Open Napa, CA - USA")
Contest 2 (C-2) (Parent Case) (Managed by Contest Manager 2)
Tournament (T-2) (Sub-Case) ("The 2019 Safeway Open Napa, CA - USA")
Since the process of collecting and tabulating the results of all the Golfers participating in a given Tournament does not change this design means that the logic for resolving and closing each Tournament would have to be repeated for every Tournament subcase created for each Contest.
One way to avoid this duplication of logic would be to create Parent cases for Each Tournament and a separate Parent Case for Each Contest. Each Contest Case would have Enrollment Sub-Cases per Contestant and Maintain a simple Page List with references to the selected Tournaments for that Contest:
Tournament (T-1) (Parent Case) ("The 2019 Safeway Open Napa, CA - USA")
Contest 1 (C-1) (Parent Case) (Managed by Contest Manager 1)
Enrollment (Sub-Case) Per Contestant
Page List (Field Group List) of Selected Tournaments
Among all exam questions, I found the case design of question 1 most challenging, primarily because it is hard to judge how much details we need to provide to justify my design choice. Relatively, other questions with coding tasks are much simpler to implement at least for me. The attached is my solution for this question. Please kindly take a peek to see how I should score with this solution.
Your review will give an idea whether I am ready and how i should fine tune my strategy. This question took 10 hours mostly on wording the design.
In reference to ERD diagram, something not mentioned in the 7.3 LSA course, but perhaps will be in the next, is the Law of Demeter.
If you strive to define only one path to navigate to an object you will end up with a more object-oriented design due to separation of concerns, single responsibility, encapsulation, etc.
Take for example your Enrollment case/object. An Enrollment case does not need to know anything about a Tournament or have a PlayerList. An Enrollment case only needs to know what Contest it is enrolling in and the deadline by which to enroll. The Enrollment case can ask the Contest what Tournaments are included in the Contest. The Contest can also act as a Proxy to each Tournament to retrieve its List of Players.
A Contestant’s post-enrollment selection of Players per Contest Tournament is purely Data. That data would contain the keys to the Contest and Tournament, Contest and Tournament having a M:M relationship as you have shown in your ERD diagram.
As for your Application Structure, I would question the need for a framework layer. MyCo’s business is based on hosting Contests. What sport the Contest involves is secondary and could be handled by specialization techniques well within Pega’s capabilities without having to resort to a complete separate Application per sport. Just because MyCo’s Business wants their initial Minimal Lovable Product (MLP) to support golf tournaments does not imply that every future release that involves a new sport should be a new Application.
What is missing from you Application structure is an enterprise-wide reuse layer. With your design, if MyCo wants to develop applications for purposes other than Contests, e.g., a Marketing, Sales, or Billing application, those applications would also need to be built on your SportsWager FW layer, which does not make sense. If, however, the generic Data classes for Contest, Tournament, Contestant, etc., are included in an enterprise-reuse, COE-manager application layer, then any application, not just SportsWager, can leverage those Data classes.
Your first “pro” for having an FW layer is “Maximize reuse of rule and promote COE”. If you were to remove “-FW-“ from your design document, that statement would be unquestionably accurate.
Also you have mentioned sportype in your data model to capture what type of sport it is and then your class structure is contradicting as it clearly talks about just Golf which means we need to go for another class structure if we have to acomodate any other sport.
If there is a need to implement behavior specific to a particular sport you can specialize the base Data class that represents $ANY sport. The rest of code in the Application should only know about the base Data class unless also specialized for the same sport.**
You can use DCR to change the base Data class to be sport-specific, e.g., MyCo-Data-Sport-Golf to then add properties that are golf-specific.
You can do this with case types as well, e.g., MyCo-Wager-Work-SportContest-Golf .
** The above golf-specific case type can assume that the sport Data class is MyCo-Data-Sport-Golf, and vice-versa.
Note that the more generic term "SportContest" was used in place of the word "Tournament", The word "Tournament" is applicable to individual-player sports such as golf, tennis, chess, etc. The word "Game" applies to team-based sports, i.e., cricket, soccer, etc..
If you wanted you could use that as a distinction within the class hierarchy, e.g., My-Data-Sport-Team vs My-Data-Sport-Individual.
The behavior of a wagering contest case can also change based on the selected sport. For example you can use DCR to change wager contest case's class to MyCo-Wager-Work-WagerContest-Golf.
Please let me know if the following Case Design Approach makes any sense and whether reasoning behind the approach is well supported.
Contest and Enrollment have 1:1 relationship (each Contest can have only One enrollment).
So both Contest andEnrollment can be Case Types.
Tournament details are just Data. There is no process involved, so creating a case type for tournament is unnecessary. It can easily be combined with other case information to present Details Per Tournament in a UI. For example- Portal for Contestants can have a repeated Grid UI for each Contest they have enrolled into and each grid can present 360 view of Tournaments' details combined with contestants' and their opponents selections of golfer(s),results etc.( UI can be a Collapsable section/Modal Window/ Link etc can be used). We can show and hide certain details based on tournament's Start and End Dates. such as selection of golfers/prize Money/Tournament results etc.
Selection (golfer) involves process & SLA dependency, so it can be a child case of Contest. Each Selection case is created at different intervals based on list of Selected tournaments and their start date.
Based on above analysis following is the recommended approach:
A Tournament is definitely Data. It is the "system of record" for its start and end dates.
In your design it appears that each Contest takes a snapshot? of each Tournament's start and end dates, then uses those datetimes in SLAs. The first SLA is used for selection cut-off, the second SLA is used for results capture.
It is possible for a Tournament to be postponed due to weather, unlikely, yes, but possible.
A 7.X Advanced Agent or 8.X Job Scheduler could look at the Tournament data to advance every Contest case waiting for that Tournament to start and end. No need for redundant SLAs.
Thanks for your response @PEDEL. No it's not a snapshot. I just wanted to highlight work classes. I should have used ( ) rather than [ ]. Also, thanks for pointing out the possibility of tournament being postponed. My initial thought was using SLAs for initiating Enrollment & Selection cases based on dates, and use an Advanced Agent (as you mentioned) to evaluate each Tournament results as and when they are available and finally to resolve the Contest case after evaluating overall Contest Results.
As you mentioned, it is possible for a Tournament to be postponed due to weather, Advance agent is indeed a viable solution.
I also hope giving contestants a portal with 360 view of each enrolled contest is better design than giving review only access to individual Contest Cases.
I have tried answering the question and attached my design document.
I have also created an application with basic process flow steps but have not included any properties or defined SLA and other minor details.Wanted to understand if we would need to do more in terms of build or just create a basic case and class structure to supplement the design document.
Would be grateful if somebody could review it and provide some feedback on the same.
Your suggestion to use case type pattern-inheritance is a good one.
An advantage of using pattern inheritance is that you can leverage the Case Designer within the same application to define the abstract, reusable portion of a case type.
At the same time within the same application the Case Designer can be used to define how the concrete, pattern-inheriting case type classes are specialized
Remember, in development mode you can do whatever you want with an Application rule as long as it does not impact how the Application operates in Production. For example you can define a development-only Application built on your Production Application. The development-only Application can do a number of things besides contain test rulesets.
My recommendation is to not spend a lot of time discussing an alternative that is not a good fit, especially if it is the first idea presented. You started out talking about the possibility of having a framework layer across every case type in the application.
If this is something you are not going to recommend, then simply summarize why and move on to talking about what do want to recommend.
This is how an "argumentative essay" should be written. You want to "sell" your recommended idea. The more you talk about something you do not recommend, the less time your audience hears about what you do recommend. Plus, audience interest tends to fade when listening to negatives, especially if you start out talking about negatives.
Back to the idea of having an "abstract, reusable portion of a case type" from the beginning. This avoids pushing reusable rules to the work pool level. The Application rule, application-level Data classes, and work pool class, IMHO, belong in their own separate ruleset and case types should have their own separate ruleset.
If you do not start out like this and later realize that the "abstract, reusable portion of a case type" could be converted to a built-on Component application, you do not then have to deal with pulling rules that are used out the work pool class
Keep dependencies to a minimum. The same applies to Data classes.
You can reference Data classes from the next layer down, e.g., the Enterprise layer, then use DCR to get at application-level Data class overrides.
If properties have been added to application-level Data classes and those need to be used, fine. Application-level case type code can reference those application-level Data properties. At the same time using direct inheritance, application-level case type code can leverage code from a built-on Component application.
This is the same as what occurs when a framework is used. The difference is that a framework typically spans every case type within the Application.
Components are modular. They can be reused by other applications. Design Patterns are reusable. A Design Pattern consists the minimum number of classes possible to implement a certain type of functionality.
Besides too much detail about the framework option you also included multiple screenshots of your build's Case Stucture. You called it "Case Structure as designed", This is after-the-fact documentation; a grader can see this for themselves. You had already described your case structure verbally highlighting key aspects of the design.
The Data Model diagram is great. Would prefer that the class names drop the word "Wagering" to allow other applications to use those classes. You did use generic class names and properties for the most part, nothing truly Golf-specific, which is good. Not every sport has "prize money" and "Tournament" typically applies to individual player sport. Basketball is a team sport but there are basketball tournaments. The enterprise level Data classes could be specialized at the application level. The Tournament Golf case specialization could leverage a Golf-specific Data property for example the golf course name, number of holes in the golf course.
Perhaps mention whether the relationship is aggregation (embedded) or assocation. One could mistake Contest as having an embedded Page List of Tournaments (SportContest?). That is an M:M relationship also. This was not indicated in the case design. You show Contest and Tournament as sibling case types but what is the relationship between them?
You can mention Email as something that can be a Component but that is something straight out of the course. What is more challenging is to mention the possibility of a new and unique Component. Perhaps whatever it is that collects tournament results could be made into a reusable Component. You do not have to build it out. Mentioning something creative helps keeps a Business reader's attention, especially if it is something that would differentiate them from their competition, i.e., give them a "leg up".