Вы находитесь на странице: 1из 396
Designing Your Application with SmartBuild PegaRULES Process Commander

Designing Your Application with SmartBuild PegaRULES Process Commander

Designing Your Application with SmartBuild PegaRULES Process Commander

© Copyright 2005 Pegasystems Inc., Cambridge, MA

All rights reserved.

This document and the software describe products and services of Pegasystems Inc. It may contain trade secrets and proprietary information. This information should not be disclosed to third parties unless otherwise provided for by a contract or business agreement with Pegasystems. This document and the software are protected by federal copyright law, international laws, and/or applicable treaties.

This document is current as of the date of publication only. Changes in the document may be made from time to time at the discretion of Pegasystems. This document remains the property of Pegasystems and must be returned to it upon request. This document does not imply any commitment to offer or deliver the products or services provided.

This document may include references to Pegasystems product features that have not been licensed by your company. If you have questions about whether a particular capability is included in your installation, please consult your Pegasystems service consultant.

Other brand or product names are trademarks of their respective holders.

This document is the property of:

Pegasystems Inc. 101 Main Street Cambridge, MA 02142-1590 (617) 374-9600, fax: (617) 374-9620 www.pega.com

PegaRULES Process Commander Document: Designing Your Application with SmartBuild Software Version 4.2 SP2 SmartBuild Print Date: April 2005 Order #: @DPCDESB02

Overview

Before You Begin

.....................................................................................................................

1

Step 1: Roadmap to Building a Process Commander Application

...................................

1-1

Step 2: Analyzing Requirements

.......................................................................................... Step 3: Getting Started — Prerequisites and Setup Step 4: Designing the Class Structure

...........................................................

................................................................................ Step 5: Building the Class Structure and Reviewing Work Objects

.................................

2-1

3-1

4-1

5-1

Step 6: Adding Properties and Sample Data Step 7: Tailoring the User Interface

.......................................................................

..................................................................................... Step 8: Designing Flows and Identifying Flow Actions

.....................................................

6-1

7-1

8-1

Step 9: Creating Flow Rules and Adding Process Details

.................................................

9-1

Step 10: Adding Communications Capabilities Step 11: Setting Up Access and Security

................................................................

.......................................................................... Step 12: Configuring System Interfaces and the PegaRULES Database

.......................

10-1

11-1

12-1

Step 13: Deploying and Evolving Your Application

.........................................................

13-1

Step 14: Leveraging Reports and Quality Features

.........................................................

14-1

Quick Reference to Essential Design Principles

...............................................................

A-1

Contacting Pegasystems

.....................................................................................................

B-1

iv

Contents

Contents

Before You Begin

1

Who Should Read This Book

2

Step 1: Roadmap to Building a Process Commander Application

1-1

Identifying Application Opportunities

1-2

....................................................

1-4

1-10

Identifying Components of an Application

1-11

Understanding Process Commander Job Functions

1-16

Mapping SmartBuild to a Typical Project Structure

1-20

About the Examples

1-22

1-23

Step 2: Analyzing Requirements

..........................................................................................

2-1

A Different Approach to Requirements Analysis

2-2

What Is the Nature of the Work?

2-3

Who Performs the Work?

2-6

..........................................................................

2-15

What Are the Major User Scenarios?

.............................................................................

...............................................................

2-18

Are You Building an Applicat ion or a Product?

2-20

Step 2 Completion Checklist

2-21

Step 3: Getting Started — Prerequisites and Setup

3-1

Using the Development Environment

...............................................................................

3-2

Identifying the Top-Level Organization Class

...................................................................

3-5

Working with the Application Accelerator

3-6

Planning RuleSets

..........................................................................................................

3-10

Creating the RuleSets

3-15

Creating the Application Parent Class

............................................................................

3-18

Changing the System Name

3-20

Configuring the Organization, Access Groups, and Users

3-21

Step 3 Rule Type Reference

3-25

Step 3 Completion Checklist

3-27

Contents

v

Step 4: Designing the Class Structure

................................................................................

4-1

Important Terms and Concepts

........................................................................................ Class Structure Design Process

.......................................................................................

4-2

4-8

Refining the Class Structure

........................................................................................... Identifying Work Pools (Class Groups) Defining Work Object IDs

...........................................................................

............................................................................................... Determining Work Parties and Sources

......................................................................... Establishing Additional Repeating Groups Final Class Structure Check Step 4 Rules Reference

.....................................................................

...........................................................................................

................................................................................................. Step 4 Completion Checklist

..........................................................................................

4-17

4-18

4-20

4-23

4-27

4-30

4-31

4-32

Step 5: Building the Class Structure and Reviewing Work Objects

.................................

5-1

Important Terms and Concepts

........................................................................................

5-2

Using the Application Ac celerator Approach

....................................................................

5-3

Using the Class Rule Form Approach

..............................................................................

5-5

Creating a Work Parties Rule

.........................................................................................

5-10

Entering the First Work Objects

.....................................................................................

5-13

Step 5 Rules Reference

................................................................................................. Step 5 Completion Checklist

..........................................................................................

5-17

5-18

Step 6: Adding Properties and Sample Data

.......................................................................

6-1

Important Terms and Concepts

........................................................................................ Identifying and Creating Applic ation-Specific Properties

..................................................

6-2

6-3

Creating Model Rules to Initialize Work Object Properties

.............................................

6-12

Declaring Dependencies Among Properties Creating Application-Specific Data Classes

...................................................................

6-17

...................................................................

6-27

Simulating Connectors Using Sample Data

...................................................................

6-29

Capabilities to Consider in This Step

..............................................................................

6-31

Step 6 Rules Reference

................................................................................................. Step 6 Completion Checklist

..........................................................................................

6-35

6-36

vi

Contents

Step 7: Tailoring the User Interface

.....................................................................................

7-1

Important Terms and Concepts

........................................................................................ Selecting a User Access Technique

................................................................................. Benefits of the Built-in, Rules-Driven User Interface

........................................................

7-2

7-4

7-6

Understanding Components of Work Object Forms

.........................................................

7-8

Tailoring the Standard Forms

......................................................................................... Capabilities to Consider in This Step

..............................................................................

7-18

7-32

Step 7 Rules Reference

................................................................................................. Step 7 Completion Checklist

..........................................................................................

7-36

7-37

Step 8: Designing Flows and Identifying Flow Actions

.....................................................

8-1

Important Terms and Concepts Introducing Flow Design

8-2

8-3

8-5

8-10

........................................................................................

................................................................................................... Creating First Flow Shells Six Basic Design Shapes

................................................................................................

...............................................................................................

Extending and Refining Flow Shells

...............................................................................

8-20

Step 8 Completion Checklist

..........................................................................................

8-31

Step 9: Creating Flow Rules and Adding Process Details

.................................................

9-1

Important Terms and Concepts

........................................................................................

9-2

A Recommended Approach

.............................................................................................

9-3

Reviewing the Flow Shapes

.............................................................................................

9-4

Adding Process Details

..................................................................................................

9-12

Verifying the Entry Process

............................................................................................

9-28

Step 9 Rules Reference Step 9 Completion Checklist

.................................................................................................

..........................................................................................

9-29

9-30

Step 10: Adding Communications Capabilities

................................................................

10-1

Understanding the Correspondence Model Building Correspondence Capabilities

10-2

10-10

....................................................................

.......................................................................... Capabilities to Consider in This Step ............................................................................10-13

Step 10 Rules Reference Step 10 Completion Checklist

.............................................................................................

......................................................................................

10-15

10-16

Contents

vii

Step 11: Setting Up Access and Security

..........................................................................

11-1

Important Terms and Concepts Security Implementation Checklist

......................................................................................

.................................................................................

11-2

11-5

Granting Application Access

..........................................................................................

11-7

Granting Access to Work Objects and Other Instances

...............................................

11-10

Granting Access to Change Application Rules

.............................................................

11-24

Capabilities to Consider in This Step ............................................................................11-26

Step 11 Rules Reference Step 11 Completion Checklist

.............................................................................................

......................................................................................

11-30

11-32

Step 12: Configuring System Interfaces and the PegaRULES Database

.......................

12-1

Important Terms and Concepts

...................................................................................... Delivering Services to External Systems

........................................................................ Connecting to External Databases and Systems

...........................................................

12-2

12-5

12-7

Capabilities to Consider in This Step ............................................................................12-10

Working with the PegaRULES Database

.....................................................................

12-14

Step 12 Rules Reference Step 12 Completion Checklist

.............................................................................................

......................................................................................

12-17

12-18

Step 13: Deploying and Evolving Your Application

.........................................................

13-1

Important Terms and Concepts

......................................................................................

13-2

Preparing the Application for Deployment

......................................................................

13-3

Deploying the Application

...............................................................................................

13-7

Evolving the Application

...............................................................................................

13-10

Capabilities to Consider in This Step ............................................................................13-12

Step 13 Rules Reference Step 13 Completion Checklist

.............................................................................................

......................................................................................

13-14

13-15

Step 14: Leveraging Reports and Quality Features

.........................................................

14-1

Important Terms and Concepts

...................................................................................... Business Activity Monitoring Capabilities

.......................................................................

14-2

14-3

Improving Quality through Rules

..................................................................................

14-10

Step 14 Rules Reference Step 14 Completion Checklist

.............................................................................................

......................................................................................

14-19

14-20

viii

Contents

Quick Reference to Essential Design Principles

...............................................................

A-1

Ten Guardrails for Success

.............................................................................................

...........................................................................

A-2

Monitoring Compliance with Guardrails

A-6

Contacting Pegasystems

.....................................................................................................

B-1

Customer Support

B-2

B-2

.......................................................................................................... Documentation Feedback

B-2

Office Locations

...............................................................................................................

B-3

Index

I-1

Before You Begin

This book shows you how to take advantage of PegaRULES Process Commander and its patented rules engine to deliver integrated business process management (BPM) and business rules engine (BRE) solutions. As you Build for Change™, use this book as your roadmap to delivering solutions that address today’s toughest process automation challenges, including rapid deployment and evolution. The SmartBuild approach for designing, building, and evolving Process Commander applications enables you to:

Analyze your requirements in the context of a Process Commander solution.

Apply best practices to design your application, including the class structure, data elements, forms, flows, process logic, and security.

Work with your data, including the underlying database and interfaces to other systems or data sources.

Take advantage of the reporting and quality improvement features that come with Process Commander.

The benefits to your business are agility for growth, productivity, and compliance.

2

Before You Begin

Who Should Read This Book

If you are part of a team that is building a Process Commander application, read this book. It describes:

Defining requirements for the application you want to deliver

Creating, tailoring, and assembling the components you need

Taking advantage of the standard features and capabilities that come with Process Commander

Deploying and evolving the application, and managing ongoing changes

Successfully delivering any application requires a mix of business analysis and application development resources. This book is intended primarily for Process Commander project team members who are responsible for business process design and application development. However, it also provides information to assist system and database administrators in project/resource planning. Specific project roles are described in Step 1: Roadmap to Building a Process Commander Application.

How to Use This Book

If you have not already done so, review the Quick Start. Use it as a self-paced tutorial to get acquainted with Process Commander. It introduces many fundamental concepts that you will find helpful as you begin developing applications.

This book is structured to provide useful information for both new and experienced Process Commander application developers:

If you are new to Process Commander: Follow the chapters in order as you develop your first few applications. These chapters provide examples to illustrate the SmartBuild steps and concepts. Each chapter concludes with a list of rules that you worked with and a checklist of completed deliverables.

As you become familiar with Process Commander: Use the rules and deliverable checklists at the end of each chapter to stay on track with SmartBuild. Refer to Appendix A for the Ten Guardrails for Success. Each guardrail summarizes important SmartBuild principles and guidelines.

Who Should Read This Book

3

Related Documentation

The following PegaRULES Process Commander documents are available:

PegaRULES Process Commander Introduction — provides an overview of the architecture, concepts, and features of Process Commander.

PegaRULES Process Commander Quick Start — provides a tutorial with standard elements used in configuring a Process Commander application and guides you in creating and interacting with a simple application.

PegaRULES Process Commander Administration and Security — describes how to perform the initial startup, setup, and day-to-day administration.

PegaRULES Process Commander Integrating with External Systems — supports IT professionals who plan, design, build, and test the interfaces with other systems that can be used with a Process Commander application.

PegaRULES Process Analyzer User Guide — describes how to install and use Process Analyzer, an optional component that provides online analytical processing (OLAP) data for PegaRULES Process Commander.

PegaRULES Process Simulator User Guide — describes how to install and use Process Simulator, an optional component that provides simulation of PegaRULES Process Commander business processes.

Application Developer Help — provides contextual information about Process

Commander. Access help by clicking the Help link on the Portal or

Commander. Access help by clicking the Help link on the Portal or on the

on the

toolbar.

Installation Guide (located on the installation CD) — describes how to install Process Commander.

Pega Developer Network (a section of the Pegasystems Support Network located at www.pega.com/support) — provides technical notes and tips for using PegaRULES Process Commander.

For information on installing or working with third-party applications, such as Microsoft Visio, consult vendor documentation.

Step 1:

Roadmap to Building a Process Commander Application

Welcome to PegaRULES Process Commander. This chapter describes the first step of SmartBuild, the key approach to rapid development and successful deployment of Process Commander applications. This first step includes how to:

Recognize good application opportunities.

Learn about the SmartBuild process for designing and developing applications.

Select a project methodology.

Identify components of a Process Commander application.

Structure your project team with the appropriate resources.

Who Does This: Project managers and business analysts typically work together to perform these tasks.

1-2

Step 1: Roadmap to Building a Process Commander Application

Identifying Application Opportunities

Process Commander is designed to complement, not replace, other information systems and technologies that you use in managing your business. You can use it to build standalone applications, or easily integrate Process Commander applications as components of existing legacy systems. Its flexibility and features are applicable to a wide range of business process automation solutions. The following types of business scenarios are ideally suited to leverage Process Commander’s strengths:

Wherever business-driven change is frequent, such as enterprise marketing programs, customer service, or cross-selling situations.

With internal or distributed parties that perform service or product fulfillment, such as loan appraisers, insurance adjusters, or subcontracted suppliers.

For processes with handoffs or parallelism, that often accompany distributed workforces and outsourced processes.

If centralized expertise must be captured and propagated, such as with credit decisions or dispute processing.

For supporting partners within the company, such as driving administrative processing for purchasing, legal, or human resources.

Choosing an Initial Pr oject — the Quick Win

A Quick Win opportunity allows you to demonstrate the value and return on investment (ROI) of the initial Process Commander project by delivering tangible results to the business. Rapid delivery with overwhelming success on the first project is the key to incremental projects that collectively and ultimately deliver the “big win.” Identifying the right gap to fill with your first project is important to achieving the proven advantages of a Quick Win.

Before assembling the team and structuring the project as described in this chapter, choose a Quick Win business opportunity from possible application opportunities. By definition, a Quick Win can be delivered within 60 to 90 days, offers standalone return on investment, and involves high-volume work that uses easily available data sources.

Identifying Application Opportunities

1-3

To identify a Quick Win opportunity, consider the following:

Where do you need to address process execution gaps between management objectives and business operations? For example, look for existing characteristics such as high staff turnover or training costs, high error or rework rates, human-intensive processes, and poor service/customer attrition.

Where would you like to improve or achieve better results? For example, look for desired characteristics such as increased throughput, reduced cost, faster turnaround, and improved tracking/accountability.

Where could you automate critical processes? For example, look for characteristics such as manual or paper-based steps, areas where data is copied from one system to another, and repetitive semi-automated processes such as customer correspondence generation.

Where do you have opportunities to remove “black holes”? For example, look for areas where work ownership/accountability is poorly defined or relies on manual processing.

Where do you have opportunities to digitize policy and process rules? For example, look for decision-critical knowledge residing on paper or in the heads of highly skilled individuals: processes that are regulatory driven (exception/dispute handling, corporate compliance), calculation intensive (tax or fiscal requests), and industry driven (policy requests or claim processing).

Quantify the possible opportunities in terms of financial and/or productivity metrics. Assess each opportunity in terms of business impact and system integration complexity, and select a Quick Win. Spend no more than a few hours on this task. If you need longer, you are defining requirements rather than assessing solution magnitude.

What You Completed

Identified application opportunities and a Quick Win initial project.

1-4

Step 1: Roadmap to Building a Process Commander Application

Using SmartBuild — Smart Design for Smart Systems

SmartBuild is the sequence of 14 steps for developing business process management (BPM) and business rules engine (BRE) solutions with Process Commander. Each step describes how to design and build specific components. You perform these steps and the associated tasks iteratively to deliver a fully functional solution. In short, SmartBuild is the design and development process for Process Commander solutions. This book is your guide to SmartBuild.

The foundation of SmartBuild is a philosophy of iterative development, object reuse, and rapid deployment — all key principles of object-oriented design. The SmartBuild philosophy extends beyond the technology itself to the holistic concept of the smart system — that is, a system with the ability to drive (not just record) the work. Smart systems have business-driven flows and rules that impose specialized requirements on the design and development process. Addressing this process requirement is an integral dimension of SmartBuild.

This combination of process and philosophy is a critical differentiator that makes it possible to deliver solutions quickly and evolve them easily as the business dictates — in other words, it is how SmartBuild actively promotes the ability to Build for Change TM .

Fundamental SmartBuild Design Principles

Process Commander is an object-oriented development environment. You can use many popular object-oriented techniques to analyze requirements and document the design. For example, you might prefer use case diagrams and/or unified modeling language (UML) tools. Regardless of the technique you use, follow these SmartBuild principles for a successful design effort:

Define objects first; then define process flows. Individual categories of work (or work objects) form the foundation of a Process Commander application. For example, a check or credit card exception, a medical or insurance claim, and a purchase order are work objects. They drive all other aspects of your application — behavior and data. You start the design process by defining the basic work objects that your application will handle. These work objects form the skeleton of your class structure, which defines data and

Using SmartBuild — Smart Design for Smart Systems

1-5

design element relationships. Finally, you define the process paths (or flows), along which the work objects progress.

Reuse and iterate. Reuse is a timesaving advantage of object-oriented design, and iteration is the key to reuse. Always start simply and add complexity gradually. For example, don’t try to identify all work object properties in one step. Use the standard objects and properties that come with Process Commander. Then refine the structure by adding specialized work objects, properties, and other design elements. Each time you add something new, first check if something similar exists or whether it can be shared with other existing objects. SmartBuild design capabilities make this approach quick and easy.

Start with a standalone application; connect with other systems later.

Interfaces to and from other systems typically present analysis, development, and security challenges. Many of these characteristics change as your design evolves. To avoid significant delays and later rework, create sample data in the Process Commander database as a placeholder for future automated interfaces to and from other systems.

Based on these themes, Figure 1-1 on the next two pages illustrates the SmartBuild process and provides a checklist for designing Process Commander applications. For more information on design principles and guardrails for success, see Appendix A.

1-6

Step1: Roadmap to Building a Process Commander Application

1-6 Step1: Roadmap to Building a Process Commander Application F igure 1- 1. Smar tBuild ó

F igure 1- 1. Smar tBuild ó Smar t Design f or Smar t Syst ems

Using SmartBuild ó Smart Design for Smart Systems

1-7

Using SmartBuild ó Smart Design for Smart Systems 1-7

1-8

Step 1: Roadmap to Building a Process Commander Application

What SmartBuild Is Not — the Role of a Project Methodology

A logical design/development process and philosophy are not enough. The tasks of designing and building the application components are only part of delivering a solution. You also need business requirements, project management, documentation, and testing, as well as a range of other critical efforts. To delineate and coordinate all of these aspects, most software projects employ a project methodology to structure the project with milestones/deliverables and guide the implementation from start to finish.

SmartBuild is not a project methodology. In keeping with the open architecture of Process Commander, SmartBuild can work with current types of project methodology. Your team follows SmartBuild steps iteratively within a project methodology. SmartBuild neither requires nor promotes the use of a specific project methodology, deferring the choice to project or organizational standards. It doesn’t impose a project structure or document templates. Instead, its component steps map smoothly to most project structures.

Why Choosing an Iterative Project Methodology Is Important

Follow a project methodology that supports the SmartBuild philosophy of iterative design/development and rapid deployment. For maximum benefit and efficiency, the goal is to identify a Quick Win business opportunity, implement an initial solution quickly, and evolve it incrementally. Look for guidelines that emphasize active user involvement, iterative design methods, and frequent, smaller deliverables, rather than an old-fashioned waterfall approach.

An iterative project methodology leverages the object-oriented principle of reuse, delivers incremental and measurable results faster, and emphasizes small deliverables based on regular managed inspection and adjustment of requirements. In most IT environments, an established best practice is to use an iterative methodology to keep pace with business needs.

Using SmartBuild — Smart Design for Smart Systems

1-9

For more information about this type of methodology, here are some options to consider:

IBM Rational Unified Process® (RUP)

(www-306.ibm.com/software/rational/)

Scrum (www.controlchaos.com)

Extreme programming — XP (www.extremeprogramming.org)

Spiral model (www.ieee.org)

Naked objects (www.nakedobjects.org)

The New Methodology (www.martinfowler.com)

How SmartBuild Delivers Results Better and Faster

The Process Commander development environment includes hundreds of BPM-appropriate objects, rules, and capabilities that are ready for immediate use no additional development required. You can quickly get a basic, working application (not just a prototype) up and running by making small changes to adapt these features for your business needs. Process Commander also includes easy-to-use accelerators, such as the Application Accelerator, which can significantly reduce your application setup time once you have done the upfront design work.

SmartBuild shows you when and how to use these tools and incorporate components for optimal results. By following SmartBuild in sequence and iterating over steps where appropriate for your project, you automatically take advantage of all the built-in design and implementation tools. SmartBuild will save you work, your solution will be up and running sooner and the architecture will readily accommodate business-driven change. As the Process Commander platform evolves, your solution will naturally take advantage of the newest technology.

What You Completed

Reviewed the SmartBuild process for designing and developing applications.

Selected an iterative project methodology, if not already adopted.

1-10

Step 1: Roadmap to Building a Process Commander Application

Understanding the Process Commander Object Model

Familiarity with th e con cep ts, b en efits, and te rms of obj ect orien tation is h e lpfu l as you design and bu ild Process Comman der app lications. Based on th e Jav a progr ammin g languag e, Pro cess Comman der in corpor ates inh eritance, reu se, information hid ing, and en cap sulation. How ever, some distin ction s are imp ortan t to und erstand . Figur e 1 -2 contr asts obj ect orien tation con cep ts (found in Jav a and similar langu ag es) w ith simil a r f eatures of Process Comman d er.

1-10 Step 1: Roadmap to Building a Process Commander Application Understanding the Process Commander Object Model

Figure 1- 2. Contrasting Process Commander and Conventional Object-Orient ed Concepts

In Java, classes, attribu tes (fie lds), and me thod s are defined through code, cr eated and tested by software deve lopers. A sing le form of class inheritance is dominant.

In Process Commander, two types of inheritanc e ar e supported. Developers work b y cr ea ting ru le s and u sing Ru leSe ts. Pro c ess Command er conv erts ru le s in to corr espond ing Jav a code to ex ecu te th e correspond ing ru les. Because man y typ es of ru le s — includ ing flow rules th at imp lemen t bu siness pro cesses — do no t requ ir e programmin g sk ills, bu sin e ss an alysts and o th ers who are no t IT prof ession a ls can p artic ip a te in th e app lic a tion d ev e lopmen t effort.

Identifying Components of an Application

1-11

Identifying Components of an Application

The following sections provide a preview of the components of a Process Commander application

What you create to develop the application

What you configure to identify users and implement security

What standard quality management and reporting features to incorporate

What database management and system integration capabilities to configure

Rules to Define the Appearance and Logic of the Application

Every Process Commander application consists primarily of a collection of rules as well as other components. What you need to develop or tailor depends on your business process. To automa te simple processes, applications need only a few custom-built elements, while complex processes usually require many more. Figure 1-3 describes components of your application defined by rules.

Component

Description

One or more RuleSets

Containers for the rules in your application.

A class structure, including a top-level class

Foundation of your application. Your classes and properties, combined with those in the standard Process Commander class structure, define the work being done and the data being captured.

HTML-based forms, tailored for your work

Face of your application — what business users and managers see and interact with when using the application.

One or more flows, created using Microsoft Visio

Traffic directors for your application — to control how work moves through a business process.

Activities and decision rules

Muscle of your application — to add the automation to process work based on business rules.

Flow actions

Forms that record user input and decisions to advance work through a flow.

1-12

Step 1: Roadmap to Building a Process Commander Application

Component

Description

Correspondence

Communication channels (such as e-mail) to and from your application to inform other people or systems automatically about work status.

Services

Requests from external syst ems for information and processing performed by your application

Connectors

Requests from your application sent to external systems (or external databases) for information or processing.

Figure 1-3. Typical Application Components Defined by Rules

Standard Rules to Provide Reusable Building Blocks

You don’t need to start from scratch to build an application. Process Commander includes hundreds of useful building blocks, known as standard rules, for you to use as a starting point. For example, the application user interface consists of a set of HTML-based forms that you tailor for your application.

Many standard rules require little or no modification for use in an operational application. Of course, you also create your own application-specific objects and rules as needed. Your own library of reusable rules suited to your environment will grow over time as you build more Process Commander applications.

In this book, the words create , update, and edit are used to describe your development process in building and evolving rules. In the context of Java development, the corresponding term is instantiate. Technically, creating a property rule is equivalent to “instantiating a persistent instance of the Rule-Obj- Property rule type.”

For data objects, the verb configure is often used as an alternative to create . The content of data objects may change more often than the content of rules. The verb tailor is a shorthand term for overriding a standard rule by copying it and customizing the copy. The term application-specific rule means any nonstandard rule, a rule your team creates in support of your application.

Identifying Components of an Application

1-13

Data Objects to Identify Situational Values and Implement Security

In addition to the rules that you create or tailor, a Process Commander application as it operates relies on basic information about your business for identification and security purposes. Some of these elements are specific to your application, while others are shared across all applications in your Process Commander environment. They are not rules or processing logic, but data objects, instances of classes derived from the Data- base class. The task is to configure — record and manage — such information.

The security model lets you control access at different levels, including RuleSet, organization hierarchy, job function, user, and class. Figure 1-4 shows what an administrator needs to configure for a typical application.

 

Shared Across

Component

Applications?

Description

Organization

Yes

Business structure of your organization, including application

hierarchy

developers and users.

Users

Yes

People in your organization who build, use, or evolve any Process Commander application.

Access

Yes

Groups of people who perform similar job functions in applications.

groups

Access groups control portal layout and application access.

Access roles

No

Designated process responsibility within a specific application. Access roles refine application access by operation and class.

Calendars

Yes

Identifies the workweek and business holidays for a year,

Figure 1-4. Typical Application Components Configured Using Data Objects

1-14

Step 1: Roadmap to Building a Process Commander Application

Standard Quality Management and Reporting Features

Process Commander includes features that support continuous improvement and process management. These features can provide valuable quantitative data to help supervisors and managers identify opportunities for improving your business processes. You can take advantage of these basic building blocks in your application without significant development effort (Figure 1-5).

Component

Description

Quality management

Tools that promote process improvement. You can easily add service level

features

rules, statistical sampling of completed work for quality review, and process cost calculations to your application.

Reporting features

Tools that support business process management. Dozens of standard reports and graphs help you analyze work progress and quality. You can also design custom reports using the Report wizard or third-party tools.

Figure 1-5. Standard Quality and Reporting Features

Identifying Components of an Application

1-15

Databases and System Interfaces

Process Commander is based on an open database architecture that works with Microsoft SQL Server, Oracle, and IBM UDB/DB2 database software. See the Platform Support Guide PDF document (located on the Pegasystems Developer Network) for the latest list of supported platforms, application servers, and databases. Process Commander stores rules, work objects, and other objects in a database known as the PegaRULES database. More information about working with this database is provided in Step 12: Configuring System Interfaces and the PegaRULES Database.

For some applications, you may need to modify the PegaRULES database, access it with third-party reporting tools, or exchange data with other systems. These development tasks are typically done towards the end of your application development effort. Figure 1-6 lists data-related components that you may need to work with as part of developing your Process Commander application.

Component

What to Do

PegaRULES database

Modify tables or columns based on your class structure and reporting needs.

Services

Implement interfaces initiated by other systems to access your Process application.

Connectors

Implement interfaces initiated by Process Commander to access external systems.

Figure 1-6. Database and System Integration Components

What You Completed

Reviewed the components of a Process Commander application.

1-16

Step 1: Roadmap to Building a Process Commander Application

Understanding Process Commander Job Functions

Before assembling your project team, make sure you understand the Process Commander job functions:

Business user — a person who uses the application you build to receive, process, and resolve work.

Business manager — a person who uses the application you build to monitor/approve work performance and quality for one or more groups of business users.

Developers and implementers — three types of people who build and evolve Process Commander applications:

Process architect — a business analyst who defines and maintains business rules, service levels, and flows or processes.

System architect — an application developer who creates the class structure for your work with supporting automation capabilities, and implements interfaces with external systems.

System administrator — a systems engineer who is responsible for installation and setup, security, and other operational functions.

Step 11: “Setting Up Access and Secur ity” discusses in more detail how the security model controls access to information and features that are appropriate for a user, and how to apply it in your application. Basically, users automatically see portal layouts specific to their job function when they log in to Process Commander. See the Administration and Security book for more information. It is important to make sure that each function is represented on your project team.

Understanding Process Commander Job Functions

1-17

Recommended Skills

Consider the guidelines in Figure 1-7 as you assign project team resources to Process Commander roles. For a successful project, you need some people with Process Commander training and certification credentials on the team. In addition, experience and aptitude for learning new tools/skills are important attributes of team members.

Development Team Role

Preferred Experience

Process architect

Business process flowcharting

User interface design

Business logic definition

Some familiarity with scripting or application macro tools (HTML and JavaScript preferred)

System architect

Data modeling and relational databases

Object-oriented and modular design

Moderate level of programming expertise (Java

preferred) System connectivity and interfaces

System administrator

Hardware and operating system administration

for your platform User and network management tools

Database management tools for your database platform

Figure 1-7. Development Team Roles and Skills

1-18

Step 1: Roadmap to Building a Process Commander Application

Assembling a Project Team

As with any business process management solution, you need the following resources on your Process Commander project team.

Project Management Resources

Project manager with business and technical expertise relevant to the application purpose to run the project.

One or more trained and experienced Process Commander guide/facilitators, typically either from Pegasystems or an authorized partner.

Business Resources

Two or more people who work in the business area (at least one business user and one business manager) to test your application.

Business analyst to provide business requirements.

Process architect — a business or process analyst for business process definition and maintenance. Familiarity with HTML is helpful but not required.

Technical Resources

System architect — an application developer with Java experience to handle complex design tasks and interfaces with external systems.

Note: You may need more than one system architect, for example, one system architect with Java experience, and one or more system architects with experience setting up interfaces to other systems.

Understanding Process Commander Job Functions

1-19

System administrator — a systems engineer with experience on your selected platform to handle software installation, security, and maintenance.

Database administrator — experienced with your selected database to handle database installation (if necessary), setup, and maintenance.

The number of people you need depends on the size of your organization and the complexity of your business process. As a guideline, a project team of this size — one person per job function, or approximately eight people — is adequate for developing and deploying a Process Commander application that supports as many as several hundred users. Obviously, the amount of dedicated time expected for each resource depends on the size and complexity of your application.

What You Completed

Identified the project team, including trained/certified Process Commander resources and additional training requirements.

Assigned the standard Process Commander functions to appropriate team members.

1-20

Step 1: Roadmap to Building a Process Commander Application

Mapping SmartBuild to a Typical Project Structure

As a starting point for your project planning, Figure 1-8 shows how SmartBuild maps to the phases of a generic project structure. Following an iterative project methodology, start small and deliver an initial application with the core capabilities needed to support your business process. Then evolve the application over time. Use quality management features to identify opportunities for process improvement. This approach supports most process scenarios and promotes rapid development and deployment.

Phase

Key Job Functions

Description

Define

Business analyst

Analyze your business process and map its characteristics to a

Process architect

Process Commander solution (Step 2).

Design

System administrator

Set up your Process Commander development environment.

and Build

System architect

Design the class structure for your work and identify the data

Process architect

elements (Steps 3 — 6). Iterate as needed.

 

Tailor the user interface and implement flows with process

details (Steps 7 — 9). Iterate as needed. Add communications and security features. Configure any external system interfaces (Steps 10 — 12). Iterate as needed.

Test

Business users

Select several business users to use the functions of all workflows

Business managers

(Step 13).

Process architect

Deploy

Process architect

Move the completed application to your production environment and

System administrator

make it available to users (Step 13).

Improve /

Business analyst

Use your application as the basis for continuous improvement. Use

Evolve

Process architect

reports and graphs to assess work and process quality, and then add new capabilities and work groups (Steps 13 — 14).

Figure 1-8. SmartBuild Within a Generic Project Structure

Mapping SmartBuild to a Typical Project Structure

1-21

How Iteration Applies to SmartBuild

Each iterativ e proj ect me thodo log y and proj ect team h a s its own appro ach for s egmen ting a proj ec t in to a se rie s of ite ra tion s and r e le ase s. You can map th e Sma rtBu ild step s to your itera tive appro a ch, withou t chang ing th e step sequen c e.

Fo r ex amp le, Figur e 1 -9 illustrates the project stru ctur e and dur ation for deliv ering a Qu ick Win with SmartBu ild. Th is approach is th e simplest form o f an iterative proj ect. First you id en tif y some th ing with standalon e bu sin ess v a lue that you can d e liver with in 60 to 90 d ays, wh ich is typ ically a sub s et of a larg er bu sin ess pro cess. Then p erform Steps 1-14 in ord er and release the in itial app lication fo r produ ction. Dep end ing on th e n a tur e and comp lex ity of the work, you may also n eed to iterate ov er r e lated segmen ts of SmartBu ild ( Step s 3 to 6, 7 to 9, and 10 to12) and seek busin ess feedb a ck. Subsequen t projects (or iter a tions) would address o ther d efined parts of th e bu sin ess pro cess.

Mapping SmartBuild to a Typical Project Structure 1-21 How Iteration Applies to SmartBuild Each iterativ e

F igure 1- 9. Deliver ing a Quick Win wit h SmartBuild

What You Completed

Mapp ed SmartBu ild to you r proj ect me thodo log y.

Estab lish ed the proj ect stru ctur e and h igh-level project p lan.

1-22

Step 1: Roadmap to Building a Process Commander Application

About the Examples

Th is book uses th e fo llowing examp les to h elp you get started bu ild ing Pro cess Commander applications:

Peg aSamp le includes b asic compon en ts for reso lv ing work ( Figur e 1-10).

Th e application called PegaRP is a basic ta sk management produ ct with cap ab ilities fo r tr ack ing d evelopmen t proj ects and rela ted ta sk s.

YourCoLo an is a loan request app lication with capab ilities for accep ting and pro cessing various types of con sumer lo ans.

The Sample Work Application

Th e s amp le app lica tion n amed Samp le Work in c lud es th e b asic compon en ts tha t you n e ed to create and r e solv e four types of work, as shown in Figur e 1-10.

1-22 Step 1: Roadmap to Building a Process Commander Application About the Examples Th is book

Figure 1- 10. Entering New Work in PegaSample

Th is app lication is availab le to an y u se r who h as PegaSamp le listed in th e All Class Groups of Work in an access group. (PegaSample is by default available to op era to rs cr e ated b y th e In itia l Se tup wiz ard). Us ers can se le c t th e app lic a tion and en ter work to b ecome famili a r with th e d efau lt us er in terfa c e. Us ers c an cr ea te and examine rule s to se e th e elements of a simp le Process Commander application.

Step 1 Completion Checklist

1-23

Step 1 Completion Checklist

After finishing this SmartBuild step, check that you have the following components before continuing.

Application opportunity and Quick Win first project identified (prerequisite

for the other components). Overview of the SmartBuild process for designing and developing

applications. Iterative project methodology selected.

Understanding of the components that are part of a Process Commander

application. Process Commander job functions in relation to individuals on the team.

Project team selected and assigned to job functions, including

trained/certified Process Commander resources and additional training requirements. SmartBuild steps mapped to your project methodology.

Project structure and high-level project plan established.

Step 2:

Analyzing Requirements

After you have a team and a high-level plan in place, Step 2 of SmartBuild involves assessing the requirements of your application. This step describes what you need to know about the business process you want to automate:

What is the nature of the work, including the business purpose and primary

units of work? Which organizations, people, and interested parties are involved?

Does the work involve existing systems or data sources?

Do you need to localize the solution (for example, for language and currency)?

What are the major, high-level user scenarios?

Are you building an application or a product?

This step also introduces how this information applies to a Process Commander solution, including key concepts and terms.

Who Does This: Business analysts and/or process architects typically perform these tasks.

2-2

Step 2: Analyzing Requirements

A Different Approach to Requirements Analysis

In contrast to the classic waterfall development approach and many other methodologies, SmartBuild does not require or promote extensive initial effort and time in developing requirements. Because Process Commander includes a set of building blocks, known as standard rules for business process management applications, you are rarely starting from scratch. For example, its predefined forms have built-in, functional behaviors and work properties. You can extend these components to suit your business needs and add more at any time.

The most direct and rapid route to an operational application is to use these building blocks, making only modest changes at first. Then extend these elements further as you become familiar with their characteristics. In this context, you tailor existing components to your requirements, rather than build everything you need from scratch. This approach also simplifies your analysis:

For best results, keep your upfront analysis restricted and object-centric.

Follow the guidelines in this step and resist the temptation to define in detail at

this time how work is entered or processed. For now, treat a process as an interface and think only of the object (or class) of data returned. This approach lets you deliver consistent application results faster, and avoids rework later.

Describe completed work, rather than the underlying process that produces

it. Assume that you are researching an issue at some time in the future by examining an archive of completed work. This technique streamlines your analysis process. Object analysis occurs at the beginning because its purpose is to establish the class structure that is your application foundation. Detailed data analysis is done later.

Most importantly, become familiar with the standard objects, behaviors,

and properties. Consider tailoring the existing elements first before defining your own design elements. This approach reduces both upfront analysis and the scope of custom development.

With these guidelines in mind, you can begin analyzing the requirements for your solution.

What Is the Nature of the Work?

2-3

What Is the Nature of the Work?

Moving forward with the recommended design approach, start by defining what your application does and then move on to how. A logical place to begin your business analysis is to establish the type of work the application will manage. Because Process Commander is object-oriented, this task consists of identifying the fundamental objects that represent work in your application:

Describe the primary business purpose (or work process) that the application will manage. Include what part of your business the application supports.

Describe the major units of work (or work objects) that the application will handle. Categorize them, if appropriate. Together, they form the major classes and subclasses in your class structure.

Your objective is to establish the basic purpose and structure of your application’s work classes, not a detailed design. Plan to spend no more than several hours on this task, even for complex applications. At this stage, don’t try to create a detailed requirements document. A realistic goal is a one- or two-page description, ideally with phrases and lists. In keeping with an iterative design approach, refine these decisions as you create the class structure.

Note: For rapid development, limit your initial analysis to the primary types of work objects. This approach keeps your class structure simple and easy to manage at first. You can always add work objects later.

2-4

Step 2: Analyzing Requirements

PegaRP Example

Figure 2-1 describes the work that the PegaRP example application supports.

What You Need to Define

As Defined for PegaRP

Purpose of the work

Record, track, and manage the effort associated with developing and supporting a Process Commander application or product.

Completed units of work that can

Software tasks to perform (such as a support request).

be represented as work objects

Projects that group related tasks.

Figure 2-1. Description of Work in PegaRP

Helpful Hints

If you’re familiar with other object-oriented design tools, you may be tempted to define your work objects in detail now. Instead, follow an iterative approach to top-down design, focusing on the high-level objects only.

For now, don’t think about defining all characteristics (or properties) of work objects. Process Commander includes an extensive set of standard work properties that you can reuse for efficiency. However, you can easily extend them to suit your needs. You learn about extending properties in Step 6, “Adding Properties and Sample Data.”

As a guideline, a work object should be an entity for which you want to drive data entry, priorities, deadlines, and reporting. Its name should be a noun. For example, Code meets these criteria in the PegaRP example and is thus an appropriate type of task work object. However, problem severity might be better defined as a property of a work object, rather than creating separate classes of work objects for the different severity levels.

What Is the Nature of the Work?

2-5

In defining work objects, consider only completed work in your application. Review your object names for clues:

Avoid defining work objects with names that reflect process state (such as DeferredTask or ClosedTask), or with names that don’t transcend work completion (such as NewTaskRequest). Deferred, closed, and new describe the state of an object. Thus, these names would be status properties of the object, not separate objects.

Avoid objects with names that are too generic (such as Task). Instead, use object names that reflect a specific type of task (such as Code, Rule, or Documentation).

Process Commander provides other features such as service levels to address detailed processing and quality requirements. For more information, see Step 14:

“Leveraging Work Reports and Quality Features.”

What You Completed

Described in a few sentences or phrases the business purpose and primary work process for your application.

Identified the major types of work objects in the application, including subcategories.

2-6

Step 2: Analyzing Requirements

Who Performs the Work?

After you identify the type of work managed in the application, you need to determine who performs the work. This task consists of identifying the business groups and people that compose the user community for your Process Commander application:

Determine which business areas will use the application. These entities are part of the organization hierarchy for your Process Commander environment, which mirrors your business reporting structure. The hierarchy is built on the nested levels of organization, division, and unit. Division names must be unique within the organization, and unit names must be unique within a division. You can also use work groups to group related people across the hierarchy for matrix management requirements.

Identify the key people who will develop and use the application, including their job function (such as business user, system architect, etc.) and process responsibilities. Operator IDs enable these authorized users to access the system, access groups reflect their job function, and access roles reflect their process responsibilities.

Note: This task applies only to the people who directly do work in the application. For now, you need not identify other interested entities and people (or work parties) that are impacted by, but not directly responsible for, the work process. Identifying work parties is the next task.

Your objective is to identify the business areas and individuals that are the primary users of the application. You can add to the organization structure at any time, so you don’t need to define the structure completely at this point. However, organization information is shared across all applications on a Process Commander system and is also the basis for security features that control what users can see and do. Considering these issues early can save time because they affect other aspects of your analysis and design.

Who Performs the Work?

2-7

Defining the Organization Hierarchy

Internal organization structures tend to be dynamic, especially when viewed over several years. This factor is significant for BPM solutions, as resolved work typically persists over time to support historical analysis. Additionally, most companies today have existing systems for managing the details of their organization structure.

Process Commander is designed to record only the essential details that uniquely identify the work-relevant organizational entity in a way that is not redundant with existing systems of record. Thus, the Process Commander organization hierarchy consists of exactly three levels (as represented by unshaded boxes in Figure 2-2).

Organization — top level, which identifies the company entity. It is especially

useful for segmenting work in environments where a single system processes the work of more than one company (such as at service bureaus). Division — second level, which identifies another high-level entity of

the company (sometimes a sub-company). For example, you might use the structure of your company’s senior management team as a starting place for the entities at the division level. Unit — lowest level, which identifies the most specific level within the division.

Who Performs the Work? 2-7 Defining the Organization Hierarchy Internal organization structures tend to be dynamic,

Figure 2-2. Process Commander Organization Hierarchy

2-8

Step 2: Analyzing Requirements

In Process Commander, the most important level for work identification purposes is the lowest level (the unit). In reality, a particular unit number (or other identifier) might not be unique without the associated organization and division values. For example, two different divisions of a large company might both have an Accounts Payable unit or a #2534 unit. Using a three-part identifier consisting of the organization, division, and unit therefore ensures its uniqueness.

Obviously, organizations commonly have many levels between the second and lowest levels (division and unit), as represented by the shaded boxesin Figure 2-2. Recording all possible levels in Process Commander would impose redundancy with other data sources. It would also introduce maintenance issues (especially for large organizations) associated with frequent unit reorganization within the larger reporting structure. Therefore, Process Commander doesn’t require or use the interim levels.

In contrast, organization units (and cost centers, which can also be recorded in Process Commander) tend not to change as frequently or significantly.

What to Do Now

Using either paper or a software tool of your choice, create an organization chart diagram that illustrates your hierarchy as it is to be recorded in Process Commander.

Depending on your company, your organization hierarchy can range from simple to complex. Most companies create a single organization for ease of maintenance. You must also have at least one division and one unit. A small company might have only a few entities at each level in the hierarchy, while larger companies might require many entities at all levels.

Initially, identify only the business areas that will either be the primary users of your application or interested work parties. For example, you might decide to exclude the marketing department for now if it isn’t directly involved in or impacted by your application work process.

The organization hierarchy is shared across all applications on a Process Commander system. To avoid confusion and promote reuse, make sure that the entities you define

Who Performs the Work?

2-9

accurately reflect the fundamental business structure of your company. If you are building a product for resale, you also need to define a separate sample organization that represents an expected customer implementation.

Note: Following a top-down approach helps you establish a structure for your organization hierarchy that is scalable across applications.

Figure 2-3 shows a typical hierarchy, which is a good starting point. Note that the Information Systems and Sales and Service divisions both have an Operations unit, each of which can be uniquely identified by the organization, division, and unit.

Who Performs the Work? 2-9 accurately reflect the fundamental business structure of your co mpany. If

Figure 2-3. Typical Organization Hierarchy

2-10

Step 2: Analyzing Requirements

Identifying the People Who Perform the Work

After establishing the business areas that use the application, you next identify the people who perform the work. Think about people who use Process Commander applications in two dimensions:

An access group represents a person’s job function and allowed actions in a Process Commander environment. It controls the applications, portal layout, and groups of work (or work pools) you can access. Access groups typically mirror Process Commander job functions.

An access role represents a person’s authority level relative to part of the work process. It controls access to specialized application capabilities. Access roles often pertain to a specific process, but can be shared across applications if defined appropriately. Several roles may collectively define the overall responsibilities for an individual.

Your objective is to describe the application users based on these categories. You can list the known people first and then map them to access groups and identify any necessary roles. Alternatively, you can map roles to access groups first and list the people later.

PegaRP Example

Based on the PegaRP example, Figure 2-4 illustrates the typical access groups and roles.

Access

As Performed in PegaRP

Need Custom

Group

Description

(Function and People)

Access Role?

Business

Anyone who enters new work in

Application users

No

user

PegaRP

Design and development staff

Business

Managers who assign work and monitor

Design manager

Yes — restrict

manager

progress in PegaRP

Development manager

the ability to

 

Documentation manager

assign/report

QE manager

on work

Who Performs the Work?

2-11

Access

As Performed in PegaRP

Need Custom

Group

Description

(Function and People)

Access Role?

Process

Business analysts who perform work

Design and development staff

No

architect

(business rule changes) in PegaRP

with an assigned worklist

System

Application developers who perform

Development staff with an

No

architect

work (system rule changes) in PegaRP

assigned worklist

System

System administrators who perform

Operations staff with an

No

administra-

work (system administration tasks) in

assigned worklist

tor

PegaRP

Figure 2-4. PegaRP Access Groups and Roles

Helpful Hints

Restrict your initial analysis to the primary application users as you can always add more users later. However, keep in mind the overall structure of your company.

While the organization hierarchy must be shared across all applications on a Process Commander system, access groups may be shared if that makes sense.

When you identify the people who use the application, include the people who are responsible for developing and maintaining it.

Think of an access role as the ability to selectively grant access to actions in a process. Use them sparingly for ease of management.

System administrators are typically responsible for setting up and maintaining the organization structure (including individual people). Creating a spreadsheet is helpful in compiling and organizing the organization information for administrators.

What You Completed

Identified primary groups of people that use the application, organized by business structure.

Identified primary individuals that perform work in the application, including their job function and any specialized roles in the work process.

2-12

Step 2: Analyzing Requirements

How Does the Work Impact Other Entities or People?

Process Commander supports the concept of work parties, which identify entities and/or people impacted by the work. Work parties are interested in the progress and resolution of a particular work object, but do not perform work in the application. Typical work parties to consider include:

Customers (typically the primary party in applications that support customer- facing processes such as call centers).

Staff members who are interested in or impacted by, but not directly responsible for performing, work that is managed in the application.

Related external organizations (such as service providers, partners, government agencies, and regulatory bodies) or people.

Affected facilities in your company.

Next identify the work parties for your application. Process Commander includes several work party types you can use as a starting point. More information about work parties is included in Step 4, “Designing the Class Structure.”

PegaRP Example

The PegaRP example uses two of the standard work parties (Figure 2-5).

Work Party

As Defined for PegaRP

Person

An external customer for whom someone originates a work object in PegaRP.

Operator

An employee who is interested in the work object resolution, but is not responsible for performing the work.

Figure 2-5. PegaRP Work Parties

What You Completed

Identified work parties that are impacted by, but not directly responsible for performing, the work managed in the application.

Who Performs the Work?

2-13

Does the Work Involve Other Systems?

Process Commander applications usually complement, not replace, other systems and technologies that you may already have in place for doing work. You can use these applications as standalone solutions or components integrated with legacy systems. Using integration services (Step 12), your application can access both data and processes in both directions. The next task in your analysis is to establish whether the application needs to interact with existing systems.

In evaluating integration requirements, consider these scenarios:

Create and populate a work object in a Process Commander application directly from an existing system, perhaps with customer details from a Customer Relationship Management application from Pegasystems or Siebel Systems (using SnapStart, a desktop data import facility, to access Process Commander).

Access data or processes in the original system of record by dynamically reaching out from a Process Commander application (using connectors).

Access data or processes in a Process Commander application from an existing system, such as SAP R/3 or Oracle PeopleSoft (using services).

Your objective is to identify any other systems involved (such as SAP R/3) and the type of information needed (such as a product list). You don’t need to define integration mechanisms, file layouts, or data fields now. Process Commander has integration services for this purpose (see Step 12: “Configuring System Interfaces and the PegaRULES Database”).

PegaRP Example

The PegaRP example doesn’t require access to or from other systems. All supporting data are recorded directly in the application.

What You Completed

Identified existing systems or data sources that may share data or processes with the application.

2-14

Step 2: Analyzing Requirements

What External or Predefined Reports Are Required?

For some applications, reporting requirements in specific formats are mandated by government, regulatory agencies, or corporate departments. These may require specific data elements or computations that are not otherwise captured during the course of completing the work.

As part of requirements gathering, identify such needs, and review the source and value of each reporting need. Typically, the primary focus of Business Process Management applications is completing the work effectively and efficiently, not gathering data for external use. Process Commander applications automatically gather data about the business process itself — as described in Step 14 — but this data may not meet external reporting needs.

List each report (or external data feed) needed as an output of the application. Review carefully the definitions underlying each external or mandated report format so that the business process and if necessary the work object forms of your application can support capture of the needed data elements.

When external reporting requirements are mandated, project sponsors need to note the following: gathering data needed only to support reporting requirements, rather than data needed to process the work efficiently, may add to processing costs.

Do You Need to Localize the Solution?

2-15

Do You Need to Localize the Solution?

Localize means to build solutions that are suitable for use in one or more specific locales (languages, countries, and cultures). Building such applications requires specialized capabilities. When you follow SmartBuild to build a Process Commander application, you can add support for additional locales if needed. The SmartBuild steps involved in localizing an application include:

Step 3:

Dimensions of locale and built-in support

Step 4:

Setting and changing the user locale

Step 5:

Defining an alternate business calendar

Step 6:

Presenting the user interface in different languages

Step 7:

Handling currency

Who Does This: Process architects, system architects, and system administrators each perform different aspects of these tasks.

Important Terms and Concepts

The following terms and concepts relate to localizing an application:

Locale refers to the features of the user’s environment that depend on language, country, and cultural conventions, including aspects such as date and time format, currency symbol and format, and character sorting order.

The Unicode Standard, developed and maintained by the Unicode Consortium, establishes a universal scheme for handling text in all character sets.

Process Commander incorporates industry-standard Java libraries (International Components for Unicode, or ICU) to present currency, dates, time, and other regional information in the most appropriate way for each locale.

The International Organization for Standardization, commonly referred to as ISO, is a coordinated network of national standards institutes that establishes a

2-16

Step 2: Analyzing Requirements

wide range of international standards for business, government, and society. ISO standards related to localization include date/time formats and currency codes.

With an overview of the work and the participants, next consider the localization requirements for your solution. First determine whether you plan to implement the solution primarily in a single locale (such as the east coast of the United States) or across multiple locales (such as New York, London, Paris, and Zurich). Then evaluate the key dimensions of the locales you need to accommodate, as shown in Figure 2-6.

Dimension

Considerations

Geography

Where are you primarily building and maintaining the solution?

Where is the work performed?

If users interact with external customers, where are they located?

Language

In what language(s) do the participants primarily perform work?

If users interact with external customers, what languages do they prefer to speak?

Currency

Does the work involve any monetary amounts? If so, in what currencies?

If the work involves multiple currencies, do you need to be able to convert between them (or simply store/display them)?

Figure 2-6. Localization Requirements

Basic locale support is built in and requires no development. To deliver a localized solution, you design and build the application for one locale. Follow the process in this book, as you would for a solution that doesn’t require localization. You then add rule-driven presentation capabilities for each additional locale, without significant recoding.

PegaRP Example

PegaRP is designed for use in a single locale. The work does not involve currency values and the user interface is currently single-language (US English).

Do You Need to Localize the Solution?

2-17

For More Information

For more information about localizing a Process Commander application, see “Guidelines for Localizing Your Application” at www.pega.com/support. You can also find a wide range of printed and online sources about localization. Here are some options to consider:

For an overview of localization:

eBusiness Globalization Solution Design Guide by IBM

www.redbooks.ibm.com/redbooks/pdfs/sg246851.pdf

For more information about Unicode:

www.unicode.org

For more information about ICU:

www.ibm.com/developerworks/oss/icu4j/index.html

For more information about ISO standards that apply to localization:

What You Completed

Identified the primary locale(s) that the solution needs to accommodate.

2-18

Step 2: Analyzing Requirements

What Are the Major User Scenarios?

As discussed earlier in this step, you can defer the detailed definition of work entry and flow requirements. This approach helps you take advantage of (rather than inadvertently duplicating) the many built-in capabilities in Process Commander. You have established the nature of the work in the application, the entities and people who are involved with it, other systems that might be impacted, and the primary locales (or geographies) where the users are located.

The remaining dimension is to establish how people will interact with the application. Defining this information now is useful for several reasons:

It influences some of your earliest design decisions regarding the class structure (or foundation) for your application.

It supports the development of scenario-based test cases to support pre-implementation application testing.

It clearly defines the high-level business perspective, which is critical to validating the resulting application.

Your objective is to describe the major business usage scenarios in general terms. Think in terms of business functions (people) and common scenarios (interactions), rather than properties, states, or authorization levels for individual tasks.

What Are the Major User Scenarios?

2-19

PegaRP Example

The PegaRP example is designed to support the following user scenarios:

A business user enters a new work object in PegaRP:

A project, which may group several related tasks. Projects can be one of several types — enhancement, inquiry, problem, or research.

A task, which can be one of several types — code change, documentation change, support request, etc.

A business manager (triage manager, development manager, documentation manager, QA manager, etc.) reviews new projects and tasks, and takes one of the following actions:

For a project, enters supporting tasks (if necessary) and assigns the project and any tasks to staff members for resolution.

For a task, associates it with a new or existing project (if necessary) and assigns it to a staff member for resolution.

Corrects the project or task type, and takes one of these actions.

Decides to reject the project or task, and resolves it without further assignment or action.

Application development team members (process architects, system architects, and system administrators) perform and resolve tasks that appear on their worklists.

Business managers review work statistics in the standard reports and graphs to evaluate the effectiveness of the team.

While not reflected here, this example could also support an external system user scenario. For example, you could add a service to record a new work object based on an issue sent from a remote system.

What You Completed

Summarized key user scenarios for developing test cases.

2-20

Step 2: Analyzing Requirements

Are You Building an Application or a Product?

In the final part of your requirements analysis, your last task is to characterize the application type. Because of its flexibility, you can build two distinct categories of Process Commander applications:

Applications that are specifically designed, used, and evolved by a specific organization. This category includes applications that you develop for your own use, and applications that Pegasystems or its authorized partners develop on behalf of their customers.

Commercial products that are built for a particular business need and intended for distribution to and individual adaptation by many different organizations. This category includes packaged solutions available directly from Pegasystems, as well as those offered by its authorized partners. It also covers solutions that are designed for a multi-customer or application service provider (ASP) environment.

While this dimension may seem a minor part of your analysis, it is important to take a few minutes to consider it now. Your decision drives several of your early design choices, as described in the next few chapters.

Process Commander offers many features for balancing design flexibility and intellectual capital protection. For example, you make a series of decisions concerning RuleSet organization, class structure, work pool segmentation, and rule availability. Defining these fundamental components effectively at the beginning avoids significant time and effort in future rework.

PegaRP Example

The PegaRP example represents a solution that a wide range of customers can implement and tailor for their environments in different ways, so it represents the product scenario.

What You Completed

Decided whether you are building an application or a product.

Step 2 Completion Checklist

2-21

Step 2 Completion Checklist

After finishing this SmartBuild step, check that you have the following components before continuing.

A few sentences or phrases describing the business purpose and primary work of the application.

A list of the major types of work objects in the application, including subcategories.

A list of the primary groups that use the application, organized by business structure. A simple organization chart is a useful format for organizing this information.

A list of primary individuals that use the application to do work, including their Process Commander job functions.

A list of additional work parties (entities and/or people) that are impacted by, but not directly responsible for performing, the work managed in the application.

A list of existing systems and data sources that may share data or processes with the application.

A list of primary locales to accommodate.

A high-level summary of the key user scenarios for developing test cases.

A few sentences describing whether you are developing an application or a product.

Step 3:

Getting Started — Prerequisites and Setup

With your high-level requirements defined, you are ready to begin developing your application. Because Process Commander operates in a shared server environment, many people can use or develop different applications at the same time. This chapter walks you through SmartBuild Step 3, which consists of setting up the development environment for your application:

Logging in and becoming familiar with the development environment.

Understanding how the Application Accelerator streamlines initial application

development. Defining one or more RuleSets for your application.

Defining the top-level class of your class structure.

Setting up the system name, organization hierarchy, access groups, and key users.

Who Does This: System architects typically perform these tasks, with assistance from system administrators on the last task.

3-2

Step 3: Getting Started — Prerequisites and Setup

Using the Development Environment

The portal provides a single, integrated environment for building, testing, and using applications. You do not need separate design and runtime tools or environments. In addition, the open authoring feature means you can use the most effective tool for the task (such as Microsoft Visio for creating flow diagrams, Microsoft Excel for importing small amounts of data, or Eclipse for writing HTML and Java) to evolve your Process Commander application.

Saving your design elements also automatically stores the rules in the PegaRULES database, which the rules engine uses to automatically generate Java for execution as necessary. Rule updates are immediately available for testing in your application. In addition, other helpful features are a single click away:

Run built-in accelerators and wizards to streamline many tasks that you perform while building and administering your applications (in the Dashboard home layout in the Accelerators and Wizards section of the workspace).

Add rules or design elements to your browser Favorites for quick access.

Click the Help button on the Manage Rules toolbar to access the Application Developer Help system.

Import lists of properties or other information from Microsoft Excel directly into the appropriate rule in Process Commander.

Access additional developer tools from the Tools bar.

Logging In

You can access Process Commander from any Microsoft Windows ® 2000 or Windows XP workstation using Microsoft ® Internet Explorer 6.01. To develop applications, you also need Visio 2002 or Visio 2003 (also called Visio XP) Standard Edition and Adobe System’s SVG Viewer, a free plug-in available from www.adobe.com.

Using the Development Environment

3-3

Figur e 3 -1 d escribes th e compon en ts o f th e Process Comman d er URL for b rowser access.

Using the Development Environment 3-3 Figur e 3 -1 d escribes th e compon en ts

Figure 3- 1. Pr ocess Commander URL

En ter the URL in the Addre ss ba r to d isp lay th e We lcome p age (Figur e 3-2 ).

Using the Development Environment 3-3 Figur e 3 -1 d escribes th e compon en ts

Figure 3- 2. PegaRULES Pr ocess Commander Welcome Page

3-4

Step 3: Getting Started — Prerequisites and Setup

What you see n ex t d epend s on your operator ID. Us ers see d iffer en t layou ts of th e Process Commander Portal wh en th ey log in to Proc e ss Comman d er, d epend ing on th eir job function. To p rov ide qu ick access to frequ en tly performed ta sk s, th e con ten t in th e n av ig a tion p ane l on th e left and th e work spa c e of th e righ t v aries d ep end ing on your job function. In this book, th e tex t and imag es corr espond to a system ar ch itect ro le in Process Comman d er v ersion 4.2 SP2.

What You Completed

Logg ed in to Pro ce ss Comma nd er as a system a r ch itec t.

Portal Layout for System Architects

Fo r mo st of the task s in th is book, you log in to Pro cess Comman d er as a system ar ch ite c t. When you first log in, you shou ld se e th e Da shboa rd home layou t for system ar ch itects (Figur e 3 -3). Look at th e d e tails in your Profile, wh ich is located at the bo ttom of the Dashbo ard bar on th e n av igation p anel. If th e Portal Layout valu e is some th ing other th an S ystemAr ch ite c tDD, ask your system admin istrator to upd ate your op erato r ID.

3-4 Step 3: Getting Started — Prerequisites and Setup What you see n ex t d

Figure 3- 3. Dashboard — System Ar chitect Layout

Identifying the Top-Level Organization Class

3-5

Identifying the Top-Level Organization Class

After installing Process Commander, your system administrator normally runs the Initial Setup wizard to prepare the environment for application development. This wizard configures the prerequisite elements for logging in to Process Commander and building applications, including:

A skeleton organization hierarchy.

A core set of operator IDs and access groups associated with the Process Commander job functions.

A baseline RuleSet (such as YourCoAll) with a top-level class (such as YourCo-) for the organization, to be shared across applications.

Ask your system administrator for this information for your environment.

Note: Refer to the Administration and Security book for more information about the Initial Setup wizard.

3-6

Step 3: Getting Started — Prerequisites and Setup

Working with the Application Accelerator

Process Commander provides the Application Accelerator to streamline the process of setting up the foundation of your application. It guides you through the process of specifying and then automatically creating the basic components. Think of the Application Accelerator as a jump start to a simple operational application.

You can also perform these initial development tasks manually, which you may prefer to do when building very complex solutions. However, you will find that the Application Accelerator saves time and reduces effort, especially for simple applications that have a single RuleSet.

In keeping with the SmartBuild process, start small with a core set of business requirements and add components iteratively. First use the Application Accelerator to create the foundation for your application. Then use the Process Commander Portal to expand the application as your design progresses.

The first step in building a Process Commander application consists of designing its foundation — key elements such as the RuleSet, class structure, and type of work. You learn how to design these components in this and the next several chapters. Once you have designed the components, you can use the Application Accelerator to implement them quickly and easily.

The Application Accelerator automates key early steps in the SmartBuild process by implementing your application design based on the parameters you supply. The Application Accelerator replaces the tasks of defining and creating the components individually. This guided approach significantly decreases training and development time. Visual indicators record your progress, while the ability to review the results of completed steps is only a click away. You can pause or save your work at any time and resume later at the same point.

Working with the Application Accelerator

3-7

To run th e App lication Accelerato r, op en th e D ashbo ard home layou t. Find the Accelerators and Wizards section of th e work spa c e and click Cr ea te New App lication . Figur e 3-4 shows the first of sev eral forms that promp t for information abou t your app lication design in th e prop er sequ ence.

Working with the Application Accelerator 3-7 To run th e App lication Accelerato r, op en

Figure 3- 4. Application Accelerator

Note: Don’t confu se the step s you fo llow wh en u sing the App lication Accelerato r with th e SmartBu ild me thodo log y step s pr esen ted in th is book. Th e s equen c es ar e r e la ted, but th e step numb ers ar e no t iden tic a l. Th e Application Accelerator requires only six numb er ed step s.

What the Application Accelerator Creates

Th e App lication A c celer a tor au toma tes th e task s of creating th e fo llowing b asic compon en ts, wh ich are r equir ed for all Process Comman d er app lications:

A Ru leSet and version for the application, added to your access group

Simp le class stru ctur e, in cluding cov ers and wo rk-related classes

Class group (work pool) and supporting datab ase tab le

3-8

Step 3: Getting Started — Prerequisites and Setup

Work object and cover prefixes

Properties and models

Work parties rule

Work object forms (harness and section rules) with your application properties added

One or a few basic flows

Workbaskets, worklists, and work groups

For simple applications, a significant part of your structural development is done once you complete the steps in the Application Accelerator. More complex applications may benefit from expanding these components, adding capabilities such as communications (for example, e-mail, fax, or letter), or integration with other systems. Steps later in the SmartBuild process address how to design and implement these additional components, as well as how to deploy and evolve your application.

Helpful Hints

Follow the SmartBuild design principles and naming conventions described in this and the following chapters.

Document your decisions as you design your application. To use the Application Accelerator effectively, have the design documentation available for reference when you begin.

You don’t need to complete all the Application Accelerator forms in a single session. You can pause, save your work and resume work later, either in the same or a new session.

Working with the Application Accelerator

3-9

Your system administrator creates a top-level class (such as YourCo-) and a division class (such as YourCo-FinDiv- to be shared across all applications in your division. You need to know the name of these class before you begin.

The Application Parent is the top-level class for your application: For most applications, the appropriate value is a class consisting of the top-level class followed by plus a division name (such as YourCo-FinDiv-).

The Application Name is the business purpose for the application. It also becomes a segment in the class group name.

3-10

Step 3: Getting Started — Prerequisites and Setup

Planning RuleSets

As a container for components of your application, a RuleSet stores a related group of business rules. A RuleSet is what you deploy in your production environment or ship to a customer. RuleSets provide security, version control, and the ability to deploy your application in a different Process Commander environment. Each application uses a RuleSet to identify its rules.

Understanding RuleSet Names and Versions

Every RuleSet has a name and a version to help you identify and manage its contents and deployment.

The rules engine uses a combination of the rule type, purpose, RuleSet name and version, class structure, and security model to determine the correct business rule to apply in each situation as work is processed. Optional date and customer circumstance conditions may also apply. This process is called rule resolution.

When you modify a rule instance, you can save your changes to a higher- numbered version of the RuleSet without impacting the current version. You can then make the modified version of the rule available to a subset of users for testing, without affecting the rest of the user community environment.

You can also control how an individual rule is applied during rule resolution by changing the rule availability.

When a development iteration is completed, you can lock a RuleSet version to prohibit subsequent changes.

Planning RuleSets

3-11

Figur e 3 -5 d escribes th e n ame and v ersion format for a RuleSet.

Planning RuleSets 3-11 Figur e 3 -5 d escribes th e n ame and v ersion

Figure 3- 5. RuleSet Name and Version Format

RuleSet Naming Conventions

Use short, easily rememb ered name s.

Avoid ob scure acronyms. The name shou ld clearly de sc ribe th e Ru leSe t. For example, CityMortg age is better th an CMLS (short for City Mortgage Lo an System).

Beg in your RuleSe t n ame with some th ing tha t un iqu e ly iden tifies your comp an y and th e busin ess pu rpose. This conv en tion also p rev en ts po ten tia l Ru leSet co llision s if th e app lication is late r installed on o ther Process Commander systems.

Don’t u s e Pega or Pega- as a prefix for your Ru leSet name s. These valu es are restricted .

Avoid special char acters su ch as dash es, und erscoring, plus sign s, or quo tation ma r k s.

What You Completed

Defined Ru leSet n aming conv en tions.

3-12

Step 3: Getting Started — Prerequisites and Setup

How Many RuleSets Do You Need?

The next task in setting up the development environment is to decide how many RuleSets you need. Simple applications require a single RuleSet, created by the Application Accelerator. For more complex applications, organizing features into two or more RuleSets improves access and distribution control. Consider work complexity and application type to make this decision.

In most cases, your environment includes a baseline organization-wide RuleSet, containing the few rules that apply throughout the organization. This RuleSet, created by the Initial Setup wizard, is not included in the count of RuleSets you may need as part of your application.

Note: Keep your application simple, with as few RuleSets as possible.

Work Complexity

A set of business processes that is managed and used by a centralized group typically requires a single RuleSet. The PegaRP example involves a few types of similar work performed by related work groups. It has one RuleSet.

A complex process that involves many distinct types of work, or has rules that are modified by several groups, can benefit from two or more RuleSets. For example, an application for handling home mortgages on a national scale could involve significantly different types of work performed by different work groups. You might want two RuleSets (one each for receiving and processing a mortgage), or multiple RuleSets (to reflect geographic regions with different processing).

Application Domain (Single-Use Application or Product)

Applications — application to be installed in one organization typically has a single RuleSet with multiple versions for controlling ongoing changes. For example, an internal purchase request application might have one locked

Planning RuleSets

3-13

Ru leSet version, w ith add ition al un lo cked version s for develop ing n ew features.

Produc ts — applications to be installed in several organizations — often benefit from mu ltiple Ru leSe ts to ac commodate the ne eds of diffe rent customers. Produ ct d evelop ers can g roup commo n f eatu res th at ar e shar ed acro ss a product su ite, bu t sep arate th e featur es that ar e sp ecific to each produ ct tier. For ex amp le, a lo an pro cessing produ ct with mo du les for d iff er en t lo an typ es (mortg age , au to, cr ed it lin e, e tc.) mig ht h av e s ev er al RuleSets — separate ones for defining th e classe s associated with each ma jor lo an type, plus a shared one for proc essing.

Process Comman d er in cludes four Ru leSets that prov id e work man ag emen t cap ab ilities. Your Ru leSets inh erit th e ru les in th ese fou r Ru leSets, and supplemen t th em as need ed fo r your app lication . First, you n e ed on e or mo r e ma ster Ru leSets for your app lication or p roduct. You may need Ru leSets for d ev e lopment and d iv ision a l cu stomiz a tion . Figur e 3-6 shows an eff ec tiv e Ru leSe t arch ite ctur e for a large en terprise with mu ltip le d iv ision s.

Planning RuleSets 3-13 Ru leSet version, w ith add ition al un lo cked version s

Figure 3- 6. Multi-Division Rules Management

3-14

Step 3: Getting Started — Prerequisites and Setup

Helpful Hints

Use the organizational RuleSet (created by the Initial Setup wizard) to contain rules that apply to all applications and all users throughout the organization. (For example, a company logo image, stored in a binary file rule, belongs to an organizational RuleSet)

In large organizations, create an additional RuleSet for each division, to allow for divisional variations in rules (and provide a place for rules that apply to all the applications in a division).

Use the Application Accelerator to create the first RuleSet needed for each application.

A RuleSet can inherit features from other, prerequisite RuleSets and also from lower-numbered versions of itself.

When you make application changes (such as adding new features or rules), use a higher-numbered version of the production RuleSet.

Use multiple RuleSets to accommodate user community differences (such as by geography or division). In contrast, when you want to customize an application for different categories of work parties (such as preferred customers), use the concept of circumstance instead.

If you are developing a product, expect to have at least two RuleSets in each customer implementation. Your product is delivered to the customer in a locked RuleSet. After the product is installed, customers create another RuleSet that inherits from yours, so they can make local changes.

What You Completed

Identified the number and relationships of RuleSet(s) needed.

Creating the RuleSets

3-15

Creating the RuleSets

If your d eve lopmen t str a teg y is to u s e th e App lica tion Ac ce ler a tor to start d eve lopmen t, en ter the app lic a tion Ru leSe t in App lic a tion Ac ce ler a tor Step 2 ( Figu re 3-7).

Creating the RuleSets 3-15 Creating the RuleSets If your d eve lopmen t str a teg

Figure 3- 7. Application Accelerator Step 2

Th e App lication A c celer a tor cr eates th e RuleSet and a co rr espond ing version (01-01-01). You n e ed to access th e Ru leSet fo rm (Ru le-Ru leSet-Name ru le typ e) or th e Ru leSe t Version form (Ru le -Ru leSe t-Version ru le typ e) on ly to r ev iew or update these cr ea ted rule s, or to cr eate additional Ru leSets or versions.

As a best practice, update th e Ru leSet Version rules created by the Application Acc e lera to r to id en tif y Peg a-ProCom:0 4-02 as a pr erequ isite to ea ch o f your app lic a tion RuleSe ts. Add ition a lly, upd a te th e Ru leSe t ru le b y ch eck ing th e Requ ires Ch eck-Ou t box , to enab le facilities that help coord in a te dev e lopmen t activ ities with in th e proj ect team.

3-16

Step 3: Getting Started — Prerequisites and Setup

Determining Who Can Access a RuleSet

When it completes, the Application Accelerator automatically adds the created RuleSet to your own access group. Your system administrator can update the access groups of other development team members as necessary so that they can view, execute, and add to the rules in that RuleSet. When your application is deployed, RuleSet and version access can be provided through multiple means, reducing the need to update individual access groups.

The RuleSet list, assembled for each us er upon log in, consolidates RuleSet and version information from four sources:

Requestor Type (Data-Admin-Requestor class)

Organization (Data-Admin-Organization class)

Division (Data-Admin-OrgDivision class)

Access Group (Data-Admin-Operator-AccessGroup class)

Granting Access for Organization Use

During application rollout, an administrator typically grants access at the organization level for applications that are intended for general usage. As a result, everyone in the organization can use the application. For example, you would grant access to the following RuleSets at the organization level:

Pega-ProCom, one of the standard RuleSets that come with Process Commander.

An internal purchase order application for use across your organization.

Granting Access for the Division Level

Alternatively, you can restrict business-specific applications to one or more business areas by granting access at the division level instead. For example, you might choose this approach for an application that is intended only for human resources staff.

Creating the RuleSets

3-17

Controlling Access by Job Function

You can further refine RuleSet availability based on job function by using access groups. RuleSets that are specified in an access group appear at the top of the RuleSet list in the user’s profile and are applied first during rule resolution. A common reason for using this method is to selectively control access to new features or applications. For example, you might create an access group to grant access to the latest development version of your RuleSet only to your system architects.

As a shortcut, create an access group for your own use and specify your RuleSet as the default for development. However, you need appropriate access groups to make the RuleSet available to your project team and test users.

What You Completed

Identified the parts of the organization and individual people who will need access to your RuleSet when the application is deployed.

Identified the appropriate organization hierarchy levels and access groups for you and the project team (with assistance from your system administrator).

3-18

Step 3: Getting Started — Prerequisites and Setup

Creating the Application Parent Class

The next task in setting up your development environment is to choose a name and starting place for the application class structure. You learn more about the Process Commander class model and how to create your own class structure in the next chapter.

An application top-level class is an abstract class with two name segments, such as My-Co-HR-

The organization top-level class, created by the Initial Setup wizard (for example, MyCo-)

A segment identifying the domain or division of the application (for example, HR)

When it completes, the Application Accelerator creates additional classes derived from the application class, but does not create other rules directly in the application top-level class. Two or more applications can share the same application top-level class.

Naming Conventions

You read about naming conventions earlier in this chapter in the section on defining your RuleSets. As you become familiar with Process Commander, the benefits of adopting good naming conventions for all objects in your application will become obvious:

Short names are easy to remember when locating a specific object.

Descriptive names are easy to find when reviewing a list of objects.

Similar names make it easy to locate related objects.

In many cases, you may find it useful to define the top-level class as the company name and/or division. Make the owning division and/or the business purpose a subclass, and derive all other classes from it. This option is useful if you have

Creating the Application Parent Class

3-19

many Process Commander applications, or if your application uses supporting data in processing work. All applications can share the top-level class properties.

Some Examples

For the PegaRP example, the RuleSet is PegaRP and its top-level class is PegaRP-.

Suppose you are building two applications, YourCoPO and YourCoAP, for the Finance division. In a shared RuleSet, create a top-level class (YourCo-) for company use and a second level (YourCo-Finance-) for division use. Then create the work-related classes (YourCo-Finance-PO-, YourCo-Finance-AP-) in the application RuleSets. Define common elements once (such as your logo for YourCo- and division-specific rules for YourCo-Finance-), so YourCo-Finance-PO- and YourCo-Finance-AP- can inherit them.

Guidelines for Creating an Application Parent Class