Put to the Test: Pegasystems' SmartBPM Suite 5.1

With this latest version, Pegasystems has made its powerful product easier to use for process participants, business analysts and developers.

InformationWeek Staff, Contributor

August 14, 2006

7 Min Read

This article was previously published online.


• Dynamic binding of processes and rules supports more sophisticated and granular applications.

• Automatically generated user interfaces support delegated development and ensure a close fit to user needs.

• Ajax-based portal with rule-driven JavaScript provides intelligent, goal-centric pop-up interfaces.

• Strong support for development and deployment lifecycle management.


• Depends on sophisticated development expertise (preferably a Pega-certified system architect) from the outset.

• Lacks an inherent, role-based model for work assignment, complicating process modeling.

• Too many opportunities for programmers to step around the configuration features and break model-driven applications

With the 5.1 release of its SmartBPM Suite, Pegasystems has made its powerful product easier to use for process participants, business analysts and developers. Although the suite is one of the more daunting BPM systems to deploy, this new release is significant because of the kind of business process management suite it offers. Pega's package manages processes in a fundamentally different way than any other BPMS I've examined.

SmartBPM is based on a unified rules-and-process engine in which processes are first-class citizens alongside different types of business rules. Pega effectively binds all the elements required to deliver an application at run time, including process fragments, business rules, presentation elements, integration calls and security controls. Everything is dynamically selected and bound based on the work context, as defined by the events and attributes of the case (process instance).

Competitive approaches tend to limit the use of business rules to decision points calling a standalone rules engine. With Pega, the inferencing capability of the core rules engine detects changes in the state of the related information and then works out what to do based on the goals of the process. That could be just about anything, from forward chaining (moving to the next step in the process), invoking a separate process thread in parallel, raising an alert to a manager or even backward chaining through the rule set to retrieve some piece of missing information automatically.

Keep Data In The Domain

Another key differentiator for Pega is that rather than regarding the information domain as out of the scope of the BPMS, the entire SmartBPM environment is based on a componentized, service-oriented run-time environment in which data classes are specialized alongside the business processes and declarative rules. This approach lets Pega resolve the right rules and processes to bind to the case based on the context of the work. Although specialization delivers tremendous downstream flexibility, enabling better market segmentation, it also presents challenges in the early stages of deployment.

Overall, the approach facilitates app customization to meet particular needs. Say you have a standard way of processing orders, for example, but when an order comes in for a key customer and the product is out of stock, you want to offer a special alternative. Or perhaps it is a first-time customer and, as a result of a directive from on high, you want to use a special set of customer-satisfaction checks. Pega handles these situations by layering on specializations from the rule base, adding alternatives without your having to go back and manually weave these revisions into the baseline process.

Other BPM suites require a cut-and-paste approach, where each scenario requires a copy of the process that is then adapted. Over time, this can lead to fragmented process architectures and a higher cost of ownership. However, creating the right class structures to meet the downstream goals of the organization demands long-range planning and expertise. For a major enterprisewide project, it's best to involve a Pega-certified system architect from the outset.

Deliver Pop-ups In The Portal

The new Ajax-based portal environment serves both process development and run-time delivery. The portal uses business rules to build the Ajax environment dynamically. As with the previous version of Process Commander, the user experience is composed (and driven) at run time based on the rules and process definitions. With the Ajax upgrade, the user interface is more intelligent, as it responds to the intent that was defined in the process and rules base. New rule-driven pop-ups help the user identify related information quickly.

The Process Commander portal is role-based and augmented by a rich case- and content-management model that ensures people see only the information and processes they're supposed to see. What's more, the buttons and choices made available are constructed based on the context of the case. This functionality supports a "delegated development model" that ensures the appropriate managers, analysts and admins maintain the rule sets that directly affect their part of the business.

The look and feel of the development environment has been updated. The developer's desktop is split across six areas representing the different development roles: process, decisions, user interface, integration, reports and security. All six areas are under the control of the security model to ensure the right user interface is delivered to the right class of user.

Within the development tooling, users can see snapshots of an object just by hovering over its name. Control over the content of a pop-up in the user portal is defined declaratively using rules, and the corresponding Ajax code is generated and managed automatically. Moreover, these intent-driven interfaces can be updated instantly as higher-level policy changes ripple down through the rule sets.

For modeling, Process Commander relies on Microsoft Visio, which must be available on the designer's desktop. It's launched through an OCX control into the browser window (along with the relevant stencil). A check-in/out mechanism ensures that the process model is only worked on by one person at a time.

The system stops short of providing process support for the development activity (using the power of the process model and rules to guide the developer). However, a context-sensitive help system calls the relevant references at the field level. In the next version, this will extend right into facilitated online discussion groups and product support.

A Few Rough Spots

Developers face some concerns I would not have expected. Since the entire execution environment relies on Java, there are no built-in dialogs for role assignment, for example. Work is assigned based on a property set of a Java class. Creating a new role for a given process model is cumbersome and convoluted.

Although a business user may be unnerved to see the underlying Java code exposed in the configuration dialog (role-based security can protect the faint of heart), the IT community will feel relatively comfortable inspecting the dynamically generated code. Depending on the needs of the app, this code can be embedded or, if need be, developers can embed their own Java code.

For the business analyst, a new testing feature steps through the model, automatically navigating across roles. This also includes the ability to inspect the rules, HTML and other properties of the case. A Rule Referential Integrity feature (shown on page 18) is included to identify any conflicts in the rules sets or between rules and processes.

Version 5.1 facilitates introspection of third-party apps, letting developers represent such apps in the development environment without connecting to live production systems. An LDAP wizard guides a system admin through the process of creating single-sign-on access to third-party applications.

In the Process Analyzer component, wizards are used to build differing "scenario definitions" that become automated tests for the application. These simulations use existing performance data, with measurement carried out automatically.

Bottleneck Management

Version 5.1 also delivers new functionality to support deployment, including an Autonomic Event Services module, which monitors the health of third-party apps, measuring fine-grained SLA (service-level agreement) information. This helps in the overall management of the environment, tracking response times and helping eliminate bottlenecks associated with third-party apps.

Pegasystems has set itself a challenge: to unify and simplify the worlds of business process and rules as they interact with line-of-business data. Competitive products tend to treat these as distinct disciplines, which implies multiple skill sets, but perhaps more importantly, a less-extensible application. All BPM products require you to jump through a few hoops to get started; it's just that Pega's hoops are higher than most. However, given Pega's focus on supporting BPM apps across global organizations (rather than just a process or two at a time), the rewards--like some of the challenges--are bigger.

Pegasystems SmartBPM Suite 5.1, starts at $100,000; usage-model pricing based on the number of rule invocations

Derek Miers is an independent business process management analyst and consultant. Write him at [email protected].

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights