LSA Data Excellence Handout

CLSA Continuous Excellence Enablement

© 2020 Pegasystems Inc. CONFIDENTIAL

CLSA Continuous Excellence Enablement (C2E)
What is it?
A substantial part of the CLSA ecosystem earned their qualifications on versions of Pega prior to 8. The
latest version of Pega includes many changes from prior versions, and supports new best practices that all
LSAs need to understand to be fully effective.

The CLSA Continuous Enablement Excellence Program (CLSA CE²) addresses this need. During the remainder
of 2020 Pega will provide essential information on topics directly relevant to our CLSA community. The
training materials are being developed by highly experienced CLSAs with many years of implementation
experience.

This class, LSA Data Excellence, is the first in the series, and will be available in Pega Academy as self-study in
the near future.

This document contains an overview of the LSA responsibilities and the takeaways on how to empower your
delivery team with App Studio, all in the context of data excellence.
Data Excellence:
LSA Responsibilities

3
LSA Responsibilities: Data Type Composition
Separate Reuse Layers and Case Layer

• Split out into different Applications

those Rulesets that shall contain
rules to be re-used across
different Case Layers
• Applying Branches at distinct Layers
drives App Studio’s class naming
and ruleset decisions
• Consider Access Groups per Layer

4
LSA Responsibilities: Data Type Composition
Branch setup

• Create a Branch in the Layer where

the data types need to be available
• App Studio and Dev Studio share
context of what Branch you are
currently working in

5
LSA Responsibilities: Data Type Composition
Minimal Data Type setup

• For new Data Types created in App

Studio, your current Branch in use
governs the:
– Fully-qualified Class Name
– Ruleset for Classes and Properties
• Create enough Data Types
and enough Properties in them
to unblock your Dev Team
• Defer decisions on “Data Source”

6
LSA Responsibilities: Data Type Composition
Minimal Case Type Data Modeling

• Work in a distinct Branch on the top-level

Layer (“Case Layer”)
• The new Case Type
and the rules that apply to it
are created in the Case Layer
• Create enough Properties on your
Case Type to guide your Dev Team
to the intended configuration
• Branch-Review Dev Team outputs:
– Positioning of Class & Property rules
– Continued adoption of
Composition principles

7
LSA Responsibilities: Data Type Encapsulation
Use App Studio to transparently encapsulate behavior in the right Class

• Building out Views for Case Types

… in App Studio …
using a Composition-driven Data Model yields
appropriate Encapsulation

• App Studio encapsulation opportunities

– Data model (Properties)
– Views (Sections)
– Calculations (Declare Expressions)
– Validations
• Switch to Dev Studio to encapsulate other
rule types into the appropriate Class
– Data transforms
– Whens
– Activities … and others

8
LSA Responsibilities: Data Type Encapsulation
LEFT NOT ENCAPSULATION DRIVEN DRIVING ENCAPSULATION

• Each feature duplicates similar behavior • Single implementation (and testing) of capability
from another existing feature
• Consistent capability available
• Duplicate behavior introduces: anywhere the data type is used
– Maintenance overhead • Can be parameterized to further drive reuse
– Testing overhead
– Regression risk • Packageable as a Component
• Natural by-product of using App Studio

9
LSA Responsibilities: Data Type Encapsulation
LEFT NOT ENCAPSULATION DRIVEN DRIVING ENCAPSULATION

• Each feature duplicates similar behavior • Single implementation (and testing) of capability
from another existing feature
• Consistent capability available
• Duplicate behavior introduces: anywhere the data type is used
– Maintenance overhead • Can be parameterized to further drive reuse
– Testing overhead
– Regression risk • Packageable as a Component
• Natural by-product of using App Studio

BRANCH REVIEWS
• Check encapsulation in correct Applies To class
• Seek justification for case-level rules coupled
directly to embedded properties

10
LSA Responsibilities
Applying inheritance
• Familiarise with Data (and other) Classes in Strategic • Use App Studio to define skeleton Data Objects
Applications licensed by your client needed by your application
– Suggest additional Strategic Applications or • Use Dev Studio to revise Directed Inheritance
Marketplace Components
• Identify additional superclasses of reusable data
model and/or behaviour for Client reuse layers • Branch reviews:
• Prefer Class specialization over Ruleset specialization – Consider whether features implemented by
Delivery Team are more reusable than the Class or
– Superclass rules remain accessible at runtime Ruleset they shall be merged into
– When usage of the Pega data type needs to be – Beware of redundant Property rules
Concrete but Pega publishes it as Abstract created by App Studio that can be safely removed
– All capabilities are open with
Class Specialization

11
LSA Responsibilities:
Polymorphic Inheritance
• Embrace Pega’s object-oriented capabilities
– Mentor those on your Delivery Team
who are less familiar with object-oriented
• Identify generic super-classes which
drive process behavior
– Identify the Extension Points needed for
subclasses to override; mark as
“Extension”
– Document “Usage” in Extension Points,
guiding Delivery Team specialization
• Make subclasses available as
Application rule Data Types
for Delivery Team to exploit in App Studio
• Process is truly Built for Change
– “Drop in” new subclasses
as business drivers evolve

12
LSA Responsibilities
Application rules by layer; Access Groups per Delivery Team role, per Layer

MyFinance:LeadArchitect
MyFinance:CitizenDeveloper

MyBank:CitizenDeveloper
MyBank:LeadArchitect

13
LSA Responsibilities
... when Baking the Layer Cake
• Branch development supported in App Studio as well as Dev Studio
• Branch reviews:
– New class ruleset decisions
– Ruleset decisions for rules that Apply To classes
– New class names follow naming conventions

14
LSA Responsibilities
... when Baking the Layer Cake
• Branch development supported in App Studio as well as Dev Studio
• Branch reviews:
MyBank-Data-Asset
– New class ruleset decisions
MyBank-Data-Assets – Ruleset decisions for rules that Apply To classes
– New class names follow naming conventions
MyBank-Data-AssetInfo

MyBank-Data-AssetDetails

15
LSA Responsibilities
... when Baking the Layer Cake
• Consider packaging capability as Components
when independently reusable of the Enterprise Layer

MyBank-Data-Customer • Class inheritance review for new/changed classes

– Pattern- and Direct-inheritance reflects the “X is a Y” convention
MyBank-Data-Customer-Address – Pattern- and Direct-inheritance superclasses exist
in the same RuleSet or those from built-on applications
MyBank-Data-Address

• Beware of grouping classes using Pattern-inheritance like a Java “package”:

– Address is not a Customer
– The RuleSet is the Pega equivalent of a Java package

16
LSA Responsibilities
Data Modelling for Systems of Record
• Minimal disruption whilst supporting your client’s • Use Data Pages to insulate your Delivery Team from
ever-evolving Digital Transformation journey the intricacies of interfacing with Systems of Record
– Goal: No System of Record specifics in Case layer

• Understand the System of Record landscape

• Implement Data Pages to represent
– Current state ALL System of Record interactions
– Final state – Even those where Pega is the System of Record
– Interim states

• Data Classes are “Abstract first” until

• Be more driven by the data needs of your a need for instances recorded in Pega is needed
Pega applications

• Consider Reference Data in this technique

• Be less driven by the current constraints of how data – Drop-down / Auto-complete lookup data
is made available from the System of Record – Reference data can just as easily exist in
other Systems of Record

17
LSA Responsibilities
Data Access for Systems of Record
• Being Composition-driven when forming your Case • Design your Savable Data Page “Save Plan”
type data model allows Page / Page List properties to: to be Resilient
– Refer to Data Pages that transparently source – Expect errors; surface them in the Data Page
required data from Systems of Record – Check for Save errors when using
– Record a Snapshot of this data Save-DataPage method in Activities
(if the business need requires)
– Records changes to the master data in the
Systems of Record through the same Data Page • Performance considerations:
– Can (and Should) aggregation across multiple
Systems of Record be done in parallel?
• Decouple the Case layer from
– Should embedded data with no business need to
– Where the Systems of Record are exist outside of a case be externalized to its own
– What form the Systems of Record take concrete data type
– How the Systems of Record persist the data

18
Empowering your
Delivery Team …
… with App Studio

19
Empower your Dev Team
… in App Studio
Composition
• Citizen Developers can confidently:
– Build out new Case Types
composed of these Data Types
– Add Properties to Data Types
as new features demand

• You can “let go” once:

– High-level Data Objects are defined
– High-level Composition of Data Objects
in Case Design is implemented

• Citizen Developers can confidently build on features

that the LSA has made available via inheritance

20
Empower your Dev Team
… in App Studio
Encapsulation

• Citizen Developers can confidently build out

appropriately encapsulated:
– Properties
– Views
– Calculations

• You can focus on:

– Branch-reviewing adoption of encapsulation
– Applying encapsulation to designs
– Applying encapsulation to implementation of
more advanced rule types

21
Empower your Dev Team
… in App Studio
Polymorphism
• Citizen Developers can focus on
the feature set needed by Data Type

… and the process is assured to continue working

– What are the “Customer Details”

to capture for a Partnership?

– How do I map the LLC to the

“Credit Risk Assessment” service request?

– We can add a “Share Registry” Collateral type

without modifying the process
– The process is unchanged
– The data captured that drives the process is
what is different – encapsulate this in a subclass
22
Empower your Dev Team
… in App Studio
Baking the layer cake

• Rules are created based on:

– The Application layer of their Access Group
– The Application layer of their preferred Branch
• Data Types created in App Studio yields the correct
fully-qualified name even when pattern-inheriting
• Data Model, Data View, View and Case Type rules
created in App Studio typically land in the most
appropriate Ruleset based on
– Application Layer; and/or
– Branch

23
Empower your Dev Team
… in App Studio
SOR Modelling

Delivery Team can use App Studio to continue

implementing Process/Application level features …

… on the promise …

… that Data Pages will forever honor their required behavior:

• Regardless of what the System of Record is right now
– Pega may be temporarily acting as a System of Record
• Regardless of how many Systems of Record may be involved

“Retrieve the Customer whose ID is 123”

“Get all Customers in Japan whose Status is Platinum”
“Perform this Credit Risk Assessment”

24