Comparison of leading BPM platforms: Pega and IBM BPM

    The concept of BPM (Business Process Management) is increasingly becoming part of 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 anything: a sheet of paper, a text document, Visio, or any other charting tool ... But there is a class of tools that are specifically designed to serve as a tool for transforming your business - these are BPM platforms.
    The task for such a platform is posed in two ways: on the one hand, it is necessary to visualize the business process, and on the other hand, it needs to be executed.



    I will not describe the entire market for such platforms, this was done well 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 will be required, or google it yourself by title: “ Gartner BPM Magic Quadrant 2014 ”).
    The purpose of this article is to compare the technical capabilities of the two leading platforms, Pega and IBM BPM , currently available (autumn 2014), in terms of experience in their use in business process automation projects .

    If you are planning to transform your business or you need an IT solution that will achieve the 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 the 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 agreed upon technical specifications. 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 pay attention to aspects of project management, requirements management, expectations management.
    Secondly, with all the similarities between Pega and IBM, you can not compare only the base 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 broader sense than the basic BPM platforms - they are entire complexes of software and methodological tools.
    The article consists of the following sections:
    1. Brief overviews of the internal structure of Pega and IBM BPM, as well as a brief description of implementation methodologies. These reviews do not pretend to be complete descriptions, but are provided for reference purposes, but I hope they will be very useful for a primary dive. For more complete information, refer to the documentation of the corresponding platform.
    2. The main comparative points are 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 benefits 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 has been built that make up the basic Framework of PRPC, including the developer's portal itself, accessible through a browser (since this portal is also used by the internal development team, we can say that Pega is developed on Pega ).
    To understand how Pega works, you need to define two basic concepts: a class and a rule:
    • A class is a standard unit for an object-oriented paradigm, which is a structure containing some related data and methods for processing it.
    • A rule is an instance of one of the special built-in (i.e. defined in one of the frameworks) classes, assigned or assigned to other classes. Rules can be seen as the implementation of the Strategy pattern (also sometimes referred to as Behavior; a full description of the pattern is on the wiki ): a rule belonging to a class defines its property, behavior (flow, flow action), way to display data (section) and much more 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 defined in the base class.
    Pega has many diverse frameworks on the basis of which the final application can be built using inheritance, for example I will give only 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, the approach

    The basis of the approach is based on three things:
    • Situational Layer Cake (Layered architecture): through inheritance and polymorphism implemented in the form of Rule Resolution Mechanism, Pega allows you to ensure that the business process for a particular client changes depending on a wide variety of conditions, for example, how the level of loyalty 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 and Routing tasks, Reporting, Responding, Researching, decision making and Resolving cases.
    • DCO (Direct Capture of Objectives) is a methodology and a set of tools supporting it, aimed at ensuring that within the framework of the project only what is really needed by the business is developed.

    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 case scenario, the sequence of actions will be as follows:
    1. Choose the first project that shows the best balance between the amount of costs and potential effect; in the future it will be possible to move on to other projects;
    2. Create an application, further steps are performed using DCO tools, i.e. directly in the system;
    3. Fix business goals and requirements;
    4. Introduce specifications describing how the system should work, relate them to goals and / or requirements;
    5. Having divided the work into separate sections, for each, perform the following steps:
      1. Conduct a DCO session with users in order to verify a common understanding of specifications (I draw attention to the fact that DCO sessions serve to verify specifications before starting their development directly, and not for the initial collection of requirements);
      2. Implement functionality according to these specifications;
      3. Show users the result.

    Pega's approach has a fly in the ointment: to use all the DCO tools, you need to create an application so that you can define business goals, record requirements and write down specifications. However, when creating an application through AppExpress, you must specify data such as goals, a set of cases and business objects, as well as select the basic framework and the necessary layer structure of the application, which implies that part of the work on collecting requirements should already have been done.

    If the goals are not so scary - you don’t need a tool to identify them, then other questions may well lead to the fact that at first the application is created only for collecting requirements, and then the application for automation is created. However, this may well be leveled 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 call a specific service.
    • Service is an atomic executable unit of an application. Services can be embedded in other services. Conceptually, there are two types of services: 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 - an executing component that ensures the work of business processes;
    • Process center - a component that provides access to the process repository for development;
    • Process designer - eclipse-based development environment;
    • Portal - work environment of end users (may not be used);
    • Process data warehouse - a repository of statistical information about the passage of process instances;
    • Blueworks Live is a cloud-based 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. It allows you to run multiple projects at once, allows you to install basic integration support on a clustered server.
    • Advanced - contains an additional built-in data bus and advanced integration tools. Designed for high-loaded projects.

    IBM has various related products, as an example I will cite 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 (criteria for choosing a project, the importance of business goals, iterative collection of requirements and development), IBM has much fewer tools to support this approach.
    When implementing the solution on IBM BPM, the following approach is assumed:
    1. Choose a project that shows the best balance between cost and potential effect;
    2. Describe business goals at BlueworksLive;
    3. Describe the business process in BlueworksLive;
    4. Conduct a series of meetings with users to run the process described in BlueworksLive (the so-called Playback 0);
    5. Move the process from BlueworksLive to the Process Center to start development;
    6. Further iteratively:
      1. Develop a 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.
    PegaIbm
    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 the relationships between them. You can also link development results to specifications to track project progress.
    IBM has the ability to enter goals in BlueworksLive, enter descriptions of the steps of business processes (similar to the specification in Pega) in BlueworksLive, but there is no way to introduce general requirements, associate goals with specifications or with an implementation.
    Positioning Differences
    Pega is a single tool for automating cases, processes and / or business rules. To automate the integration, it is recommended to use an external data bus.
    IBM BPM is a single tool for process automation and integration. For cases and business rules, the IBM stack has separate products.
    Pega has the ability to delegate individual 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 the “combat” operation, but a similar tool is in IBM ODM: there is the ability 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 a data object in one class, the logic of processing this data, and interfaces for input and output.
    IBM has a Service Oriented Architecture (SOA). It is impossible to encapsulate a data object in one unit, the logic of processing this data, and interfaces for input and output.
    In Pega, the instance of the case has a single data area, including for all its steps, subprocesses and sections of screen forms. Sub-cases have a separate data area: the input data mapping for them is similar to that in IBM, and the output is aggregated through a separate special mechanism.
    In IBM BPM, each instance of a process or service is limited by its data area. To transfer data from one process to another (for example, when opening a screen form with process data), it is necessary to explicitly specify the input and output variables and map them with each call.
    Pega provides the ability to reuse any created rule in another application thanks to the Ruleset mechanism.
    Difficulty reusing additional unintended components: low.
    In IBM BPM, reuse of individual components in another application is possible only by allocating them to special toolkits, which may require refactoring of already created and working applications.
    Difficulty reusing additional unintended components: high.
    The use of techniques and mechanisms
    Pega has a small set of possibilities to be customized with hard code, but it has a very wide range of standard components.
    IBM BPM has a significantly smaller set of standard components, but allows you to easily develop your own in JavaScript and / or Java.
    Pega has a built-in mechanism for adapting the interface 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 you to implement AJAX sending and updating data automatically, by selecting the appropriate options in the designer.
    At IBM, updating data without reloading the form is implemented separately: there are special types of services that support AJAX calls, and the 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, you do not need to worry about how and when this data was received.
    For operations with data from external systems, special types of services are used. Separation of the integration layer from the business logic layer is supported manually by programmers (for example, internal rules and development recommendations). To use these external systems, you must either get them as an input variable, or directly call integration services.
    Custom functions
    The standard portal has social functions: messaging, information about the participants in the process.
    It can be used with any process call options.
    The standard portal has social functions: messaging, information about the participants in the process, expert assistance.
    It is possible to use only when using the standard portal.
    All mail notifications (about a new task, about a delay, etc.) are configured separately for each task.
    Standard alerts in IBM BPM turn on immediately for the entire application and automatically notify users of all new tasks. However, alerts also come if the user himself has launched some kind of 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 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 some 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 starting work in the Pega Developer Portal:
    Business experts find it easier at a basic level, this does not require programming skills.
    It’s more difficult for a programmer, because A more comprehensive understanding of architecture and the retention of more aspects are required.
    The entry threshold for starting work in IBM BPM Process Designer:
    Business experts are more difficult, because The environment is intended for programming.
    It’s easier for the programmer, 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 are unparalleled in another platform.
    Unique benefits of Pega:
    • Declarative rules are rules that specify certain characteristics of an application (for example, a formula for calculating business data) that must be executed at any time. PRPC independently provides the challenge and enforcement of these rules.
      For example, declare expression rules that specify a formula for calculating a variable value. The execution of this formula is provided by the engine in one of two options:
      • Recalculate the result every time you change any variable in the formula;
      • Recalculate the result at each reading of the value of the calculated variable.

    • Dco tools: assessment of the complexity of the project; creation of 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 can be built).
    • Possibilities for the analysis and forecasting of the results of process changes.
      For example, you can see how often business process instances moved along a particular branch, and 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 a conclusion


    Despite all the technical differences between the two platforms, they still have the same main problem - people who use these platforms incorrectly. The key to success of most projects lies in a few simple points, almost independent of the chosen platform:
    • Know your platform: very often in real-life projects on platforms, what is already implemented is implemented, but in a slightly different way (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 sorts of accounting systems).
    • Set business goals: if a project is conceived in order to "spend the budget", then it is unlikely to be successful, no matter how good the platform is chosen. In contrast, if a project is developed with the understanding that its implementation will allow the company to save N million rubles per month, then the right people 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 the business customer to the programmer is measured by a couple of dozens of managers, analysts from two or three sides, architects, other sympathizers and megabytes of documents. As a result, not what is needed is simply realized.

    I will be happy to answer your questions in the comments or in PM. If you are interested in comparing some 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 the article for publication, I learned that in the summer a new version of IBM BPM 8.5.5 was released, in which some improvements were made. I can’t comment on them, because not seen in action. However, as far as I know, physically this version has not yet been implemented anywhere at all, so no one has real experience.

    Also popular now: