Posted: 18 Dec 2018 15:58 EST Last activity: 6 Jun 2019 18:30 EDT
Application structure /ECS
Assume that Org1 wants to build workflow platform to serve its client 1, client 2 ...client n
There are some predefined generic workflows and business rules. Org1 want to maintain client 1 case data separately and don't want to mix it up with other clients. Also, Rep is going to work on one client at a time.
Please suggest an approach to solve the issue.
Solution 1: Have a Framework application and then separate client application built on a framework.
What are the disadvantages of solution one approach?
Here Org1 framework can be maintained with genric flows and business rules, Client1,Client2...Clientn can be treated as divisions and can have seperate divisional implementations with their specific data.
My experience on building a similar project with similar approach you mentioned.Initially when we start we assume there is no workflow customization and over the period things will change and we tend to customize workflows or other artifacts at the implementation layer. Some of the pain points with this approach
1) if you allow workflow customization for each client then it will become difficult to maintain and need more dev resources
2) Regression testing each client needs more testing resources.
3) Onboarding a new client needs Development effort unless you build wizards to setup the client.
We re-wrote the same application after 10 years running the application in PROD with just building the framework layer and use ABAC to secure data , reporting and allowing little bit of customization like Correspondence
Curious what is meant by "just building a framework layer" yet deployed to Production? Then it would also be the implementation layer.
The original requirement sounds like a multi-tenant situation - Data separation within the same database. This is a possibility depending on your business model. The "boutique" business model can be appropriate for mid-size consulting firms. For example in the US there are firms that support boutique 401(k) retirement plans.
If security is the primary reason for clients wanting case data stored "separately" the client should be assured that Pega supports multiple ways to enforce data security such as RBAC and ABAC. In the same database only case data would be stored separately, data classes such as assignments would still be stored in the same table.
I have never heard of anyone doing anything like that with Pega, i.e., the same PegaRULES Schema used by different applications that utilize a different PegaDATA Schema. That would only work if you have different tables that could then be mapped to a different schemas but to do that you need different class names for everything, not just case types.
Separate databases are fine but this entails having to support multiple production environments.
In my scenario, yes you can call it as implementation layer because that's where cases are being created, but we call it as framework layer, thinking towards future of the our business if we have to implement for different regions / clients where there will be a significant workflow customization.
I also have the same problem/situation. Basically, I want one common layer for all of my clients but I want to be able to select different requirements/modules for each client. The rules I want to give to each client will be different and also the data shouldn't overlap. According to your post, are you saying it is possible to customize in the same application what is given to each client? Can you explain a little more on the process or point me to where I can learn more about configuring whether a part of the application will be given to a specific client?