And, in a rub at SAP, Oracle is adding hooks for SAP customers as well, on the rationale that more than 30% of the SAP base also uses various Oracle apps.
Part of the announcement leverages several Siebel CRM to Oracle ERP integration packs that have been available for several years. They include an opportunity-to-quote process that links Siebel CRM On-Demand to Oracle E-Business Suite; order-to-cash process, tying Siebel CRM to Oracle E-Business Suite order management module; and a vertically-oriented cal center process for life sciences that ties Siebel contact center to Oracle’s Adverse Event Reporting System.
The new piece includes the SAP integration packs that Oracle has been touting, that cover Siebel CRM, Agile PLM, Hyperion business intelligence, PeopleSoft HR, plus several vertical industry modules including Oracle’s Utilities and Communications sector billing and revenue management modules.
These integration packs are available now. On the horizon, Oracle plans to make available additional vertical industry integration packs for consumer packaged goods (CPG) manufacturers and the high tech industries.
Our View
There’s relatively little new in this announcement, except that Oracle is saying that it intends to expand development of pre-built integrations. Oracle is playing catch-up to SAP, which has several years lead in developing these packaged integration processes. In fact, the concept is as old as the old Crossworlds EAI collaborations, which have since been rewritten by IBM as J2EE containers to run under IBM WebSphere Process Server.
In a sense, these pre-built integrations were, in essence, bridging applications, meaning that they were vendor-designed functional modules that happened to be point-to-point integrations. The drawback is that, with customer needs so diverse, such packaged approaches to integrations traditionally could not reach a critical mass of the market because customer needs or application configurations often were more unique.
But the good news is that such pre-packaged integrations supported the concept of abstracting business objects from their source systems, which is highly consistent with SOA. And with when service standards providing common syntax and protocols for exposing the functionality of different applications, the barriers to developing and supporting packaged integrations were lowered.
