CLSA Community Meetup: LeasePlan: Low-code Enterprise Development using Constellation (March 2023)
In this event conducted on March 14-15 2023, Marco Duizer (Principal System Architect, Pega Consulting, @duizm) shared his insights on the Low Code Enterprise Development approach that was successfully implemented at LeasePlan. Marco discussed:
- A reusable application architecture using Modules (known as "Accelerators" on this project), preferred over monolithic enterprise layers
- Their delivery approach that engaged all stakeholders, unified in their movement to deliver the key business outcomes rapidly
- The feature lifecycle which encourages more rapid adoption each time the feature is included in an application
- The benefits of adopting Constellation, including a showcase of the various UI implementation options across channels and who is responsible for what.
Ronald de Lignie (Lead System Architect, Pega Consulting, @delir) provided a retrospective on the lessons learned from leveraging Constellation (and other modern Pega features) at LeasePlan. Ronald covered:
- Business benefits realized for LeasePlan across channels using Pega's Center-Out Business Architecture
- Walkthrough of the Constellation Architecture and LeasePlan's apps utilized it to make Pega experiences available across various channels including Constellation UI, Salesforce Lightning, Web Embed and building on Constellation SDK
- Promoting Configuration over Customization through the use of modern Pega features like Configuration Sets, Constellation Localization
- Design, development and debiugging lessons learned: some general to Pega Platform; some specific to adopting Constellation
We were also privileged to welcome back Paul Barnes (Senior Director, Business Excellence - Intelligent Automation, Pegasystems, @barnp) who confirmed that success stories like LeasePlan - as well as other clients like Rabobank (whose approach we discussed in an earlier webinar) - are informing Pegasystems' guiding principles for Pega Platform implementations going forward.
See below the replay to visit useful links, download slides, and review the Q&A that came in during both sessions!
Enjoy the replay! Use the chapters in the video toolbar to get to the content you need!
"Ronald's Recommendations" on Constellation training available from Pega Academy:
- Low Code App Builder
- Configuring Constellation Applications: 8.7 or 8.8
- Pega UX Solutions
- Pega DX API and Constellation UX Design
CLSA Webinar: A digital innovation journey with Rabobank ... a predecessor to the LeasePlan program which used similar design principles to what LeasePlan adopted as Accelerators, and what Pega is referring to as Modules going forward.
App Studio: Is this the tipping point? ... a podcast episode from Aaseya who worked in collaboration with Pega Consulting on the LeasePlan delivery, discussing the business and developer benefits of working in App Studio first, where Accelerator building blocks can be easily adopted into new apps by any App Studio author.
Pega Generative AI coming to Pega Infinity '23
Paul Barnes: Modular Reuse 1-0-1
Marco Duizer: Low-code Enterprise Development @ LeasePlan
Ronald de Lignie: Constellation and modern Pega development @ LeasePlan
Questions & Answers
- Modules? Accelerators? Components? Applications? Frameworks???
- Module architecture
- Implementation approach
- Roles & Responsibilities
- Version & Deployment management
- App Studio adoption
- Channels / SDK
- DX Components
- Lessons learned
Subscribe to this article to be notified when we post updates to the Q&A!
Modules? Accelerators? Components? Applications? Frameworks???
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?
|A Framework generally contains a lot of functionality and is the single basis for a full business application. Modules are smaller and are easier to govern reuse across multiple applications within the enterprise. This means you do not have a very large enterprise layer or Framework which contains most of the enterprise's reusable functionality.|
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:
|Is each Module built as a different Pega Application?||Yes. Modules are clean Pega Applications that build on the enterprise layer only.|
|How do "Automations" fit in the terminology discussion?||
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.
|Are Modules breaking down a 'Built on application' into more granular level?||
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:
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?
|We have multiple user-facing applications for the domains. All user-facing applications use the same set of Modules based upon their needs.|
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.
|Do Modules each contain a single data object and definition, or a set of functionalities surrounding the subject of the Module ('Customer' for instance)?||
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.
|What is the difference between the business rules layer and the Module?||
Both use standard Pega rules.
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.
|Is a centralised data model shared across all Modules?||
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?
|If you have two Modules, they do not know each other. They can have an ID property referring to data that may be sourced from another Module, like having a "Driver ID" field. This can be used to show data with the data query pattern.|
|Tradiitionally we used to implement Connectors in the enterprise layer. You are mentioning to make enterprise layer light, so where should the Connectors be implemented now?||Connectors are to be implemented in the most relevant Module for the type of data the Connector sends or receives.|
|Are we doing away with divisional and org unit layers?||Modules and the Situational Layer Cake can co-exist. LeasePlan still made use of the layer cake, both within its user-facing applications and the Modules.|
|Is the project a multi-team/stream set up who are all building on a single platform?||We have 3 Cloud environments for different applications, with multiple teams running their apps on them. The Modules are distributed to the different environments using Pega Deployment Manager.|
|Do you deploy the application in different instances or a single big instance?||We have multiple Pega Deployment Manager pipelines to move only those user-facing applications - and their dependent Modules - to exactly where they are required.|
|What testing strategy was in place at LeasePlan for unit testing and UI testing?||
|With Pega Unit Testing, were you able to achieve good test coverage?||Yes, we did! We also validated during the build review done by COE.|
|Does having so many Modules and business applications impact the rule engine performance?||
Rule engine performance behaves the same as standard ruleset-stack. Skimming remains advisable after Production releases.
|Should we wireframing the UI's when it takes more time than authoring it in Pega as part of DCO?||
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.
|Is there a scenario where you have to create a similar service as PEGA OOTB DX APIs?||We didn't have that. For all apps we have been able to use OOTB APIs so far.|
Roles & Responsibilities
|Does the System Architects need to do work before Business Architects can work directly in App Studio?||
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.
|Was there a role of a Citizen Developer who is taking complete care of a process implementation from App Studio with little dependency with System Architects?||We used fusion teams with Business Architects and System Architects working together.|
|What has been done to bring people into the new way of working? How are you monitoring its adoption?||
At the start of the LeasePlan project we had LSA's training the different developers on the new way of working. We now have:
Version & Deployment management
|How is change management handled in LeasePlan where updates may be made by Citizen Developers?||Business Architects make the new designs. The LSA initiates a branch merge to validate the change and see what the impact is. Business Architects get more familiar with the impact of changes as they adopt this way of working more.|
|When a Module is used across many applications, do you maintain different versions?||We maintain all versions.|
|How is maintainence and upgrade of different versions handled across multiple streams of work?||
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.
|How do you manage the Module set for applications that are developed on different infrastructure? Do you have a master application where you build the features and then sync that layer across all the other infrastructures?||
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.
App Studio adoption
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:
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.
|When a new feature is designed in App Studio and needs to be made as reusable, how do you segregate the rules created by Business Architects in App Studio from the actual rules for the Production application?||
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.
|How do you manage the meaningless rules that are auto-generated by App Studio?||
All rules created by App Studio have a purpose. Removing them will remove cause the application to not function correctly.
|Can you show/explain with an examples what implementing UI without Action Sets looks like?||
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:
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:
|Is there any React coding or are UIs all configured using Pega?||
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.
|What steps can we follow to implement our UI-Kit applications in a way that is aligned to Constellation, so that it will be easier to upgrade to?||
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.
|Regarding to localization, is there a good way to avoid adding every Field Value to @baseclass?||
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.
Channels / SDK
|In the "How to use it" Constellation diagram (Final page: Low-code Enterprise Development @ LeasePlan), does the agility go down significantly as you move to the right?||
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.
|Do Salesforce interact with a Constellation SDK?||Not quite. Showing Pega user interfaces in SalesForce Lightning uses a specific "Connector" available from Pega Marketplace, which is not a SDK.|
|Would you recommend that clients must use Constellation DX API for harness-based and headless-based applications?||
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
|Is Web Embed what used to be called Mashup?||
Web Embed is for Constellation;
Mashup is still applicable for the Traditional UI Architecture
|Can you elaborate on mapping between React Material UI properties to DX API properties or views?||
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...)
|How did you ensure at LeasePlan that custom DX components use libraries that do not contain security vulnerabilities?||We have a dedicated team of React developers building these components who have reviews in place to ensure they are following all standards (security, testing, code-review, etc.).|
|Should we create custom DX components in the same version that Constellation is currently built? Or can I create it in higher latest version?||
I would always keep versions equal.
When published to the Pega Infinity server they are stored in a Ruleset Version.
|What was the biggest pain point in using and developing with Constellation?||
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!