Монолитна или догађајно вођена архитектура?

U webshopu se prima narudžbina, a zatim neko prepisuje podatke u poslovni sistem. Skladište dobija zasebno obaveštenje, a fakturisanje počinje tek kada kolega proveri zalihe. U ovom slučaju, pitanje nije teoretsko: monolitna ili događajno vođena arhitektura bi zaista pomogla? Pre nego što damo tehnološki odgovor, vredi razumeti gde se informacija zaglavljuje i koji ručni korak još uvek služi pravoj poslovnoj svrsi.

Kod mnogih rastućih kompanija, problem nije sam sistem. Problem je u tome što ljudi prenose podatke između različitih sistema, timova i odgovornosti. Ovo je sporo, sklono greškama i teško za praćenje. Zadatak arhitekture nije da izgleda moderno, već da poslovni proces funkcioniše predvidljivo čak i kada se broj narudžbina poveća, asortiman proizvoda proširi ili organizacija promeni.

Šta monolit znači u praksi?

U monolitnoj aplikaciji, glavne poslovne funkcije rade u jednom sistemu. Na primer, ista aplikacija upravlja narudžbinama, klijentima, informacijama o zalihama, ovlašćenjima i pripremom fakturisanja. Baza podataka, poslovna pravila i korisnički interfejs su obično usko povezani.

Ovo nije greška i nije sinonim za zastareli pristup. Dobro dizajniran monolit može biti izuzetno dobra odluka za mnoge kompanije. Pravila su na jednom mestu, jednostavnije je upravljanje, manje je međusistemskih grešaka, a više koraka procesa može se obraditi u jednoj transakciji. Ako prilikom evidentiranja narudžbine treba istovremeno rezervisati zalihe, proveriti kreditni limit i kreirati zadatak izvršenja, monolit može pružiti jasno funkcionisanje.

Problem počinje kada sistem više ne služi jasno odvojenim poslovnim oblastima, već se svaki novi zahtev ubacuje na isto mesto. Manja promena u fakturisanju može neočekivano uticati na skladišni proces. Zbog jednog izdanja razvoja, cela aplikacija mora biti instalirana. Ako više timova radi na istoj bazi koda, koordinacija može sama po sebi usporiti promene.

Međutim, ovo je takođe pitanje dizajna i organizacije. Nije svaki veliki monolit neodrživ, i nije svaki manji sistem odmah zaslužan za razdvajanje.

Kako funkcioniše događajno vođena arhitektura?

U događajno vođenom radu, poslovni događaj šalje signal ostalim relevantnim sistemima. Takav događaj može biti, na primer, „narudžbina predata“, „roba primljena“, „proizvodna operacija završena“ ili „faktura plaćena“. Sistem koji kreira događaj ne mora nužno izvršiti sve sledeće zadatke. Umesto toga, objavljuje šta se dogodilo, a ostali sistemi reaguju u okviru svoje odgovornosti.

Uzmimo jednostavan primer. Webshop beleži da je stigla nova narudžbina. Sistem za upravljanje zalihama rezerviše robu, logistički sistem kreira zadatak komisioniranja, rešenje za komunikaciju sa klijentima šalje potvrdu, a izveštavanje ažurira dnevne prodajne podatke. Nije potrebno da webshop poznaje sva pravila u detalje.

Ovo je posebno korisno kada više sistema sa različitim životnim ciklusima mora reagovati na istu poslovnu promenu. Proizvodnja, skladište, organizacija transporta, korisnička podrška i finansije ne rade nužno istom brzinom ili u istoj aplikaciji. Događaji mogu pomoći da informacije ne budu prenete putem e-pošte, tabela ili telefona.

Međutim, događajno vođena arhitektura ne znači da se sve odmah i u svim okolnostima ažurira. Kod nekih procesa je prihvatljivo da se status narudžbine prikaže u skladišnom prikazu nakon nekoliko sekundi. U drugim slučajevima, kao što su rezervacija zaliha ili odobrenje plaćanja, potrebna su stroža pravila. Dve situacije ne treba tretirati na isti način.

Monolit ili događajno vođena arhitektura: nije pravo pitanje da li-da ili ne-ne

Dva pristupa se često tretiraju kao lažni izbor. Kao da kompanija može imati samo jednu veliku aplikaciju ili mnogo usluga povezanih događajima. U stvarnosti, većina dobro funkcionišućih okruženja je hibridna.

Centralni poslovni ili proizvodni sistem može ostati monolitan, dok istovremeno prenosi određene poslovne događaje drugim sistemima. Na taj način osnovni procesi funkcionišu na jednom mestu, na kontrolisan način, ali webshop, veza sa prevoznikom, obaveštenje klijenta ili platforma za podatke ne postaju zarobljenici unutrašnje logike centralnog sistema.

Ovo je obično sigurniji put razvoja nego iznenadno razdvajanje celog sistema. Ako kompanija trenutno ima pouzdan, ali teško integrabilan sistem, prvo treba razjasniti koji poslovni događaji su važni. Ne tehničke promene podataka, već stvarna poslovna stanja: proizvodna serija je završena, paket je predat kuriru, rok za odobrenje je istekao, došlo je do odstupanja u zalihama.

Kada je opravdano zadržati monolit?

Monolit je opravdan kada su procesi usko povezani, promene su retke, i poslovanju nije potrebno više sistema koji se samostalno razvijaju. Kod interne poslovne aplikacije koju koristi malo, dobro definisanih uloga, manji operativni teret često vredi više od obećanja tehnološkog razdvajanja.

Takođe može biti opravdano ako organizacija nema kapaciteta za upravljanje složenim integracijama. Za upravljanje događajima nije dovoljno uvesti posrednika za poruke. Potrebno je nadgledanje, logovanje, upravljanje ovlašćenjima, strategija ponovnog slanja, tolerancija na greške i jasna odgovornost. Ako obrada ne uspe, treba znati ko će biti obavešten, kako će ispraviti podatke i šta će se dogoditi sa zavisnim procesima.

Monolit nije dobar zato što ga nazivamo jednostavnim, već zato što su njegove granice jasne. Funkcije, podaci i odgovornosti se ne mešaju nekontrolisano.

Kada događajno vođen rad donosi poslovnu vrednost?

Događajno vođen pristup je snažan kada u kompaniji ima mnogo prenosa i ponavljajuće koordinacije. Tipičan znak je kada više timova mora biti obavešteno o istoj promeni, ali to danas rešavaju ručno. Na primer, nabavka šalje poseban e-mail skladištu, skladište vodi zasebnu tabelu, a prodaja saznaje kasnije da narudžbina ne može biti ispunjena.

Korisno je i tamo gde se očekuju novi povezani sistemi. Kompanija danas koristi samo webshop i ERP, ali sledeće godine može uvesti portal za klijente, automatizovano štampanje etiketa, integraciju sa prevoznicima ili platformu za podatke za menadžment. Ako su osnovni poslovni događaji dobro definisani, nove sposobnosti se mogu dodati sa manjim rizikom.

Najvažnija prednost nije tehnološka fleksibilnost. Već to što postaje vidljivo šta se dogodilo u procesu. Na osnovu dobro dizajniranog lanca događaja, može se pratiti kada je narudžbina primljena, kada je izvršena rezervacija zaliha, zašto je izvršenje zaustavljeno i u kojem sistemu je došlo do odstupanja. Ovo daje bolju osnovu za donošenje odluka menadžmentu i manje opterećuje zaposlene koji danas pokušavaju da sastave priču iz sećanja.

Skriveni trošak: složenost i odgovornost

Događajno vođena arhitektura nije besplatna fleksibilnost. Sistem može kasniti, događaj može stići dva puta, primalac može biti privremeno nedostupan, ili se poslovno pravilo može promeniti tokom procesa. Na ovo treba unapred planirati.

Na primer, nije dovoljno reći da se prilikom predaje narudžbine smanji zaliha. Treba definisati šta se dešava ako je plaćanje odbijeno, ako se narudžbina izmeni, ako skladište pronađe manje robe, ili ako se isti događaj zbog tehničke greške obradi dva puta. Takva pitanja su zapravo pitanja poslovne kontrole. Tehnologija ih može pravilno obraditi samo ako su proces i pravila jasni.

Zato je opasno odlučivati samo na osnovu trendova u razvoju. U sistemu koji je prerano razdvojen, prethodna unutrašnja složenost jednostavno se prenosi na veze između sistema. Greška više neće biti unutar jedne aplikacije, već između dva ili tri tima, izvora podataka i granica odgovornosti.

Koja pitanja je vredno postaviti na početku?

Pre nego što se izabere arhitektura, vredi pratiti konkretan proces od pokretačkog događaja do završetka. Ko beleži podatke? Gde se isti podaci ponovo generišu? Za koji korak je potreban e-mail, telefon ili zasebna tabela? Ko može reći zašto je neki slučaj zaustavljen? I koje pravilo poznaje samo jedan iskusni zaposleni?

Ako odgovori pokazuju malo sistema i snažno povezane procese, uređen monolit može biti odgovarajuća osnova. Ako se pojavi mnogo odvojenih sistema, česti prenosi i rastuće potrebe za integracijom, povezivanje putem događaja može biti opravdano. Između toga postoji mnogo prelaznih, postepeno uvodljivih rešenja.

Dobra arhitektura nije vredna zbog broja usluga koje sadrži. Već zato što put narudžbine, proizvodnog zadatka ili fakture ne postoji u glavama ljudi, već u kontrolisanom procesu. Ako se to uspe razjasniti, tehnološka odluka više neće biti stvar vere, već usmereni poslovni razvoj.