Tags

, , , , ,

A periodic conversation I get involved is the the relationship between Oracle’s SOA Suite and Integration Cloud. We’ve long held a view based on our conversations with Oracle product management.

There is a formal statement of direction for SOA Suite available ….

Click to access fusion-middleware-statement-of-direction.pdf

The bottom line as we read it:

  • SOA Suite isn’t going to be scrapped and customers will not be forced onto Integration Cloud.
  • Future changes are going to be on making transitions easier to the cloud, and a customer decision to adopt OIC.
  • Releases will focus on keeping things up to date and aligned with the underlying technologies from Java 8 to Java 11 as a long term release of Java. WebLogic version updates.
  • We’ll see mechanisms to cloud deliver integrations as the primary focus.

Our interpretation…

So SOA Suite isn’t going away. This doesn’t surprise, we’ve held this view as the customer base is significant. As SOA Suite often goes hand in hand with customers using EBusiness Suite (EBS) which is going to be supported into the 2030s there will be a lot of resistance to replace the software central to getting data in and out of EBS.

Function development in the document doesn’t feature very highly. This reflects the fact that firstly SOA Suite is pretty mature, and the principles of abiding by the standards such as BPEL constrain evolution. While SOA Suite is not going away, the bulk of development effort is going into OIC such as functionality that can provide the features like the Managed File Transfer (MFT) extension to SOA and B2B (support for edifact data flows.

Development is driven by largely by the underpinning technologies such as WebLogic which has seen some significant changes to support more cloud native deployments such as containerisation. Plus the newest versions of the J2EE standards. This where we believe most changes to SOA Suite will come from.

Looking at the changes visually

We have expressed visually the evolution of OIC from its discrete services of ICS (Integration Cloud Service), PCS (Process Cloud Service) etc to the combined product With this we have overlaid the non cloud products of SOA Suite and Oracle Data Integrator (ODI) its bulk data partner. The following image sequence shows how we have seen the landscape change.

The 1st PaaS capabilities running on OCI Classic. With OIC not present as the different areas that no form OIC where available separately.

These diagrams are side by side to help visually show the combining of services into OIC, with ICS being the heart of the capability.

With OIC consolidated we initially saw ODI being superseded with DIPS for cloud bulk data. This predated the Oracle organizational change which saw PaaS being slit to align with IaaS or SaaS. Services like OIC aligned with SaaS as it follows the more low code model and citizen developer ideals. Those services that are more technical aligned with the IaaS part of the organization.

With strong containerization capabilities, and revamped marketplace SOA and a reinstated ODI have become rebuilt container images that are obtained through the market place. This makes the lift and shift easier as the marketplace solution takes away the build and configuration needs and provides a standardized base configuration onto which you deploy your services.

It is also worth noting that a generation of ODI is underway identified as OCI Native. This product is focussed on delivering an OCI native capability to facilitate data migration onto OCI.

Future as we see it …

As already stated we believe SOA Suite will be around for a long while to come. But once the majority of EBS customers have transitioned to SaaS (which is probably going be for some going to be a lengthy journey because of the customisation and the maturity/cost of cloud at customer deployments) we’ll see SOA Suite start to fade.

With the OIC execution agent able to run in a clustered deployment for Hybrid deployments. Features such as B2B available in OIC now available, not to mention the adaptor options and the underlying Gen 2 infrastructure becoming a lot more mature (meaning Cloud at Customer (C@C) is stable and scalable for deployments that are location sensitive).

The following images, roughly align to the phases shown in the previous diagrams.

OSSI was Oracle’s look at building a product like Microsoft Flow or If This Then That. We believe it was effectively prebuilt integrations using ICS with simplified UIs for business users to populate. It however was quietly dropped.

As OIC has matured, the scaling and performance capabilities are been developed such that it is capable of meeting through put of millions of events. Leaving SOA, and the ability to get at the configuration to tune it for the rare hyper scale environments. But more importantly address the lift and shift use cases where EBS and its integrations are moved from a customer data centre to Oracle Cloud.

The top tier of using Oracle Kubernetes Engine and Event Hub are for integration best suited to hyper scale demands, where the abstraction layers that come with OIC and SOA Suite are effectively removed to maximize processing velocities. The trade of being moving from low code (i.e. quick development tooling) to raw code (requiring for more technical expertise and effort to develop).

Conclusion

SOA Suite will eventually disappear but not for a long time. As OIC can support Hybrid deployments it make sense for it to be the long term answer as it fits more elegantly into the iPaaS space than SOA Suite. Oracle can introduce a great deal of intelligence to autotune OIC as it is not bound by the same constraints such as SOA Suite.

If your technology roadmap is long range, as it may well be with heavily customized ERPs being a dominant IT presence. Then we would recommend establishing the timelines or criteria for starting a transition strategy – which will largely be dictated by the future of your ERP like EBS. This could of course be aligned fairly radical steps like binning the current 20+ year old ERP with its thousands of customizations in favour of a clean start and adopting SaaS ideals (i.e. processes follow industry norms and using PaaS4SaaS techniques to build the custom business processes as effectively discrete functional elements, that use the integration layer of the SaaS service and deployed so it feels seamless). Such a roadmap doesn’t necessarily mean rip SOA Suite out and rebuild all your integrations with OIC immediately. The two technologies can play well together and be used side by side.

So consider freezing SOA Suite and building anything new with OIC. If you’re going to replace the ERP. Then make sure your integrations that touch the ERP are decoupled from the rest of the logic. Then when legacy integrations need to be amended / updated look at replacing with OIC. When it comes to replacement we would recommend starting gently with simpler integrations. This gives you a gentler learning path and less risk until understanding OIC, defining your integration patterns. We would not recommend slavishly porting the SOA implementation models such as the use of the VETORO pattern that would drive having 5 or more different discrete BPEL processes for an integration unless they have clear value. Challenge any integration that tries to use SOA Suite as a tool for all jobs. Leveraging Function as a service and other OCI native solutions can yield simpler, easier and more efficient solutions without driving up costs.

You may wish to run the integrations in OIC through the execution agent until the ERP transition has happened. For integrations that are between two systems that are both on-premises, no need to bounce that data to the cloud and back without good reason.

Overtime integrations will run on OIC which will eventually replace SOA Suite, but not today.

Useful Links