meta data for this page
Big band vs. incremental approaches for the development of a new shop
I often get asked what approach I recommend for building a new SAP Commerce shop and both approaches may be the right one for your legacy shop. Since 2010 I saw successes with both methods. Here is criteria to help you decide on which approach to use:
| Criteria | Big bang approach | Incremental migration to a new shop |
|---|---|---|
| Definition | A new shop is developed while the old one is on maintenance. One day the new shop goes live while the old one is turned off | Slowly one area is tackled, the requirements are defined, a new component is developed and when it goes live, it replaces the old one |
| When does the business sees the benefits of the new shop? | Late, after the new shop goes live | Early, after the first new component goes live |
| Possibility of introduction of new features during the development of the new shop | Limited. First the minimum viable set of features must be developed | High. Each new component may have new features |
| Must the business requirements and processes be clear before starting with the development? | Yes to estimate the day of the go-live and the total effort accurately | No, only the requirements for the first components to be migrated must be known. Once they are replaced, the requirements for the next components are collected |
| Risk of critical bugs which make the business lose money | High because it is difficult to be sure that the new shop will behave like the old one and contains all valuable features. This risk can be reduced by investing in testing the new code and in the parallel usage of the old and new shop | Low because the development team focus in only one area at a time |
| Total development effort (and time) | Less than the incremental approach because the programmers are writing new code without the need to support the old features | More than with a big bang approach because the shop is changed in small steps which must be compatible with the old components which aren't migrated |
| Complexity of the deployment and go-live | Low: The traffic to the old shop is switched to the new shop. From that moment, only the new shop is used | High: The development of the new shop may require a shared authentication mechanism (for example, Single Sign On) which needs additional servers. During the development process you will have more moving parts |
Big bang development approach
It is essential that you know the business processes before starting with the development when you plan to use this method. This approach works well for shops with product catalogues which have similar pricing, order and fulfilment processes. The key here is that there is a high similarity in the articles. It is also important that these shops are commerce-oriented making the content simple.
Success story
In 2020 in 9 months 7 backend and 5 frontend developers and 3 analysts and I built a new hybris shop based on the Omni Connect Channel web services using a vue.js as the framework on the frontend. The goal was to replace the old SAP Commerce shop using the accelerator frontend (JSP) and start using the SAP cloud.
Although we found many critical bugs during the two days after the go-live, after one week we reached our first record of orders placed on one single day. And the business was extremely satisfied with the new shop.
Incremental replacement of the old shop
Any other shop with complexity in the product catalogue, processes or contact catalogue must be slowly replaced by new code -one component at a time-. Usually this method is used when most of the requirements aren't documented and they must be extracted from the legacy code.
Success story
In 2018 2 full-stack developers and I as technical product owner replaced in 3 months the pricing calculation, search and add-to-cart functionality of six products representing 70% of the sales of a legacy shop. The initial search, configuration and pricing was done on the new system which sent the cart to the old shop. The checkout, fulfilment process and display of orders was done on the legacy system.
After the new system went live the business could change the prices in real-time and offer additional services for those products for a fee.
Discussion