Process Center Repository in the Cloud
- April 4, 2012
- 3 Comments
Previously we’ve discussed why BPM was a bit late to the cloud, but now we’ll turn a little to what BP3 hopes to do about it in our little corner of the market.
The Process Repository Use Case
In our own area of specialization, IBM BPM, we can see new use cases as a result of new software capabilities and architecture. In Teamworks 7, and continued by WLE 7.2 and IBM BPM 7.5, the “Process Center” was introduced to the product offering. It represents a production system to manage your process repository. It includes versioning, asset management, file management, and the ability to push updates to your run-time servers (development, test, or production).
The process center acts like the development server while process authoring is going on, keeping everything in sync. It should be treated as a production system – much like your version control system is a production system, even though the end-users are IT professionals. But it is also a development system – one to which developers or administrators may need access to log files, the file system, Websphere configuration, etc. Traditional customer IT departments aren’t set up to support this “inbetween” mode- typical systems are either “development” and leveraging shared resources that can interfere with its operation at any time, or they are “production” systems in which case developers can not access the machine directly.
Deploying the process center to the cloud is a natural fit:
- It is isolated from the variance of development server resources at most companies
- It is available immediately rather than in weeks or months that it might take to get CAPEX approved and machines provisioned into the Data Center
- Actual installation effort is greatly reduced
- And yet, direct developer access can be provided if warranted. If not, a development run-time server can be set up on the fly, to provide such access on that testbed. Or a copy of the process center instance can be spun up, for purposes of debugging an issue.
- Outside consultants or developers can be included in the development process without giving them access to sensitive IT resources or physical hardware. We can spin up temporary authoring “machines” for doing BPM development and analysis work.
- And of course run-times can be spun up on demand to allow for parallel isolated testing of multiple process development initiatives.
It is a natural fit to put the Process Center repository in a Virtual Private Cloud. And that’s just what we’re offering our customers at BP3 – we’ll manage your process center like a production system, but give you all the development-level access you need. Moreover, we’re eating our own dog food by using this deployment approach for our own internal development efforts since the beginning of the year, and so far it is working great – for a very demanding set of users.
It isn’t the final state of IBM BPM in the cloud – IBM will likely see to that in future versions of software – and we’ll improve upon our own offering. But for customers that want to have more control over their deployments, while still benefiting from virtualization in the cloud, this is a great step in the right direction. More to come.
If you’re interested in our cloud deploy offering, check it out.