2. Communication service for other ecommerce services and software
This service can be described as a good old telephone switchboard. When some part of the platform needs to 'speak' with some other part, this service provides these parties with communication means. Considering we are dealing with a B2B open headless architecture platform, the 'callers' may be unfamiliar with each other, come from different vendors and speak different 'languages' (APIs). They must communicate seamlessly with each other.
Now, it is possible to connect services directly to some small ecommerce portals. It may even seem like a promising idea at the start of the digital transformation, as it is cheap and quick. For example: let's create a simple page with order statuses and see how it goes. Let's add a reorder button there, we do not need any expensive platform for it. However, this road brings problems later on, and these problems tend to snowball.
As the digital transformation proceeds, the number of services and tools used in the ecommerce solution grows, as does the number of communication channels between them. At some point we have 10 services that need to talk to each other, and each has its own unique API. We will have to teach each one to 'speak' nine different 'languages' for the system to work. If we decide to replace one of them, we will need to teach the new one nine 'languages' and re-educate the remaining ones. Considering these services may come from different parts of the system – some are ecommerce, some are a business ecosystem, some may be payment or logistics tools, some may even reside on the client's side - such re-education becomes extremely difficult and time-consuming.
Although it is sometimes appropriate to start with direct connections, such as evaluating the user adoption success, especially if there are reasonable doubts about it, this practice must end quickly, and an agile and progressing ecommerce platform should be deployed as early as possible.