Question
National Account Service Company
US
Last activity: 23 Apr 2021 9:02 EDT
Running a DSM with another CDH application
Hello,
Can someone please clarify if we can have a DSM Pega application running in the same instance that is also running a CDH application?
I did a small POC where i built a CDH application with a context dictionary and a simple DSM application with Data flow and strategy flows. Both the applications are running in the same host instance. I was able to get that running without any issues.
Will there be any issues that we run a DSM application in the same instance where a CDH application is running? Appreciate some information and feedback on this.
I did see a post where it was confirmed that only one CDH application can be run in one host instance. We cannot have multiple CDH applications running in one instance.
https://collaborate.pega.com/question/context-dictionary-multiple-applications-same-environment
Thanks,
SG
Pegasystems Inc.
IN
Can you please elaborate on why do you need a separate DSM app apart from CDH?
National Account Service Company
US
@RaghuShankhawaram We are building a seperate DSM application that we are building as a product and deploying at a customer site that already has another CDH application running.
We cannot merge our DSM application into that CDH application, as that will involve additional development and cost for the customer. To avoid that cost and to enable our DSM application can co-exist with their CDH application, we prefer to deploy our DSM application independently.
Can you confirm if we can have a DSM application deployed in an instance that already has another CDH application. Do you see any issues or concerns with that. If yes, appreciate if you can list them.
Does by having a DSM application in an instance that already runs CDH application create any kind of technical architectural issues in the Pega Platform or CDH?
Thanks, Swami
Pegasystems Inc.
US
@SwaminathanG8419The best (and supportable) practice is always for a CDH system to reside in its own Pega Cluster, not mixed with other Pega applications, whether they are DSM applications, Customer Service applications, or any other type of Pega application.
The reason for this is that a CDH should be expected to be upgraded at least once a year, if not even more frequently (releases typically come out 2x per year), so Pega can provide new functionality and improvements on a regular basis. Since Pega Platform and CDH versions move in lock step, upgrading CDH requires upgrading Pega Platform, and if there are other applications deployed in the same Pega cluster, this upgrade will require ALL of those applications to be upgraded (and regression tested). In practice, we see this leading to increased upgrade costs for those other applications, which leads to upgrades only being done every few years, which leads to outdated CDH versions being used, which leads to missing out on new capabilities that clients (and their end users) need. For this reason -- removing any possible obstacle to frequent painless upgrades -- are the primary reason why we strongly advise against attempting to "mix" other applications into running on the same Pega cluster that is hosting a proper CDH application.
@SwaminathanG8419The best (and supportable) practice is always for a CDH system to reside in its own Pega Cluster, not mixed with other Pega applications, whether they are DSM applications, Customer Service applications, or any other type of Pega application.
The reason for this is that a CDH should be expected to be upgraded at least once a year, if not even more frequently (releases typically come out 2x per year), so Pega can provide new functionality and improvements on a regular basis. Since Pega Platform and CDH versions move in lock step, upgrading CDH requires upgrading Pega Platform, and if there are other applications deployed in the same Pega cluster, this upgrade will require ALL of those applications to be upgraded (and regression tested). In practice, we see this leading to increased upgrade costs for those other applications, which leads to upgrades only being done every few years, which leads to outdated CDH versions being used, which leads to missing out on new capabilities that clients (and their end users) need. For this reason -- removing any possible obstacle to frequent painless upgrades -- are the primary reason why we strongly advise against attempting to "mix" other applications into running on the same Pega cluster that is hosting a proper CDH application.
For clarity, the meaning of "CDH" (Customer Decision Hub), since version 8.5 release in Fall 2020, refers to the modern NBA Designer driven CDH application. Historically, many people thought of "CDH" as referring to DSM (raw Decisioning / raw Pega Platform), which is why we take an extra moment to clarify what the product name, CDH, now refers to. Hopefully this helps clear up the topic -- and thanks for taking the time to ask!
National Account Service Company
US
@peres2 Thanks Shoel. So what this means is, even though architecturally and technically it is fine to have a DSM application running in an instance that already has a CDH application running. But from an upgrade path for both the applications, it can create logistical issues. A CDH application will get automatically upgraded when the underlying CDH engine and platform is upgraded, the other DSM applications in that instance will have to be manually upgraded and regression tested. To avoid that issue, it is recommended to have a CDH application running in a dedicated instance/cluster and not share that with any other Pega applications.
If we upgrade our DSM applications as well when the Pega platform and CDH engine is upgraded, I would assume that should resolve the above issue.
Is that a correct understanding?
National Account Service Company
US
One more thing, the tech stack is Pega 8.5 with CDH.