I am just back from Pune, India, where I attended training in designing with TIBCO iProcess Modeler. Having prior experience in BEA’s AquaLogic BPM, it is now interesting to compare these two tools:

Both BEA and TIBCO have acquired their BPM technology through acquisitions. TIBCO, which has a long history as a middleware vendor and is specifically known for its robust messaging solutions, merged with Staffware, the leading workflow/BPM vendor of the time of acquisition in April 2004. BEA, an infrastructure vendor specifically known for its transaction managament and application server products, acquired Fuego, a pure-play BPM vendor, in March 2006. Unlike Oracle or IBM, BEA and TIBCO have given their BPM tools an independent and promoted status in their technology stack. With XPDL as the native process description language, they embrace tasks (or steps) as the primary BPM entities and allow pragmatic integration also at the BPM level. It will be interesting to see how Oracle — with its recent acquisition of BEA — will incorporate AquaLogic to its BPEL-centric architecture.

As for modeling, BEA AquaLogic adheres to the BPMN standard, whereas iProcess relies on its own proprietary notation. What I find specifically awkward in TIBCO’s notation is that the anchor point of connection in a shape denotes the type of the connection! Also, there are no swimlanes indicating the role responsible for the task, but users, groups or roles are defined in the task (step) definition. This makes the diagrams less readable and harder to maintain.

1-0 to BEA.

Disappointingly but to little surprise, the look and feel of the iProcess Windows client had not changed a bit in two years since the last time I had exposure to iProcess, the former Staffware BPM. Already then, I deemed that it is unexcusably old-fashioned and awkward. But as they say, if it ain’t broken, don’t fix it: underneath the unaesthetic user interface, there is a powerful and versatile workflow tool that redeems its promise in people-intensive workflow processes. Besides, there is now also the thin browser client, whose look and feel is at least from this millenium.

AquaLogic only comes with the browser interface. At least in its 5.7 version, the standalone user interface is quite plain and rather awkward to use. It may be suitable for rapid application development but not for very demanding production use. The native method to create forms in AquaLogic is to use so-called BPM Object Presentations that bundle the displayed data as BPM Object structures with appropriate attributes and methods. Sophisticated use of BPM Objects requires some up-front information modeling. However, BPM Objects provide a useful way to bundle requisite information to structures that can be passed as arguments between processes.

TIBCO iProcess cuts corners in this respect and represents information in a flat fashion as basic-type context variables called fields. Composite fields can only be defined by associating a table with it. This simplifies the construction of forms, but makes process (or, procedure, in TIBCO terminology) interfaces more brittle, as the arguments are passed in basic types. What I find as a powerful feature in comparison to AquaLogic, however, is the ability to readily use conditional statements in forms to enable changing the form contents dynamically at run-time.

For the UI part then, I would say it’s a draw. 2-1 to BEA.

Where I especially would see iProcess as more advanced than AquaLogic is in what TIBCO refers to as Work Management: releasing/withdrawing of procedures, version control and queue administration. These issues are handled in much clearer and more straightforward manner than in AquaLogic. It is possible to develop an unreleased version, while the released version is staged to testing, then release a new version, possibly revert back to an “as-was” version and so on. In AquaLogic server environment, deployment of new releases is rather laborious and involves multiple steps, process versioning happens automatically under the hood and queue administration, if it can be called such, is more like an afterthought. Instance administration is also clearer in TIBCO.

TIBCO scores here. 2-2.

Then again, the area in which TIBCO’s greatest embarrasment (along with the Win UI) lies is — somewhat surprisingly — integration. Seriously, we are about to enter 2010’s and the primary mechanism to integrate with external applications is through commandline-calling functions and interface files! At least it is possible to call BusinessWorks, which is TIBCO’s EAI/SOA tool, but this is only possible asynchronously through JMS queues.

BEA is much more mature in terms of integration. It allows introspection of various computing resources (Web Services, EJBs, JMS queues, etc.) that can then be readily used as logical entities within the process. While architecturally it is advisable to use WebLogic Integration as the EAI tool for fine-grained orchestration of native resources, nothing prevents such integration in AquaLogic as well, if it is pragmatically justified.

BEA scores double. 4-2 to BEA.

In summary, both BEA AquaLogic and TIBCO iProcess are conceivable process management tools for people-intensive business processes. iProcess is better in the workflow functionality, but AquaLogic beats it when it comes to EAI and SOA. iProcess may be better suited to legacy environments with lots of manual work, whereas AquaLogic outperforms it in more modern computing environments with substantial P2A and A2A components.