From IBM to Pega: #2 The Data Model

Continuing with the study of Pega Platform as an IBM BAW expert, another major aspect comes up soon, and comparisons start again: The Data Model. It is worth taking a deep look at the differences between both tools regarding such a fundamental aspect.

Variables vs Fields
Again, the first thing that comes up is the different names for the same concept. While the whole community of developers around the world seems to agree on calling “variable” to these little storage units, Pega gives them the name of “field”.

But stepping into a deeper analysis of this concept, we can find some other differences, more relevant for the characteristics of the tools.

Variable (Field) Types
What types of variables does each platform provide by default?

The basic types are pretty much the same (with different names again), and we can find text, numeric and date types, in both tools. But the first difference comes up when we find that Pega extends this basic set with other useful types such as “currency”, “email”, and “picklist”.

On top of the basic types we may consider collections. IBM provides “lists” while Pega adds another concept called “groups”, enabling the developer to manage unordered collections of values, and naturally, group lists.

And while this is as far as it goes for IBM, Pega still extends its offer with “Fancy Types”, which include “location” type (automatically presented to the user as a map), “attachment” type to attach files, and “user reference” type to handle users of the applications.

In addition to the default system types, both platforms provide the possibility to build custom Data Types for more complex objects. Here Pega goes one step ahead as well, allowing to handle parent-child relations among Data Types, providing inheritance to child classes. Moreover, Pega offers two different ways to declare inheritance: direct (explicitly defined via property) or by pattern (defined by the names and dashes on the class name).

So Pega seems to offer a more complete set of built-in tools to support the Data Model, but we should notice that beyond these default resources, IBM BAW works on Javascript code and builds over Java. This means that the developer has access to any tools and classes provided by libraries in both languages, opening an infinite range of possibilities to create custom utilities.

Automatic Behavior
Another remarkable feature in Pega Platform are “calculated fields”. Pega gives the possibility to define the value of a field from automatic calculations based on the values of other fields. This way, when the value of a field is changed, all dependent fields are automatically recalculated and updated.

IBM does not provide such a thing out-of-the-box. To implement a behavior like this, the developers must make use of other tools like Javascript snippets (both on client or server side), or events/UCAs.

Context
This is probably the most significant difference for me, and it is a consequence of the whole Process Modeling approach that we discussed in the previous entry.

IBM has a multi-layer approach to the process implementation. Processes can have subprocesses and nested processes, and their tasks are implemented by services that can have more nested services as well. Each of these processes and services has its own scope for the definition of variables, that can be set as input, output or private. This context model follows the conventional style and allows to have global and local variables, and to use parameters, limiting the lifecycle of each variable only to its necessary scope.

Pega on the other hand has a one-layer approach to the process implementation. The developer creates the case type and configures each of the steps from the Case Type definition. All the fields used along the case seem to be defined at this level as global.

Populating
Something in Pega that has really amazed me is the possibility to automatically populate a data type. The tool provides something called “Data Views” that can be used to interact with the Systems of Record. Thus, a List Data View can automatically query the SoR and load the desired records to a list of the corresponding data type. It even allows to define the data refresh strategy, linking the data to the SoR permanently or working with a copy of it. There is also a Single Data View that can query a single record or insert/update one into the SoR.

This kind of behavior needs to be explicitly implemented in IBM BAW. IBM does provide generic tools to query a database but the developer needs to implement the query and call it at any time he needs the data.

Conclusions
With all this in mind, I think that one can conclude that Pega provides a more flexible and powerful mechanism to implement and handle the data model of the applications. It provides more functionalities and simplifies some use cases like dependencies or populating.

On the other hand, IBM gives me the feeling of a more robust and reliable system, maybe because it uses a more traditional and simpler model, closer to what I have been using since my first days on IT.

This time Pega seems to finish as the “winner” in this comparison game. I guess that this evens the scales by now, but there are still more things to consider in future entries, so stay tuned!