Tworzenie sklepów internetowych

Gdy sklep przerasta swoje aplikacje

Typowy rozwijający się sklep działa na stosie aplikacji: jedna do opcji produktów, jedna do cen B2B, jedna do zestawów, jedna do subskrypcji, jedna synchronizująca stan magazynowy z magazynem. Każda kosztuje miesięczną opłatę, każda dodaje skrypty do witryny sklepu i żadna nie została zaprojektowana do współpracy z pozostałymi. W końcu dwie z nich kolidują przy finalizacji zamówienia i nikt nie potrafi powiedzieć, które.

Budowa niestandardowa zastępuje kilka z nich jednym fragmentem kodu, który robi dokładnie to, czego potrzebuje Państwa firma. Nie zawsze jest to właściwy wybór. Jeśli aplikacja dobrze wykonuje zadanie i kosztuje 20 euro miesięcznie, budowanie jej samodzielnie nie ma sensu. Ale gdy aplikacje kolidują, gdy żadna nie pasuje całkiem lub gdy opłaty za kilka aplikacji przewyższają koszt budowy w ciągu dwóch lat, rozwój niestandardowy się zwraca.

Integracje, które głośno zawodzą

Najdroższym rodzajem błędu integracji jest błąd cichy. Synchronizacja stanu magazynowego zawodzi o 2 w nocy, nikt tego nie zauważa, a sklep sprzedaje przedmioty, których nie ma w magazynie. Zamówienie nie dociera do ERP i nigdy nie zostaje wysłane. Te awarie rzadko wynikają wyłącznie ze złego kodu; pochodzą z integracji zbudowanych bez uwzględnienia tego, co się dzieje, gdy drugi system działa wolno lub jest niedostępny.

Każdą integrację budujemy tak, by ponawiała nieudane wywołania, rejestrowała, co zrobiła, i alarmowała wskazaną osobę, gdy czegoś nie można rozwiązać automatycznie. Specyfikacja, którą uzgadniamy przed budowaniem, obejmuje wyraźnie te przypadki awarii, ponieważ to na nie idzie większość rzeczywistego wysiłku.

• Co się dzieje, jeśli drugi system nie odpowiada
• Co się dzieje, jeśli dane przychodzą w nieoczekiwanym formacie
• Kto jest alarmowany, jak i jak szybko
• Jak nieudana synchronizacja jest odtwarzana po naprawieniu problemu