Apparently, Sandy Kemsley was not too happy about the way OMG’s BPM Think Tank is evolving, and neither was Bruce Silver. Nevertheless, her remarks about Intalio’s participation in the BPM On Demand Panel are a bit off base.

Sandy’s point seems to be that deploying Intalio|Server on Amazon EC2 does not qualify it as an on-demand offering, for it’s supposedly not multi-tenant. While I usually respect Sandy’s technical judgement and am eagerly awaiting her review of Intalio|BPMS 5.2, I cannot help but disagree with her statement.

First and foremost, the definition of multi-tenancy is a very loose one. If you define it as the ability to run processes from multiple customers on the same physical server, then Intalio|Server Powered by Amazon EC2 certainly qualifies. If you restrict the definition to deployment models that rely on a single instance for the entire software stack, then even established SaaS vendors such as Salesforce.com would not qualify, for they run multiple instances of their entire stacks on totally separate server grids (my account is hosted on na3, which stands for North America #3). Everything in between is shades of gray that deserve further study.

The main benefit of the multi-tenant model is its ability to deliver economies of scale by sharing common resources across multiple users. It is especially attractive with respect to the ability to upgrade multiple customers from one version of the software stack to another, all at once. It is usually achieved through some kind of virtualization, and what differentiates one multi-tenant model from another is the level at which such virtualization is done in the stack: for Salesforce.com, it’s done on top of the database, essentially providing a virtual database on top of a physical RDBMS (currently Oracle). For Ning, it’s done on top of the PHP virtual machine, providing one execution context for each social network. And for Intalio|Server Powered by Amazon EC2, it’s done on top of the operating system, using rPath in the middle. Each level has its pros and cons, and many aspects should be considered when selecting the one that will be used for building an on-demand offering. None is better than the other, but one will be more suited to a given set of requirements, and this is all that matters.

In the case of Intalio|Server, the requirements where the following:

Safe and secure isolation of process contexts from one customer to another
Make no mistake, this is the most critical requirement of all. Whatever one customer’s process does, you do not want it to compromise the safe and secure execution of other customers’ processes. If the faulty execution of a customer’s process leads to a server crash (highly unlikely), you do not want it to stop the execution of other customers’ processes. And under no circumstances should one customer’s process get access to data managed by another customer’s process. Now, let me make something very clear: no matter how smart your engineers are, or how many of them you have on your payroll, the safest and most secure way of achieving such goals is by deploying separate server instances for each customer, deployed on separate instances of the operating system. Through such an architecture, the operating system acts as a safe container for the process server it is hosting, and the risk of contamination from one process server to another are reduced to the minimum.

Scalability from a fraction of a CPU to an unlimited number of CPUs
One of the benefits of the on-demand model is that you do not have to worry about how to scale the underlying infrastructure, from servers to networking equipment and databases. And while many customers will want to scale their deployments up, some will want to start small, with the lowest barrier to entry possible. What this means for the SaaS vendor is that its deployment model must be able to support everything from a fraction of a CPU, to tens, hundreds, or even thousands of CPUs to be used by a single virtualized process server instance, serving the needs of a single customer. Once again, the best way to achieve this goal is to virtualize at the operating system level, for such virtualization scales up and down better than any other piece of the stack, database engine and process server included.

Ability to support third-party components (such as DMS and Portal)
Implementing multi-tenancy at the level of the process engine could work if it was the only component to be used at runtime. Unfortunately, a complete BPMS (at least one worthy of the BPM 2.0 moniker) requires more than a process engine. For example, you’ll want a solid document management infrastructure, a portal, an ESB, etc. Unfortunately, most of these components are designed to leverage virtualized operating systems in order to support their deployment in a multi-tenant environment (for the reasons explained above). As a result, virtualizing the process engine without virtualizing these additional components would serve no purpose whatsoever.

Identical feature sets between on-demand and on-premise editions
Last but not least, on-demand computing should be a deployment option offered alongside its on-premise alternative, rather than a religion guided by meaningless dogma. As a result, it is critical that all the features available with one deployment model be also available with the other, and vice versa. This seamless ability to migrate from one model to another is what will give customers confidence in the on-demand model, and it requires that on-demand and on-premise editions of the product behave exactly the same, from the way groups can be created, to the way permissions can be defined. Once again, such a uniformity of behavior is best achieved when virtualizing at the operating system level.

All that being said, a good on-demand solution built on top of a virtualized operating system should pay attention to very important deployment considerations. Forget them, and you end up in a world a pain, like so many first-generation Application Service Providers discovered seven or eight years ago. Here are a few to keep in mind:

The later point might be the most important of all. While trying to scale down, make sure to define a limit you won’t cross, usually defined as the number of instances you will deploy on a single server. In the case of Intalio|BPMS Powered by Amazon EC2, it is somewhere between 10 and 20 instances per server. Beyond that point, the footprint of the BPMS stack gets too big. Should you want to run hundreds or thousands of customers on the same physical server, a totally different architecture would be required, and this is what Coghead built for example (on top of Intalio|Server).

Scaling up, very similar considerations must be kept in mind. While a virtually unlimited number of process engines could be deployed on a grid (our largest customer deployed over 1,000), the database engine will quickly become a bottleneck, especially if your processes are persistent and transactional. In such a case, your deployment architecture might have to be optimized (read customized). But again, the same applies to any SaaS vendor.

So, to set the record straight: Intalio|Server Powered by Amazon EC2 definitely, positively is a multi-tenant on-demand offering for BPM, and the only thing that might disqualify it is that such an offering only covers the runtime components today. But tomorrow brings a very different story, as illustrated on this earlier post.

Note to Sandy: you did not answer this post.