Can a Module also be a Component Application?

Do you see a Module as Pega Component or Pega Application?

Are Accelerators and Business Rules blocks implemented as Applications?

Module is the term Pegasystems is using to refer to a reusable feature set made available for enterprise applications to build on.

LeasePlan preferred the term Accelerator to refer to the same concept. For the purposes of this webinar and Q&A, Module and Accelerator refer to the same concept.

While a Module could be implemented as a component application, Pegasystems recommends implementing Modules as regular Pega Applications that are referenced as a Built-on Application for an enterprise application. 

I have used Framework layers to provide a central place for reusable assets like flows, sections and connectors. Is a Module like a Framework layer?

Can you share an example of when to use a Built-on Application compared with a Component Application? 

Can a Module be implemented as a Component Application?

What advantages does using Modules bring compared with Components?

Pegasystems recommends implementing Modules as a Built-on Application. Drawbacks of Component Applications include:

• They cannot handle work types;
• They have deployment limitations when using Pega Deployment Manager

Automations are another technique in packaging reusable functionality into a Module.

Along with Flows and Smart Shapes, Automations make reusable functionality easily available in App Studio to configure a user-facing application.

Yes. In addition, the Module is usable without any additions in the business application.

The Business Architect should be able to configure more of the user-facing application in App Studio by including features available from the Module. 

Can you give an example on what is a suitable candidate for a "Process" defined in a Module?

I am used to Process rules being tightly coupled to specific case types with a very specific business purpose

An example is a "Get Customer Details" process. This process can:

1. Check the Customer system of record for whether the Customer data is available, 
2. Provide standardized error handling if the Customer data is not found.

Process rules that implement a feature in a Module may be more technically-oriented. Process rules are a convenient way to make a feature available for selection in App Studio by the author of any case type that depends on it.

What purpose does a single application built on multiple Module applications serve?

Are there multiple applications for each business domain which build on a single enterprise layer?

Are Customer, Quote and Finance separate Module applications?

Yes. Each are implemented as individual Pega applications, made available for user-facing Pega applications to reference as Built-on applications.

Modules may contain a set of functionalities related to the Customer, such as Accounts, Contacts / Relations, Addresses.

If there is functionality related to Customer that should be available to whichever user-facing applications used Customer functionality, then it would make sense to package that related functionality into the one module.

Both use standard Pega rules.

• The Module is more on features around an Business object, such as data pages and integrations;
• The Business Rules layer is orchestrating usage of these features.

Are Modules fully isolated?

Do you duplicate rules from the Module, or reuse the Module rules in place?

Modules are indeed isolated. Any accelerator should be plug-and-play. as it resolves around business features. We do not have duplications.

There is an enterprise data model in the enterprise layer that the Modules are built upon. Modules can inherit and extend the data objects provided by the enterprise layer. 

We had a few data objects (for example: Person, Address) on the enterprise layer; while there were others defined for the first time in a Module.

How to handle the data dependencies between different Modules?

For example, if the Contract Module needs to use a data class from the Customer Module, how to decouple the 2 Modules?

• Unit testing: the lowest level of testing to reduce the number of process error
• Process testing
• External tools which ran the process via the Constellation SDK

Rule engine performance behaves the same as standard ruleset-stack. Skimming remains advisable after Production releases.

If the client has wireframes, then we can use them.

If wireframes are not available then we can use the DCO sessions and see it directly in Pega already.

If you are building features in Modules, yes.

However the Business Architect can start with a process and the System Architects can replace a certain step with a feature built in a Module.

System Architects and Business Architects work in close collaboration.

How do you segregate the responsibilities for who builds the features in the Modules, and who builds the user-facing applications?

The features are built in an the Module application. We started per project to build these into Modules, and the completed features were always merged by the responsible LSA.

We are now moving to a central, CoE build team for Modules now that we have a lot of features.

At the start of the LeasePlan project we had LSA's training the different developers on the new way of working. We now have:

• A 3 day training now for new team member enablement.
• Design and Build reviews to monitor adoption.

We started with one team being responsible for each Module.

As a Module becomes more mature, the maintenance is handed over to the Pega CoE.

A Module is authored in one single environment. We use different pipelines in Pega Deployment Manager to move Modules between the different (development) environments. A prerequisite is that the artifact repository can be accessed by all enviroments.

In the past, we have tried to use App Studio but have found that rules authored there got saved into the case type class. Even when using branches, App Studio saved into the top-most branch in the application.

How do we better influence the class and branch of the rules authored in App Studio?

Use Branch Development Preferences to control both:

• Which of the application's branches App Studio creates its rules in; and
• The rulesets from which application layer the branch rule will eventually be merged into.

In this way of working, you can influence where App Studio creates the rules it authors. This approach also allows you to author Module components from App Studio by selecting the Module application layer.

Brian Pageau's blog post on How branch development works in App Studio describes how to make full use of Branch Development Preferences.

The rules created by Business Architects start the development of the feature.

Create a branch connected to a user story. All delivery team members - including Business Architects - use that branch to contain all rules authored for the feature, in App Studio and Dev Studio.

All branches for completed features become subject to review as normal development, regardless of how many authors were involved.

A branch is created in App Studio from Branch Development Preferences within a couple of clicks, we do not have any issues with this.

All rules created by App Studio have a purpose. Removing them will remove cause the application to not function correctly.

Everything we did and showed in the webinar is achieved without using action sets. They are not a configuration option in Constellation views. Constellation already has implementation patterns built-in to fulfil many of the business outcomes that - on UI-Kit - could only be achieved by using action sets.

Here are some useful resources that elaborate on Constellation's step away from action sets:

• Blog from Sam Alexander: Goodbye, Action Sets ... Yes, but for good reason!
• CLSA Webinar December 2022: What's New in 8.8: UI/UX and Insights

Does Constellation use 3-tier architecture?

... or is Constellation still hosted on the app server with the main pega instance?

There is a clearer separation into 3 tiers with Constellation:

1. Constellation design system components residing in the browser (or whichever channel the user is using) are generating the user interfaces for the presentation layer based on View metadata for the current action. The View metadata is supplied through the Constellation DX API
2. The workflow and data orchestration continues to be fulfilled in the Pega Infinity server. 
3. The database remains the system of record for rules and case data. The Pega Infinity server interfaces with other systems of record as defined by data pages which act as Data Access Objects.

All UI authoring is done in Pega, no React knowledge is needed for your Constellation applications to be used using Pega's native Constellation UI.

Developers with experience in modern front-end technologies (including, but not limited to React) can adapt a client's existing design system to Pega Constellation using Constellation SDKs from Pega Marketplace.

We do not expect that the Pega System Architect is responsible for crafting custom UI componentry any more. Pega System Architects work in collaboration with their client's professional front-end developers to adapt their unique design system to Pega.

When starting a new case type on Traditional UI Architecture like UI-Kit, define the case type's data model first and always reference this in the case type workflow. Then, build the reusable features in Modules which the application builds upon.

With the correct data design and case design, you will be able to more easily transition to Constellation when the time is right.

Best practice is NOT to use @baseclass. This is an anti-pattern for us, because it pollutes your class model with a large number of rules that are inappropriately available via inheritance. 

In Constellation, localization is configurable from App Studio which creates a new Localization rule type. In there, we model localization per element and implement translations accordingly.

Yes. At the far left is using the Constellation native, OTB UI which is the fastest time-to-value. 

As you move further to the right, client-specific needs would replace Pega OTB capability which adds development time, the mix of technical skills needed, and total cost of ownership (TCO).

All models are valid and supported. Clients and delivery teams need to be conscious of the agility and TCO considerations with using models towards the right.

All web channels are fulfilled though the DX API. Constellation applications can be used headless if needed.

No change in design and build process is needed for that

Web Embed is for Constellation;

Mashup is still applicable for the Traditional UI Architecture

In the SDK, you get - per DX component - a template with the material UI setup.

You can use this as a starting point to start mapping it to your design system. In that way, you can start translating component by component (for example, text property first, then date property, and so on...)

I would always keep versions equal.

When published to the Pega Infinity server they are stored in a Ruleset Version.

in the beginning that we were the first ones to use it on this scale. With Platform 8.8, it is really great to work with Constellation. I do not want to go back anymore! 

The biggest change is to design before build. It is a prescriptive design system, so without case type and a data model that references all its data dependencies, you cannot author a user interface. Once the design is finalised, you can author the user interface rapidly!