My preference here would be to go with option 1 if the SOR is only used to read the data from. This create one DO for completeness while isolating underlying data segregation across systems, something needs to be taken into account during configuration. Also specifying reference to another SOR in the notes and adding the same SOR in the Blueprint is very important, not only it adds to the overall fidelity but the SOR info is accounted for when estimates are produced using the Blueprint.
Approach 2 is more suitable if these SORs are also being updated from Pega where the sources have different data refreshes etc. This also gives you the isolation but then would require some kind of business entity to wrap the data which then can be used be the application.
I would consider above points to determine best suitable option as both have their own merits.
Thank you @Amey Thombre for the thoughtful perspective. I agree with the rationale you outlined, and I would like to add an important clarification based on how Blueprint and Blueprint Import behave today.
While Option 1 is indeed preferable from a modeling standpoint, it is important to note that Blueprint currently generates integration assets only for Systems of Record that have at least one Data Object explicitly tagged to them. Simply listing a secondary SoR under “Systems of Record” or documenting it in descriptive fields does not result in an Integration System being created during Blueprint import. As a result, the second integration will not appear in the generated application.
Because of this, Option 2 may appear beneficial for sizing purposes, since each SoR is recognized independently; however, it also introduces duplicate Account Data Objects that must be manually reconciled and merged after import. This additional cleanup often outweighs the benefit of more explicit sizing.
Given the current behavior, Option 1 remains the recommended approach for scenarios where the secondary SoR is “read‑only” meaning it exists solely for documentation purposes and is not tied to a Data Type. It preserves a clean and canonical data model and avoids post‑import model consolidation, while still allowing teams to account for the additional integration effort during estimation and implementation.
Here is my perspective: you have two different SORs and likely two (or more) services that you will be calling to retrieve your content. You typically need one data class for each service call you are making and you will typically have at least one data page that is executing the service call.
From a data modeling perspective, I would identify which entity you are loading first and which you are loading second. Let’s say you have a GetAccount service that you pass an account id to and it gets you your customer demographics. Then you have a second service call that retrieves more account details or a list of transactions or the like. The second service uses data from the first service call (account id for example) to make the second call. Structurally, I would build an account class, and then I would create that second class for retrieving the extra content. I would add the second class as a page property to the first class intending it to be a data reference passing the id from the first to the second as part of that reference.
So, short answer, one class per service called, excepting the circumstance where you have a getSingleService and a getListService both returning the same content. Those could have the same class, just different data pages.