Dennis,
I would approach the “BPM in the cloud” topic from a) a BPM reference model and b) an architectural framework for improving enterprise BPM systems.
At first, it should be clear the definition of BPM. I think, the most important BPM is “enterprise BPM system” which is a portfolio of business processes of the enterprise, as well as the practices and tools for governing the design, execution and evolution of this portfolio as a system. Well-known BPM as a discipline and BPM as software are used to implement this “third” BPM (see http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html).
The BPM reference model tells us that any enterprise BPM system is a complex and dynamic set of interconnected and interdependent artefacts: events, processes, rules, roles, objects, services, etc. The evolution of some artefacts and the relationships between them is necessary to accommodate typical changes in policies, priorities, compliance, technology, laws, etc. So, to be agile and responsive in business, it must be easy to modify all artefacts and their relationships without causing any negative effects (e.g. unexpected delays and undesired consequences) in any part of the BPM system.
The architectural framework defines the four main architectural principles necessary to achieve a high level of flexibility.
- All artefacts must be versionable throughout their lifecycle .
- All artefacts must evolve to become digital, externalised and virtual .
- All relationships between artefacts must be modelled explicitly .
- All models must be made to be executable .
The second principle can be extended that, finally (see figure below), the artefact should be able to exist somewhere in a “cloud” (i.e. somewhere on the Internet without any knowledge of, expertise in or control over the technology infrastructure that supports it) and should be available whenever needed. Although the concept of cloud computing is still in its infancy, our experience shows that the best use of this concept requires both
a. a customer-centric (i.e. not vendor-centric) “cloud” and
b. the internal preparedness of an enterprise to put its artefacts into the “cloud”.
I think, that this approach can reduce the cost of moving to clouds, because it considers a possibility to use clouds from the architecture of the system. Also it can help to define that SLA should be required for a particular “clouded” service, because explicit and executable models provide enough information to evaluate how the availability of a particular service contribute into the availability of higher services.
Thanks,
AS
Posts
