How do you decide whether to move BPM to cloud?

Metastorm business transformation maven Neal Lohmann discusses cloud computing and Business Process management migrations. Issues to consider when moving BPM to the cloud include the types of processes, their complexity, the number of interfaces, and the state of the databases involved.

These days, architects are called on regularly by CIOs looking at the cost of IT to analyze cloud computing scenarios. The CIOs wonder if there are not economies to be gained by outsourcing CPU cycles or purchasing bandwidth on demand, and they put the architect to work on the solution.

BPM at first, tied to the core business activity as it is, did not seem a great candidate for such cloud migration. But IBM, Cordys, WS02, Metastorm and others have begun to create cloud versions of BPM systems or Web-based BPM modeling tools that work in the cloud. BPM, too, is being measured for the cloud.

Issues to consider when moving BPM to the cloud include the types of process involved, their complexity, the number of interfaces involved, and the state of the databases involved.

We caught up recently with Metastorm's Neal Lohmann, director of business transformation solutions, to talk about issues to consider when architecting for the cloud. As you may guess, the answer on cloud for now is that one size does not fit all. 'What should go in the cloud?' is the key question to ask, according to Lohmann.

As a guide to this process, Metastorm has created a capability map, or cloud services heat map. Lohmann said it is a functional break down of what an organization does. It divides capabilities into what is complex and what is simple – and what is unique and what is general. It a way of asking of a business process: ''Does it add value or does it commoditize?''

If I look at all the different things we have to do, I can look at it from the point of view of what would go in the cloud.


Neal Lohmann
Director of business transformation solutions, Metastorm

"If I look at all the different things we have to do, I can look at it from the point of view of what would go in the cloud," he said. As an example, Lohmann cites cases from the insurance business, where something like a life insurance claim is simple – someone dies and the claim is paid – and something like a claim for disability, where the process becomes more complex and perhaps a less apt candidate for cloud.

Once they are mapped, capabilities for cloud deployment must be prioritized, so capabilities are scored.

If a company has 119 'simple' billing systems, that does not mean they all go to the cloud, said Lohmann. These systems can be highly interconnected, so architects need to separate the parts in order to put them in the cloud. Clearly, service-oriented architecture has a role here. Moving to the cloud may be an opportunity to consolidate apps and go across multiple platforms, but this is an area where planning and caution should be employed.

"If I tell a cloud vendor I have 60 systems to interface with, I don't know if that is my best opportunity," Lohmann said, somewhat sardonically.

Data, too, is an issue that affects BPM-to-cloud migration. The cloud may offer savings, but that may obscure risk, when some data bases are better off right where they are.

Some operational data bases are old and a bit of a black box. ''A lot of companies have a hard time retiring databases,'' Lohmann quips.

Dig Deeper on Topics Archive