Implementing Oracle Integration Cloud

A couple of days ago the updates for OIC included a new feature B2B (April 2020 new). Specifically, support for EDI X12. Whilst this doesn’t mean SOA Suite B2B is redundant yet (as that still offers a broad range of other complex exchange protocols HL7, EDIFACT, SAP iDoc – complete list here). I wouldn’t be surprised if Oracle considers leaving behind support for one or two of the more complex file formats such as EDIEL. But with X12 cracked, I wouldn’t be surprised to see EDIFACT follow soon.

SOA CS future?

So where does the leave SOA CS given one of the differentiators to OIC was the existence of the B2B and MFT elements? OIC has not yet fully displaced SOA and SOA CS, there are use cases that OIC can not yet fully address. For example in the MFT space OIC has caps on filesize (whilst MFT does not). MFT also supports Applicability Statement (AS) standards (IETF specification for AS2). Unlike some of the payload formats, particularly the metadata-driven ones we may see fall away more quickly, the AS standards provide the means for communications to be responded with a ‘Message Disposition Notification‘ (MDN) which means the receiver will tell the sender the receiver has safely and fully received the communicated payload – non-repudiation. We have seen banks and other data-sensitive organizations continue to use such standards (after all you want your employer saying they told their bank to pay your salary, and the bank say, nope not got anything or transfers between the bank and the tax man).

How quickly these gaps will be addressed in OIC is not clear, or whether these cases will be addressed, or whether SOA will continue to answer these edge cases until superseding standards and techniques make them redundant.

The bottom line is there are too many customers with legacy estates on-prem for SOA CS to be retired any time soon. However, I would not be surprised if SOA follows the route of ODI when it comes to Oracle Cloud. Oracle has developed ODI on Oracle Cloud Marketplace, which provides an on-prem style deployment configured (and presumably tuned) to run on Oracle Cloud as an IaaS Virtual Machine. This potentially simplifies the BYOL license model leaving the customer responsible for a level of patch maintenance (be that take a new ODI Marketplace instance spin it up and apply the configuration, then drop the old one, or run the traditional patch processes).

We will see SOA continue to be patched and maintained for a long time to come. But I wouldn’t surprised if Oracle makes it more and more attractive for SOA customers to use OIC – possibly combining OIC and their SOA Suite instances with a view that when customers need to update migrations, they consider the port.

Whilst this may sound like Oracle are potentially leaving customers without the infamous paddle. However, our experience in the partner space is that Oracle seeks to enable them and recognize that most partners are very capable. Not to mention, when the heat is on, partners with middleware Aces can usually find their way through the Oracle organization to get what is needed.

I think we’ll continue to see a number of Oracle’s specialist partners file the gap with tooling adapted from on-premise solutions. It is these partners that also have the wealth of expertise on knowing to get the most out of SOA Suite and keep it secure.

Finally …

So OIC will continue to absorb capabilities that had separated it from SOA suite cementing it as the mainstream offering. But the old warhorse will be around for a long time (remember many older companies still use Cobol successfully) yet. To use a car analogy, those sticking with their trusty vintage Mark 1 Golf that has done 500,000 miles will have to stop looking to the manufacture for service and parts and enlist the support of a passionate specialist.

To be clear, this is only our opinion, and not informed or confirmed by Oracle.