Michele Cantera and Ben Pring talked about the compatibility of BPM and SaaS, especially in the key issue of whether process agility can be achieved with SaaS delivery models, or if that’s only suitable for standardized applications and processes.
Pring’s area of expertise is SaaS, and the first part of the presentation was on the SaaS trends in the next five years, and the areas where it will have the most impact. He spent some amount of time defining SaaS (which I won’t reproduce here), how it is confused with outsourcing and hosting, and its benefits. It is useful to consider, however, some of the reasons why companies are moving to SaaS, since these are true for BPM as it becomes available in a SaaS environment:
- Too much software and hardware that is purchased but never used.
- The high cost of software implementation, particularly the cost of services required.
- The hidden costs of IT that drive up the effective cost of on-premise systems.
- The emergence of new technologies that enable SaaS, such as grid computing.
SaaS is almost always used to reduce costs, both the up-front costs of the systems themselves and the infrastructure required to support them. However, many organizations have security concerns (which may or may not be unfounded), and there is often a real or perceived reduction in functionality (particularly related to integration) compared to an on-premise system. SaaS is no longer seen as a crazy idea any more — Salesforce.com proved that organizations would put confidential business-critical data in a remote system — and many enterprise application vendors are looking for ways to capitalize on this growing market.
Cantera took over to talk about BPMS and SaaS, starting with the range of different service delivery models from on-premise shared services (which she refers to as “not really SaaS” — you think?), to business process outsourcing (again, not SaaS since the end-customer doesn’t provide the people in the process and/or it’s not purchased on a subscription basis), to SaaS delivery of process-based applications (e.g., Enkata, based on Lombardi TeamWorks, or L@W, based on Metastorm), to an actual SaaS BPMS platform (e.g., Appian Anywhere, or Fujitsu Interstage). In most cases, the process-based applications are fairly rigid to the end consumers; unlike the platforms, which expose pretty much the entire functionality of the equivalent on-premise BPMS, the applications may not allow any process changes, or only limited changes.
She said that she doesn’t see a push to using a BPMS platform via SaaS, but I think that’s a chicken-and-egg problem: Appian’s product isn’t even released yet, and Fujitsu’s seems to be under the radar, so customers either don’t even know that this capability exists or think (correctly) that it’s not available yet.
There are a number of architectural patterns for implementing multi-tenancy BPMS on a single SaaS server:
- Each application has its own instance of the BPMS, and its own instance of a repository, but on a shared server. Gartner sees this as the dominant architecture in order to ensure process agility, although at a higher cost due to separate BPMS and repository instances for each application.
- Each application has its own instance of the BPMS, but all instances share a partitioned repository on the shared server.
- Each application shares a single instance of the BPMS and repository on the shared server (currently, no BPMS vendors support this model).
Cantera and Pring spoke together on what degree of process agility can be expected in a SaaS BPMS environment. They started by discussing — separately — how to determine if SaaS is right for you, and if BPMS is right for you, then looked at the process agility characteristics of BPMS in the various service delivery environments. If we look just at the characteristics for BPMS platforms via SaaS, they indicate a moderate operational cost, high degree of customization possible and therefore high process agility with a low to moderate cost associated with that process agility. The problem, of course, is that the vendors just aren’t quite there yet.