-- I work for Oracle, all opinions here are my own & do not necessarily reflect the views of Oracle -- Oracle Ace Director Alumni
TOGAF 9 Certified Architect
- https://blog.mp3monster.org
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.
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.
With the recent announcement of working with Automation Anywhere (press release here) adding to the partnership already in place with UiPath, Oracle’s approach to Robotic Process Automation (RPA) is differing to other players such as SAP and Pega Systems for example who have acquired vendors.
It is an interesting question as to whether partnering is the right solution given that RPA vendors can and do challenge the need for an integration platform. After all with the exception of IoT most solutions have an some form of UI or API the robot can connect to. This assertion whilst isn’t wrong it fundamentally overlooks the ability to push transaction volumes through, UIs are vulnerable to change, the ability to apply very robust security. But when discussing integration needs with business rather than technology leaders such factors can be so easily overlooked.
Whilst acquisition is a possibility, unless Oracle acquires one of the big three (Automation Anywhere, UiPath, Blue Prism) they are likely to end up with a less established and/or less feature rich offering, that could very easily be perceived as an expensive OIC adaptor. Where as by having now partnered with two of the three major players, it is easier to sell the story that the technologies can be complimentary.
So how do they compliment rather than compete? The traditional buyer of OIC is an IT team either corporate or departmental. Such teams are often constantly being pushed for new Integrations to and often the most problematic of these are the smaller demands for proof of concepts etc that drive innovation forward, or enables the next new business opportunity or short lived integration need. By introducing support for RPA means several possibilities …
Reverse the sales story, where an RPA sale has displaced traditional PaaS but the scale up has become too costly then the pitch can be it’s easy to make smooth transition to a PaaS solution by using the adaptor to streamline the use of RPA where it is needed,
Using RPA against services the have changing and regularly enhancement are likely to suffer from the need to continually maintain the RPA scripts. If this happens a lot then the RPA model will feel very brittle. Whilst this is a plus from an iPaaS perspective, we don’t want the fact that perhaps central IT have suggested RPA as an interim solution and therefore end up being to blame for the effort involved in maintaining brittle scripts,
RPA can be used by less technical users to effectively develop and prove business needs and thinking before an often over stretched IT team get involved – use RPA fed with appropriately sourced data via Integrations to help determine/prove business idea, before making the larger investment in a scalable robust solution,
Integrations can be exposed and extended using RPA for tactical short term fixes, if the pilot proves value, and the next step is scale up – then replace RPA with OIC.
The last of these possibilities is very interesting as we’re moving towards what could be described as the citizen adaptor (in the same sense of having citizen developers).
Central IT teams embracing the idea citizen developers and integrators means rather than what is sometimes referred to as Shadow IT being that only a shadow with no visibility of what is happening. By embracing the idea, we create the opportunity to:
Influence/set the parameters for the tools being used – increasing the chance of ensuring efficiencies in investment (and/or license compliance),
See if common solutions or problems are occurring across the organization therefore focus efforts of building strategic solutions that deliver the biggest return on investment,
Potentially leverage efforts from shadow IT teams for the benefit of the wider organisation,
Most importantly opportunity to monitor what is happening to ensure legal and contractual compliance is assured e.g. if corporate policy prevents the use of cloud storage services from being used to hold certain types of data – it will be easy to see what Integrations exist with such services, and then review the data involved.
In this light working with, rather than trying to compete against the market leading RPA vendors has the distinct potential to present OIC as a strategic enabler.
Whilst OIC is not a traditional development environment, once you get past simple integration development you’re going to want to start implementing some configuration management controls and release promotion mechanisms. We discussed this in the book, and illustrated how this can be achieved in a simple manner using the OIC APIs.
However this can be further simplified, and consolidated so that a configuration management approach doesn’t just work for OIC, but can be applied to other products both in the Oracle cloud and beyond. Flexdeploy from Flexagon, has long provided this kind of tooling around Oracle’s SOA Suite but over the last couple of years has been addressing the same challenges for Oracle’s cloud offerings.
When we have spoken with Flexagon about the tool’s capabilities we found a product that very feature rich and addressed all the use cases we could identify as being needed. However, rather than take our word for it, checkout the following resources:
Traditionally integrating with systems that don’t offer APIs or a shared storage mechanism (such as open tables) has been something of a headache often resulting in the ‘last mile’ of the integration process being manual. The manual steps often come because the cost of building and maintaining the means to integrate has not been cost effective or even an option (vendor has end of lifted a product, and not willing to add an integration mechanism).
The idea of ‘screen scraping’ isn’t new, but the cost of implementing such mechanisms has dropped and the new generation of Robotic Process Automation (RPA) tools such those provided by UiPath have made it significantly easier to integrate and automate UI driven processes. Whilst UI based integration isn’t recommended as a first option for integration, it shouldn’t be ruled out particularly as it gets easier and easier to generate and maintain the UI automation. There are several factors that need to be considered as to whether such an approach is appropriate, for example:
the ability to run a robot to execute the UI interaction,
the volume of data needing to be moved through the UI – you wont escape the latency issues that may exist with UI steps,
is the UI being automated changing rapidly (is there enough cost benefit for automating)
Oracle have been working in partnership with one of the leading RPA product vendors – UiPath, which has resulted in an adaptor for Oracle Integration Cloud. The adaptor allows you to pass data to the UiPath Orchestrator component which will run the processes in an unattended mode. In the adaptor configuration you provide information about how many resources you want the Orchestrator to apply to the task, the queuing of the job and so on.
UiPath’s Architecture
for more information on RPA and the adaptor the following links maybe of help:
Whilst Oracle’s roadmap in the RPA space is not entirely clear we have heard indications that Oracle are limiting themselves to just UiPath (this is what UiPath say about the partnership).
Regardless of the approach you’ll see that the adoption of RPA is important in Oracle’s vision, with their Agile Finance making a clear indication of its view (see the paper here).
We have had a number of interesting conversations of late about the transition from ICS to OIC and to spice the discussion whether it should be OIC or Autonomous OIC. The reality of the situation is that the transition between ICS and OIC is a relatively straight forward one using the export and import tooling.
The real challenge is the impact to organisations appears to be the change in licensing models as OIC works with the newer Universal Credit Model (UCM) where as ICS is in the older arrangement of traditional accounts where you buy the use of specific services, in some ways not too different from traditional Oracle traditional product licensing. For organisations that operate with corporate level buying teams this is organisationally more challenging. As just buying credits can feel like your giving the IT children pocket money and you don’t trust them to ensure the money is spent wisely and they don’t come running back a day later when they say spent all the money can we have some more.
IOC or Autonomous OIC
For the smaller customers where they’re generating less than 5000 Messages per hour (think Integration triggers where each message is <50k – which is fairly big for most needs. Although be aware but moving large files is going to eat through your messages as the transfer cost is file size / 50k = no. messages used (consumed or sent), of effectively 250MB per hour. The autonomous option is a no brainer for smaller use cases in terms of cost as it means on current pricing you have your integrations operating for a lot less than £500 per month (£0.5867 x 24 x 30 – using standard with the flex scheme – https://cloud.oracle.com/en_US/OIC/pricing). With that the SaaS adaptors are also included – that means you could operate say Workday to Oracle Financials for an SME without much problem.
Note: Presently June 2018 Edition of Oracle PaaS and IaaS Universal Credits Service Descriptions - does not clearly define KB and mixes KB and Kb. Having raised this with product management it has been confirmed to mean KiloBytes and NOT Kilobits
As the volumes increase, the differences are going to change, whilst we haven’t done the maths, we’d expect the increasing volumes to eventually favour traditional OIC.
The rules do go beyond simple messages when the Visual Builder (VBCS) and Process (PCS) elements gets involved. The formulas do boil down to users and message counts so the maths are relatively managable. Note the explination for concurrent users is a little more complex than may first appear, and worthy of a blog explination in its own right.
There are other considerations as well for Autonomous OIC vs standard OIC, such as whether you want to have more or less control on the processes such as absorbing updates, handling backups, whether you need to isolate the data from everyone else – and this is a question that is likely to be driven by compliance over anything else for most. Whilst we’ve just highlighted the list prices, when doing the calculations of the cost benefit, you need to factor in the skill sets involved in the different options and the ability to respond to dynamic demand.
Just to link it back to the book, whether its OIC or Autonomous OIC the integration engeine is essentially still the same as ICS. So reading about ICS is still going to help, of course there will be some cosmetic differences, but the fundamentals remain the same.
When ICS was launched it delivered on of the values of PaaS namely you didn’t need to worry about setting up storage, database and compute, it was all sorted out for you. Admittedly it come with a lack of elasticity when it came to resilience and scaling. In contrast Services such as SOA CS which required you to go through each of the layers, but gave you a degree of flexibility. The whilst simpler than building SOA on-premises it still represents a laborious and fiddly process that took time.
When OIC (Oracle Integration Cloud) arrived and the introduction Universal Credits we had a pricing model that made it a lot easier to be elastic in terms of approach to resourcing, but a deployment model that following SOA CS rather than ICS. To an extend, one step forward, and another back.
Fortunately we are seeing head way that means we have recovered that backward step.
Suite but over the last couple of years has been addressing the same challenges for Oracle’s cloud offerings.
Oracle have been working in partnership with one of the leading RPA product vendors – UiPath, which has resulted in an adaptor for Oracle Integration Cloud. The adaptor allows you to pass data to the UiPath Orchestrator component which will run the processes in an unattended mode. In the adaptor configuration you provide information about how many resources you want the Orchestrator to apply to the task, the queuing of the job and so on.
When ICS was launched it delivered on of the values of PaaS namely you didn’t need to worry about setting up storage, database and compute, it was all sorted out for you. Admittedly it come with a lack of elasticity when it came to resilience and scaling. In contrast Services such as