Sunday, 3 May 2015

Typical e-commerce infrastructure

It's really easy to buy things online. Just choose what you want, click on it, go through the checkout process and after few days you get your items delivered to you. And all you do is to click few times on a website or tap few times on specific mobile application.

What happens behind the scenes is more complicated than you might think. Professional e-commerce solutions usually contain more than 10 different server systems, each doing something different. Here is a simplified view of a typical e-commerce infrastructure:


Simplified e-commerce infrastructure

We already covered the customer part. The customer deals only with the shop channel and nothing more. Through this channel the customer is usually redirected to specific page where he/she provides bank account or credit card details.

Shop channel - this is the most critical system of all, because this is where we do the actual interaction with our customers. This interaction is in the form of a website or mobile application. Nowadays the website is built with responsive design in mind, so there is no need for separate mobile website channel.

The shop channel is usually part of a bigger e-commerce system which allows you to manage the channels, configure the search/navigation features, feed the system with items to sell, etc. Most notable players in this field are:
  • hybris
  • Demandware
  • Intershop
Search & Navigation Engine - There are few problems that the e-commerce systems have to deal with. You can't have statically built category navigation because each time you do something different with the existing categories on business level, this will reflect all your channels. So, the category management has to be dynamic.

Another issue is the product data that the channels displays. If you build the display data management in the e-commerce system, then each business change will have futrher development impact. So, the product data management has to be dynamic as well.

How about the search functionality? Do you want to build facet search engine from scratch? I guess not.

All of this is handled by search & navigation engines. Most notable names in this are are:
  • Endeca
  • Fredhopper
  • Solr
Product Information Management System - in few words, once there is clear view of what items you want to sell (t-shirts, gloves, bottles, etc.), the PIM system is responsible to enrich the available data for these items by providing images, video, relevant descriptions, item attributes (size, colour, shape, etc.). Then the PIM system feeds the search/navigation engine with this information (probably indireclty, through the e-commerce system, depends on the architecture decision). And when the customer searches for "green gloves" through you website (remember that this is one of your e-commerce channels), the channel forwards the search request to the search engine, the engine provides the relevant data for this search to the channel, and the channel renders the information in appropriate way, providing the associated images, links to videos, text descriptions and so on.

PIM can be part of the e-commerce system and there might be no need for external system. Most notable names in the PIM world are:
  • Heiler/Informatica
Order Management System - The customer goes through the checkout process and from his/hers perspective that's all. However, from e-commerce perspective that's just the beginning. At this point the customer's order is stored in the channel's DB. Then the e-commerce system exports this order to the OMS. It's the OMS which is responsible to fulfil the order. Part of the usual OMS functionality is:
  • Forward the order details to the fulfilment provider and check if all items are available (they might not be).
  • Check that the customer's payment has been confirmed by the payment service provider.
  • Deal with inventory changes and notify all e-commerce channels about all inventory changes. The usual problem is when we have let's say 2 channels selling the same items. One item can be sold in one of the channels and at that time the inventory of the second channel thinks that the same item is still available for sale.
  • Deal with returned items and as consequence deal with the refund process.
  • Notify all other business systems (usually ERP systems, not on the diagram) about the orders, order status changes and other events.
  • Notify the e-commerce system about the most current order status, e.g. currently processing, sent to customer, received by customer, rejected by fulfilment provider, etc.
  • Deal with further order splitting (if we have multiple fulfilment providers) and forward the order details to the appropriate fulfilment providers.
The OMS is the actual engine which glues everything together. It's the business engine behind the scenes which connects all crucial business systems and drives the communication between these systems. It's the focal integration point when we consider further expansion of the e-commerce solution with new components or other external systems.

Fulfilment / Inventory Provider - Simply said, this is the "storage facility". This is where we get our information about the inventory quantities and this is where we send the order details for dispatching and actual fulfilment.

Payment Service Provider - This is the system which provides the payment capabilities for the e-commerce solution.

Well, that's it - a brief introduction in the e-commerce world and a very simplified view of the involved systems. In a real world situation it might happen that the e-commerce part of the whole solution is quite simple and most of the load is taken by the OMS. In other situations it might be the other way around - very complicated e-commerce solution and relatively simplified OMS. It all depends on the solution requirements, the architectural decisions, available infrastructure and many other factors. There is no single "silver bullet" solution.

No comments:

Post a Comment