Architecture considerations for international B2C Webshop rollouts between Monolith, Microservices and Self-contained Systems
Generate new sales through international webshop rollouts - many retail companies are currently flirting with this plan. However, the digital step abroad is anything but child's play due to numerous pitfalls. Thorough planning of internationalisation is therefore the basic prerequisite for conquering new markets.
The sales curve in e-commerce continues to point upwards: sound Forecasts of the US-American market research company eMarketer the global online trade will generate more than 2 trillion US dollars for the first time in 2017. This sum could even double again by 2020. Many retailers see the internationalization of their online business as a promising strategy for participating in this growth.
The strategy determines the requirements
Realizing this growth, however, is a highly complex undertaking that requires a comprehensive internationalization strategy. Dealers must analyse the individual circumstances of their own company and formulate an individual idea of the forthcoming international expansion based on this. One question is particularly important here: How strongly does a retail company want to respond to the country-specific peculiarities of the target markets envisaged?
The central question is: to what extent should country-specific characteristics be taken into account?
The answer to this question depends to a large extent on the specific strategic considerations of the company. Therefore, to the regret of many a retailer, there is no patent solution beyond all doubt for a successful international B2C shop rollout. Instead, each company must find its own way within a wide range of options.
For example, it is possible to centrally manage a company across national borders. In this case, decisions made at the company headquarters must also be implemented internationally. Logically, companies of this kind attach great importance to being able to centrally develop and maintain new web shops or to sell all products via a single shop.
In addition, however, there are also companies which, in the course of their internationalisation, set up their own national companies, which manage the business in the target markets themselves and, due to their detailed knowledge of the market, also (are allowed to) make business-critical decisions - such as the design of a web shop - as far as possible independently. Marketing with its central elements for business success such as pricing, offer management and the development of a consistent look & feel in all sales channels is often left to the country organizations. Accordingly, the decision as to whether a product that generates outstanding sales in France is also offered in Russia and sold there at the same price or at a different price is usually made directly in the target markets and not at the corporate headquarters in such companies. The head office thus transfers a high degree of flexibility and responsibility to the national companies. They are thus in a position to react independently to the competitive situation in their market.
The two variants just presented serve only as examples of how the general corporate strategy can affect the planning and implementation of the internationalisation of the webshop. In addition, there are countless other ways to lead your own company into new markets. What is certain, however, is that the specialist webshop architecture must match the favoured internationalisation strategy and the resulting requirements.
The classic monolith
Many retailers initially see a monolithic architecture as the most pragmatic solution when they start their internationalization project. In this case, a new shop is developed from the existing shop system. All international shops brought into production in this way are thus part of a self-contained system. This variant offers a great advantage: Since the new shops can follow the samples of the existing ones, an international B2C shop rollout within a monolith requires relatively little effort - and is therefore relatively quick and inexpensive.
A considerable challenge of the monolithic structure, on the other hand, becomes apparent later when some country shops have already been launched: Although the initial shop forms the basis for the new web shops and many characteristics can be adopted, even dealers with a centralized focus have to adapt their international shops at least minimally to the country-specific peculiarities of the respective market. Not only can language, script and currency differ from country to country, but the preferences regarding payment methods also often vary widely. In addition, almost every country has its own set of rules regarding information obligations or taxes.
These special features can lead to additional expenses in a monolith. On the one hand, the possibilities of responding to them are limited within a monolith, since all shops partly fall back on the same elements and each technical change or extension must take the internal connections into account. Under these conditions, offering each target market the payment methods popular in the respective country, for example, is just as time-consuming as complying with the different legal framework conditions in the individual countries. On the other hand the monolith becomes larger and more complex with each further shop and each further special case, so that the system becomes ever more unclear and more difficult to maintain.
Furthermore, from a certain number of shops onwards, efficient test coverage in a purely monolithic architecture is only possible with great effort. Finally, changes due to the sharing of functional elements can potentially affect all shops. The effects of such updates must therefore be tested in all countries - even if, from a technical perspective, an update is only relevant for a single shop. The danger of falling into a test trap is great. The guarantee of testability with increasing complexity is therefore a central criterion when selecting an architecture. A high level of automated test coverage can mitigate this problem, but is also associated with considerable effort and costs.
Modularization within a monolithic structure
Limiting the ever-increasing complexity is one of the major challenges facing retailers who are driving their internationalization project forward with a classic monolithic architecture. The most promising way to master complexity is to modularize the large overall structure into smaller, technically delimited components. For this, however, the monolithic basis of the system does not necessarily have to be dissolved. Instead, this procedure within a monolith contributes to making the testability of the system more efficient: New or modified system components no longer have to be tested in all country shops. So you don't have to have an overview of the complete system for an update.
Modularization increases the flexibility of the project.
In addition, modularization increases the flexibility of the project: By adapting the components to specific business requirements, it is possible to let different development teams work on different modules relatively independently of each other at the same time. In this way, country-specific special cases can also be implemented more efficiently. However, this flexibility is not limitless. Since the monolith is still built on a common technical basis, newly developed or revised components can only be deployed together. Instead, a release of the entire monolith must be coordinated so that the modules continue to fit together. Thus, excluding undesirable interactions within the monolith remains a complex administrative task.
Distributed Systems: Microservices and Self-contained Systems
Monolithic structures are not the only way to build a webshop. There is also the option of encapsulating the modules in separate services and creating a distributed system from individual components. Such systems can be built from microservices or self-contained systems (SCS), for example.
Within the Microservices architecture, complex applications are composed of very fine-grained, independent services. Based on this, the microservices that each shop needs can be selected individually for each shop down to the last detail. However, the small-scale structure has one disadvantage: the administration and maintenance of microservices is difficult due to their high number and numerous interfaces. In contrast to microservices, SCSs are larger in size. In contrast to their fine-granular counterparts, they are designed as independent web applications that can be used separately and flexibly exchanged due to their own data storage, integrated business logic and user interface. If required, SCS can use microservices as a basis again.
Whichever variant a retailer chooses: Due to the strong encapsulation of the individual modules within the distributed system, it is now possible to develop country-specific components independently and deploy them separately. This architecture thus offers advantages in particular to dealers who want to offer their national companies as much freedom as possible in the design of their web shops and operate them on local servers in the countries. The development teams, which may even be located in different societies, are thus able to organise themselves and their work more independently. In theory, even the selection of different technologies is possible. This architecture also increases testing efficiency, as the effects of updates only need to be checked in the shops that actively use the component.
Central core in the distributed system
However, the fact that an individually developed service could be made available to the national companies for each functionality does not mean that this would also make sense from an efficiency perspective. Instead, services that are used by all shops can be brought together in a central core. In this case, however, country-specific services are outsourced and only loosely linked to the core. This approach has two advantages: On the one hand the core services remain clear, testable and controllable and on the other hand changes in the local services do not endanger the core.
But which services can be part of the central component, which is geared to all country shops, and which problem areas should be solved individually for each country? Due to the immense differences between the internationalization and IT strategies of individual companies, there is no universal answer to this question. In our experience, however, the motto "Global where possible - local where necessary" provides a rough guideline.
Global, where possible - local, where necessary
In order not to maneuver yourself into a test case, the central component should not contain too many features according to this motto - and especially those that are susceptible to frequent updates. Instead, it makes sense to integrate the absolute basic structures in it in particular. These are limited to the essential modules of an online shop such as the product catalog, in which the components of the assortment are stored. In addition, functionalities such as the search function or the basic functions of the shopping basket can also be added, which can usually also be standardized internationally without any problems.
How quickly country-specific features have to be taken into consideration, on the other hand, can be seen by looking at the price calculation within the shopping basket: regional differences such as different shipping costs quickly go beyond the limits of a global standard functionality. Price calculations should therefore be designed in such a way that they can be easily extended by region-specific components. A new feature would then only require the development of a further component, which would in principle be available for all countries - even if it is ultimately only used by a few shops. A change to this component would then - as described above - only affect those countries that actively use it. The testing effort would thus be manageable.
Another way to reduce both programming effort and testing problems is to set up multi-country clusters. The basis for the formation of such clusters, however, is not necessarily the language - for example, all English-speaking shops are combined on common servers. Instead, similar purchasing behaviour and comparable forms of addressing customers and the resulting compatible patterns in the component structure play a role in deciding which countries form a cluster. In addition, such clusters can also be used to maintain shops in smaller markets - provided they do not have the necessary infrastructure to take care of their own - centrally or from a larger country. In this way, the responsibility for shop maintenance between local and central teams can be varied almost infinitely.
Conclusion: Architecture plays a decisive role in success
The selection of an architecture suitable for the individual expansion project is one of the central keys to a successful (and long-term affordable) international B2C shop rollout. In particular, retail companies are confronted with the challenge of having to combine the desire for flexibility in the design of individual web shops with the need for efficiency. Building a modularized system that makes deployment more flexible and increases testability is the decisive step towards this balance. In this way, it is possible to build digital business immediately and at the same time be flexible enough to quickly realize future business opportunities with the existing architecture.