Every adjustment to an IT architecture strategy should therefore always follow a business purpose. A planned change therefore serves the goal of remaining competitive and being able to position your brand (even) better on the market. Under no circumstances, however, should the reason be that other market players are doing the same or that system XY is currently en vogue. Against this background, this article presents one of many possible scenarios in connection with the end of support for SAP Commerce.
Why monolithic systems are reaching their limits
A fundamental driver is the further development of digital commerce. Technological progress and increasing specialisation in individual digital commerce processes have caused the number of technology providers to skyrocket in recent years. As the following chart from Statista shows, the number of providers of marketing solutions, for example, has increased almost fifteenfold in the last 10 years:
The integration of such systems is increasingly presenting legacy systems with challenges when it comes to integrating and orchestrating multiple applications.
Of course, monolithic commerce systems still exist today, which are very well integrated into the respective IT architectures of a company. Paradoxically, these systems still operate because various functionalities of the platform were outsourced at an early stage. Nevertheless, these areas that are no longer required are still included in the platform. This paradigm results in a number of fundamental disadvantages of such e-commerce systems:
Lack of flexibility:
Monolithic systems consist of a single, coherent and often ‘locked’ code base. Any change or adaptation in one area of the system can have unforeseen effects on other parts, which makes further development more difficult. Implementing new features or reacting to market changes thus becomes a complex and time-consuming task.
limited scalability:
Since all functions and services are integrated into a single system, scaling one part of the system can affect the performance of the entire system. This often leads to inefficiencies and high operating costs. Dependence on a single vendor: Many monolithic platforms are proprietary and lock companies into a specific vendor. This restricts the freedom to choose the best technologies for specific requirements and often leads to higher costs.
Long development cycles:
Due to the complexity and close links within the system, development cycles often take a long time. New functions, bug fixes or updates can be delayed, which puts companies behind the competition.
When should an architectural reorganisation be considered?
One characteristic of monolithic systems is the cyclical provision of new software versions. It is irrelevant whether the system is still on-premise or already hosted in the manufacturer's cloud. Due to the high degree of customisation, every upgrade means time and costs for the company to keep the system up to date. With every new version that introduces new - and in some cases unnecessary - functionalities into the monolith, the risk of having to make customisations in the front and back end also increases. In the worst case scenario, this leads to a decline in the user-friendliness of the commerce system and a loss of sales. In principle, every in-house development is directed against the standard processes of the existing system, which increases the complexity further and further. This is precisely where the service-orientated approach of composable commerce platforms comes in.
The advantages of Composable Commerce are therefore:
High flexibility:
Companies can select the best components for their specific requirements and integrate them seamlessly. This ‘best-of-breed’ approach makes it possible to react quickly to changes and implement new technologies without having to rebuild the entire system.
Scalability:
As the individual components work independently of each other, they can be scaled individually. For example, if the traffic on the product pages increases, only this part of the system can be scaled without affecting the rest. Independence from providers: By utilising open standards and APIs, companies are no longer tied to a single provider. They can easily integrate new solutions or replace existing components without having to rebuild the entire system.
Faster innovation cycles:
Thanks to the modularity of Composable Commerce, companies can implement new functions more quickly. Changes in one component have no impact on other parts of the system, which significantly shortens development cycles.
How is the realignment taking place?
The transition from a monolithic system to a composable commerce approach will be complex. The technical development effort in the legacy system ultimately also reflects a company's business processes. However, the system's code depths often conceal functionalities from processes that have long since been replaced and are no longer used. To ensure that the changeover runs smoothly, companies should consider the following best practices:
Prioritise business requirements:
Identify the most important features of your existing solution and start migrating the related components that have the biggest impact on the business outcome. This allows organisations to quickly reap the benefits of the new system while migrating the less critical parts gradually.
Make-or-buy decision for individual functions:
By detaching from the monolith, the question arises as to whether the functionality can be provided via an external service or must be developed in-house. As a general rule, the more customised and important the individual function is for the e-commerce business, the more likely it is to be developed in-house.
Step-by-step migration:
Instead of converting the entire system at once, companies should proceed step by step. The prioritised business requirements result in a roadmap that can be used to request only the relevant resources. A step-by-step approach makes it possible to identify and resolve problems early on before they have a major impact.
Integration and interoperability:
Ensure that the new components can be seamlessly integrated into the existing system. API-supported architectures and orchestration engines are crucial here to ensure interoperability between the various modules.
Training and change management:
Switching to a new system requires not only technical adjustments, but also a change in working methods. Start at an early stage to accompany the change with active change management in order to minimise resistance and promote acceptance.
Monitoring and optimisation:
After the migration, it is important to continuously monitor the performance of the new system. Use analytics and metrics to evaluate the success of the migration and identify areas that can be further optimised. The complete ‘big bang’ switch to a Composable Commerce solution is a scenario that will not be pursued further at this point.
Conclusion
The end of support for SAP Commerce on-premise offers companies the opportunity to review their e-commerce architecture and make strategic decisions. Moving from a monolithic e-commerce system to a composable commerce approach provides organisations with the flexibility, scalability and innovation that are essential in today's competitive landscape.
The transformation not only affects technology, but also the entire organisation and its processes. A step-by-step migration can create an optimal cost/benefit ratio and minimise risks. In the long term, Composable Commerce offers a future-proof platform that enables companies to quickly adapt to new market requirements and always offer their customers the best possible experience.
