We have a requirement for a customer who is willing to build a Pega Customer Relationship Management suite of applications which would comprise –

1. Pega Customer Service for Insurance
2. Pega Sales Automation for Insurance

The customer has also expressed an interest in leveraging the concept of “Shared Service Cases” - For example, Pega Sales Automation operators can process Pega Customer Service cases, and Pega Customer Service operators can create and update sales leads and opportunities. This concept is already available as a product feature for Pega CRM Suite. The customer also wishes to perform actions on the Leads/Opportunities assignments from the Interaction portal itself and vice versa.

In order to build a robust architecture keeping in mind the future business changes  – We have come up with 3 different application architecture approaches. Need suggestion on which one to go for – as the user base for the streams (CS and Sales) might be the same?

Option 1: This option allows to build a custom implementation application that is built-on 2 native Pega applications, with the flexibility to extend the OOTB case types and meet the business requirements. This option also allows sharing of common data and services. However, this implementation has a disadvantage that if down the line the customer wishes not to use either of the services (Customer Service or Sales Automation) restricting the features will be a challenge.

Option 2: This option allows to build, 2 different implementation applications, one for the Customer Service (MyCustomApp-CS) and the other for the Sales Automation (MyCustomApp-SA), and then link them by creating another implementation application (MyCustomApp). This will allow the respective developments to stay in respective applications while the 3rd implementation application (MyCustomApp) will only be used by the higher management users to view the progress (reports etc.) for their organization (the data for which will be fetched from the underlying built on applications). This application (MyCustomApp) will not have any case types extended. Customization of case types will happen only in the respective applications (if any). The common data and services will be shared across MyCustomApp-CS and MyCustomApp-SA by using "Shared Rulesets" and "Integration Rulesets". This approach has the advantage that if in the future the  customer wishes not to use either of the services (Customer Service or Sales Automation) we can restrict the features/rules

Option 3: This option is similar to "Option 2" but the 3rd Implementation application will not be created. A separate portal will be created for the higher management to view the progress which will point to either of the application and data for the other application will be fetched via services.