Static is the New Dynamic.

What is enterprise ecommerce?

"Enterprise" can be a scary word when talking about software, as it is often associated with "expensive", "heavy", or even "old-style".

Well... this is definitely not what we mean.

Enterprise ecommerce means ecommerce that can support enterprise-grade requirements. Think of performance, market-specific business rules, and customer personalization — just to mention a few.

In this article, we are going to describe an architectural approach to build enterprise ecommerce, the Jamstack way. We will see how to leverage the best tools to support the most common workflows and use cases. It's an opinionated, yet adaptable stack orchestrated by Commerce Layer at its core.

Static ecommerce architecture

In our latest post, we already gave a high-level overview of a static ecommerce architecture, mentioning the most popular headless CMSs and static site generators. This one is a kind of zoom-in that reveals much more details and makes it more actionable.

So let's start with the big picture:

As you can see (hint: open the diagram in a new tab and keep it handy) besides Commerce Layer there are 7 tools involved (the blue circles) and 14 workflow steps (the yellow ones). We will start by listing the tools, giving some advice to help you choose the best ones for your needs. Then we will analyze all the workflows.

Tools

The Jamstack leverages custom-built or third-party APIs to bring dynamic features to the static sites. Call them (micro)services, serverless functions, or lambdas. Regardless of their name, this is what we need for enterprise ecommerce:

1. Headless CMS

We need a headless CMS to manage all content, including product and category pages. There are more than 50 headless CMSs to choose from. We recently got published on the Contentful blog, with a tutorial explaining how to build an ecommerce static site with Contentful, Jekyll, and Commerce Layer. Our friends at DatoCMS created a very useful plugin to link Commerce Layer SKUs to any content model in DatoCMS. They are also working on a new tutorial on how to build a static site ecommerce with Gatsby. More articles and tutorials with the best CMSs are coming soon as well, so stay tuned!

2. Static site generator

The choice of the static site generator depends on your favorite language, the available integrations or plugins, and the build performance. If your inventory is small, the build time is not a life-changer. Otherwise, it's a factor that should be taken into consideration. Think of an ecommerce catalog of 20.000 products in 5 languages. We are talking about 100K pages. If your SSG's build time is — let's say — 10 pages per second, you need almost 3 hours to rebuild the entire site. Which is not that funny.

All the SSGs are working hard to improve their performances, often introducing incremental build features. Today, I would say that if you need to manage large inventory, you should have a bias towards HUGO, which is the fastest static site generator to date. HUGO provides an incredible build rate of 1 page per millisecond. Doing the math, it's capable of building a 100K pages website in less than 2 minutes. Which is much funnier.

3. Multi-CDN

Static sites really shine when served over a CDN. There is no doubt that Netlify is playing a starring role in the entire ecosystem. The term "Jamstack" itself was coined by Mathias Biilmann Christensen, the CEO of Netlify. Their product definitely makes static sites more dynamic, by adding user identity management, HTML forms, and AWS lambdas with ease.

That said, enterprise ecommerce may need more than one CDN. A best practice is to choose the best CDN for each market and put a (geographical) load balancer in front of all your CDNs to further improve your site performances. Akamai, Cloudflare, or Amazon CloudFront are all great alternatives to consider. While some regions like South America, Japan or China may require local CDNs to boost your page speed even for the most remote of your customers.

4. Search tool

The catalog that you manage through the CMS represents just one view of your products, the one that is manually merchandised by the content editors. Even if the majority of headless CMSs provide some full-text search functionalities, they can't generally match a full-featured search engine. This is especially true when you want to provide your customers with personalized search, that is giving each customer different search results for the same keywords, based on their behavior or purchase history.

From our direct experience, we couldn't recommend Algolia more. They deliver personalized search and blazing fast shopper experiences, as a service. Some of the most popular alternatives include Amazon Cloud Search and Elasticsearch.

5. File storage

Images play a key role in ecommerce. Since customers can't touch your products as they do in the physical stores, images are your products and the better their quality-weight ratio, the higher your conversions. Considering all the different devices that your customers will use to shop your catalog, the number of image sizes and formats that you need to manage can become huge.

Your goal should be to store one master image for each product and create all the derivative images through a real-time image processing service. The file storage services that you can choose from include Amazon S3, Google Cloud Storage, Microsoft Azure Storage, or any publicly accessible web server.

6. Image server

As mentioned above, our architecture needs an image processing service to create all the derivative images from your master images. To fulfill that job, imgIX is the tool that we've used more in our own projects and the results have always been brilliant. Cloudinary is another option that you may consider. Some CDNs provide image processing functionalities as well, like Akamai Image Manager or Cloudflare Mirage Image Optimization.

7. Middleware

The last tool of our diagram is the middleware, a system that connects our architecture to other systems. For most use cases, Zapier will work great, as it lets you easily connect more than 1000 applications through their APIs. Commerce Layer ships with a Zapier app, so it's virtually integrated with all those applications, right out of the box. The support of Amazon Lambda functions in Zapier workflows further extends its possibilities. In case it's not enough for your legacy systems, you may want to evaluate some alternatives, like the solution provided by MuleSoft.

Our architecture omits any system behind the middleware, like the PIM (Product Information Management), the ERP (Enterprise Resource Planning), or the DAM (Digital Asset Management). Those tools are generally part of picture for the larger companies. We just prefer to keep them out of the scope of this article.

Workflows

Now that we have our shopping list, let's see how those tools fit together to manage all the required workflows.

• SKUs, prices, and stock are imported into Commerce Layer through the middleware. Prices can belong to many price lists and stock items can belong to many stock locations, feeding the business model of each market.
• SKUs are imported into the headless CMS. Content editors get the list of available SKUs and associate them to their content. You can find an example of the content model here.
• Content is imported into the SSG from the headless CMS. This can include any customer experience, like the "classic" product and category pages or any editorial content that can be made shoppable through Commerce Layer APIs.
• Prices are imported into the SSG from Commerce Layer. This is a best practice if your prices don't change that often, as it optimizes performances. If you need to build some sort of dynamic pricing, instead, you can decide to fetch them live via JavaScript.
• The SSG builds the site, ideally through a continuous delivery mechanism. The static pages are deployed to the CDN(s) for better customer proximity and faster load time.
• The site content is indexed in the search tool. The recommendation here is to create one index for each market/language combination.
• The JS code interacts with the search API, delivering full-text and faceted search. The static catalog becomes ultra-dynamic. Customers experience personalized journeys and become more likely to convert.
• The master images are stored in the file storage service. They must be accessible by the image server and must have the highest resolution that you want to deliver (e.g. zoom images).
• The image server processes the derivative images in real-time and caches them on the CDN(s). The association between products and images can be done through a shared naming convention on the file names, based on the SKU codes.
• The JS code populates the SKU availability messages through Commerce Layer APIs. In case you want out-of-stock SKUs to be removed from the site, you can create a webhook on Commerce Layer and trigger a new (incremental) build for each out-of-stock event.
• The JS code builds the checkout experience through Commerce Layer APIs. Since we are talking about enterprise ecommerce, this is probably the option that your clients will like more. In case you don't have strict requirements in terms of checkout branding, you can still use the hosted checkout provided by Commerce Layer — at least in a first phase — reducing your integration effort and boosting your clients time to market.
• The JS code builds the customer account area through Commerce Layer APIs. This includes the customer's order history, wallet (i.e. credit cards on file), address book, and returns management. Through the API you can also fetch real-time tracking updates of the parcels that are being delivered, providing customers with a much prettier interface than the one that is typically offered by the shipping carrier sites.
• Orders and customers are imported into the ERP, the CRM, or even a third-party OMS if the one that ships with Commerce Layer doesn't fit your client needs. As anticipated, the number and type of systems behind the middleware can vary widely and is intentionally left out of the scope of this post.
• Other events trigger marketing automation flows and real-time integrations. Likewise, the number of possibilities is endless and can change case by case. Some examples include the integration of an external party fraud detection tool, abandoned cart recovery, advanced reporting or business intelligence.

Conclusion

Each of the steps above would require a follow-up article. We will definitely publish a more detailed analysis of the most interesting topics in the future but we hope that this high-level overview can still be a helpful starting point. As usual, there are many edge cases to consider and we'd love to discuss any challenges that you may have encountered in your own experience.