Implementing BPM solution is projected as one of the most rewarding initiatives in and organization based on process excellence and cost savings parameters. While the ROI of BPM looks great on paper it is one of the most challenging implementation in enterprise wide scenario. The common difficulties or I must say pain of implementation felt across the enterprises is longer than life time for implementation resulting in inflated cost of implementation.
Look Beyond Mirage of Process Modeler
The most fancied part of BPM is drawing processes in process modeler enabling business people to implement business models, changing market scenarios and measuring metrics associated with changes. The fact that is ignored in envisioning the implementation by business people is graphical modeling tool doesn’t stand alone. The 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 in order to manage those multiple process steps in an automated manner.
Integrating with Enterprise Wide Application
The other misunderstood part is human centric workflows. The impression these workflow create is that they can be configured and run without development support. The fact is a complete BPM solution has to be able to communicate with programs – lots of programs.
The difficulty in this part of communication with programs is connecting with different set of interfaces which are more often not consistent. People often discover late that they are dealing 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.
The way to address this problem is to build web services communication with the legacy application which is commonly called wrappers or adapters.The catch is you have discovered this rather late that you need to build wrappers for web services communication with your BPM tool.
You discover now we are talking of SOA .The other thing which now comes in to play which standard to use BPEL, XML or XPDL.
Closer Look at Adapters
Adapters serve as the conversion mechanism for those applications that expose their functionality and data via published APIs 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 applications.
The pain point here is not every legacy application publishes APIs – some were never intended to be called by another program. In those cases, you need adapters that can “screen scrape” the terminal-based interface of the legacy application, putting an API on top of programs that support user interaction via terminals.
In some few cases, you may use adapters that allow your BPM solution to call the legacy applications' databases and file systems directly. However, the editing and validation logic that you write as part of this direct data access approach is bound to be either incomplete or in conflict with the data access and validation logic that exists in your legacy apps. So it’s best to use this direct data access as little as possible.
Semantic Differences
Take one step further in your discovery of problems - you have now come across the problem of semantic differences between legacy and BPM application.
Every application that is used to run a major enterprise uses data elements (i.e., fields) with different element names (Do customer_ ref and customer_num refer to the same data?) and different element properties (Is the pin _code field numeric or alpha?) These data elements are managed within different structures (Do we have records with multiple phone numbers per address or do we have multiple records per address, each with a single phone number?) Finally, the semantics or meaning of the data varies from application to application (Does item-weight refers to net weight or gross weight? Is it expressed in kilograms or pounds?).
You now feel the need of data transformation code to convert the data from the style, format and semantics of your legacy applications to the style, format and semantics of the BPM solution.
Conclusion
The following conclusions can be drawn from the above discussion
- Never do the mistake of considering BPM as standalone implementation
- Plan BPM implementation considering the environment of your legacy application
- The implementation should be planned based on the services adapters that needed for integration with BPM solution. Semantic differences should also form part of your implementation planning to avoid any last minute surprises
- BPM implementation needs lot of custom development for implementation
- For effective implementation the core committee should comprise of owners of different legacy application and the IT people owning those application. This will help in visualizing a wholesome approach and avoiding the last minute surprises. The ownership of implementation must be shared with legacy application owners.
