Multi-tenant Distributed Process Environment (Part 2 of 2)

Last week at Chennai, Nasscom EmergeOut conclave recognized the prominence SaaS & Cloud hold in IT psyche today, and they had Innovation in the SaaS/Cloud space as its primary theme. I chaired a session called 'Software Procurement Model Trends'. It was interesting to note the amount of serious adoption in the whole gamut of companies from very small startups thru SMEs to large corporations like Diamler. And while today it is more about Software as a Service (SaaS), companies are now beginning to seriously look at Platform as as Service (PaaS) as well.

I also shared views on  SOA & BPM in the Cloud at the Great Indian Developer Summit in Bengaluru last month and geared my thoughts on multi-tenant business processes. Like I had noted in my earlier post, as business processes get more integrated into the enterprise IT infrastructure landscape, new solution architectures are possible. We’ll begin to see whole cloud and distributed application models being encapsulated into single-solutions with embedded business processes. Wfe’ll see these same solutions being deployed on the cloud, and even further being deployed in a dynamically scalable multi-tenant model.

This is, in my view, the more advanced of the three possible models for SOA/BPM in the cloud:

• Using Business Process Management (BPM) for integrating applications in the cloud
• Above BPM itself running in the cloud
• BPM embedded inside solutions running in the cloud (single-solution view)

BPM in a SaaS model, wherein one can model and execute their business processes over the web, is not exactly new. Gartner reviewed the web based BPM modeling and deployment possibilities in 2008, and cited the three possible deployment models:  For each application instance it may have its own BPMS and repository on a shared server, or a shared  repository, or the extreme form of shared BPMS+repository an a shared server. The whole web based BPM modeling and deployment fad has come and gone. This is partly due to limitations on the kind of use cases that fit in into BPM on the web, with solutions and services they access possibly being within the enterprise. And accessing services inside the enterprise firewall from outside is not the easiest of configurations to open up for secure access. So, model and execute on the web in a SaaS model is probably still time away from mainstream adoption. Until enterprise IT landscapes mature some more; with more widely distributed solutions over the web- possibly accelerated by rapid acceleration of SaaS model business solutions and also the accelerated adoption of public clouds within enterprises.

Now, one possibility not explored much is BPM and SOA becoming an integral part of a single solution. Though SOA is an integration paradigm and BPM is a model-driven business process layer targeting integration solutions & human workflow processes, both do offer a very elegant model for today’s modern applications. The granular coarse-grained services professed by SOA is a very good way of partitioning and abstracting sub-systems in any application. What’s more, BPM is a good mechanism to model all first level business processes and flows in any application. This is the single solution view of SOA/BPM.

However, once we switch to a single-solution view, with SOA/BPM being used in the solution as a first order design paradigm (and not just to integrate external applications or services), SOA/BPM can exist in two forms. 1) A simple solution model with an embedded BPM layer that helps organize the solutions functional sub-components better thru coarse-grained services, and all first level of solution capabilities modeled and realized as BPM processes. 2) A solution model that is actually distributed, but still in a single-solution context enabling and providing functionality for a single business solution. Extending this further, you could look at this single-solution environment as one that actually has distributed functionality (a la normal SOA - even as all the web services are essentially modular functionality that aggregate to form the whole application). These applications will use distributed sub-components in a SOA services abstraction and have business processes that provide a higher level of functionality in the application that access these components. Similar to the single solution view described above, but now these sub-components and business processes also are distributed across servers.

It is in this single-solution SOA context that SaaS and multi-tenancy become relevant. Using this model, an ISV could build an application on a platform that leverages the modularity offered by SOA abstractions and the easily customizable first level business process flows enabled by BPM. And, they can make this application available in a SaaS model. If there were to be a BPM+SOA based application platform made available by any of the BPM/middleware vendors, then it is only natural to expect this to also support declarative multi-tenancy.

Multi-tenancy enabled BPM/SOA-platform? Does it sound far-fetched? Not really… Last my month my class (Internals of Middleware Systems course at IIIT-H) built a multi-tenant SOA platform as the course project. They demo’d the solution at the end of the course. It had full working declarative multi-tenancy built into the SOA platform they built, and it included a business process (orchestration) engine based on Camel and a web services platform, registry and repository, and declarative multi-tenancy. (Phew! J ). I was pleasantly surprised. They actually got the whole solution working (albeit in a basic POC mode). So technically, a PaaS for Multi-tenant BPM/SOA based applications is definitely feasible. Sometime, hopefully soon, there could be commercial offerings in the market.