How Does Using a BPM Solution in the Cloud Differ from Using an On- Premise BPM Application? Which is Better?

One of the biggest challenges facing organizations of all sizes is the increasing dispersion of the workforce as more and more employees work remotely. This challenge is being compounded by today's tough economic climate which requires that companies become more agile. This means that these organizations must implement BPM solutions which can properly support workers who need to access them from outside the firewall. It also means that these BPM solutions must be easy to implement and modify as the organization's needs change. On-premise solutions have proven to be unable to fulfill these requirements, while a new generation of Software-as-a-Service (SaaS) and cloud computing alternatives are specifically designed to address these escalating needs.

I agree with Jeff. I would like to add one more point , the main advantage for industries to implement BPM Via Cloud/SaaS is low cost of entry. SMB's don't want to spend too much dollars to see whether a BPM solution will work for them or not. From a Process Analyst/Architect the real question is will it change the way how applications are developed using Cloud BPM. I believe some question will be answered in ebizQ QCamp.

A very interesting question. Like most things the answer isn't black or white, there are various considerations that come into play,

One of the first things to consider is what business problem you trying to solve with your BPM application.

1. If it is mostly a system integration problem - then you'll need to make sure the BPM application can access and interface with the systems needed. If those are mostly internal systems then access restrictions could be an issue when trying to use a cloud based BPMS. If you need to access external systems, then an on-premise BPM application could have trouble accessing information outside the firewall.
2. If it is a human centric BPM application then you need to make sure that the application has access to docuements and people related to the BPM application. A cloud based BPM application allows people to access the application no matter where they are, but may have a harder time accessing an internal document repository. Of course, if you are part of a completely cloud based organization (including your document repository) that won't be an issue. For an on premise BPM application - vice-versa.

I believe the key to answering this question relies on your connectivity to the Cloud. If you have a dedicated connection configured between the host organization and Cloud provider, the primary differences will be around deployment, management and scale of the BPM solution since it will effectively look like a BPM solution running behind the firewall. If the BPM solution moves outside the firewall in the Cloud, then there's a host of issues that need to be addressed, that may result in an internally deployed BPM solution being a more effective solution.

Things become unnecessarily complex with the introduction of the Cloud. The key elements that need to be evaluated are, how am I billed for usage and what happens in the event that the host is unavailable. This latter question needs to be answered even if your own data center is hosting the BPM (or any) solution.

The Cloud is about 2 things: cost and elasticity. They are not mutually exclusive, but typically users tend to want one or the other.

To begin to answer this question, you have to consider (as I do often on the ebizQ BPM in Action blog) that business process management (BPM) is not a technology or single thing. From the user perspective it is a value proposition, the hopefully easier way you integrate your inhouse applications of varying brands or developed inhouse over generations, interoperate with your suppliers' and customers' applications (all of equally mongrel heritage), and achieve portability as all the rules change tomorrow morning (as they certainly do). To the extent that the cloud can enable this integration, interoperation and portablility, it is goodness. Where it interferes (and there are such situations), on-premise is better.

Of course, there are on-premise clouds so it is important to define cloud computing before asking how BPM (or ERP or CRM or ....) works on/in it. See http://www.ebizq.net/blogs/bpminaction/2009/03/cloud_computing_is_not_the_nex.php

-- Dennis Byron

There isn’t just one Cloud but a number of different sorts: private Clouds and public Clouds, which themselves will divide into general-purpose and specialized ones, and all of those Clouds will be full of pre-defined and readily available services. Accessing and provisioning these services is a very different proposition from what we think of as applications today so, in my opinion, it would be wrong to think of BPM as a cloud solution – we shouldn’t think of BPM on demand or process as a service – we need to think about a Platform as a service (PaaS). Therefore, the cloud represents a very different opportunity from process enabled solutions as we think of them today; The PaaS should provide us with a mechanism whereby a user can put together an “application� based around normal working patterns, using readily available services. Similar, in fact, to application servers or middleware solutions – only more business friendly.

Using a PaaS makes it is possible to handle any sort of business problem usually tackled by enterprise solutions, by leveraging the capability to associate virtually any number of web services within the context of an application. Service Provisioning is effectively an application generator within a process and is inherently more flexible, easier to provide, easier to manage and easier to use than traditional “ERP� type products.

Organizations that understand the benefits that the Cloud will deliver, have realized that in order to enable their business to be more responsive to change, they have to create a process layer, which decouples the processes from the control of applications. In the same way that middleware provided a data abstraction layer, a PaaS provides a “process abstraction� layer that delivers business services when and where they are needed.

Before this approach was available, enterprise applications typically would be in charge of their localized sets of processes, with the subjugation of adjacent applications to these processes. With every application handling this process differently, clearly this would not be, and is not, a workable solution in the Cloud.

With a process enabled PaaS, the control of processes is externalized away from individual applications. It makes them equal peers, subjugated to the layer that controls the execution of the processes, the provision of services and the delegation of tasks or activities to the individual applications according to their specific uses and needs.

In order to do this effectively, the PaaS must be able to do the following:
• Manage applications in parallel as well as in series
• Manage people-intensive applications
• Decouple the process from the application
• Work both inside and outside the organization
• Be both continuous and discrete, and allow processes to change over time
This is a tall order. But it is doable!

An interesting set of responses.

I think of BPM as a set of technologies that automate business processes across one or more siloed application stacks. It makes little difference to that core proposition whether those stacks are on-premise or in the cloud (or both), subject to the points JP Morgenthal has already made about firewalls.

So I'd argue that the main differences at the outset are the same as with any cloud (or SaaS) versus on-premise application, namely, faster deployment and lower cost because the cloud provider bears the cost and upfront heavy-lifting of deploying and owning the infrastructure.

However one might also ask whether, looking further ahead, a cloud environment would ultimately change the nature of BPM because of factors such as easier modification, more standardized integration and APIs, and the ability to do more process integration at the user interface layer by taking advantage of standardization on web client technologies such as the browser, AJAX, Flex and so on. Over time, I suspect that we'll start to see BPM becoming an integral part of Web application platforms rather than a separate bolt-on.

In my experience, most of the other responses here would be too academic for business decision makers to properly evaluate. Whether BPM in the cloud is successful first depends upon whether business justification can be made for the investment.

Technologically, I believe there are few, if any, hurdles left to overcome for cloud computing reality. There are trade-offs to be sure, but they don't negate the option of cloud computing - it's already here. Obvious technological hurdles such as large volume storage, application integration, and system security have always been there, whether the solution has been housed inside or outside the firewall. With cloud computing, they are just possibly exacerbated. And while the architecture may not fully be there, but that won't stop businesses from trying to take advantage of a financially viable option like cloud computing. If anything, architectural innovations of cloud computing will happen precisely because of the adoption of cloud computing.

Forgetting the value-proposition of BPM efforts (since they will generally be the same whether hosted or not) and just focusing on the discussion "to BPM in the cloud or not", for businesses today (particularly SMB) there is serious potential business justification for cloud computing - outsourcing infrastructure, deployment, and maintenance costs. Just how much justification there proves to be will depend upon the cost of the emerging cloud service(s) (PaaS, Saas, etc.) versus the company's cost for the same services.

Of course, besides the financial aspect of business decisions, there's risk to consider. Risk is not as easily calculated as the financial calculation and will only be valid for the given business context and decision maker. And it's likely, though not dramatically so, that risk for a BPM project in the cloud will be higher than any other IT project moved to the cloud for the sole reason that some businesses may perceive their business process (for whatever they do) is a competitive advantage (similar to the data outsourcing discussion we've been having with businesses for several years now). Even so, risk too will be outweighed if the price is right.

My belief is that "to BPM in the cloud or not" will follow the same decision process all other outsourcing decisions have followed now that sufficient technology exists to support it. At some point, financial benefit(s) can outweigh all other inertial factors against outsourcing (whatever resource it is the business uses). And that's what it will come down to - is the price right.

Good insights and discussions so far. One key area we have not discussed yet which I believe needs to be taken into account right up front is process ownership, support and management. If an enterprise decides to use a cloud BPM platform to deliver a portion of a business process or the entire business process, who has responsibility if an issue occurs? From a business perspective, this is a critical area of planning that must be addressed up front when looking at using a cloud BPM platform or even integrating a cloud Business Process Outsourcer (BPO) with internal business systems. Management and ownership must be clearly defined and communicated between the cloud provider and the enterprise. What if a process transaction doesn’t complete or completes incorrectly, who gets involved and how can we get to the root cause of the problem if it crosses enterprise-cloud service provider boundaries? What about the points of integration between systems and data managed by the cloud provider and systems or data managed by the enterprise? It is at those points of integration and hand-offs that ‘finger-pointing� is likely to occur. What if the use of the BPM platform by the enterprise starts to exceed the threshold of the level of service agreed to by the BPM cloud provider? Who manages the re-negotiation inside the enterprise and can the enterprise explicitly track all points of consumption of the BPM platform by different constituencies inside the enterprise so that consumption can be managed?

These issues are difficult to manage inside an enterprise and become even more challenging and critical to explicitly define, apply contracts and manage when dealing with cloud services for BPM or otherwise.

I think enterprises must put the time, thinking and best practices in place around consumption governance and management, usage monitoring and rating and transaction and business activity management and monitoring when considering using cloud services for areas such as BPM. Consumer-provider management is needed both on the side of the enterprise and on the side of the cloud BPM service provider to make this model work beyond the pilot test for driving meaningful business process activity at an enterprise level.

BPM applications in the cloud will likely be multi-enterprise process applications, implementing collaboration contracts between multiple parties, automating the value chains sustaining these collaboration schemes, and ensuring that SLAs are fulfilled between the collaborating partners. Typical processes candidates for cloud operation include the SEPA SDD rule book processes in the financial payment domain, the VMI/CPFR processes in the supply chain domain, and the RosettaNet PIPs in the electronic equipment eco-system industry.

Bernard Debauche
VP EMEA Marketing
Axway

BPM in cloud is a topic discuss widely today. BPM as SaaS is kind of subset of cloud computing. For simplicity I am talking about subscription based BPM and solutions. There are a lot of reasons that companies would consider a SaaS or an on-premise solution. Most of the reasons are business and not technology, and they should be. Before I go into those I would like to point out that solutions based on BPM already have webportals to do distributed task or work management, so that you can include people from your extended ecosystem to join in to work on processes. These people could be your partners, BPO or global employees. For that you do not need SaaS solution.
Company would go for a SaaS solution if cost is factor and they do not want to invest in infrastructure. It comes down to doing capital expenditure or an operational expense. Another factor in determining if a company would subscribe to a SaaS solution is whether they think the process is a non-differentiating process or not. If the process is period end closing, accounts payable etc. they would consider SaaS or even hosted solution. But if the process is mission critical, core process then they would think twice. E.g. I am not sure if a large communications company would run their network provisioning on SaaS. Another factor could be number of systems your solution needs to integrate to. If it is a self contained solution, SaaS makes sense or even if there is some integration with legacy systems, but as integration point increase, the on-premise solutions look more feasible and cost effective.
In the topic title mention of “Solution� and “Application� is important. When we talk about BPM in cloud there are two approaches – process-as-a-service and platform-as-a-service. There are a number of solution providers that create applications on top of BPMS platform and offer those to their customers in SaaS (multi-tenant). There is lot of value there as the solutions built on top of BPMS and bring all the inherent values of BPMS like visibility, agility, efficiencies, and business empowerment etc. along with costs benefits of SaaS. Effectiveness of platform-as-a-service is yet to be seen.

Ajay Khanna

Sr. Director Product Marketing & Management
Savvion