Last week, Pegasystems announced their BPM “Platform as a Service” (PaaS) offering, and I had a chance prior to that to chat with Kerim Akgonul, VP of product management. My first thought on reading the phrase “internal cloud” was that they were just hitching a ride on the cloud bandwagon — check out James Governor’s 15 Ways to Tell It’s Not Cloud Computing for all the reasons that this isn’t cloud computing — but there are definite cloud-like capabilities to what they’re offering from the viewpoint of the individual projects, although not to the organization as a whole.
A problem that I see in many large customer organizations is that BPM projects end up being departmental, and even if the vendor manages to sell enterprise-wide licensing, it often ends up only deployed in one department. In many cases, this is because departments don’t want to share BPMS instances, and it’s just too hard to go through the effort of deploying another separate server and instance for every project. There’s also the need for multiple instances for development and testing, usually hand-installed at some cost. This is exacerbated in large organizations with a variety of geographically-dispersed business units, where they may have several different independent BPM projects on the go at the same time, and have difficulty in applying successes in one area to another.
Pega’s PaaS offering is a platform on top of SmartBPM that allows corporate IT to offer out independent BPMS instances to business units: true multi-tenanted instances for individual projects, but sharing the same infrastructure. Effectively, they’re turning corporate IT into an internal cloud BPM vendor, and the individual projects as customers of that offering. This gives some of the benefits of an externally-hosted SaaS BPMS — shared infrastructure, fast provisioning — while alleviating (perceived) security concerns of using external services for operational systems. You still have to buy and maintain the servers, and have in-house Pega system administration knowledge (which would not be necessary in a true SaaS environment); the real benefits come to the individual projects.
Allowing each project/department to deploy their own virtual BPMS will definitely speed some projects along, but it feeds the habits of some of the problems of departmental solutions that we’re trying to get away from. Encouraging the continuation of the silo culture makes it difficult to get to a true process-centric view of your business and tackle those end-to-end processes. However, Pega is allowing for some cross-instance sharing of artifacts using a new registry/repository to encourage reusability: different instances can share services, processes and rules directly, or make a copy into their local instance.
There’s some nice features in terms of synchronizing upgrades of instances: instances can opt out of an upgrade for a period of time to allow for custom application synchronization, although there would be limitations to how long that they could delay the upgrade. This capability is critical since many of the instances are likely to have custom applications built within them, and they’ll need time to test and make adjustments to those applications for a new version of the underlying platform.
At this point, there’s no billing capabilities or other modules that would allow this to be used as a multi-customer SaaS offering, but next year, they’ll be offering a series of applications that may be offered internally or externally, for example, by business process outsourcing firms.
The first version of PaaS is planned for release before the end of the year, although it wasn’t yet in beta when I had my discussion with them three weeks ago. I expect to see more at PegaWorld in just over a week.
I’m viewing trends like this as a long-overdue maturation of the industry: vendors are starting to realize that customers are having serious problems with rolling out large BPM programs across their organization, and starting to offer products and advice on how to accomplish that.