Syndicated News

Dynamic or Static? A Data Integration Dilemma

We’ve been hearing a lot of debate recently about the best way to integrate content from a CMS system into a customer-facing eCommerce system – and vice versa.

Is it better to base your solution on a “dynamic” integration, where content is transferred in real-time from the source system to the head system at the exact moment it’s requested by the end user? Or is it smarter to start with a “static” integration, where all necessary content is pre-loaded from the source system to the head system on a regular schedule?

There are strong opinions on both sides of this issue. At CoreMedia, our preferred approach is usually the dynamic one, because we believe this contributes to greater ease-of-use and significantly reduced time-to-market. However, we also recognize that this isn’t a one-size-fits all solution. Sometimes a customer’s circumstances demand a different approach.

The purpose of this blog post is to explain how these two approaches differ and why a customer might choose one approach over the other. We’ll clear up some confusion, tackle a few pervasive myths, and suggest some guidelines for companies struggling over the best way to integrate their eCommerce system with their CMS.

CLARIFYING TERMS

First, let’s take a step back and discuss the words “static” and “dynamic.”

Although these terms are commonly used to describe the two different integration approaches outlined above, they are often used misleadingly.

In the context of eCommerce augmentation, the integration approach often gets confused with the type of content experience you can create with it. Let me explain what I mean.

There are basically two different ways to think about the consumption of online content based on how both “fresh” that content is and how often it gets updated:

Static content refers to an experience that never changes (or at least one that doesn’t change very often). This includes things such as company descriptions, footer pages, legal terms, FAQs, etc.
Dynamic content refers to an experience that changes frequently, such as breaking news, social offers, recommended product lists, etc. These changes can be triggered by a wide range of events including personalization rules, search queries, or even frequent manual updates.

But, when you’re talking about integration, these terms mean something very different:

Static integration means content gets pushed and stored into the “head”, which is responsible for presenting content the end user. And when you’re talking about a commerce-led scenario, the “head” refers to the eCommerce system and the CMS is not involved in processing end user requests.
Dynamic integration means the “head” pulls content from the CMS in real-time when it’s needed to process an end user request. The eCommerce system (the “head”) is not aware of the content itself and the CMS delivery system is required to fulfill all end user requests.

The confusion occurs when people assume that “dynamic” integration is always required to deliver dynamic content, and that a “static” integration is only suitable for delivering unchanging content. But this is decidedly not the case, as I’ll explain in the next section.

To avoid confusion, it makes more sense to use the word “Pull” to describe so-called dynamic integrations and “Push” to describe the static approach.

The following diagrams illustrate some simple architectures for achieving each of these two approaches (thanks to Joe Toppe for providing the inspiration for these images):

SIMPLE PUSH ARCHITECTURE:

SIMPLE PULL ARCHITECTURE:

Tackling MYTHS

Now that we’ve cleared up the terminology, I’d like to address some of the more common myths that can make it difficult to approach content and commerce integrations with an open mind.

Myth #1: Dynamic content experiences only work with a Pull approach.

Wrong: Most (if not all) dynamic experiences can be implemented with either approach.

It all comes down to how the solution is implemented. Some dynamic use cases are easier to implement using a Pull approach, while others are easier to implement using Push. (In fact, with enough time and money you can implement virtually any use case using a Push approach; however, there will be a major impact on usability, as a Push approach typically requires editors to access more than one system to publish content.)

Myth #2: Personalization only works with a Pull approach.

Wrong: It is absolutely possible to implement personalized experiences via a Push integration, especially if you’re only working with a limited number of user segments.

As with dynamic experiences, it all comes down to the implementation. In practice, most implementations rely on a Pull approach for personalization data since these experiences.

Myth #3: You can’t create dynamic shoppable videos with a Push approach.

Wrong: Many vendors are doing this today using a Push approach, albeit with a trade-off in ease-of-use and speed.

Myth #4: You cannot deliver dynamic prices or inventory-aware content with a Push approach.

Wrong: Using the Apache Velocity engine, you can deliver both dynamic pricing and inventory-dependent templates.

Myth #5: Pull is always better than Push.

That Depends: Here at CoreMedia, we have been able to help our customers achieve tremendous improvements in efficiency, ease-of-use, and time-to-market with a Push approach. However, we recognize that the right choice is different for every customer – it depends on the use cases, editorial workflows, and the specific eCommerce system you’re integrating with.

This next section describes some of these fact in more detail.

PRACTICAL CONSIDERATIONS

Given that you can deliver a lot of the same basic functionality using either integrations, how do you determine which approach is best for you?

We can’t cover all possible factors, but there are a few common ones to keep in mind.

Cost: At first glance it might seem these two approaches wouldn’t differ much from a cost perspective, as the same content is being delivered to the same people at essentially the same time. Upfront implementation costs shouldn’t be all that different either. This issue becomes important, however, when you have an eCommerce system that includes all infrastructure and traffic costs as part of the base fee. In those specific situations, any content delivered by a system other than the eCommerce system will definitely cost extra.
Security / Control: Some customers feel more comfortable with a single delivery system for all content. For example: What if the CMS system goes down and fails to deliver critical content at the right time? This is particularly worrisome when it comes to legal content. With CoreMedia, stability and security are not a problem, but it could be a factor with another CMS.
Ease-of-Use / Time-to-Market: With a Push model, content essentially needs to be published twice: once in the CMS and again to the eCommerce system. This mean editors have to learn two different tools and adapt to a more complicated editorial process. A Pull approach also means your content is not dependent on the eCommerce system’s staging process which, in many companies, happens only once a day. This adds additional time and increases risk of error.
Data Consistency: With a Push approach, content and the product catalog get staged in a single step, which often means less risk of misalignment between the two.However, most CMS systems have processes in place for correcting out-of-synch content.
Internal Politics: Sometimes the best business decisions get overruled for reasons that have nothing to do with technical requirements or business strategy. If your implementation partner or eCommerce vendor prefers one approach over another, you may not have a choice.

RECOMMENDATIONS

Ultimately, there’s no simple, single answer to the question driving this blog post. And this is why CoreMedia supports a flexible approach, not only by supporting multiple integration scenarios – including Commerce-led, Content-led, hybrid, and headless – but also by accommodating a variety of data integration patterns.

So we’ll leave you with the following recommendations:

Start by identifying your top priorities for the implementation: Is speed and ease-of-use most important? Is bandwidth cost a critical factor?
Focus on specific use cases, editorial process, and implementations.
Then, work closely with your software vendors and implementation partners to determine the most appropriate pattern for your needs and priorities.

[This post is based on an original idea by Karsten Reuter.]

View original content: Here