We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
BPM
user-pic

Are All Processes Good Candidates for Cloud Computing?

Vote 0 Votes
A subject that will be covered in-depth at ebizQ's upcoming BPM in Action Virtual Conference by David Linthicum: do you think all processes are good candidates for Cloud Computing?  If no, which ones are not?

And coming this June 23rd, make sure to tune in for the BPM in Action Virtual Conference.

8 Replies

| Add a Reply
  • Yes, In my opinion, all processes are good candidates but the real question is, “Are customers really ready to put all their data in the cloud??. While the cloud may be able to technically support and facilitate the automation of any process, we needn't look any farther than the raging debate over cloud security to determine if people are ready to fully buy in to the concept. For instance, any process that involves critically sensitive information and hinges upon security is not, in many people’s view, cut out for cloud computing, right now. This is a symptom of public perception. High-profile cloud security eruptions have taught businesses to be wary of placing sensitive information in the hands of someone else (hosting) and some companies simply prefer on-premise BPM where everything is physically in-house. It's this very reason why BPM vendors should offer customers the option to choose between the cloud or the ground in deploying solutions.
    http://www.ebizq.net/blogs/pp/

  • I notice the question used the word "Process" rather than say, "applications" or "data" so is "process" implied as a catch all? I'll assume you meant then, everything.

    Since a cloud can be public or Private then the answer is really yes. Deploying any application from the cloud, even an Iphone App, fat client or Virtualized application to any general or even specific device is valid IMHO.

    The real problem comes though, when you try to make too many assumptions about devices that want to get at the "process" in the cloud. Not all devices will have the right browser, the right horse-power, the right features (Flash, Silverlight, flex) or whatever. So do developers write processes (and applications) that run in or from the cloud to support the lowest common denominator of technology (we know won't ever happen). We tried that with thin clients 15+ years ago!

    So, we have a real long way to go. For instance, without products like that from my company (OpenSpan), 2 cloud (web or virtualized) apps probably will still continue to integrate only through copy and paste. The user (business) will see little benefit so adoption will be stalled. The Copy and Paste comment would be funny if it weren't true! Until we focus on the user, the Business Processes and making users more efficient regardless or cloud or not, the question should be more of; Will business benefit from having all processes into the cloud? WIll they care? Will they notice?

  • I base my answer on the following statements: a) process is a explicitly-defined coordination of services to create a particular result b) all process are services and c) the use of cloud computing requires the internal preparedness of an enterprise to put its services into the cloud (i.e. BPM for clouds is generally the same as BPM without clouds).

    So, if you properly architected your enterprise BPM-centric system then all processes can be put into clouds. Of course, the spandex rule must be applied - “just because you can doesn’t mean you should?. I think, to decide which process should be put in cloud we should look at non-functional characteristics. Each service has the same functional characteristics both for in-house and in-cloud deployments. But, its non-functional characteristics (response time, security risks, cost, SLA, etc.) can be different for in-house and in-cloud deployments.

    Using that process is an explicitly-defined coordination of services, knowing “in-house? and “in-cloud? non-functional characteristics of those services and having some simulation, we can estimate “in-house? and “in-cloud? non-functional characteristics of the process. Then based on some rules (acceptable level of risk, acceptable response time, etc.) we can decide to have this process either “in-house? or “in-cloud?. For example, a process which intensively uses its services (which are sitting “in-cloud?) may be put “in-cloud? (preferable the same). Of course, different environments (production, development, QA, training) may have different rules and this estimation can change over the time.

    Thanks,
    AS

  • Make your decision this way: overall, how much easier and cheaper does the cloud make your specific solution?

    For my clients, their requirements are to help people run common business processes with less effort. Putting BPM in the cloud (on our SaaS solution) makes complete sense, because they have a system up and running immediately, maintained for them 24/7, without the overhead of setting it all up themselves and stretching an overstretched IT team. And the end-users don't care where the system is, just as long as it works.

    If my clients were in fact trying to perform complex integration and orchestration of services through a SOA/BPM mix, I'd say that the cloud is probably not the best approach. After all, we know that all this stuff is possible through web-services (and therefore the cloud BPM solution can get at it), but in reality what organization is in the lucky position to have all of the systems they want to integrate available in that way? I don't think the cloud makes so much sense where there is more integration than process, or the sensitivity to an occasional time lag on a transaction is going to cause problems.

    As for security, I think that we see security issues where people have not taken the time or effort to analyze and mitigate the risks. For example, one of my clients is a securities firm, performing stock trading for specialized organizations and individuals. They outsource their core system, and they trust their business data in the hands of another organization. And they do this because they have performed the due diligence necessary to show that their data is as safe in the hands of a third-party and it is floating in their own server room.

    If you put business data in the cloud, encrypt it - and Amazon's technical whitepapers don't try and hide this fact. But just because you host your data in-house does not protect you from that need. The Seattle health system, Providence, lost the records of 386,000 people from in-house systems on lost/stolen backup tapes ( http://blog.consected.com/2009/11/hitech-hipaa-hr-cant-just-push-burden.html ) as an example.

    There are many good target solutions for the cloud. It just comes down to 'return on investment' whether you should chase them.

    Phil Ayres
    http://www.consected.com

  • Yes and no. It's a question of Cloud maturity and what you mean by Process.

    Yes, because eventually, if Cloud is the success everyone wants it to be, IT infrastructure and data will reside there. Yes because simple process definition can reside there (definition, not automation).

    No, simply because those elements are scattered on premise right now. Phil and Francis make good points about infrastructure and orchestration. Passing and parsing of data between Cloud and on premise will make customers very wary, plus the complexity with the amount of connectors and data flying around from within the enterprise wall to without really isn't worth the effort imo and there are no gains to be had with a partial solution.

    "Will they notice" Francis says, actually that could be the acid test for Cloud itself, like Cloud Computing's very own Turing Test, whereby Enterprise and Customer cannot distinguish between an on premise solution and a completely hosted one....

  • According to my reasoning, a process is not amenable to computing support (of whatever kind, including 'cloud computing'), unless it can be
    (1)  rationalized,
    (2)  standardized,
    (3)  re-formulated in terms of programs, objectivating human volition-utterance
          (one or more individuals), and finally
    (4)  executed by means of computing processors, objectivating human volition-
          execution.

    Typical process candidates are from the repetitive part of the processes, performed by humans in handling automata. Of which four kinds may be distinguished: machine, logistics (in the widest sense), social, and – not to forget- computing automata.

    Notice, processes occuring in business most often do not satisfy these pre-conditions.

  • BPM in the Cloud is still early stage for many organisations.

    For business buyers it is great way to circumvent IT (the Stealth Cloud) but there are business and technical risks. Oddly enough the technical risks are the easiest to fix.

    For a longer discussion, see my blog "BPM in the Clouds"
    http://iangotts.wordpress.com/2010/06/10/is-bpm-ready-for-the-cloud/

  • All processes are good candidates for Cloud Computing but not in this stage of the Clouds evolution.
    I am not including in in my definition of Cloud Computing Internal Clouds or Private Clouds.
    The reason that many processes are not yet good candidates for Cloud Computing is that typical Architecture includes: Data Layer, Business Logic Layer and Service Layer. Processes are implemented in a Process Layer on top of these layers. As long as the other layers are not deployed in the Cloud, Processes will not be implemented in Cloud Computing. So far it is very rare that Critical Core applications for Large Enterprises are implemented in the Cloud, therefore related Processes are not good candidates for Cloud Computing. However, non Core processes such as CRM related processes are good candidates for Cloud Computing.

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT