Adobe recently announced their new Commerce Integration Framework(CIF), designed to deliver experience driven commerce solutions. Implementing a commerce experience with the Adobe Marketing Cloud is a powerful way to enable marketers to influence customers and drive engagement. However, integrating commerce with Adobe Experience Manager (AEM) does not always give the marketing team the best of both platforms. 

Adobe Marketing Cloud

A quick breakdown of each system can help us understand what each does well. AEM is a content and digital asset management system (CMS and DAM) built to enable marketers to create digital experiences. On the other hand, a commerce system such as CIF is a transactional system that has four main components: catalogs, carts/orders, checkout processing, and product management (pricing and inventory). Inherently CMS's are based on static delivery, while commerce systems are dynamic in nature. 

These are two fundamentally different systems, and integrating them creates unique challenges, including trying to leverage what each system does best without losing common functionality. For example, each system has commonly used features such as previewing content or data before sending a marketing message or an invoice to a customer. The assumption is often that because both systems have a preview feature, system integration will obviously result in a new system that has the ability to preview. Unfortunately, that is not the case in all implementations. Adding a feature to a platform that does not have that feature is easier than getting two independent features to work as one. Creating requirements or reviewing a system design for a content-plus-commerce implementation requires an understanding of how both systems’ out-of-the-box features will work together.

Another challenge associated with integrating AEM and CIF is in maintaining Adobe's best-in-class authoring for commerce components. While quality control to this high standard requires that the commerce system be the owner of all the data, integration requires extending or injecting data into a data set controlled by an outside system. In version 1 of Adobe's CIF, this was mitigated by ingesting all the product data into AEM. However, product synchronization often causes additional challenges for large or multi-lingual data sets. An unfriendly author experience, or needing to utilize multiple system to execute a task, typically results in lower adoption rates and a need for additional user training for the new system.

Finally, performance is often the number one priority of a commerce implementation, and adding a CMS, which likes static content, to a commerce system that is constantly processing data, amplifies the need for a solid architectural approach. Even with a careful strategy, performance in a system typically degrades over time as the number of products increase, personalization becomes more sophisticated, the customer base increases, and the system is utilized more overall. 

There are three common approaches to Adobe with a commerce system.   


Headless Commerce

A typical approach with CIF v1, a headless commerce scenario involves AEM owning the experience, with commerce as the backend system. The implementation pattern involves AEM getting feeds or making real-time calls to the commerce APIs, to present data to the customer. The commerce system does not have to be headless to act as a headless system. Most enterprise commerce systems have a robust API layer to interact with third-party solutions. 

Pros:
  • Marketers interact with a single system to create experiences.
  • Each system has a well defined role within the solution. 
  • Customers get a seamless experience throughout their journey.

Cons:
  • Commerce functionality must be recreated in AEM.
  • Implementation is often time consuming.
  • Infrastructure can be a concern.
  • Commerce author ability is low, reducing account, cart, and checkout options.
  • Performance suffers as AEM is forced to act like a dynamic system.

 

Headless CMS and Commerce

When both applications are headless, a single-page app, CDN SSI, or some other "glue" that puts all the pieces together is needed. In this type of implementation, a marketer creates pieces of a page or pages with commerce slots. When the page is pushed to a customer, a third application marries that content with the appropriate commerce data to complete the experience. This has been the most common trend in recent implementations, and is enabled well in CIF v2.

Pros:
  • Each system does what it does best.
  • There is no real integration between the systems.
  • Speed to market is typically quicker.

Cons:
  • Preview functionality is hampered: within AEM, marketers see only static content.
  • Issues can be difficult to track when content or data appears in incorrect places.
  • Marketers have to manage content in two systems to create a complete page.
  • This implementation requires twice the training, which can hinder adoption of the platform.
  • Feature utilization and upgradability can present challenges.
  • Because headless solutions translate everything into data, content-rich features can be less effective.
  • Upgrades become less effective when features are not utilized as data.

Adobe I/O could change the game here. We are looking forward to learning more on this at Summit!


Split Ownership

In a split ownership, each application serves pages and the routing is done at the web server level. AEM serves content- and marketing-focused pages. and the commerce system serves transactional pages. This approach is enhanced by the CIF v2 implementation, which standardized the output of the commerce system and integrated it with the Marketing Cloud.

Pros:
  • Each system does what it does best with its out-of-the-box features being utilized.
  • AEM creates cacheable experiences with commerce data included.
  • The commerce system utilizes transactional pages.
  • The Adobe authoring experience is leveraged with preview.
  • Marketers use a single system.

Cons:
  • System integration can get complicated.
  • Without a proven framework, integration is definitely time consuming.
  • Upgradability can be in question.
  • Integrations absolutely increase the cost of an upgrade in cases where APIs change.

 

Want to learn more about how SMITH and Adobe can help you reach your goals in ecommerce? Click the button below.

SMITH + Adobe

 

Tags: Commerce, ecommerce, Experience Design, Technology, Adobe, Adobe Commerce, Commerce Integration Framework, AEM, Adobe Marketing Cloud, Headless CMS