Gestionarea complexitatii in platformele de e-commerce si eficientizarea costurilor

Inca se mai fac proiecte mari, monolitice. Inclusiv eu, am lucrat la astfel de proiecte in ultimii ani, inca exista multe asteptari de la providerii de solutii e-commerce ca o singura platforma sa faca de toate.

Si daca ne uitam in peisajul local de provideri de platforme e-commerce, fie ca sunt SaaS sau solutii ce se implementeaza on-premise, arhitectura e una monolitica. Ca arhitectura, in plan local, suntem cu 10–15 ani in urma. Exista si exceptii, dar overall, cam aia e.

Si asta duce la situatii mai complexe si mai greu de gestionat (mai ales cand incluzi intr-un singur modul multa logica de business si cod). Si zici ok, eu de fapt am incredere, pentru ca am 100% unit tests coverage si am integration tests. Dar, modificarile sau dezvoltarea de functionalitati noi sunt procese mai lente si cu impact financiar mai mare (dureaza si costa mai mult).

Odata cu dezvoltarea platformelor, care aveau trafic mare/nevoia de a scala rapid, notiunea de microservices architecture a inceput sa capete popularitate si rata de adoptie mai mare in randul companiilor de acest gen. API-first design, Decoupling, etc — termeni care pot fi intalniti des, dar la partea cu punere in practica, putini sunt cei care pot sa se laude ca au un nivel de maturitate tehnologica la nivelul la care se lauda. Si companiile mai mari fac studii legate de pozitia lor in piata pe partea de Digital Maturity, vad unde se pozitioneaza si stabilesc planuri pe termen mai lung, unde si-ar dori sa ajunga.

Revenind si la partea cu gestionarea complexitatii, ca principiu, e mai simplu sa rezolvi o problema sau sa adaugi un feature, intr-un proiect in care ai niste flow-uri simple, usor de urmarit si un codebase mai light, decat intr-un proiect mare, in care s-a adunat multa complexitate in timp.

Deci, nu trebuie sa tii in platforma de e-commerce si sistemul de loializare, si partea de gestiune stocuri si facturare, partea de gestionare produse, poze si alte cele, partea de gestionat continut, ci le poti avea in sisteme mai simple, care lucreaza integrat.

Ca principiu, putem sa vedem ca exista din ce in ce mai multe abordari cu: PWA (frontend/presentation layer pe web separat/independent de platforma care se ocupa de backend si aici uite, graphql le leaga), apoi chiar acele endpoints folosite de frontend pot fi platforme diferite.
Gestionarea de produse o poti face mai usor intr-un PIM (Product Information Management), decat in aceeasi platforma lovita din toate partile de clienti si admin users.
Datele sunt duse catre un Data Lake si de acolo vine partea de rapoarte si alte analize. Comenzile, facturile si alte documente pe fluxul de plata (credit memo) in module de ERP, ori CRM ori SFA, partea de shipments la fel, in aplicatii care pot gestiona mai multa complexitate (distributie pe mai multi curieri, balansare incarcare, etc). Si lista poate continua.

Acum, cand alegi o platforma de comert, poate unul din principalele criterii ar fi mai degraba abilitatile acesteia de a oferi conectivitate cu alte platforme si tehnologii decat features. Features — sa acopere partea de inceput, ulterior sa poti cladi peste.