Comparison of leading BPM platforms: Pega and IBM BPM

The concept of BPM (Business Process Management) is becoming more and more dense in the life of large and small corporations. Its essence is to consider the company's business processes as assets, using which you can increase the profitability of your business. The tool that you use for this can be any: a piece of paper, a text document, Visio, or any other diagramming tool ... But there is a class of tools that are specifically designed to serve as a tool for transforming your business - this is a BPM platform.
The task for such a platform is set in two ways: on the one hand, it is necessary to visualize the business process, and on the other hand, it must be executed.



I will not describe the entire market for such platforms; this is well done in an article by an independent Gartner agency, from where I took the illustration above (the full text can be downloaded from Pega or IBM , but registration is required, or google yourself by the title: “ Gartner BPM Magic Quadrant 2014 ").
The purpose of this article is to make a comparison of the technical capabilities of the two leading platforms, Pega and IBM BPM , currently available (autumn 2014), in terms of experience in using them in business process automation projects .
')
If you have conceived to transform your business or you need an IT solution that will allow you to achieve business goals set by senior management, or you are just interested in BPM solutions, then welcome to cat.

Principles of Comparison

First, a few words about exactly how I will conduct a comparison.
Firstly, BPM is to a large extent an approach to project management, a certain way of thinking, and not only a platform for automating written and coordinated TK. Both Pega and IBM generally recommend similar approaches: goal setting, iterative development, ease of change; but the devil, as usual, is in the details. Therefore, in my review I also focus on the aspects of project management, requirements management, expectations management.
Secondly, with all the similarities between Pega and IBM, it is impossible to compare only the basic platforms. Pega has many additional frameworks licensed separately. IBM has different levels of BPM licensing, as well as several other platforms that complement BPM.
Therefore, in this review, Pega and IBM are understood in a wider sense than the basic BPM platforms - they are whole sets of software and methodological tools.
The article consists of the following sections:

1. A brief overview of the internal structure of Pega and IBM BPM, as well as a brief description of implementation methodologies. These reviews do not claim absolute completeness of the description, but are given for reference purposes, but I hope they will be very useful for the primary immersion. For more information, you need to refer to the documentation of the platform.
2. The main comparative theses grouped in a table. Each row of the table corresponds to one of the compared aspects or features, and the columns correspond to the implementation of these aspects in different platforms: Pega and IBM, respectively.
3. The unique advantages of both platforms.

Pega Architecture Overview

The Pega core is a java enterprise application running on any application server. Based on this kernel, a stack of classes is built that make up the basic PRPC Framework, including the developer’s portal itself, accessible via a browser (since this portal is also used by the internal development team, it can be said that Pega was developed by Pega ).
To understand how Pega works, you need to define two basic concepts: class and rule:

• A class is a standard unit for an object-oriented paradigm, which is a structure containing some associated data and methods for processing it.
• A rule is an instance of one of the special built-in (that is, defined in one of the frameworks) classes assigned or assigned to other classes. Rules can be viewed as an implementation of the Strategy pattern (also sometimes referred to as Behavior; a complete description of the pattern is on the wiki ): a rule that belongs to a class determines its property (property), behavior (flow, flow action), how the data is displayed (section), and much another.

Any Pega application consists of a set of classes that define either the data structure (then they are stored in the Data- branch), or the structure of works or cases (in the Work- branch). Each of these classes can inherit properties and methods (defined by rules) from classes defined in frameworks, or from other application classes. Any class can override the rule specified in the base class.
Pega has a wide variety of frameworks, on the basis of which a final application can be built using inheritance, for example, here are just a few of them:

• PRPC itself is a framework;
• DSM - for building decision-making systems;
• CPM - for building customer interaction systems;
• Various industrial packages: financial, insurance, energy and others.

Pega, approach

The basis of the approach is based on three things:

• Situational Layer Cake (Layered Architecture): due to inheritance and polymorphism, implemented in the form of Rule Resolution Mechanism, Pega helps to ensure that the business process for a particular client changes depending on a variety of conditions, such as the loyalty level of a given client, and from the regional legislation of the service office.
• 6R is the concept of building an integrated solution that provides receiving (Receiving) and assigning (Routing) tasks, reporting (Reporting), responding (Responding), collecting information (Researching), making decisions and resolving (Resolving) cases.
• DCO (Direct Capture of Objectives) is a methodology and a set of supporting tools designed to ensure that the project develops only what the business really needs.

Pega provides a single space for collecting and managing requirements, for developing and testing functionality, and for the end user to work with a business application.
In the best scenario, the sequence of actions will be as follows:

1. Choose the first project that shows the best balance between the volume of costs and the potential effect; in the future it will be possible to move on to the remaining projects;
2. Create an application, further steps are performed using DCO tools, i.e. directly in the system;
3. Record business goals and requirements;
4. Introduce specifications describing how the system should work, associate them with goals and / or requirements;
5. Having broken the work into separate sections, complete the following steps for each:
   1. Conduct a DCO session with users to verify a common understanding of specifications (note that DCO sessions are used to verify specifications before they start developing them, and not for the initial collection of requirements);
   2. Implement the functionality according to the specifications;
   3. Show users the result.

In Pega's approach, there is a fly in the ointment: to use all the DCO tools, you need to create an application so that you can define business goals, fix requirements, and write specifications. However, when creating an application through AppExpress, you need to specify data such as goals, a set of cases and business objects, as well as select the base framework and the necessary structure of the application layers, which implies that some of the work on gathering requirements should have already been done.

_{If the goals are not so scary - to identify them you do not need a tool, then other questions may well lead to the fact that you first create an application only to collect requirements, and then you create an application for automation. However, this may well be offset by exporting and importing requirements and specifications.}

IBM Architecture Overview

The IBM platform stack is a java enterprise application running on the websphere application server.
IBM BPM has the following elements:

• A business process definition is an executable process diagram, in accordance with the BPMN standard. A process may include another process or invoke a specific service.
• Service is an atomic executable application unit. Services can be invested in other services. Conceptually, services are of two types: fully automated (integration call, data processing, etc.) and non-automated (requiring user interaction).
• Data type - defines the data structure within the application, may include properties of simple types (string, number, etc.) or composite, specified by another data type. Specific variables and instances of data objects are defined in each process or service.

IBM BPM consists of the following parts:

• Process repository - stores all information about processes, services, data structures, etc .;
• Process server is an executing component that provides business processes;
• Process center - a component that provides access to the repository of processes for development;
• Process designer - the development environment based on eclipse;
• Portal - end users environment (may not be used);
• Process data warehouse - a repository of statistical information about the passage of process instances;
• Blueworks Live is a cloud service for modeling and documenting business processes. The constructed model can be imported into the process designer, but in practice this feature is rarely used.

IBM BPM has the following license levels:

• Express - contains all the BPM components described above, but is limited to only one project. It is possible to install only on a single server, without the possibility of clustering.
• Standard - contains all the BPM components described above. Allows you to run multiple projects at once, allows you to install on a clustered server, basic integration support.
• Advanced - additionally contains an integrated data bus and advanced integration tools. Designed for high-load projects.

IBM has various related products, for example, here are some of them:

• ODM - a platform for business rules;
• Case manager - a platform for creating and organizing a set of cases;
• Integration bus - integration bus.

Ibm approach

Although the methodological approaches of Pega and IBM are very similar (project selection criteria, the importance of business objectives, the iteration of requirements collection and development), IBM has fewer tools to support this approach.
When implementing a solution on IBM BPM, the following approach is assumed:

1. Choose a project that shows the best balance between the volume of costs and the potential effect;
2. Describe business goals in BlueworksLive;
3. Describe the business process in BlueworksLive;
4. Hold a series of meetings with users to run the process described in BlueworksLive (called Playback 0);
5. Move the process from BlueworksLive to the Process Center to start development;
6. Further iteratively:
   
   1. Develop part of the business process;
   2. Show results to users (Playback 1..N).

Comparative Theses

The table below compares the various features of the Pega and IBM platforms.

Pega	Ibm
Requirements and Project Management
Pega provides DCO tools for managing business goals, requirements (WHAT the application should do) and specifications (HOW the application should work) with the ability to specify links between them. You can also associate development results with specifications to track project progress.	IBM has the ability to enter goals in BlueworksLive, enter descriptions of business process steps (analogue of the specification in Pega) in BlueworksLive, but there is no possibility to introduce general requirements, to associate goals with specifications or with implementation.
Positioning differences
Pega is a one-stop tool for automating case studies, processes, and / or business rules. To automate integration, it is recommended to use an external data bus.	IBM BPM is a one-stop tool for process automation and integration. There are separate products for cases and business rules in the IBM stack.
Pega has the ability to delegate specific rules to business users while programmers are working on the rest.	IBM BPM does not have the ability to separate part of the rules and / or business process so that users can change them during “combat” operation, but IBM ODM has a similar tool: there is an opportunity to provide access to change individual business rules to different groups of people.
Architectural differences
Pega has an object-oriented architecture. It is possible and recommended to encapsulate the data object, the processing logic of this data and interfaces for input and output in one class.	IBM has a service oriented architecture (SOA). It is impossible to encapsulate the data object, the processing logic of this data and the interfaces for input and output in one unit.
In Pega, a case instance has a single data area available, including for all its steps, subprocesses, and screen form sections. Sub-cases have a separate data area: setting the input data mapping for them is similar to that in IBM, and the output data is aggregated through a separate special mechanism.	In IBM BPM, each instance of a process or service is limited to its data area. To transfer data from one process to another (for example, when you open a screen with process data), you must explicitly specify the input and output variables and perform their mapping on each call.
Pega provides the ability to reuse any created rule in another application thanks to the Ruleset mechanism. The difficulty of reusing additional components that were not foreseen initially: low.	In IBM BPM, the reuse of individual components in another application is possible only by selecting them into special toolkits, which may require refactoring of already created and working applications. The complexity of the reuse of additional unforeseen components initially: high.
The use of techniques and mechanisms
Pega has a small set of features to customize the hard code, but has a very wide range of standard components.	IBM BPM has a significantly smaller set of standard components, but makes it easy to develop your own in JavaScript and / or Java.
Pega has a built-in interface adaptation mechanism for mobile devices.	IBM BPM out of the box does not yet have an adaptation mechanism for mobile interfaces, but there is an additional plug-in library (toolkit) that allows this to be achieved.
Controls and events in Pega allow AJAX to automatically send and update data by selecting the appropriate options in the designer.	In IBM, updating data without reloading the form is implemented separately: there are special types of services that support AJAX calls, and controls have the ability to handle Javascript events. However, the connection of events and services, data mapping and processing of results is performed manually by the programmer.
To work with data from external systems, DataPage is used to separate the integration layer from the data layer and the business logic layer. When using data from an external system, for example, on-screen, in general, there is no need to worry about how and when this data was obtained.	For operations with data of external systems special types of services are used. The separation of the integration layer from the business logic layer is supported manually by programmers (for example, internal rules and design recommendations). To use these external systems, you must either get them as an input variable, or directly call integration services.
User Functions
The standard portal has social functions: messaging, information about participants in the process. It can be used for any process call options.	The standard portal has social functions: messaging, information about participants in the process, expert assistance. Can only be used when using the standard portal.
All email alerts (about a new task, about a delay, etc.) are configured separately for each task.	Standard alerts in IBM BPM are enabled immediately for the entire application and automatically notify users of all new tasks. However, alerts also come in if the user himself has started some additional service. In this regard, in complex projects are rarely used.
There are more standard reports in Pega than in IBM BPM, and they give a more complete picture of the progress of the process. All additional reports are implemented on the same technology as the standard ones and are placed in a single interface space.	All additional reports are implemented on the same technology as the standard ones. There are also several special reports in the development environment that are used to analyze the effectiveness of the process and predict the results of any changes. The tool is very powerful, but requires a customized development server and an installed development environment. In this regard, it is used extremely rarely.
Entry threshold for getting started at the Pega Developer Portal: Business experts are easier, because At the basic level, no programming skills are required. It’s harder for a programmer because a more comprehensive understanding of the architecture and retention of a larger number of aspects is required.	Entry threshold for getting started in IBM BPM Process Designer: It is more difficult for business experts because environment is intended for programming. A programmer is easier, because for a basic level, knowledge of a small number of specific elements is sufficient.

Unique benefits

This section describes the special advantages of platforms that have no equivalent in another platform.
Pega's unique advantages:

• Declarative rules are rules that define certain characteristics of an application (for example, a business data calculation formula) that must be executed at any time. PRPC independently provides call and execution of these rules.
  _{For example, declare expression rules that define a formula for calculating the value of a variable. The execution of this formula is provided by the engine in one of two options:}
  
  • Recalculate the result with each change of any variable included in the formula;
  • Recalculate the result with each reading of the value of the calculated variable.
  
  
• Means dco: assessment of the project labor intensity; creating various sections of documentation; the relationship between goals, requirements and specifications.

Unique benefits of IBM BPM:

• Visibility of a single end-to-end process in BPMN 2.0 (if such a process is possible to build).
• Opportunities for analyzing and predicting the results of process changes.
  _{For example, you can see how often the instances of a business process moved along a particular branch, calculate the total operating costs. Then make a change in the business process and look at the forecast changes in operating costs and other KPIs.}

Instead of conclusion

Despite all the technical differences between the two platforms, the main problem is the same - the people who use these platforms incorrectly. The success of most projects lies in a few simple points, almost independent of the chosen platform:

• Know your platform: very often in real projects on platforms, something is realized that is already there, but a little differently (another user portal, its own notification system, etc.).
• Once again - to know your platform: no less often in real projects on such platforms they try to implement something that they are not intended for (a popular option is all kinds of accounting systems).
• Set business goals: if the project is started in order to “spend the budget”, then it is unlikely that it will be successful, no matter how good the platform is chosen. In contrast, if the project is developed with the understanding that its implementation will allow the company to save N million rubles a month, then the right people will have an incentive to make the right decisions at the right time.
• Involving business users in the development process: another common problem is that in large projects, the distance from a business customer to a programmer is measured by a couple of dozen managers, analysts from two or three sides, architects, other sympathizers and megabytes of documents. As a result, what is needed is simply not realized.

I am pleased to answer your questions in the comments or in a personal. If you are interested in comparing any other aspects of BPM platforms or a more detailed description, write, perhaps this will be the topic for the next article.

_{A small update: already at the stage of preparing an article for publication, I learned that a new version of IBM BPM 8.5.5 was released in the summer, with some improvements. I can not comment on them, because not seen in action. However, as far as I know, this version is not physically implemented anywhere at all, so no one has any real experience.}