Your options for “owning the glass” in an online eCommerce site

Online retail sites are changing drastically. I have observed many sites moving to a cinematic or experiential experience with their online eCommerce sites. So what does “owning the glass” even mean? Owning the glass means the piece of technology is responsible for defining the experience and then serving up the experience. In general, there are usually two to three servers in play here:

  • Commerce Server (CS) – provides layouts, pages, navigation, catalog, search, shopping cart, promotions, pricing
  • Content Management Server(CMS) – provides content, pages, articles, layouts, navigation
  • Digital Asset Manager(DAM) – provides images, videos, text, for all channels.

Now don’t get me wrong, many Commerce Systems today tout themselves as a CMS also but as you will see, depending on the platforms you are dealing with the lines are blurred with regards to navigation, pages, and layout. This means you have to make a choice if you have a CS and a CMS in play. Historically the CMS has better editing capabilities for things like content, pages, layout, and navigation but many commerce server’s are getting very close to things like inline editing, layout creation, and page creation – blurring the lines even further.

In general, there are four approaches for who “owns the glass”:

  • Commerce Server owns the glass
  • Content Management Server owns the glass
  • Side-by-Side shared experience
  • Custom front end

Each one has its benefits and drawbacks. Let’s drill down on each one to see the pros and cons of each kind of implementation.

Commerce Server owns the glass

In this scenario the commerce server will serve up the navigation, footer, pages, and layout of each page. There are some things to consider when you choose this option and it really depends on the tooling provided with your eCommerce server whether or not this is a good option for you. Some key questions you need to ask about the eCommerce tooling:

  • Does your tooling support workflow approval?
  • Does your tooling support site preview within a date range? (this is important because most content or campaigns are scheduled to go live in the future)
  • Does your tooling support creating pages, layouts, etc and is flexible to connect to a CMS and/or DAM?
  • Does your tooling have inline editing of pages and content, ie. WYSIWYG.
  • Does your tooling allow for A/B testing of content or content displayed for specific customer segments or content displayed by customer interaction?
  • Does your tooling allow for third-party content providers? This could be through a widget framework or tooling extensions.
  • Does your tooling have role based management for the different operations of your site? Catalog, Pricing, Geographical site restrictions, Brand site restrictions. You may need to control what people can do what in the tooling to prevent problems.
  • Does your Commerce Server have the ability to have federated search with content and product search results?

If you answer yes to these questions then you should be fine with this scenario. So how would this actually look? Here is a simple diagram showing this scenario when all three types of systems are in play:

Commerce owns the glassPros:

  • Marketing and product people work in the same tool
  • A single tool for essentially the entire site look and feel with the exception of complex content from the CMS – which is usually done by the creative team.
  • Most commerce servers come with mobile or responsive design options built on the same code base.
  • A central point of failure for the site experience
  • Commerce servers usually are architected for multiple languages, currency etc. You may not get this type of architectural option when a CMS owns the glass.
  • Single source code for headers, footers, or page areas

Cons:

  • “Showbrowsing” could be costly, in other words, if they are not buying stuff on your site and only browsing or reading articles this may increase your server capacity.
  • You really need to answer “Yes” to all of those questions for this to be practical

Content Management Server owns the glass

This option is very attractive if you already have a content management system in place and your site is very content heavy with a dash of shopping experience sprinkled throughout. The real key here is making sure your commerce server is equipped with a really good services oriented architecture (SOAP, REST, etc). If your commerce server has all the essential API’s for integration then this may be a very attractive option. Since most CMS’s have the common basics of pages, layouts, navigation, etc the questions here are a little different:

  • Does your commerce server have all the API’s to run in a headless state?
  • Does your CMS and CS support single sign-on?
  • Does your CMS tooling have the ability to connect into the commerce server for products, catalog, pricing, and promotions?
  • Does your CMS tooling use or connect with the segmentation capabilities of your commerce server?
  • Does your CMS tooling allow for third-party content or widgets?
  • Does your CMS have the ability to have federated search with content and product search results?

If you answer yes to these questions then you should be fine in the scenario. So how would this actually look? It is actually very similar to the first option. This assumes product images and content could also come from the DAM. Here is a simple diagram showing this scenario when all three types of systems are in play:

CMS owns the glass

Pros:

  • Content rich sites have a single delivery platform for pages, header, footer, layouts
  • Load is taken away from your commerce server and is primarily on the CMS
  • Consistent tooling for content delivery
  • A central point of failure for the site experience
  • Usually excellent inline editing of pages
  • Single source code for headers, footers, or page areas

Cons:

  • Product, Promotions, Marketing, and Catalog management has separate tooling
  • You may have to duplicate connector code for other channels into the commerce engine (mobile, tablet, call center, etc)
  • You really need to answer “Yes” to all of those questions for this to be practical

Side-by-side shared experience

This option is attractive if you wish to have separation of duties between the two systems. It provides for the best of both worlds and addresses the “showbrowsing” problem many sites experience. However it comes with a few drawbacks you need to be aware of. Some questions to consider when thinking about this platform:

  • Is your team structure separated into different groups? ie. An eCommerce team, a marketing team, a product team, a content team
  • Does your company have a governing experience team that defines standards and the overall look and fell of your brand with authority?
  • Does the commerce platform and content platform have the ability to have a merged approval flow or business process?
  • Is the commerce and content systems services based to have optimal re-use of assets – content, header, footer, etc
  • Do you have a centralized development team? Because there will be shared components in this model (header, footer, navigation) you will need to address this.
  • Do you adhere to a DevOps model where the risk of testing and delivery of complex solutions is addressed?

If you can successfully answer those questions with favorable answers then this option may be practical for you. This option is complex and is only recommended for large companies that have teams that have very different focus or other branded sites that may or may not have shopping capabilities. I am seeing this architecture when things like social communities, forums, forms, and other informational type sites are a primary focus of the brand.

Side-by-side implementation

Pros:

  • Separation of duty for teams is clearly defined – the commerce team administers the buying experience, the content people administer the content experience, creative puts the digital assets in the DAM for all to use.
  • The load on the servers is split

Cons:

  • Duplicate publishing, code, assets, language text
  • Shared or copied code between the experiences
  • Deployment and development synchronization may be challenging if a clear DevOps process is not in place

Custom Front-End

This is pretty much an open field and there are two key aspects to this approach that need to be considered before going down this path. One, is you should probably have your own development team and good development practices in place before even considering it. Having a great business partner could really help out with this one. Many of the template sites you get from an eCommerce vendor or a CMS vendor were created with extensibility in mind and they are usually done with the best developers. Second, your CMS and Commerce Server need to be completely services based (SOAP, REST, etc) and the API’s need to be solid. However, with all of the new cloud based development platforms around this option might look very appealing for the different channels – web, mobile, call center, store associate, etc. There are so many questions that need to asked for this one I am not going to list them all, but here are a few:

  • Do you have a professional development team or business partner that can write solid extensible code that can adapt to change?
  • Does the custom solution have tooling to quickly assembly pages, layouts, navigation, search, etc?
  • Are your commerce and CMS systems 100% SOA?
  • Do you already do similar types of front ends now?

Custom front end

Pros:

  • You own the code, you can do as you want and you are also responsible for it.
  • Could potentially distribute workload evenly across commerce centric pages and content specific pages.
  • A single source for the channel, no duplicate code for headers, footers, etc.
  • New technology, maybe the other systems are coded in a language not in your companies wheel house – maybe you have standardized on PHP, Ruby, or NodeJs and the other servers are something else.

Cons:

  • You own the code, you can do as you want and you are also responsible for it.
  • You will have to keep in-house talent or pay a business partner to not only fix bugs but stay up with the latest trends and code interface in a flexible way.
  • It adds another layer to the stack – this may be good or bad but anytime you add layers it’s usually not a great sign.

Well that sums it up. I am really interested to hear if you have had to make a choice like this in the past year or so and what your experiences have been. What kinds of questions would you ask?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s