Some time ago during a discussion on ITtoolbox.com, I theorized about BPMS Cloud as the last, ultimate step, providing the final means to transition to a post-IT era.
As is well known, Cloud computing companies dedicate their business to enabling Enterprises to outsource all or part of their IT operations to external utility providers. From a Computer Science point of view, though, it may be considered that what Enterprises really outsource is their Enterprise Architectures (EA). Obviously, the outcome of such outsourcing depends on the quality of what is being outsourced.
Every Enterprise naturally creates Architecture during its development, whether it is aware of this or not. However, if it is not aware of it then ugly, chaotic, inefficient architecture is created. Such Legacy Business/IT Architectures are composed of a variety of applications chaotically integrated in a point-to-point manner through their APIs. With this kind of architecture it is extremely hard to change anything, let alone accomplish the Cloud Oriented Transformation. This is not good either for an Enterprise or for its IT. Given the current competitive market where 73 percent of large companies have already gone or are planning to go SAAS in the next 18 months such unfortunate Enterprises have few choices:- Immediately start Business Architecture Transformation to be able to ‘unbind’ their architectures; then outsource the unbound chunks one-by-one;- Try to outsource their architecture ‘as-is’, get poor results, and eventually become much less competitive.
So, for the purposes of this article we consider an Enterprise with well-formed, Service Orchestration –based Enterprise Architecture. We call it Elegant Enterprise (EE, Figure 1.) 
Figure 1: Elegant Enterprise Architecture.
EE is BPM/ESB/SOA based. To explain the operational behavior of such an Enterprise let us consider the usual Event-Driven user request scenario:
1. One of the external Actors places a service request through one of the Channels;2. This request is translated into one of the standard (usually XML-based) formats through XML /Security Gateway and is placed on the ESB as a request message;3. The corresponding Business Process Flow(BPF) Instance in a BPMS reacts by proceeding through BPF;4. On the way it calls, in an uncoupled manner, different services from Business and Data Service domains, as well as Business Rule Engine (BRE) services.5. Every service produces some functional activities and reacts with a reply message containing information that eventually reaches the actor to notify her that the request has been fulfilled (or not)
Elegant Enterprise is not just a catchphrase. It means that every part of the organization works by the same standards, methods and rules. It means that an Enterprise uses very few types of well defined, organized, and uncoupled artifacts. That makes this EA State the Desired State for pre-Cloud Architecture, and simultaneously the perfect Initial State for Cloud-Oriented Transformation. Let us note, how uncoupling different domains makes it easy, effective, and efficient to outsource them.
It is important from the outsourcing methodology to classify the types of Cloud computing companies. Two of them can be specified so far:
1. Service Domain (SD) Powerhouses. By SDs I mean the good old CRM, ERP, Billing, ESB, Security, etc.; by their corresponding powerhouses – either existing service providers like Saleforce®.com, or those inevitably coming in the future like SAP®, Oracle®, IBM®, etc. These computing powerhouses will provide hosted services based on their existing technologies and products: Netweaver™, Fusion™, and MQ™. So they are the obvious place to outsource one’s ESB and Service Producer domains.
2. Agnostic utility computing companies like Amazon®, Google®, Telemerk® etc. They are and will be providing data storages and dedicated or grid computing infrastructure for your services no matter what their nature and underlying technologies. They might become certified providers of the aforementioned powerhouses in order to be able to run and maintain their products. They usually comply with all standards defining data security and safety, so they can be an efficient and safe enough place to run one’s Data and Commodity Business services.
Of course, their hardware infrastructure is and will be highly virtualized to enable easy deployment of or connection to client services, no matter what their underlying technology.
So far, we have seen Cloud possibilities for all domains except for BPM. That was the reason I called the creation of BPM SAAS very desirable, for it would allow for the construction of a complete post-IT Enterprise Cloud Oriented Architecture (ECOA).
Then recently, on BPMS Watch, Bruce Silver’s blog on business process management, I discovered his notes from Intalio® User Conference about a keynote made by Greg Olson, founder of Coghead®,” a BPM-in-the-cloud service that uses Intalio® as the process engine under the covers”.
As Mr. Olson said: “The entire app is Web 2.0, accessible through Google Gadgets or iFrame “ (see Figure 2.)…
Figure 2: Coghead BP Designer.
As “…all of the data lives in Coghead®,… [it] provides a ‘linked application’ feature, in which a facade on Coghead communicates with a RESTful API on your app behind the firewall, which … is based on the Atom Publishing Protocol (APP).”
Voila! That is it! If we change the word ‘app’ to the more appropriate word ‘service’, we have a conceptually complete picture of BPM/ESB/SOA-based Enterprise Architecture, fully immersed into Cloud, which requires only two groups of in-house Enterprise professionals:1. Advanced Business Analysts (BA) who are able to create basic Business Process Flows/Subflows (BPF) and Business Rules, working with Cloud-based tools like Coghead® BPMS and any internal or external Business Rules Engine, connecting them in BPFs through ESB;2. Cloud company – employed Software Designers, able to make these processes executable and run them through this outsourced BPMS and all SAAS products.
This pattern can easily be achieved right now from the human resources point of view. In the future it will be possible to educate and train BAs to become so technically savvy that they may be able to fulfill both roles.
My current understanding of the ECOA Desired State (I call it Heavenly Enterprise because all its operations are in Clouds☺) can be represented as in Figure 3:
Figure 3: Post-IT Enterprise Architecture.
As can be seen in the Figure 3, the only internal actors left in this architecture are Business Analysts creating and deploying Business Processes and Rules. The third type of a team is Service Designers-contractors from Cloud utilities organizing communication with their SAAS. From the external Actors’ perspective this change is absolutely transparent. We have introduced here a new entity – Cloud Service Bus (CSB). Its purpose is to keep Enterprise and Cloud uncoupled from each other for easy replaceability, which might be especially important during the initial stages of Cloud Transformation, when not all Cloud utilities may prove themselves effective and efficient enough. It will be good then for an Enterprise not to be tightly connected to a given Cloud company and to be able to switch Clouds quickly, cost-efficiently, and without significant trauma for the business.
