Arhitectură monolitică sau bazată pe evenimente?

Într-un magazin online, comanda este primită, apoi cineva copiază datele în sistemul de management. Depozitul primește o notificare separată, iar facturarea începe doar după ce un coleg a verificat stocul. În astfel de cazuri, întrebarea nu este teoretică: arhitectură monolitică sau bazată pe evenimente ar ajuta cu adevărat? Înainte de a oferi un răspuns tehnologic, este util să înțelegem unde se blochează informația și care pas manual mai servește un scop de afaceri real.

În multe companii în creștere, problema nu este sistemul în sine. Problema este că transferul de date între diferite sisteme, echipe și responsabilități este realizat de oameni. Acest lucru este lent, predispus la erori și dificil de urmărit. Rolul arhitecturii nu este să pară modernă, ci să asigure că procesul de afaceri funcționează previzibil chiar și atunci când numărul comenzilor crește, gama de produse se extinde sau organizația se schimbă.

Ce înseamnă monolitul în practică?

Într-o aplicație monolitică, funcțiile principale de afaceri funcționează într-un singur sistem. De exemplu, aceeași aplicație gestionează comenzile, clienții, informațiile despre stoc, permisiunile și pregătirea facturării. Baza de date, regulile de afaceri și interfața de utilizator sunt de obicei strâns legate.

Aceasta nu este o eroare și nu este sinonimă cu o abordare învechită. Un monolit bine proiectat poate fi o decizie foarte bună pentru multe companii. Regulile sunt într-un singur loc, operarea este mai simplă, există mai puține puncte de eroare între sisteme și mai multe etape ale unui proces pot fi gestionate într-o singură tranzacție. Dacă la înregistrarea unei comenzi trebuie să se rezerve simultan stocul, să se verifice limita de credit și să se creeze sarcina de execuție, monolitul poate oferi o funcționare clară.

Problema începe atunci când sistemul nu mai servește domenii de afaceri clar delimitate, ci toate noile cerințe sunt adăugate în același loc. O mică modificare în facturare poate afecta neașteptat procesul de depozitare. Din cauza unei lansări de dezvoltare, întreaga aplicație trebuie instalată. Dacă mai multe echipe lucrează pe aceeași bază de cod, coordonarea în sine poate încetini schimbarea.

Totuși, aceasta este și o problemă de proiectare și organizare. Nu orice monolit mare este de necontrolat și nu orice sistem mai mic merită imediat să fie descompus.

Cum funcționează arhitectura bazată pe evenimente?

În funcționarea bazată pe evenimente, un eveniment de afaceri trimite un semnal celorlalte sisteme implicate. Un astfel de eveniment poate fi, de exemplu, „comandă plasată”, „marfă primită”, „operațiune de producție finalizată” sau „factură plătită”. Sistemul care generează evenimentul nu efectuează neapărat toate sarcinile următoare. În schimb, publică ceea ce s-a întâmplat, iar celelalte sisteme reacționează în funcție de responsabilitatea lor.

Să luăm un exemplu simplu. Magazinul online înregistrează că a sosit o nouă comandă. Sistemul de gestionare a stocurilor rezervă marfa, sistemul logistic creează sarcina de comisionare, soluția de comunicare cu clienții trimite confirmarea, iar raportarea actualizează datele zilnice de vânzări. Nu este necesar ca magazinul online să cunoască toate regulile detaliate.

Aceasta este deosebit de avantajoasă atunci când mai multe sisteme, cu cicluri de viață diferite, trebuie să reacționeze la aceeași schimbare de afaceri. Producția, depozitul, organizarea transportului, serviciul clienți și finanțele nu lucrează neapărat cu aceeași viteză sau în aceeași aplicație. Evenimentele pot ajuta la evitarea ca informațiile să fie transmise prin e-mail, tabele sau telefon.

Totuși, arhitectura bazată pe evenimente nu înseamnă că totul se actualizează imediat și în orice condiții. În unele procese este acceptabil ca starea comenzii să apară în vizualizarea depozitului după câteva secunde. În alte cazuri, cum ar fi rezervarea stocului sau aprobarea plății, sunt necesare reguli mai stricte. Cele două situații nu trebuie tratate la fel.

Arhitectură monolitică sau bazată pe evenimente: nu este o întrebare de tip da-nu

Cele două abordări sunt adesea tratate ca o alegere falsă. Ca și cum o companie ar putea avea fie o singură aplicație mare, fie multe servicii conectate prin evenimente. În realitate, majoritatea mediilor bine funcționale sunt hibride.

Un sistem central de management sau producție poate rămâne monolitic, în timp ce transmite evenimente de afaceri definite către alte sisteme. Astfel, procesele de bază funcționează într-un mod controlat într-un singur loc, dar magazinul online, conexiunea cu transportatorii, notificarea clienților sau platforma de date nu devin captive ale logicii interne a sistemului central.

Aceasta este de obicei o cale de dezvoltare mai sigură decât descompunerea bruscă a unui întreg sistem. Dacă o companie are în prezent un sistem de încredere, dar dificil de integrat, mai întâi trebuie clarificat care evenimente de afaceri contează. Nu schimbări de date în sens tehnic, ci stări reale de afaceri: lotul de producție este finalizat, pachetul a fost predat curierului, un termen de aprobare a expirat, a apărut o discrepanță în stoc.

Când este justificată păstrarea monolitului?

Monolitul este justificat dacă procesele sunt strâns legate, schimbările sunt rare și afacerea nu are nevoie de mai multe sisteme care să evolueze independent. Într-o aplicație internă de management, utilizată de puține roluri bine definite, sarcina de operare mai mică este adesea mai valoroasă decât promisiunea separării tehnologice.

Este justificat și atunci când organizația nu are capacitatea de a opera integrări complexe. Gestionarea evenimentelor nu este suficientă doar prin introducerea unui intermediar de mesaje. Este necesară monitorizare, jurnalizare, gestionarea permisiunilor, strategie de retransmitere, toleranță la erori și responsabilitate clară. Dacă o procesare eșuează, trebuie să se știe cine primește notificarea, cum se corectează datele și ce se întâmplă cu procesele dependente.

Monolitul nu este bun pentru că îl numim simplu, ci pentru că limitele sale sunt clare. Funcțiile, datele și responsabilitățile nu se amestecă necontrolat.

Când aduce valoare de afaceri funcționarea bazată pe evenimente?

Abordarea bazată pe evenimente este puternică atunci când într-o companie există multe transferuri și coordonări repetate. Un semn tipic este atunci când mai multe echipe trebuie să știe despre aceeași schimbare, dar astăzi o rezolvă manual. De exemplu, achizițiile trimit un e-mail separat către depozit, depozitul ține un tabel separat, iar vânzările află doar mai târziu că o comandă nu poate fi onorată.

Este utilă și acolo unde sunt așteptate noi sisteme conexe. O companie folosește astăzi doar un magazin online și un ERP, dar anul viitor ar putea introduce un portal pentru clienți, imprimare automată de etichete, integrare cu transportatorii sau o platformă de date pentru management. Dacă evenimentele de afaceri de bază sunt bine definite, noile capabilități pot fi adăugate cu un risc mai mic.

Cel mai important avantaj nu este flexibilitatea tehnologică. Ci faptul că devine vizibil ce s-a întâmplat într-un proces. Pe baza unui lanț de evenimente bine conceput, se poate urmări când a fost primită comanda, când a avut loc rezervarea stocului, de ce s-a oprit execuția și în ce sistem a apărut o discrepanță. Acest lucru oferă o bază mai bună pentru deciziile de management și reduce povara asupra angajaților care astăzi încearcă să reconstituie povestea din memorie.

Costul ascuns: complexitate și responsabilitate

Arhitectura bazată pe evenimente nu oferă flexibilitate gratuită. Un sistem poate întârzia, un eveniment poate ajunge de două ori, destinatarul poate fi temporar indisponibil sau o regulă de afaceri poate fi modificată în timpul procesului. Acestea trebuie planificate în avans.

De exemplu, nu este suficient să spunem că la plasarea unei comenzi, stocul ar trebui să scadă. Trebuie definit ce se întâmplă dacă plata este respinsă, dacă comanda este modificată, dacă depozitul găsește mai puține produse sau dacă același eveniment este procesat de două ori din cauza unei erori tehnice. Aceste întrebări sunt de fapt întrebări de control de afaceri. Tehnologia le poate gestiona corect doar dacă procesul și regulile sunt clare.

De aceea, este periculos să se decidă doar pe baza tendințelor de dezvoltare. Într-un sistem descompus prea devreme, complexitatea internă anterioară este pur și simplu transferată în conexiunile dintre sisteme. Eroarea nu va mai fi în cadrul unei aplicații, ci între două sau trei echipe, surse de date și limite de responsabilitate.

Cu ce întrebări ar trebui să începem?

Înainte de a alege arhitectura, este util să urmărim un proces concret de la evenimentul declanșator până la finalizare. Cine înregistrează datele? Unde apare din nou aceeași informație? Pentru care pas este necesar un e-mail, telefon sau un tabel separat? Cine poate spune de ce s-a oprit un caz? Și care regulă este cunoscută doar de un singur angajat experimentat?

Dacă răspunsurile indică un număr mic de sisteme și un proces strâns legat, un monolit ordonat poate fi baza potrivită. Dacă apar multe sisteme separate, transferuri frecvente și o cerință de integrare în creștere, conectarea pe baza evenimentelor poate deveni justificată. Între cele două există multe soluții de tranziție, care pot fi introduse treptat.

O arhitectură bună nu este valoroasă prin numărul de servicii pe care le are. Ci prin faptul că drumul unei comenzi, al unei sarcini de producție sau al unei facturi nu există în mintea oamenilor, ci într-un proces verificabil. Dacă acest lucru este clarificat, decizia tehnologică nu va mai fi o chestiune de credință, ci o dezvoltare de afaceri direcționată.