Compared to most acquisitions of its size, BEA Systems Inc has gotten a pretty good head-start with Fuego. Announcing immediate close of the $87.5m deal, BEA did not have to wait for due diligence to state its plans.
And, with an existing OEM agreement in place, it didn’t have to start from scratch on putting the pieces together. Today, BEA’s AquaLogic Portal (the former Plumtree product) already bundles in the standalone version of Fuego’s BPM server (now rebranded BEA AquaLogic Business Interaction).
We are a good year ahead because we already have a relationships and have shipped two versions of the OEM product, said Shane Pearson, vice president of product strategy
So what does BEA plan to do with Fuego products in the future?
Not surprisingly, BEA will continue the existing bundling of the standalone BPM offering within the portal. But there are more interesting possibilities in providing additional drill down links to data services or to software functionality embedded in Java components or classes. Those are the first areas on BEA’s list.
According to Pearson, the goal is to provide native support of data integration, through AquaLogic Data Services (formerly known as BEA Liquid Data) and Java components through WebLogic Integration.
Specifically, that would mean being able to drill down on a process to specify how data is federated, or access a Java process, without having to leave the business process modeler. And it would mean that you could inspect more components of a business process without having to switch to BEA’s other tools.
Admittedly, when it comes to integrating business processes, the line between human workflows and machine-to-machine processes can be hazy. That’s not a problem if you’re selling one solution or another.
For instance, if you’re selling Java or SOA-based solutions, it’s obvious that you’ll promote service or transaction integration. And if you only sell BPM, you’ll focus on the human workflow, claiming ESBs or transaction-based solutions are overkill.
Not surprisingly, when opposing players sold BPM and Java-portal solutions respectively, some BPM veterans learned the hard way that not all Java portals fully complied with the JSR 168 Java portlet standard.
Yet, with the BPM market consolidating, household names like BEA, IBM, and Tibco are finding themselves owning the entire spectrum of solutions, from BPM to portal, Java Connector Architecture (JCA), and ESB. The obvious question is what will they sell, and under which scenarios.
But it also opens up possibilities for flexible solutions modeling hybrid processes that may involve a varying proportion of human workflow and automated transactions.
For instance, you could have a procurement process that under normal conditions would be totally automated (such as when it involves a partner from the A list and an amount specified under contract).
Yet there are variations, such as special procurements with vendors not on the list, for modest quantities that might not normally require approvals, or larger procurements with vendors already on the approved list.
Consequently, in some cases, there may be links between human workflows modeled in BPM and orchestrated processes that transpire over a service bus. And that’s where there’s additional potential to drive more native integrations with other BEA offerings.
It’s likely that we’ll be hearing more from BEA on this topic later in the year.