Nico Kotsapanajotou
16. August 2021
5 min
After we recently reported on what to consider when setting up a B2C/D2C e-commerce architecture at enterprise level, today we want to take a closer look at what most e-commerce companies are failing.
We have selected ten core theses that we will examine in detail. Some of them, such as content commerce or big data, have been proclaimed again and again for years, but in practice they are often only implemented in a shoddy manner. So what are the top 10 areas where companies are struggling today when building e-commerce architectures?
Many companies block themselves in the implementation of e-commerce projects with an old-fashioned mindset. According to the old school of project management, far too much value is placed on timing and budget. Both factors thus set the framework conditions for a given quality.
This often leads to problems in the expectations on the management side. If you want to drive a Ferrari right away, but have the budget for a Dacia, don't be surprised if you get a small car that doesn't make an impression.
In addition, service providers are usually bound to fixed budgets and timings and do not provide any additional services, while they implement highly complex projects whose requirements are constantly changing according to the waterfall principle. This leads to an incredibly high project management overhead and never-ending discussions about change requests.
In a modern working world, there are several levers to solve this. On the one hand, the quality of a project should be defined in as much detail as possible, and only then should timing and budget be based on this. On the other hand, you should trust a partner who achieves the best result with as little overhead as possible within a flexible framework.
Many shy away from the risk involved, but at the end of the day, significantly more development hours flow into the quality of the product. It also helps if you are able to take over large parts of the project management yourself. Working and time-booking in shared Jira boards also helps in terms of transparency.
Anyone who still hosts e-commerce systems on premise is doing something wrong. On-premise systems are difficult to scale and, especially in the case of large growth, there is always a need to replace the systems. Also, the responsibility for failing system components such as broken hard disks always leads to statements such as "Yes, we will send someone to the data centre, I think it should be repaired in 1-2 days". You can no longer afford that in high-traffic online shops.
If you want to set yourself up for the future, you should host all systems in the cloud yourself - if you have the competence - or look specifically for SaaS and PaaS systems when selecting the components from the outset. SaaS if there are no developers and a low degree of customisation. PaaS if you have in-house developers or need to customise the systems very strongly.
Countless companies still use CSV exports and imports to transfer data between different systems. In some cases, gigabyte-sized files are transferred in nightly processes that last for hours and you always have to hope that they were successful.
If you want to be competitive today, you have to let systems communicate with each other via microservices and APIs. In the right overall architecture, microservices and APIs are independent of programming languages and can reliably exchange large amounts of data with each other via XML and JSON.
Admittedly, headless systems are still a relatively new component of e-commerce architectures, but an incredible number of companies are currently missing out on a future-oriented approach to the topic of the front end. In some cases, outdated technologies such as mobile dedicated pages are still used or responsive designs are not correctly displayed across all viewports.
If you want to master the topic of frontend in the future, you have to separate backend and frontend systems from each other. Decoupling is the first step so that changes in the backend, such as updates, no longer affect the frontend, but only the API has to be adapted. This makes it possible to individually design the presentation of all touchpoints and, in combination with an in-house IT team, to implement adjustments much faster.
The classic for content-rich sites are two different systems for content and commerce: CMS and shop system. In principle, this is not wrong, but even today these are strictly separated in the frontend of many companies. In the worst case, even on completely different URLs that open in a new browser window. Logins and shopping baskets cannot be used consistently across all touchpoints.
If you want to be future-proof, you should seamlessly marry CMS and shop system in a decoupled frontend within the framework of a MACH architecture. This is not an easy undertaking at first, but it offers the end customer a much more attractive shopping experience. MACH in this context means: Microservices - APIs - Cloud - Headless.
Data quality is one of the biggest problems for e-commerce companies. Often, data from different systems is never merged correctly and is not archived properly. In addition, many data records are incomplete or not comparable.
In order to have the topic of data under control in the long term, all important data must be identified and stored in a data warehouse (usually an SQL database) via APIs. With a business intelligence tool, the data can then be compared and merged into reports.
Often, the operational business is not recognised as a growth driver and is seen as an annoying appendage for the online business. Usually a minimum of customer service, too few payment methods and only one shipping option are offered.
If you have your operational business under control, you can create decent growth from that alone. High-quality, accessible and fast-responding customer service, as well as the connection of all relevant payment methods via a PSP and the offer of several shipping service providers and shipping options (e.g. express delivery) are the key to customers, especially in new markets.
Unfortunately, the topic of internationalisation is too often viewed only from a strategic perspective. As a yes or no decision. But the quality of any internationalisation lies in the details. Technical implications in particular are often underestimated.
Multilingualism is often underestimated. If you want to successfully open up a new market, you have to display the webshop in the local language and offer the local currency. This often turns out to be too big of a challenge, also in connection with the common taxes in the country. The interaction between ERP and shop often becomes a bottleneck. When selecting systems, care must be taken from the outset to ensure that they are suitable for an international presence.
It is unbelievable how many companies with monolithic systems are dependent on one service provider or one technology and have almost no way out. Often, the complexity of the centralised systems has reached such a high level that a project to break this dependency seems almost impossible.
If you want to be successful in the long term, you have to make systems interchangeable. A composable commerce approach in which best-of-breed components are connected with each other helps to exchange individual building blocks without major effects. As far as service providers are concerned, you should look carefully at who offers you exactly this perspective and not try to earn money through licences or other dependencies.
In-house IT is without question the supreme discipline of e-commerce. Once you have started without your own IT, it will be difficult for you to get your act together. Nevertheless, this topic is becoming increasingly important. Service providers are often too far away from the action or not agile enough to implement even the smallest changes in the shortest time.
If you want to join the ranks of the big players in the long term, you undoubtedly need your own developers. This is not only significantly cheaper (potential savings of up to 75%), but also brings an enormous boost in the quality of implementation due to the short lines of communication and avoids large project management overheads.
