Ten Guardrails for Success

Designing PegaRULES Process Commander (PRPC) Solutions

#1 Adopt an Iterative Project Approach

You must define an initial project scope that can be
delivered and provide business benefit within 60-90
days from Design to Implementation.
An iterative approach enables you to put a solution into
production in a short period of time so you can begin
gathering meaningful feedback from the business to
drive subsequent releases. Key points to remember:
Document five concrete use case scenarios upfront
and evaluate them at the end to calibrate benefits.
Use your scenarios as storyboards and ensure that
each delivers a measurable business benefit.
#2 Establish a Robust Foundation

Your class structure must anticipate the layering of
rules and comply with Chapter 4 (Designing Your
Class Structure) of the Designing Your Process
Commander Application book, which describes the
SmartBuild process for designing and building
PRPC applications.
As the foundation of your application, a well-architected
class structure is critical for optimal processing and
performance. It must be understandable, easy to
extend, and utilize the standard work and data classes
appropriately. Key points to remember:
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

You must use the standard PRPC out of the box
rules and functions in the initial project release. Do
not duplicate standard functionality.
Do things the easy way. Using the tested components
that ship with PRPC decreases time-to-market and
allows you to benefit from future enhancements. Key
points to remember for the initial 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 for controlling typical work or
managing the status or timing of work.
#4 Limit Custom JAVA

You must avoid J AVA steps in activities when
standard PRPC rule types, library functions, or
activity methods are available.
While using the J AVA option can be a powerful tool,
investigate all of the rule types and existing objects
before resorting to adding a J AVA step in either an
Activity or HTML rule. Key point to remember:
Reserve your valuable time and Java skills for
implementing things that do not already exist.
#5 Build for Change

You must identify and define 10-100 specific rules
that business users own and will maintain.
Openly discuss rules with the business users throughout
the SmartBuild process. Agree on the rules for which
they are responsible and design/build accordingly.
Appendix B in the Designing Your Process Commander
Application book contains a list of rules that are intended
to be maintained by Process Architects. Key point to
remember:
Activities should NOT be on this list. Use other rule
types for business-maintained logic.
Copyright September 2004 Pegasystems Inc. Page 1

#6 Design Intent-Driven Processes

Your application control structure must consist of
Flows and Declarative Rules, calling Activities only
as needed.
Intent-driven processes have the rule-driven intelligence
to guide users to do the right thing in a given situation.
Key points to remember:
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 only implement 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
Connectors) per page.
Flows must be easy to read, move from top to bottom,
and minimize cross-over between steps. Key points to
consider if a flow has more than 15 SmartShapes:
Create a subflow.
Use parallel Flows to perform functions.
#8 Monitor Performance Regularly

You must evaluate and tune application
performance at least weekly using Performance
Analyzer (PAL) to check rule and Activity efficiency.
Always allocate time during development to perform
PAL testing to ensure that your configuration evolves
cleanly and efficiently. Key point to remember:
When available, use the PAL Advisor and address
any ratings greater than 100%.
#9 Calculate and Edit Declaratively, Not Procedurally

Whenever the value of a property is calculated or
validated, you must use Declarative Rules
wherever appropriate.
Declarative Rules are change-aware and eliminate the
need for more expensive Activities to check for and
implement property value changes. For example:
Create a Declare Expressions rule instead of using
a Property-Set method in an Activity.
Use a Declare Constraints rule instead of a field
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 (as defined in Chapter 11,
Controlling Access and Security, of the Designing
Your Process Commander Application book).
Standard rule types (Access Roles, Access Whens,
Privileges, and Settings) provide the ability to control
who can access all or part of a work object. Use these
rules to implement a scalable security model for your
solution that is class-based and leverages inheritance.
Key points to remember:
Never code security controls in an Activity.
Use the standard access roles that ship with PRPC
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 (as defined in Chapters 3
and 13 of the Designing Your Process Commander
Application book).

Copyright September 2004 Pegasystems Inc. Page 2