Scribd
Upload
1K views

Pega Guardrails

10 guardrails of Pega

Uploaded by

sharmanidhi8143
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODT, PDF, TXT or read online on Scribd
1K views

Pega Guardrails

10 guardrails of Pega

Uploaded by

sharmanidhi8143
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODT, PDF, TXT or read online on Scribd
You are on page 1/ 2

PEGA Guardrails

The Ten Guardrails to Success are design guidelines and recommended best practices for Process
Commander implementations.
Following the fundamental principles promoted in the Ten Guardrails to Success leads to rulesbased applications that are well designed, straightforward to maintain, and architected to Build for
Change. They are your keys to success with Process Commander.

1. Adopt an Iterative Approach


Define an initial project scope that can be delivered and provide business benefit within 6090 days from design to implementation.
Document five concrete use case scenarios up front and evaluate them at the end to calibrate
benefits.
Use your scenarios as story boards and ensure that each delivers a measurable business
benefit.

2. Establish a Robust Foundation


Design your class structure complying with the recommended class pattern.
It should be understandable, be easy to extend, and utilize the standard work and data classes
appropriately.
Use your organization entities as a starting pattern, and then proceed with class groups.
Lead with work objects. Create the class structure and completed work objects early.
Position rules correctly by class and/or RuleSet.
Actively use inheritance to prevent rule redundancy.

3. Do Nothing That is Hard


Use out of the box functionality as much as possible, especially in the initial project
release.
Avoid creating custom HTML screens or adding buttons.
Always use the Auto Generated HTML feature for harness sections and flow actions.
Always use the standard rules, objects, and properties. Reporting, Urgency, Work Status, and
other built-in behaviors rely on standard properties.
Never add a property to control typical work or for managing the status or timing of work.

4. Limit Custom Java


Avoid Java steps in activities when standard Process Commander rule types, library
functions, or activity methods are available.
Reserve your valuable time and Java skills for implementing things that do not already exist.

5. Build for Change


Identify and define 10-100 specific rules that business users own and will maintain.
Activities should not be on this list. Use other rule types for business-maintained logic.

6. Design Intent-driven Processes


Your application control structure must consist of flows and declarative rules, calling
activities only as needed.
Use flow actions to prompt a user for input.
Present fewer than five connector flow actions for any individual assignment. If you need
more than that, you need to redesign the process.
Create activity rules that implement only a single purpose to maximize reuse.

7. Create Easy-to-Read Flows


Your flows must fit on one page and must not contain more than 15 SmartShapes (excluding
Routers, Notify shapes and Connectors) per page.
If a flow has more than 15 SmartShapes:
Create a subflow.
Use parallel flows to perform additional functions

8. Monitor Performance Regularly


Evaluate and tune application performance at least weekly using Performance Analyzer
(PAL) to check rule and activity efficiency.
Use PAL early to establish benchmarks. Compare these readings to follow on readings;
correct application as required.

9. Calculate and Edit Declaratively, Not Procedurally


Whenever the value of a property is calculated or validated, you must use declarative rules
wherever appropriate.
Create a Declare Expressions rule instead of using a Property-Set method in an activity.
Use a Declare Constraints rule instead of a Validation rule.

10. Keep Security Object-Oriented, Too


Your security design must be rule-based and role-driven based on who should have access to
each type of work.
Never code security controls in an activity.
Use the standard access roles that ship with Process Commander only as a starting point.
Use RuleSets to segment related work for the purpose of introducing rule changes to the
business, not as a security measure.

You might also like