meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
project_management:big_bang_vs._incremental_approaches_for_the_development_of_a_new_shop [2021/04/08 23:35] – created Antonio Robirosaproject_management:big_bang_vs._incremental_approaches_for_the_development_of_a_new_shop [2021/04/08 23:45] (current) – Antonio Robirosa
Line 1: Line 1:
 ====== Big band vs. incremental approaches for the development of a new shop ====== ====== 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 can successes with both methods and I would evaluate the following criteria before deciding on one of them.+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 aproach^Incremental migration to a new shop^+^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| ^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|
-^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 replace, the requirements for the next components are collected| 
-^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 ban approach because the shop is changed in small steps which must be compatible with the old components which aren't migrated| 
-^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 contain 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 is focus in only one area at a time| 
-^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 to set up| 
-^Posibility 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| 
 ^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| ^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|
      
 ===== Recommendations ===== ===== Recommendations =====
 ==== Big bang development approach ==== ==== Big bang development approach ====
  
-It is essential that you **know the business process before starting with the development** when you plan to use this method. This approch works well for shops with product catalogues which have similar pricing, order and fulfillment 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. +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. 
  
-=== Sucess story === +=== Success story === 
-In 2020 in **9 months** 8 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.+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. 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 ==== ==== 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 always used when most of the requirements aren't documented and they must be extracted from the legacy code.+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 === === Success story ===
-In 2018 2 full-stack developers and I replaced in 3 months the pricing calculation, search and add-to-cart functionality of six special 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, fulfillment process and display of orders was done on the legacy system.+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. 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.