Well, it’s certainly non-intuitive and it’s undeniably controversial. But it’s also true. You can’t implement BPM with BPM. Or, more precisely, you can’t implement BPM with just BPM. There are multiple reasons for this:
First of all, business processes take place in context
The multi-step business process that you draw in your nice graphical modeling tool doesn’t stand alone. In order to manage those multiple process steps in an automated manner, your BPM solution has to be able to communicate with people (for the workflow steps) and it has to communicate with applications – both your enterprise’s applications and your trading partners’ applications.
Communicating With People
As far as communicating with people is concerned, up-to-date BPM products generally include broad support for what we inelegantly refer to as “human-centric workflow.” But that still doesn’t cover all of your BPM requirements. You still need a development tool that can help create an assortment of user-facing programs. And, you have to be able to deploy those user-facing programs on a broad range of devices (PCs, PDAs, kiosks, phones, pagers), and communicate across a wide array of networks (dial-up, broadband, wireless, public Internet, private).
You also need the ability to provide for authentication and authorization as well as personalization.
In other words, you need a graphical user interface development tool and you need a portal.
Communicating With Enterprise Applications
In addition to communicating with people, a complete BPM solution has to be able to communicate with programs – lots of programs.
Now, as far as this program access is concerned, if all the applications that you have to connect to had a consistent set of interfaces, life would be sweet. But they don’t.
Instead, it’s a mixed bag of applications that you have to be able to deal with – applications built at different times, by different people, for different purposes, using different component models, different communications technologies, different databases and different data models.
So, you have to access these applications in different ways. This calls for “adapters” or “wrappers.”
For those applications that expose their functionality and data via published APIs, adapters serve as the conversion mechanism that allows the technology of the BPM solution to communicate with the technology of the application. For example, a BPM solution that can natively call Java APIs needs adapters that can place a “Java façade” on top of legacy CICS, IMS or IDMS applications.
1
Solution Center Resources
Print this article
Email this article
Talk Back!
Write to Editor
