Eloqua and Salesforce, sitting in a tree,
I-N-T-E-G-R-A-T-I-N-G
integrate
verb
/ˈɪn.tɪ.ɡreɪt/
- To mix with and join society or a group of people, often changing to suit their way of life, habits, and customs:
“He seems to find it difficult to integrate socially, but he managed to sync over the Opportunity data so he’s got that going for him…” - To combine two or more things in order to become more effective:
“You need to integrate exercise into your normal life. My morning routine involves three sets of list uploads and one dashboard refresh.”
Ah, Eloqua and Salesforce, the OG romance from Martech antiquity. Not since Antony and Cleopatra have we seen such a dynamic power couple where cosiness and healthy attachment are tertiary to market optics and total world domination. It is somewhat telling that – aside from giving lessons on Marketer pain points – the Oxford Dictionary distills the true nature of integration as that of ‘creating alliances’. Well, recently Oracle began a series of broad communications to its customer base (via Eloqua interstitials) that this alliance would see its first major realignment in 2021 with the ending of all support for what is typically referred to as ‘the SFDC Native Integration’. Specifically, Oracle is imploring its thousands of customers to make the switch to the new Salesforce Integration App to reap the benefits, features, and performance gains. No longer should this integration be transacted by Eloqua itself they say. No, now this integration would be initiated and managed by an intermediate app that would handle all communications between the two platforms.
So what’s the big deal? Isn’t this just a simple matter of ongoing platform modernization a la Program Canvas vs Program Builder? Yes and no. If the Oracle/Salesforce relationship status is anything to go by – it’s bound to be complicated.
First, let’s talk about the app itself or more precisely why it even exists. We shall save the gooey techy innards for another entry in this multi-part series. This is not some flaky third-party app you’ll dredge from the depths of the Oracle Cloud Marketplace, but a trusted first-party app written, hosted and maintained by Oracle itself – plump with all the juicy privilege that affords. This app is so crucial to the core business that Oracle spent several years carefully building and testing it under Controlled Availability with the understanding that if it was a flop, roughly two thirds of their customer base would begin to revolt. The App was a real thing even in 2015! During this gentler and more civilized time, this blogger personally experienced demos and candy visions from Product Management, while completing his tour of duty as a member of Eloqua Product Support. At the time, the intention to optimize and innovate appeared genuine, and the use of Oracle’s own (then relatively nascent) Unified AppCloud Framework seemed both logical and admirable. Oracle would eat its own dog food, and I could (eventually) stop complaining about the lack of quality API documentation. This would be an App that, in theory, anybody could write themselves but wouldn’t really have to.
However, beneath these discussions with the PM team was an undercurrent of frustration. ‘The old codebase is too complex, too sensitive and too poorly documented,’ they cried, while facing up to the reality that, with most of the original developers having departed, any improvements would be hard to implement at that point. This was in the context of a request from Oracle management that, for obvious commercial reasons, Oracle Sales Cloud (OSC) should have equal integration status to Salesforce, a request which would require the aforementioned, hard to implement, improvements. In the end this just wasn’t possible, and the ‘OSC Native Integration’ was finally killed off exactly one year ago in favor of an app-based approach.
It is in this context that we see the flip of reasoning: if OSC couldn’t be elevated to the plane upon which SFDC existed, SFDC would have to come down and join OSC in App Land. But the world looks very different in 2020 than it did five years ago, and Martech is no exception. While the MAP-CRM integration was once considered everything, it is now but a single thread in a web of technology being stitched together by a rich melange of ESB/ETL tools, point-to-point integrations, app-based integrations, agency integrations and hope-based manual integrations. The move to this App-centric approach makes perfect sense from a technology perspective if you selectively ignore the existence of these other systems, and only compare the app to what it is replacing.
Here at MarketOne, we’re big fans of unifying your data, insight, orchestration and activation layers across the entire stack, and generally becoming less sticky with any one vendor (whenever feasible), even if that vendor is serving your organization’s interests well in the present. The App-centric model is therefore one step in a tangential and meandering direction, although an admittedly convenient one. But what are the alternatives? For that I’ll point to the most telling bits, where Oracle’s own FAQ page makes it clear that this new integration does not leverage the Oracle Integration Cloud Service (ICS) which is an enhanced Enterprise Service Bus (ESB) of sorts. This means that your standard Service Based Architecture thinking does not apply, in the sense that all your MAP-CRM integration configurations and mappings are encapsulated within Eloqua itself and transacting data with only one other system. It’s true that SOA (Service-oriented Architecture) is expensive and it’s hard because you can’t avoid those no-fun-allowed IT Architects forever – looking at your Marketing. But there are fundamental limits to this approach of developing your Marketing or Sales system of choice into an integration transit nexus that ultimately serve as future barriers to any serious attempts at creating an Enterprise-grade tech stack.
It is here that we close out with some final thoughts. Reading about history is usually more fun than living through it, and having experienced war makes this author feel a bit more qualified to preach this perspective. History creates inertia and we are all living in the consequences of all past decisions made, whether we like it or not. If you’ve ever asked a room full of colleagues and experts “so why did we do it this way?” and were met with uncomfortable silence, you probably feel this one in your bones. Think of this new App as an opportunity to revisit the future of your entire tech stack, and not a revisit of Eloqua’s legacy cruft.
In future installments, we’ll be covering more detail on the technical and feature differences between the Native connector and the App itself. In addition, we will discuss what you can do now to prepare and minimize future risk to budgets and systems alike. Until then, do not panic – the two integrations will still be around for many years to come. Stay safe and stay frosty!
