Nico Kotsapanajotou
21. Juli 2021
24 min
The selection of a new B2C or D2C e-commerce architecture in the year 2023 often represents an enormous challenge for large and strongly grown companies. Most of the time, the topic of a "new online shop" is unconsciously talked down.
Choosing a new shop system is usually much more than that. Enterprise-level digital commerce requires seamless integration into existing processes and systems. Therefore, the whole issue should rather be seen as an e-commerce architecture. This article gives you an overview of the most important questions to master the topic. Here is a brief overview in advance:
A multitude of strategic aspects can have an extreme influence on an e-commerce project. Often, ideas from the management level are not sufficiently challenged, so that quality is often compromised in advance with too tight timings or too low cost expectations.
The condition for success with one's own shop is a business model that can be reasonably transferred to online trade. Anyone who thinks today that they can put the 500th online electrical shop on the winning track with a few Google ads should rethink their idea.
The product range is an excellent lever to differentiate oneself. If you want to sell the same items as everyone else, you definitely need other strong USPs such as price, delivery speed or availability when everyone else is out of stock. Own brands and D2C concepts are more suitable. Selling your own products directly to end customers without intermediaries is a great way to enter the e-commerce world. The lack of comparability of own brands ensures that you get your own entries / visibility on all platforms (Google, Amazon) and are not the 25th online shop with the same article, which then only makes it about the price.
Maybe you can also occupy a niche or open up a still unsaturated market with an innovative business model. Examples from the past are re-commerce, i.e. the buying and reselling of used items, such as Momox (turnover 2020 ~ 312 million), which trades in a variety of used goods. Or shops that deal with only one specific item but have developed this field better than all the others. An example of this is Emma, where there are only a few mattresses, but they have managed to perfect their business and achieve annual sales of over EUR 400 million.
Another big trend is marketplaces. Almost all the big players are currently working on marketplace concepts, as the reach via their own product range is limited. Zalando, Douglas and Conrad (among others) have opened up to external providers. Another fact in this context is that the pure brokering of sales is usually more worthwhile financially due to the elimination of overheads (no service, no logistics). Analysts rate Amazon's marketplace business five times higher in their balance sheet than their FBA or retail divisions. However, the implementation is a major technological challenge.
It is also possible to convert customer groups that have already been tapped into a business model. If you have a large network, e.g. in social media, even before you start, you can give your business a weighty boost. Numerous examples from the world of influencers show that it is also possible to build up a customer base first and then a business (Kylie Jenner, Pamela Reif). That you can sell anything with good marketing these days might be a bit of an exaggeration, but it shows that customers can sometimes be very strongly influenced.
In short, the chances are slim for average business ideas with few USPs. Anyone who wants to jump on the bandwagon today needs attractive products, clearly communicated customer benefits, outstanding marketing or a unique idea.
One of the biggest mistakes you can make in advance is to put yourself under pressure with a deadline without knowing the scale of your project. In the end, you will never have the freedom to make meaningful decisions, but always subordinate them to a time perspective. This is how the quality of any e-commerce project suffers.
Better: First evaluate your options on all project levels, compare all factors and only then see which growth path involves which project duration. Then convince decision-makers with sound arguments why it makes sense not to synchronise the go-live with the next best marketing campaign, but that the healthiest growth path requires a more flexible timing.
Running your own IT department - and we are not talking about the hardware helpdesk here - is a huge challenge. Anyone who wants to become more independent of service providers in the long term and ultimately develop their own software solutions inevitably faces the question: "Can I even do that? Does it even fit my company?"
A prime example for the topic of in-house IT is certainly Zalando (turnover 2020 ~ 8 billion EUR). The Berlin-based company is now much more than a fashion house, because with more than 2,300 developers it describes itself as a technology group. And Aboutyou (turnover 20/21 ~ 1.17 billion EUR) with several hundred developers also impressively proves how important technology ownership has become in 2021.
Nevertheless, there are numerous factors that make the insourcing of IT and development services possible in the first place. One of these is certainly the location. An attractive location for long-term life planning as well as proximity to universities and other technology businesses that train qualified personnel play a major role. The best locations in Germany for this are Berlin, Munich and Hamburg. If you are located in a rural area, you should consider opening an office in one of these three cities.
In addition, there is the extreme scarcity of development resources. It is not without reason that there is a strong tendency for large companies and agencies to operate many development services abroad (Ukraine, Russia, India, China) or to buy them in from there. The insourcing of IT services is always a major HR project that is best started IMMEDIATELY. Here you also have to ask yourself honestly: "Is my company even hip enough to keep ambitious developers for the long term?" or "Do I even have access to such resources?"
The role of the CTO or software architect is a very crucial one in an ambitious e-commerce project. Ideally, this person is on board from the very beginning and, in the case of a hybrid model (in-house lead, external implementation), already plans the successive insourcing of all development activities as well as software components. The quality of the IT in-house stands and falls with this role, so this person should be able to demonstrate a similarly ambitious project in one of the previous stations.
Long story short: Those who do not yet have their own development department should carefully consider whether they are in a position to build one up and keep it alive in the long term.
The counterpart of the own IT department are external service providers. Those who become too dependent will be milked like a cow in the long run. External service providers can play an incredibly important role when it comes to speed or know-how transfer. However, if individual software providers or agencies cover too large parts of the company, it becomes increasingly unlikely that the company will leave and the quality of the service providers decreases because there is no longer any pressure to work well.
Therefore, when planning the areas of the company that may be created and covered by external service providers, care should be taken not to enter into too many interdependencies. A current trend in technology supports this approach enormously: MACH architectures. Microservices, APIs, cloud systems and headless systems make it possible to combine different system components with minimal dependency within the framework of a best-of-breed concept and thus keep them interchangeable in the long term. More on this in the section Technological Implications.
The rule for choosing a service provider: as much dependency as necessary, as little as possible.
The favourite buzzwords of every salesperson: growth & scalability. But what does that mean in relation to your e-commerce project? Will a new system necessarily bring more sales because I work on page speed and usability and thus increase the conversion rate? Unless you currently have huge pain points in these areas, the answer is simple: no!
Your growth levers lie in opening up new markets (internationalisation) and target groups (marketing), offering suitable payment and delivery methods (depending on the region), expanding your offer with services within the value chain (differentiation from the competition), in greater visibility (SEO), a more extensive assortment (more and different products) and, last but not least, a faster, nicer and better usable webshop.
All these areas can be improved through technological progress, but be aware that there must also be a clear growth strategy behind it. Simply replacing the online shop is no guarantee for growth.
In addition, you should also break down your growth targets to the individual business areas and see what this means in detail. The statement "we want to increase our turnover by 50% in two years" is too short-sighted. All areas must be able to withstand this growth. What does growth mean for your company? More orders? More returns? More page views? More customer enquiries? More staff? Is your business really scalable in the long term in all areas?
Another big mistake is to pull a budget out of a hat like a magician. Of course, there is a limit to what you can invest in. But if your business is flourishing, it is even more important to invest in technology so that you can concentrate on the essential things and don't start all over again with a project in two years.
Therefore, as with timing, you should first evaluate the options and decide on the best growth path in terms of costs. If you set a budget beforehand, without any justification, you end up limiting the quality of the final product.
The biggest cost points in an ambitious project are usually the implementation and operation of the new platform. When it comes to project costs, you should make sure that you either assign a cost framework to a precisely defined service in advance with a contract or that you find a provider with whom you can make fast progress in the project in a very agile manner. Both ways are legitimate, while the former describes the rather classic way, more and more companies are daring to first create a proof-of-concept or an MVP (minimum-viable-product) within the framework of rapid prototyping. This has great advantages due to the elimination of planning and project management overheads. Especially with very ambitious projects, one should find a healthy balance between planning and agility.
When it comes to operating costs, you should distinguish between fixed costs (e.g. fixed licence amounts) and variable costs (e.g. turnover-dependent costs or traffic-dependent hosting). At the end of the day, you should be able to quantify all future costs for each solution based on your sales expectations and compare them with each other, preferably in a 5-year plan. Especially the development over time often justifies higher project costs in favour of a lower TOC (Total Cost of Ownership).
An important factor that is often forgotten when comparing solutions are the opportunity costs. For example: you are stuck with an outdated solution and have big costs for maintenance and updates every year that don't get you anywhere. Compared to a newer solution without these pain points, these are real costs. Because the resources (money or staff) that are freed up can be used profitably again.
Setting up a new e-commerce architecture is definitely not a pure management decision. Those who believe that only strategic factors influence the selection of new solutions are simply wrong. You have to understand that if you want to be technologically scalable in the long term, you also have to deal with technical issues very strongly. If you only rely on the green light from the "IT guys" for the decision, you haven't done your homework.
First of all, you should think about the general architecture. To do this, it is advisable to first list all existing systems and, ideally, to put them in a diagram (system architecture).
A general endeavour at the beginning of the 2000s was to get as many functions as possible "from one source", both on the solution and service provider side. Such monolithic systems were very powerful and left staff to focus on a few processes, programming languages, contact persons. It was simple, but not thought through to the end.
For some years now, it has become more and more apparent that the manufacturers of the big battleships can no longer keep up with smaller, more agile systems that are constantly reinventing themselves, but that customers also need much greater flexibility in order to survive in the market. For this reason, the trend is to connect individual specialised systems with each other via APIs and microservices and, if necessary, to exchange them again without much effort. Whereas in the past, when an ERP or CRM was replaced, the entire architecture was called into question and a huge project was on the horizon, today a single module can be conveniently triggered and replaced.
This approach is called Composable Commerce or MACH architecture. MACH stands for Microservices, APIs, Cloud and Headless. With this approach, individual specialised systems ("best-of-breed") are put together to form a long-term scalable architecture. You can find out which enterprise solutions are suitable for such an approach in the solution provider section.
A modern interface architecture is essential for scalable growth. There are various protocols for different purposes. The two best known are certainly SOAP and REST. While SOAP represents a more classical approach (more security, clearly defined rules), REST represents a more modern style with more freedom. Not least because of the lower bandwidth required, more and more large companies are deciding to build interfaces with REST.
In addition to heavyweight large interfaces, more and more small microservices that only serve a specific purpose are becoming established. For example, the exchange of inventory can often be outsourced to a small microservice, which then communicates inventory changes between ERP and shop in real time.
For a better understanding of your plans, you should therefore not only transfer the systems, but also their connections into a diagram. At the end of your evaluation, not only the current system landscape but also the future architecture should be visualised in a diagram. You can find more on the topic of evaluation here.
The trend in 2021 is increasingly towards a headless architecture. Headless describes systems that manage without frontends or in which the backend and frontend are detached from each other. The advantage of this is that the further development of both areas can take place independently and that I am able to design my frontend individually for all devices. The term "headless frontends" is often used. However, this is incorrect; in this context, "backendless frontend" would be appropriate.
Thus, a "shop system" in 2021 is no longer necessarily a system that comes with a frontend by default. Therefore, not only are frontend developers in demand as never before, but there are also a variety of ways to design frontends. In principle, there are four ways:
1) Oldschool: My shop system already comes with its own frontend. The advantage is clearly time-to-market and low complexity. The disadvantage is definitely that my frontend is dependent on the provider and the further development of the backend. In the long term, this leads to strong interdependencies, large update efforts and low scalability.
2) Hybrid: More and more often you see systems that already load content into another system via an API, but then use the frontend engine of another system to display it. This is often done for content-rich projects, so that the CMS system "presents" the commerce part as well. This is quite feasible, especially if the editorial part is very important for my business. However, this is also only scalable to a limited extent.
3) Frontend frameworks: The absolute trend is so-called frontend frameworks, with which system-independent frontends can be built. These usually come with a large set of functionalities. The pioneers here are Vue-Storefront and Frontastic, both of which also provide the necessary hosting competence (cloud) for the frontend. If you also find a good service provider who has worked with these systems before, you can start at a much higher level than if you start from scratch.
4) The supreme discipline: As is so often the case, the supreme discipline is setting up your own frontend with the help of the Java-Script programming languages Angular, React or Vue. However, this step requires a very experienced software architect and is certainly the most complex, because you not only have to start on a greenfield site, but also take care of the hosting yourself (preferably in the cloud).
Another advantage of modern MACH architectures is their independence from programming languages. Of course, individual system components such as ERP, CRM, etc. usually have fixed programming languages, but the writing of individual customised services can be done in a variety of languages. Thus, one is no longer dependent on finding specific developers with an exact orientation. For example, you can build your own frontend either with React, Angular or Vue. All paths lead to the goal here if they are well executed.
Nevertheless, the programming languages used are an elementary part of the search for staff. It is best to derive the tech stack, including all programming languages used, from the future target architecture and generate the profiles of software architects and developers from this. Under certain circumstances, it may be worthwhile to change a building block in the architecture again.
For decades, the only option for hosting was a so-called on-premise solution. So to speak, renting a computer that was located somewhere in a data centre and made my data available via the internet. If a hard disk failed, someone had to go there and change it. If you had strong growth, you had to buy or rent a new setup every year and live with the performance problems until then.
Those days are gone for good. With the big cloud providers from Amazon, Google and Microsoft, almost any system can be hosted in the cloud and ramped up and down depending on the workload. For this purpose, modern software solutions usually already bring their own hosting with them. These systems are called SaaS (software-as-a-service) and PaaS (platform-as-a-service). With both, you are no longer responsible for hosting. With SaaS, the platform is also further developed by the provider; with PaaS solutions, the further development is done either by myself or by a service provider. The latter is better suited for highly individualised projects with an in-house IT team. If you have a simple business model and no IT capacities of your own, a SaaS model may be more suitable.
A note on security: Recently, one hears again and again that hackers penetrate systems and demand a ransom. Now you should ask yourself how often was the hosting in one of these cases in one of the big clouds? See ...
Especially with very individual business processes, the adaptability of software solutions can play a major role. This is an essential point when selecting future systems. The type of software is also definitely important! After all, a SaaS solution that is always developed in the same way for all customers may not give me the freedom to map my processes. The topic of IT inhousing also plays an important role here. Because if I use a SaaS solution, but I can't change anything in the backend, then I don't need inhouse IT.
For this reason, all individualised processes should be identified and evaluated with the solution provider before the start of the project. The solutions found should appear logical and ideally be validated in a proof-of-concept.
The issue of updateability is a very troublesome topic in many companies. If you have ever been caught with the sentence "We always develop independently of the core", but have been stuck with the same version for years, then you know what I am talking about.
Developing independently of the core in the long term is almost like a perpetuum mobile, because that would mean that you have already done everything right by setting up the software solution. The core contains no bugs, future demands on the software or the market do not require any adaptation of the core. Bullshit. This can only be guaranteed if everything remains as it is, but then there is no progress.
Of course, there are basics that can be observed so that further developments interfere as little as possible with the existing processes of running systems. No question about that. But there is no guarantee that a provider will not have to redo everything after a few years. But that doesn't have to be a disadvantage. After all, you want to benefit from the further development of the software yourself, especially in the SaaS model.
Therefore, it is best to see for yourself how many updates there have been for the respective system in the past. How many minor and major version jumps have occurred? How many security updates have there been? And by all means compare it with your own agility. Can I react quickly to updates? Am I prepared to go along with the updates, even if at first only costs are incurred? It is often a huge mistake to judge updates from a management point of view. "What will the update bring us? - "Well, no features for the time being." - "Then we can skip it." - This is the beginning of the end in terms of updateability.
For many years, little effort was made around the issue of security. I still remember the times when "hackers" could execute code on the server via code injection into the search of a website, and thus cause great damage. Even today, many smaller companies are not aware of how vulnerable they are. More and more hacker attacks on companies and government agencies show how easy it is to hack into many systems.
You have to ask yourself, how can I compete with such experts in the field of security if I host my online shop at the data centre around the corner or, even better, directly from my company? With cloud solutions, on the other hand, you have the biggest experts on your side. What Amazon, Google and Microsoft can't do, I'll never be able to do myself. So: Off to the cloud!
If you want to be digitally successful in the long term, you should have your data under control. This also includes thinking about the creation of data, the data streams and the aggregation of data.
First of all, you should ask yourself where the data comes from and who maintains it. Again and again, one experiences in practice that ERP systems are bent over so much that they hold complex product data, although the use of a PIM system would often help here. ERP systems also often do not cover topics such as bulk processing of data. So you live for years with a workaround because you didn't think about it from the beginning.
It is better to first list all data at field level, from which departments or other sources they come and in which systems they are currently aggregated. From this, you should derive an objective from which it becomes clear which data you will need in which systems in the future. The development of data models is the first step in the right direction. This quickly becomes clear, especially when it comes to interfaces.
If you don't provide a service provider with an interface description broken down to each field, you are doing something wrong. Of course, you can throw yourself into endless workshops and explain your business model over and over again to external parties, but don't make it so difficult for yourself! It is better to provide a comprehensive interface description (including Excel with all fields) on the basis of which the project can be discussed efficiently.
Once my data models are clear and the data exchange between the systems is under control, I only have to think about where I want to store and evaluate the data in the long term. Because beyond the operational purpose, there are also several other purposes, especially in the area of business intelligence. Anyone who collects all the data, but does not consolidate it and only generates simple evaluations from it, should definitely think about the topic of data warehousing.
Strategy and technology play an incredibly important role in the selection of a shop system and set the framework conditions, but at the end of the day the feature set has to fit my business. In this context, some providers will argue, "Don't think too much about features, with our technology you can implement everything" - but it has to be said quite clearly: of course you can build everything individually, but for that you need a lot of time, a large budget and the appropriate staff to take care of the platform in the long term.
In practice, however, as a company I want to get to the market quickly, have manageable costs and in many cases not develop everything myself from scratch. Therefore, the requirements together with strategy and technology play the most important role. The most important features are outlined below.
Every web shop should have a certain set of basic requirements. These include the navigation, homepage, category page, product detail page, shopping cart, checkout, header and footer. The basic functions should be available here. A detailed catalogue of requirements should describe the expectations in the respective subject areas. More on this in the evaluation process section. Today we are more concerned with the not-so-obvious topics.
Internationalisation includes all topics related to opening up new markets. This includes different languages, currencies and tax rates. Directly related to this is the issue of multi-client capability. In this regard, you should ask yourself "Do I invoice with multiple companies?" If so, this must definitely be part of your evaluation, because then the licence costs (depending on the solution) can increase significantly.
Above all, the topic of multi-warehouse capability and stocks plays a major role - especially in omnichannel approaches. It is essential to ensure that this is supported by the system and handled in a scalable manner. In addition, the inventory management interface should be designed to avoid overselling. A microservice that communicates the smallest inventory changes in real time is usually recommended for this. The issue of tracking data is also quite relevant, as the most common question "Where is my parcel?" can be greatly reduced with a targeted mail.
The topic of content commerce is becoming more and more important, because the area of the less appealing presentation of products is already dominated by Amazon. Now, as a brand or smaller provider, I have to come up with something to differentiate myself from the competition. To do this, a shop system needs at least the possibility of creating landing pages itself. Functionalities that go beyond this, such as a blog or the marriage of content and commerce, can also be covered perfectly by integrating an external system. It makes little sense to bend a shop system so much that it becomes the perfect content world. A headless approach is the best way to present the commerce part from the shop system and the CMS elements from a specialised tool (i.e. Graph CMS, Storyblok or Contentful) as a unified whole.
Opinions differ on this question. If you have a very small product range that changes little, you will certainly be prepared to enter the item details individually in the shop backend. But anyone who has ever created a variant article in the Magento backend will probably have a different opinion. Because if you have thousands of articles with very different variants and data models, you need much more functionality in this area.
Here, it is important to determine how profound my requirements for product data are, what quality already comes from my ERP, how much the data must be enriched, what processes exist for enrichment and whether the system is suitable for this. If this is not the case, another specialised system (i.e. Akeneo) should be used.
Almost all shop systems come with a standard search function, which should be precisely matched to the requirements. This is because search is a prime example of the integration of third-party solutions within the framework of a MACH approach. With providers such as Algolia, Elastic Search or Solar, there are specialised solutions that are hosted and developed independently. If these are used via an API, they do not create a load on the actual system and can be integrated seamlessly.
The payment sector has changed a lot in the past 20 years. In the past, the big credit card providers were the top dogs in the payment sector, but today numerous independent payment methods and service providers have developed.
Whereas a few years ago each payment method was linked independently, today one chooses a PSP (payment service provider) that has integrated various other payment methods into one solution. This not only has the advantage of being usable from a single source at the front end and of being able to add new payment methods at the click of a button, but also simplifies accounting processes at the back end, since you no longer have to "gather" the data from different systems. Examples in the PSP sector are Klarna, Adyen, Mollie or Payone.
Some of the shop solutions already have pre-integrated service providers. Depending on the provider, you have to evaluate exactly which solution you want to use in the future. Tip: Sometimes PSPs also support the integration financially if this results in a generally usable interface. It doesn't cost anything to ask!
When it comes to search engine optimisation, there are numerous topics to pay attention to. As a rule, every shop system comes with the option of influencing the important building blocks such as meta tags, <h>-headings, SEO texts, etc. The SEO topics should be examined fundamentally after selecting a shop system and setting it up for the first time. Furthermore a catalogue of measures should be created. In addition to content-related topics, technical measures such as bundling, minimising and compressing static resources such as scripts and CSS, as well as optimised delivery of media content such as images and videos adapted to the respective output device should also be taken into account. After all, performance and especially fast loading times are one of the most important SEO factors today.
Absolutely necessary are: Breadcrumb navigation, Href lang tag, Canonical URLs, customisable page titles and meta descriptions, alt texts for images, SEO texts for categories, correct labelling of <h> headings, robots.txt, a sitemap, as well as Java script, CSS bundling and URL rewrites. The use of rich snippets would be a plus, because you can influence the presence on Google very well with this. For example, it is also possible to display rating stars in the organic area.
The solutions for individual customisation are one of the most important criteria when choosing a future e-commerce system. During the evaluation, you should definitely identify processes and customisations that deviate strongly from the standard and ask all service providers for their approaches to solving these issues. If certain issues can only be clarified during development, you should seriously consider a proof-of-concept. Because once you have decided on a system and then start incorporating shirtsleeve workarounds, you take away a crucial part of your scalability in the long run.
The evaluation process usually begins with an analysis of the current situation. Helpful in this step are a current overview of the system landscape, a customer journey map and a list of requirements at a low level of detail. With this information, a long list of providers can be evaluated with a little research.
In order to make a shortlist out of the selection, further discussions with providers and agencies are necessary, as well as, in the best case, contacts from your network who are already using certain solutions. Here you should pay particular attention to knock-out criteria that exclude certain solutions from the beginning. It is also helpful to have suitable industry examples that are already using the targeted solutions.
Once the shortlist with a maximum of three providers has been drawn up, you should increase the level of detail in your documents. This includes detailed functional and technical requirement catalogues, interface documents, data models and, ideally, wireframes and layouts for the new design. This saves lengthy workshops with the service providers. Most of the time, overpriced discovery packages are sold here that are not even necessary at this point. The better the information you have prepared yourself, the less time and costs are incurred in this phase. The aim in this phase is to ensure feasibility and to obtain initial price indications in the form of rough cost estimates.
Now a favourite should slowly emerge. It is advisable to compare two agencies (if implemented externally) for the favoured solution. Now you can either obtain an offer or you have already gathered so much confidence that you simply go ahead and create a proof-of-concept for the time being. Many traditional managers like to nail down exact sums for their business partners, but then get entangled in big discussions and a huge mountain of project management in the course of a project - especially when requirements change. Only a few decision-makers today recognise the possibility of simply leaving this overhead out of the equation and concentrating on implementation. Especially on the agency side, this saves an immense amount of time and frees up resources / budget for development. The quality increases. However, this requires an extremely competent product owner/project manager, a service provider who is used to working in an agile manner, and a great deal of trust.
At the end of the day, you should have checked all functional and technical requirements before making the decision, be satisfied with the time and price components and, last but not least, have a good feeling about the solution and the service provider. If this is not the case, it is better to do an extra round, even if this incurs costs. A system of this kind should last at least three to five years after release before starting again from scratch. This should not be a quick fix.
In the enterprise segment in Germany, there are currently eight providers of high-quality e-commerce shop systems at enterprise level.
1) Adobe Commerce Cloud (former Magento)
2) Commercetools
3) SAP Commerce Cloud
4) Salesforce Commerce Cloud (former Demandware)
5) Scayle
6) Shopify Plus
7) Shopware Enterprise Edition
8) Spryker
What used to be called Magento is now the Adobe Commerce Cloud. Adobe currently offers several ways to use the software. In addition to the self-hosted variants (including open source), there is also a SaaS and a PaaS solution. If desired, Magento's own frontend or even the Magento PWA Studio can be used.
Magento has come under a lot of criticism in recent years, especially in Germany, due to the takeover by Adobe, as the American company has shown little presence in Europe.
Well-known Adobe projects are MyTheresa, Helly Hansen, Zadig & Voltaire, Gabor and Hallhuber.
Commercetools is the absolute shooting star in Germany at enterprise level. What originally started as a Rewe spin-off is now a rapidly growing company that offers a powerful SaaS solution for online retail.
As with Aboutyou, Commercetools comes as a pure backend solution. So if you want to make a visual impact, you definitely need front-end development skills, in-house or from a service provider.
The best-known Commercetools projects are Rewe, Flaconi, Express, Paige and Tiffany.
SAP, Germany's most valuable company, offers numerous enterprise solutions as well as high-quality e-commerce systems. With SAP Hybris and SAP Upscale, many large companies find suitable counterparts to their SAP world.
SAP is often criticised for its lack of development speed of the big battleship. Once you're in the world, you can't get out of it.
For a long time, the best-known SAP e-commerce projects were Douglas and Obi. However, the SAP website shows few references worth mentioning in the field of e-commerce.
Salesforce Commerce Cloud certainly used to be called Demandware and was acquired by the tech giant in 2016. The Salesforce Commerce Cloud is a SaaS solution that fits very well into the existing Salesforce world of Marketing Cloud and Service Cloud.
In the past, the different pricing models per system and the sometimes confusing Salesforce backends were often criticised. In the frontend, Salesforce comes with its own framework.
The best-known projects are certainly Puma and Thomas Sabo.
Scayle is the latest software solution among the listed providers. Within the framework of this solution, the tech giant About You (now more than 1,000 employees and 1.17 billion turnover) offers companies to use its in-house tech stack.
This is a very comprehensive product as a SaaS model, which is constantly being developed further. Like most of the solutions, it is a back-end solution for which you have to develop your own front-end.
The best-known companies on the Scayle are Aboutyou, FC Bayern Munich, Depot, Marc O'Polo, Baur, Edited and Lascana.
The American software company has achieved incredible growth figures in recent years. The SaaS solution shines above all in the area of time-to-market, because it also comes with its own front end.
However, the topic of individualising business processes should be closely examined with Shopify. Not everything can be implemented out-of-the-box. But if you have a standard B2C business model, you can grow incredibly fast with Shopify. Above all, the development speed of the platform and the numerous marketing capabilities are enormous.
Well-known cases are Staples, Gymshark, Kylie Cosmetics, Fitbit or Mavi.
With Shopware, another German company has made it to the top of the shop solution providers. Originally started as an on-premise solution, Shopware has evolved a lot in the last few years, releasing a SaaS solution, a PaaS solution and a PWA front-end.
Shopware is certainly the provider with the least legacy and the highest flexibility, which also scores enormously on the topics of time-to-market and pricing.
Well-known implementations include Notebooksbilliger, Drykorn, Euronics, Borussia Dortmund and Tamaris.
Speaking of Spryker, the term "green field approach" inevitably comes up. The Berlin-based company stands out above all for its flexible design of individual business processes.
Those who want to do everything themselves in the future are definitely in good hands with Spryker, but should keep in mind that the topic of IT ownership must play a major role.
Well-known projects include Aldi Süd, Rose Bikes, Fond Of, Segmüller and Intersport.
