In today’s market there are more than a few Business Process Management Suites (BPMS). Each has their strengths and weaknesses.
Pega and OpenText (formerly known as Cordys) are two of those Business Process Management Systems, which can be used to model and execute (business) processes. The kind of functionality is the same for both platforms. Therefore, there is a lot of overlap between of the platforms, but as with all similar tooling there are also differences.
Five of the major differences are:
1. Used techniques and standards
OpenText is mainly based upon open standards that are widely available in the market. Pega on the other hand is using different type of rules (everything defined within Pega is called a rule). These rules are implemented using a propriety technique throughout the entire platform. For example OpenText uses Business Process Model and Notation (BPMN) where Pega uses a propriety format derived from BPMN to model the processes.
Also for other parts of the OpenText platform different techniques are being used. For example:
|Back end processing||Java|
|Data transformation||XSLT and Xpath|
So, to work with the OpenText platform you need to learn about multiple different techniques. To work with Pega you need to learn how to configure different type of rules (for different types of rules, specific configuration screens are available).
2. Data storage
When a process is executed within the platform a case is started. With each case data is stored about the case itself (process data). When this process data is used by the process (e.g. to make a decision or call a service) OpenText uses a Message Map (XML-structure) stored in the process instance itself. Pega uses an Object Oriented Data model, which stores the data in a work-class of the case. So Pega has the possibility to access the data using the open standard called “XPath expression”. Also, looking at the application data (data stores separately from the process data) there is a difference between the two platforms. OpenText is using a separately relational database (with columns for each attribute). Pega uses a Blob to store the information. This results in more database changes for OpenText when the structure of the case-data or application data is changed.
3. Frameworks/Add-ons for the platform
A framework can help you speed up the implementation of functionality in the platform. For both platforms a number of frameworks are available. In OpenText these frameworks have fixed hooks where you can plug in specialized code. Pega on the other hand uses object orientation throughout the platform and therefore you can override provided functionality with specialized code.
Next to the frameworks Pega also has some add-ons available. Examples of these add-ons are PMF (Project Management Framework) and NBAM Decisioning (Next Best Action Marketing). This last add-on can give suggestions on what the next best action would be to take (e.g. to retain a customer) based upon data gathered over time.
As mentioned, at the used techniques and standards, OpenText uses X-Forms to implement the UI. Both the X-Forms as used by OpenText as the screen related rules in Pega are also suited for mobile devices. So, both platforms have Out-of-the-Box portability; this means that you design/build screen once and use it from both your browser as on your mobile.
5. Architecture – Integration with other tooling
OpenText is more focused on the BPM and Integration (ESB) layer and is therefore best used in a best of breed application architecture. This means that you best use a different technology for the UI and other layers in your application architecture. Pega on the other hand advises to use the platform in an 1-platform application architecture as much as possible.
This is a short summary of the mayor differences between Pega and OpenText. This summary gives some areas of functionality and/or set-up of the platform to think of when selecting a BPMS. When selecting a BPMS you will need to check more aspects (e.g. type of functionality to be implemented, future stability of the supplier, future plans/releases of the platform and reference architecture within your organization).