On October 2, 2008 Pegasystems announced a version of its suite it calls “BPM Platform as a Service (PaaS).” I caught up with the company’s development and marketing guys to better understand what it was all about. The line in the announcement that confused me was that the “new platform delivers BPM as a service without the risks of traditional software-as-a-service (SaaS) offerings.” Traditional and SaaS were not words that I tend to put together—and I kind of think of SaaS as riskless because you pay for modern SaaS as you go along.
So I needed to understand these risks a little better. It turns out Pegasystems has an interesting story although I would have worded it a little differently. Its business process management (BPM) suite was architected and built for multiple instances although that feature hasn’t meant a lot to most BPM users in general because they tend to install BPM departmentally, in “silos,” as Pegasystems characterizes it. This Pegasystems capability was even “certified” by IBM a few years back when IBM was calling “cloud computing” “grid computing” (after IBM called it “on demand” computing I guess).
Despite IBM’s playing three-card monte with the concept, Pegasystems’ technical achievement is non-trivial. This feature allowed Pega to make some changes to its execution engine to allow different JVMs to share corporate assets (processes, business rules, UI components, integration components, and data structures) among multiple BPM instances in one organization.
So despite the fact that the property-insurance claims-processing BPM application is fundamentally different than an application to support independent agents, they can both use the same customer-account definition, the same process to change an address, and so forth. While IT departments have been able to set up such a multiple instance configuration for a number of years, Pegasystems also reduced the effort the IT department would have to put into this work, adding tools and an administrative console to clone one application to another and to streamline the instantiation process.
So what’s this got to do with the risks of SaaS, I ask? Well this all depends on how you define SaaS. To the extent that some software sold as a service provides one-size-fits-all functionality, I understand Pegasystems knock on the term. But I don’t like to paint SaaS with such a broad brush. I’d look at it another way: Pegasystems may have just enabled some Pegasystems systems-integration and business process outsourcing partners to get into the SaaS business model very cost effectively.
Look for a Pegasystems-enabled BPM-as-a-Service capability in your industry some time in 2009. It could be just what your company needs in a down economy.
-- Dennis Byron
















the lighter side of BPM
http://bpmconsultants.blogspot.com/