Let me start off with a comment, writing on a topic as wide open as PRPC technology can lead to a situation with no guideposts or frameworks to create within, and that blank canvas can be intimidating.
Given that I was told by my teachers, “do not limit yourself”; I am going to counter their collective wisdom (well that is not anything new) to make this first blog entry a little more focused and talk about getting a level of comfort and comprehension on what Pega (the tool and environment formerly known as PRPC) is.
PRPC’s biggest identifiable and pseudo-technical characteristic is that it is intimidating; its old moniker “PegaRules” was very apt, there are numerous rule types and keeping them all straight can be a challenge. When I first encountered it, the sheer number and interrelationships of the rules required to define an application was threatening; but one can learn how to understand and use Pega by trading on simplifying views of the environment.
- You can define content from the top down and the bottom up; and Pega will keep the relationships straight. Think about implementing the capabilities you need as a series of assertions; like “I need to know if the person is credit-worthy” which can be defined as a decision (most likely a WHEN rule… IsCreditWorthy), which can be decomposed into its factors. Or we can define the factors like “hasDeclaredBankruptcy” and compose them into the decision. Pega does not force the approach to definition, you can work in a pattern you find most natural/comfortable.
- User presentation is rule based and can be made to present content based on decisions without having unmanageable levels of condition statements. The user interfaces can also be defined and tested separately from the process that presents it, before merging the two.
- As your work in Pega you will reach multiple learning plateaus that let you take on bigger parts of a solution with greater confidence. This plateauing and the related “I finally have a complete grasp of Pega” statement are normal, but eventually you will see that there are subtleties still to internalize and more to learn. This simplification is one that really means you have turned the corner on understanding how it all fits together; not necessarily that you “know it all”.
- Understanding the engine that assembles, executes, and manages Pega content is not absolutely critical when you start your journey but over time, it helps you understand how the parts of the environment work together to help you understand how to diagnose issues and tune for performance. Most of the time you can truly treat the server like a magic (black) box that you provide definitions to and will produce actions and outputs in a “predictable” manner; but one must understand that sometimes there is a database -> class loaders -> model assembly -> compilation -> library calls involved that have to be dealt with, thankfully it is usually infrequent.
- Buttressing (wow, isn’t that a big word) the simplifications are a number of tools which help and really do make things much easier than hand-building and conducting low level tests. These are things like compliance reports, guardrail summaries, form based structured editing, etc.
Development productivity and best-use are served in Pega by iterative development. Despite how much we learn Pega in successively better/deeper mental models, application development benefits from successive refinement. That is why I recommend, when working to deliver an application, “Get it working first, then get it work well (that can mean fully generalized, fast, etc.).”