The BPM Layer

In part 1 we looked at CRM Evolved, Pega’s vision for enterprise applications that focus on consistent, positive customer experiences and connecting customers with outcomes. We ended with a slide from Alan Trefler’s keynote presentation at PegaWorld 2015.

The slide gives a nice overview of the main technologies that together form “CRM Evolved”. On the left we see what Pega, for quite some time, has best been known for: as a platform to support Business Process Management (BPM). BPM systems are meant to support, define and document business processes, by routing work through a process that can involve human operators and other systems over multiple departments.

Business rules and process models      

This BPM layer is in itself already a combination of technologies. It starts with a Business Rule Engine (BRE), which provides efficient ways to manage business logic. Every organization has explicit or implicit rules that govern the way they do business. For example: what are the conditions to give a customer gold or platinum status? The BRE has different types of rules, like rules that can have only an outcome of true or false, or rules that can combine decisions in the form of a table or a tree. While it is possible to only use the BRE part of Pega, to provide rule-based calculations, this is not a very common use.


A decision rule as it can be configured in Pega

Another technology in the BPM layer is a modelling tool to visualize a business process. In this modelling tool we can use shapes that represent a human task, or a step to retrieve information from another system, or a step to send an email message etc. It also has ways to define who is going to do what, and how much time they are allowed to take.

This modeler is fully integrated into the platform meaning that any change is immediately reflected in how the system behaves. It also means that this visual representation of the business process is always up to date, there is no separate body of diagrams that would be hard to maintain.


Two versions of a Flow diagram, where the “Loyalty Level” shape uses the Decision Table shown above. The Blue shape represents a sub flow, which can in itself be a complex process. And since this diagram results in executable code, simply changing the direction of the “Gold” connector has a direct effect on how the application behaves.

Here, we need to introduce a concept that will become relevant again later on. It is about that central “thing” that goes through the process. It is called a Work Page. A Work Page represents the work to be done, and is an abstraction of a piece of paper in the real world. It would, for example, represent a request for a loan, and would start its life as a web-form, needed to gather all the necessary information. But then, that “paper” would go from hand to hand, from department to department, in order to validate the request: a check on credit worthiness, a calculation of the net disposable income. The customer’s information would then be used to come to a product advice. In the end, all the information would be used to create an offer and send it to the customer. All this time, the central element would be the Work Page, and the system would push it through one big process, and all its sub processes.

It is from within this process modeler that we can leverage the real power of the BRE, because there are shapes to incorporate the aforementioned business rules. For example, a decision shape can have three separate outgoing branches, one for normal customers, one for gold and one for platinum customers.

Code generation

A third technology is essential for the BRE and the process modeler to be of any use. This technology also happens to be a kind of holy grail in information technology: code generation.

The business rules and process models with their shapes are automatically translated into executable java code. And behind some of the shapes are separate screen definitions, where we can configure screen layouts with their validations, formatting and dynamic behavior. These are translated into java, jsp, html, css, xml and JavaScript. We will not go into the details here.

The benefits of code generation are manifold. In the first place, a system can be built much faster. Creating a dynamic web-application by hand is a lot of work. With code generation, all the needed technologies are already in place. And what is more, this leverages years of work by experienced developers, which has been tested in many production systems already.

Secondly, as we create higher-level chunks of functionality, without bothering about the low-level technology, it becomes easier to change the system when new insights emerge. For example, we can change the order of steps in a process diagram, and the result is that the process really changes. This explains partly why Pega has been using the slogan “Build for change”.

The system also becomes self-documenting. The rules, process diagrams and screens as they are defined in the system are meant to be understandable for anybody involved with the system. They are not only used to generate the executable code of the system, but also to generate documents that describe the system. This way, the system and the documentation are always in sync.

The most important benefit of code generation is that it enables a top-down approach. When we start building a new system, we do not need to design a floor-plan, lay a foundation and start with the plumbing. We can immediately play around with the walls, the windows and the roof, knowing that we can easily change everything if needed. Typically, the building of a Pega application starts with workshops in which the process and screens are visualized within the Pega platform tools. The system that is generated in this early stage already shows the actual process and screens. This allows for very early feedback by end-users. The next step is building out this very same system by filling in the blanks and using real-life data. This way of working, where the envisioned behavior of the system is defined and documented directly in Pega, in the form of an executable application, is called Direct Capture of Objectives (DCO) in Pega’s vocabulary.

Ultimately, this shows a very long-term vision towards which Pega has been building for a long time: bringing two groups of people as closely together as possible: Business people who know what business-needs a system should fulfil, and IT people who know the technology to build such a system. As just described, the Pega platform can be used by Business and IT to sit together and rapidly design a process and screens, which are directly executable. Another example is “delegating rules”. This means that some of the rules can be prepared to be available for Business users to edit. A good example would be the decision rule that distinguishes between normal, gold and platinum customers. Such a rule can be made available to Business users in such a way that they can edit the values without the risk of breaking the code. They can fulfill their own Business needs without requiring a new release. The system takes care of versioning, peer-review and audit trail.

In part 3 we will see how Pega has continued to build consistently upon the BPM layer.

– Marc Hartogs

No Comments

Sorry, the comment form is closed at this time.