In my previous article on Need for BpaaS Consortium, I stressed the need for interoperability as a number one concern for the enterprises to adopt SaaS and in particular BpaaS. I pitched for the need for a generic body or a consortium that can act to address the interoperability concerns so that the consortium can do activities such as:

• Certifying BpaaS providers
• Set standards for APIs and other business functionalities they expose
• Set standards for message exchanges between the BpaaS providers

While the independent body can definitely increase the confidence of enterprises in adopting SaaS & BpaaS, but looking from another angle, the concept of BpaaS interoperability has created new opportunities for service brokers by tapping the potential opportunities in this space.

Before we go further, let us analyze the cloud computing roles as defined by NIST.

Cloud Broker: The New Role & Opportunity
The recently published Cloud Reference Architecture from NIST has defined various actors and roles:

• Cloud Provider: Person, organization or entity responsible for making a service available to Cloud Consumers.
• Cloud Consumer: Person or organization that maintains a business relationship with, and uses service from Cloud Providers
• Cloud Auditor: A party that can conduct independent assessment of cloud services, information system operations, performance and security of the cloud implementation.
• Cloud Carrier: The intermediary that provides connectivity and transport of cloud services from Cloud Providers to Cloud Consumers.
• Cloud Broker: An entity that manages the use, performance and delivery of cloud services, and negotiates relationships between Cloud Providers and Cloud Consumers.

Very clearly we are seeing the cloud broker as a new role and opportunity that can evolve in the coming days. Initial thoughts on the cloud broker revolve around obtaining the IaaS excess capacity from multiple IaaS providers and providing the service to end users with more SLA options and cheaper cost options.

However, the real value proposition of cloud brokers can be realized if the cloud brokers started acting as BpaaS interoperability providers, so that enterprises that are acquiring BpaaS capabilities actually source from cloud brokers and not directly from BpaaS providers. Cloud brokers in turn can work on interoperability between multiple BpaaS providers so that changes in BpaaS providers will be transparent to the cloud consumers and the providers can be moved and vendor lock-in is avoided.

Message Broker Pattern in B2B Communications
The concept of a cloud broker facilitating BpaaS interoperability is not new. Most of the messaging systems that enable B2B communications have adopted this pattern in the past.

A message broker pattern is an architectural pattern for communication among applications while minimizing the mutual awareness that applications have of each other. A message broker is a physical component that handles the communication between applications. Instead of communicating with each other, applications communicate only with the message broker. An application sends a message to the message broker, providing the logical name of the receivers. The message broker looks up applications registered under the logical name and then passes the message to them.

Placing the message broker between the sender and the receiver provides flexibility in several ways. First, the message broker allows the integration solution to dynamically change its configuration. For example, if an application must be shut down for maintenance, the message broker could start routing requests to a failover application. Likewise, if the receiver cannot keep up with the incoming messages, the message broker could start load balancing between several receivers.

Second, the message broker can choose between applications that have different QoS levels. This resembles the dynamic configuration, but the message broker selects the application based on specified criteria. For example, an application for premium accounts may fulfill requests quickly, but an application for general use may have a longer processing time.

BpaaS Interoprability as a Service
By tapping into the need for BpaaS interoperability coupled with the concept of a cloud broker and message broker pattern, various organizations can actively play the role of a BpaaS broker and can provide BpaaS interoperability as a service. Here is the sequence of operations in such a scenario.

• Various BpaaS providers start providing BpaaS solutions
• A BpaaS consortium will act as a nonprofit governing body in setting the standards and policies for BpaaS providers
• Cloud brokers will provide the BpaaS interoperability as part of their BpaaS offering
• Cloud consumers will consume BpaaS solutions from the cloud brokers
• Cloud brokers will set the standards for cloud consumers to consumer the business processes
• Cloud brokers in turn will ensure that the service requisition calls can be transformed to different BpaaS providers
• Cloud brokers will define the appropriate SLAs and service transition triggers that can trigger a change from one BpaaS provider to another
• Service transition will have minimal or no impact to the cloud consumer
• The Cloud broker will contribute actively to the BpaaS consortium community in terms of standards, lessons learned and certification activities.

Summary
The concept of BpaaS interoperability as a service looks real and has huge potential for players to tap into this business opportunity. This in turn enables enterprises to have more faith and confidence in adopting BpaaS. We will see an active role of BpaaS consortium in this endeavor. The following diagram provides an outline of this concept and requests that all the players move in this direction.

• You Can’t Have IT as a Service Until IT Has Infrastructure as a Service
• Desktone “Desktops as a Service”
• IT as a Service: A Stateless Infrastructure Architecture Model