Cloud + BPM = Business Process Scalability

Cloud is more likely to make an application deployment more – not less – complex, but the benefits are ultimately worth it.

I was a bit disconcerted by the notion put forward that cloud-based applications are somehow less complex than their non-cloud, non-virtualized predecessors. In reality, it’s the same application, after all, and the only thing that has really changed is the infrastructure and its complexity. Take BPM (Business Process Management) as an example. It was recently asserted on Twitter that cloud-based BPM “enables agility”, followed directly by the statement, “There’s no long rollout of a complex app.”

That statement should be followed by the question: “How, exactly, does cloud do anything to address the complexity of an application?” It still needs the same configuration, the same tweaks, the same integration work, the same testing. The only thing that changed is that physical deployment took less time, which is hardly the bulk of the time involved in rolling out an application anyway.

BPM applications themselves are not that complex. I spent more than six months of my life rolling out and implementing just about every BPM solution on the market. Trust me, deploying one of these babies is just the beginning of what can only be described as anything but a sanguine experience. In fact, I’d say very rarely is the actual deployment of any application difficult. Now getting it to work – and integrated with other systems and data sources – that’s a whole different ball game. And maybe that’s the disconnect – my definition of deployment is the installation and basic connectivity. Everything after that is customization and not intrinsic to the application but to its run-time behavior. Suffice to say cloud does absolutely nothing to change the integration and configuration and testing required to orchestrate business processes which, if you recall, is the purpose of BPM in the first place.

CLOUD MORE LIKELY TO INCREASE not DECREASE COMPLEXITY

If truth be told, using a cloud-based BPM is likely to introduce more complexity due to the very nature of these beasties; they all about orchestration of business processes. In the post-SOA world this generally means the orchestration of a series of services (REST or SOAP or POX, choose your poison) designed to codify a well-described process through which a customer or employee or whomever might “walk” to complete some task. Spread that across a cloud in which you have very little control over the infrastructure, or need to integrate back into data center deployed systems; add in a healthy helping of dynamism in a system that relies on distributed services and voila! Greater complexity.

And agility? The agility benefit of BPM comes from the capability to rapidly change business processes, which actually comes from the fact that most modern BPM leverage SOA. Even allowing that the definition of “rollout” includes “doing something useful” I’d still say it’s little more than rainbows and unicorns. If it isn’t the politics of trying to figure out what the process actually is then it’s the integration nightmare of trying to make them all work together.

Devops, are you paying attention? Cause this is your future, if you aren’t already there. While automation systems and existing open source solutions like Chef and Puppet are certainly helpful, you’re only scratching the surface of what a full data center orchestration implementation is going to require.

ALIGNING IT with the BUSINESS

Lest you think I’m all “BPM in the cloud is useless” there is a definite benefit in leveraging the elastic scalability of both infrastructure and services with BPM. Consider that if you distill BPM down it’s really a sophisticated integration bus that guides a user through a specific process, like checking the status of an order. Thus there is a definitive set of entry and exit points, with a series of steps (activities) that occur to gather the data required and return an answer. It’s a service-oriented architecture that may or may not leverage SOAP/REST/XML; the key is individual services that make up a larger system, each of which should align nicely with a specific business activity.

Each activity is often represented by a service, whether it be via integration with another application, a remote API call, or a direct service interface to a data source. Each of these is generally an individual service, each with their own unique compute resource needs. Thus the scalability of a business process is directly impacted by the scalability (and availability) of each of those services, regardless of where they may be located. It is likely that one or two of the steps in a business process may be more computationally intense than others, and it is almost certainly the case that each service will have its own   scalability profile.

Therefore, cloud – with its notion of application scalability really being virtual machine scalability (or instance) at this point – is inherently well-positioned to enable the scalability of individual services within an overall business process composition. Each service can scale as necessary, insuring that the overall (business) process scales on-demand. Consider that a single business process may have two different entry points: one for customer service reps (CSRs) and one for users via a web interface. During the week the CSR entry point may need to scale on-demand to meet the inevitable Monday morning rush. But on the weekend it may be the web interface that needs scaling because there are no CSRs to be had. This pattern could be manually handled by devops changing the resources pools assigned to each activity on Friday to a weekend-profile and then back again early Monday morning to a weekday-profile, but cloud and automation offer the means by which this can be handled without manual intervention and prevents any “surprise” scalability demands from cropping up and driving availability (and customer satisfaction) down. It scales the process from a business perspective without incurring IT hours, which keeps costs down.

This aligns IT with the business, which is rarely so clear-cut as to show the value of an implementation as is evident with BPM and SOA.

IT IS STILL ABOUT the ARCHITECTURE

Ultimately the agility and reduction in complexity offered by cloud is tied to the infrastructure, and the alleged ease with which scale and enforcement of delivery policies can be applied at strategic points of control throughout the architecture. BPM, CRM, SFA, home-grown applications. None of these are necessarily made less complex by cloud computing and in fact governing the intricate relationships of such applications is made more difficult by cloud because of the dynamism inherent in the underlying network, application network, and server infrastructure upon which such environments are built.

But it does provide the opportunity to architect that infrastructure in such a way as to align technological capabilities with business needs and serve as a means to ensure business scalability through more efficient scalability of applications and infrastructure. Automation is necessary in these more complex environments to eliminate the increased risk of human error as a cause of downtime and performance impeding problems and to assist in realizing the benefits of more efficient use of compute resources.