According to Kerim Akgonul, product management vice president, the key is speeding up the front end of the lifecycle where the rules that drive Pega’s business processes are developed. In many ways, what Akgonul was describing sounds very familiar to the words that you’d hear out of any application lifecycle management tools provider.
We want to capture the ‘objectives’ of the application during requirements phase.
Of course, here, instead of specifying business logic, you are starting by defining business rules. A wizard will help guide business users to codify rationale for the rules, players and roles, interactions with external systems, and the types of reports and process analyses that are required. Additionally, there will be capability for generating structured documents in the popular format of choice, such as Word, PDF, or Excel.
Additionally, there will be tools that manage the flow of Pega SmartBPM projects, where changes can be tracked and associated with specific project tasks and people. Additionally capabilities for automatically generating and running automated and manual unit or regressions tests will be included as well to capture the results over time.
There is a clear difference between testing code and testing business rules, explained Baskar Mohan, manager of QA for Virtusa, an outsourcing partner that acts as a systems integrator for Pegasystems clients, and has also provided software development services for Pegasystems itself.
According to Mohan, the biggest difference is in what would otherwise be termed functional testing. For conventional software applications, it often means exercising the user interface; by comparison, with rules-driven systems generate the UI dynamically, which means that it will probably look different depending on permutation. In this case, testing the firing of a rule is an exercise in detecting potential conflicts or scenarios where the process does not meat business goals.
Pega did not disclose any specific timelines regarding the next releases, or when these ALM-like features will appear.
Our View
This is yet another step in the evolution of BPM environments from software deployment to software development and deployment platforms.
To some extent, demand for these features form Pegasystems customers reflects the fact that its installed base tends to consist of large, highly complex applications that have in many cases evolved from legacy roots. That’s not surprising given that the company is over 20 years old, and has been providing modeling-based tools before the acronym BPM was invented.
With large installs, many of Pega’s customers have demanded broader features covering more of the software lifecycle.
From another standpoint, the emergence of ALM-style features constitutes the response of BM pure plays to household names like BEA, IBM, Oracle, SAP, and Microsoft that view BPM as extensions of their middle tier or application platforms. It coincides with a trend on the part of BPM players to also assume control of the deployment environment.
For instance, while SAP and Microsoft have already announced plans to make processes or workflows executable without the traditional step of generating Java or C# code, pure plays like Pegasystems aren’t exactly sitting still.
The result is that BPM is emerging, not only as an alternate application delivery platform, but increasingly, an application development platform as well.
Aside from BPMN, which at this point has yet to achieve more than lip service support (most vendors will eventually support it to some degree), most vendors view the standards domain as occupying the point where business processes are exposed as web services.
But up until that WSDL service definitions or BPEL process orchestrations are defined, BPM vendors are quietly claiming process definition, development, and deployment as the extension of their proprietary domain.
