They each map to a specific level in the 5-tier model:
· CAF (Composite Application Framework) implements the Presentation-tier. It includes User Interface + Task Management + Composite Applications.
· BPMS (BPM Suite) embodies the “Process” tier. It consists of BPM + BAM + Business Rules + Case Management.
· The SOA Grid represents the Services/Integration tier. It contains of MDM, SOA / ESB and Business Services.
BPMS can be considered as the core of BOP4, containing the primary BPM artifacts. CAF and SOA complete the stack, to allow the development of complete solutions, including user interaction and services integration.
Other vendors like Tibco and Oracle do package and sell their BPM solutions as complete suites as well. Under the hood these stacks consist of multiple separate products (glued together), each with a specific purpose and (development / runtime) environments.
The Tibco stack alone contains e.g. iProcess (BPM execution and design), Business Studio (BPMN design), Business Works (BW - develop services), iDecisions (Business Rules), Active Matrix (ESB), Rendevous and EMS (Messaging), General Interface (GI - Presentation) and iAnalytics and Spotfire (BAM).
BW (as successor of IM) and the Messaging products EMS and Rendezvous can be considered as the core products that made Tibco big. The other products were either developed or bought (E.g. iProcess, iAnalytics and iDecisions are originally Staffware products) to complete the Tibco stack and respond to the market, that has shifted from EAI towards BPM over the past years. Integrating all these products (or better: allowing them to corporate) has resulted in a sub-optimal solution.
For example: Using only iProcess/Business Studio (BPM) en BW (EAI) together already involves 3 different modeling environments, 2 runtime environments, and 2 different interfaces between BW and iProcess (one requiring EMS). It is not hard to image the complexity of administrating the stack, and developing, testing, deploying and maintaining the cross-product solutions built on it, and obviously the resulting additional cost and lead times.
For Oracle goes a similar story. When EAI became “hot” the database giant added the Fusion stack to their data-oriented and ERP portfolio. Once Oracle recognized that their BPEL engine was not sufficient to serve the BPM market, they took over BEA to fill the gap with AquaLogic BPM stack.
Apart from the integration issues of all these components another issue was introduced: In the 11g version it is still hard for Oracle to explain the coexistence of two process oriented products like Oracle BPEL and BPM in the same suite. Though Oracle states that BPEL should be used for short-lived processes where BPM is intended for long-lived processes this is a rather artificial distinction, as the BPM product can do both!
In order to prevent stepping in these pitfalls Cordys has deliberately chosen for an alternative approach. The Baan company invested considerable time (2 years!) and money to hide inside a lab developing the BPM product stack “Business Operations Platform 4” (or simply BOP4). This suite is effectively one solid integrated stack. The same web application may be used by Business Analysts, UI-, Service- or BPM developers, testers, administrators and users to do “their job”.
The so called “Composite Application Framework”-environment allows to design, implement, test, deploy and run any BPM related artifact. The BOP4 authentication and authorization mechanisms supports role based security for any user role, so every user will only “see” the functionality he/she requires. Artifacts can be seamlessly combined: Web Services, roles, data structures, business rules, UI-screens, Case Models, other BPM flows… All can be added to e.g. BPM model simply by dragging and dropping it on the canvas. A button click allows to validate, publish, run, test or debug the same BPM-process.
Cordys promotes the philosophy “eat your own dog food”. That implies that the same approach is used to setup the BOP4 environment itself: The stack completely web service based, just like the custom applications developed upon it. This implies that all tools and functionality provided by the BOP4 environment are available to use as a web service and used in the custom application! (E.g. user management).
Deploying applications itself is a simple 2 step process, that allows for a complete project to be packaged and deployed on a different environment.
It is not hard to imagine that facilitates quick time-to-market solutions, Something that has been proved by our projects. Combined with the claim of Cordys that the product is linear scalable it BOP4 is surely a strong proposition. As Cordys BOP4 is completely based upon open standards (e.g. BPMN, SOAP, JMS, XForms, SAML and XML / XPath / XSLT), the risks for vendor buy-in are limited.
Does this all sound too much as a sales pitch? Please forgive an BPM-consultant for being enthusiastic about a product that does what he really needs!
Surely: We had some issues with the first versions of BOP4, due to immaturity (Since CU4 stability has increased significantly!). And yes, not all components are completely “ready” (like BAM).
However due to BOP4-s solid architecture and the eagerness of Cordys to offer a top-of-the-bill BPM stack these drawbacks will be a matter of time. And they should, as Cordys claims: The strongest marketing tool of BOP4 is the product itself.
No comments:
Post a Comment