The new year is upon us, and with it comes the traditional series of glossy articles about key technology trends to watch. A myriad of posts appear on LinkedIn, blogs, and in respected business publications, all spreading the corporate gospel, advocating the need to throw out the old and embrace the new. A new year, a new hype, as the dictum goes.
However, it’s good to remember one of the enduring adages in the otherwise rapidly-changing world of Customer Experience (CX): any technology is only as good as its ability to integrate with a wide variety of applications and solutions. The relentless quest for ever-more niche features has come to a timely end and made way for the compelling need for a fully-integrated suite. Savvy marketers the world over are no longer persuaded to tie the commercial knot with a vendor purely on the basis of how many proverbial bells and whistles they were able to fit into a single solution.
Moreover, given the proliferation of best-of-breed and suite solutions alike, with corporate buying strategies often resulting in a mix-and-match approach, it is fair to say that IT landscapes have grown ever more complex. Being able to effectively embed a brand-new solution into such an intricate environment therefore becomes more than just another project-level aspiration. With the rise of the Cloud, it has emerged, with an alarming sense of urgency, as organizations’ prima objective. The age of function-feature has come to an end. All hail the age of integrations.
This begs the all-important question: how do you define an integration to begin with carefully-drawn arrows, mystically connecting two boxes in an expensive-looking PowerPoint slide, more than often do not find their mirror image in reality. What makes a good integration then? Can flat file transfers to ship data from point A to point B really be considered for the coveted title? Or does it take a real-time API connection with a similar-looking interface on either side before we can ascribe the definition with a clear conscience?
Furthermore, in this era of ever-rising expectations, what makes for a well-developed integration according to the vendor, may not necessarily be shared as a conviction by customers, since not all integrations are created equal. Data may flow with ease between two components which complement each other perfectly, but the customer is left with the feeling that there is no integration in the truest sense. But this is not because two platforms are not able to seamlessly exchange the data they require. It occurs because more than one solution is involved in making it all happen.
This brings us to a crucial point. Over the years, Marketing Cloud suites, including the Oracle Marketing Cloud (OMC), have grown mostly through the acquisition of best-of-breed applications. Once brought into the fold, the daunting task of integration would commence: aligning data models and types, import and export definitions, interface designs, and so on. As time progresses, well-considered solution architecture blueprints are built and signed off on, controlled availability versions of the integration are released, and feedback is gathered. At times, it may take a few iterations to get things right. Nonetheless, throughout the process, best-practice design principles, such as e.g. separation of concerns, are adhered to so as to guarantee the integration is fit for purpose. After all, building an integration for the sake of integration does not serve any meaningful end and would be little more than a redundant exercise in design.
Let us take a simple example. Imagine a platform P is made up of three components: A, B, and C. If A is fully integrated with B, and B in turn with C, wouldn’t it make sense to also pursue a direct link between A and C? The answer can be argued in a number of ways, of course. If there is incremental merit in building a bridge between A and C, be this in the interest of improved functionality or a commercial proposition, then the answer should be yes. For example, not all users of the platform necessarily purchase all three components and would still appreciate the ability to connect the dots. Moreover, if the integration between A and C would be bi-directional, a closed loop could be constructed that may perform better or more quickly than through an intermediate connection with B. That being said, if little to no value can be derived from such an integration – or worse – the integrity of the respective components is detrimentally affected as a result, the answer can also be a plain and simple no. Build what is meaningful, not just what can be built. Your architecture shall be better for it.
The previous scenario is illustrative of a wider point: any solution architecture needs to be guided by a clear set of design principles. Or to put things differently, there is a right and a wrong way of setting up a Marketing Cloud or embedding a CX ecosystem. Overall, when designing an architecture, it pays off to take heed of the principles enumerated below. These principles have been derived from the SOLID framework for software engineering. For reference, please refer to inter alia H. Singh & S. Hassam (International Journal of Scientific & Engineering Research, 2015).
Key Design Principles for Best-Practice Marketing Cloud Architecture:
Separation of Concern (SOC): Applications should be divided into distinctive features, and each feature should have minimal overlapping wit other features.
Principle of Least Knowledge (POLK): Platform A can request a service of platform B, but A should not “reach through” platform B to access yet another platform, C, to request its services.
Don’t Repeat Yourself (DRY): Integrations are added to the architecture with the explicit objective of re-usability and future-proofing, in light of potential changes to the IT landscape.
When we apply these principles to one of the integrations in the Oracle Marketing Cloud, e.g. the integration between the marketing automation platform Eloqua, and the Oracle Data Management Platform (DMP), the following implications and rationales can be postulated:
SOC
The implication:
– Unknown segmentation in DMP
– Known contact segmentation in Eloqua
The rationale:
Set baseline expectations about platform functionality and intended workflow across them.
POLK
The implication:
– BlueKai agnostic to Eloqua data model
– Minimum viable datasets for integrations
The rationale:
Maintain respective platform integrity and avoid introduction of costly/redundant complexity in cross-platform data flows
DRY
The implication:
– CRM data feed consolidation
– Common ELT jobs for BlueKai and Eloqua
The rationale:
Commonly defined data model can be used to feed different applications given common use case intention
It should be clear from the above that there is merit in not considering the art of integration lightly. So as the landscape keeps evolving and new widgets, features and grand ideas surface with every sunrise in the year 2019, reflect on which arrows to draw. Aim to commit to sensible design, one which upholds the equilibrium between specific requirements and practical considerations. Strive to see past the technical mechanism underpinning an integration and value what such a connection can truly bring to the business you are part of. Finally, before you decide which integrations to add to your corporate new year’s resolutions, ensure that its viability and usefulness will endure for longer than just the first month of the year. In the eternal words of Oprah Winfrey: “Cheers to a new year and another chance for us to get it right!”
Find out more about Oracle Marketing Cloud’s best-in-class digital marketing solutions