Monolitická alebo udalosťami riadená architektúra?

V internetovom obchode príde objednávka, potom niekto skopíruje údaje do účtovného systému. Sklad dostane samostatné oznámenie a fakturácia sa spustí až po tom, čo kolega skontroluje zásoby. V takom prípade otázka nie je teoretická: monolitická alebo udalosťami riadená architektúra by skutočne pomohla? Predtým, než dáme technologickú odpoveď, je dôležité pochopiť, kde sa informácie zasekávajú a ktorý manuálny krok ešte slúži skutočnému obchodnému cieľu.

V mnohých rastúcich spoločnostiach nie je problémom samotný systém. Problém je v tom, že medzi jednotlivými systémami, tímami a zodpovednosťami ľudia vykonávajú prenos údajov. To je pomalé, náchylné na chyby a ťažko sledovateľné. Úlohou architektúry nie je vyzerať moderne, ale zabezpečiť, aby obchodný proces fungoval predvídateľne aj vtedy, keď sa zvyšuje počet objednávok, rozširuje sa sortiment produktov alebo sa mení organizácia.

Čo znamená monolit v praxi?

V monolitickej aplikácii hlavné obchodné funkcie fungujú v jednom systéme. Napríklad tá istá aplikácia spravuje objednávky, zákazníkov, informácie o zásobách, oprávnenia a prípravu fakturácie. Databáza, obchodné pravidlá a užívateľské rozhranie sú zvyčajne úzko prepojené.

To nie je chyba a nie je to synonymum pre zastaraný prístup. Dobre navrhnutý monolit môže byť pre mnohé spoločnosti výborným rozhodnutím. Pravidlá sú na jednom mieste, prevádzka je jednoduchšia, je menej chýb medzi systémami a v jednej transakcii je možné spracovať viacero krokov procesu. Ak je pri zaznamenávaní objednávky potrebné súčasne rezervovať zásoby, overiť úverový limit a vytvoriť úlohu plnenia, monolit môže poskytnúť jasnú prevádzku.

Problém začína, keď systém už neslúži jednoznačne oddeleným obchodným oblastiam, ale všetky nové požiadavky sa dostanú na jedno miesto. Malá zmena vo fakturácii môže neočakávane ovplyvniť skladový proces. Kvôli vydaniu vývoja je potrebné nasadiť celú aplikáciu. Ak na rovnakom kóde pracuje viacero tímov, koordinácia môže sama o sebe spomaliť zmenu.

To je však aj otázka návrhu a organizácie. Nie každý veľký monolit je nezvládnuteľný a nie každý menší systém si zaslúži okamžité rozdelenie.

Ako funguje udalosťami riadená architektúra?

Pri udalosťami riadenej prevádzke obchodná udalosť posiela signál ostatným dotknutým systémom. Takou udalosťou môže byť napríklad „objednávka zadaná“, „tovar prijatý“, „výrobná operácia ukončená“ alebo „faktúra zaplatená“. Systém, ktorý udalosť vytvorí, nemusí nevyhnutne vykonávať všetky nasledujúce úlohy. Namiesto toho zverejňuje, čo sa stalo, a ostatné systémy na to reagujú v rámci svojej zodpovednosti.

Vezmime si jednoduchý príklad. Internetový obchod zaznamená, že prišla nová objednávka. Systém správy zásob rezervuje tovar, logistický systém vytvorí úlohu na vychystávanie, riešenie komunikácie so zákazníkmi pošle potvrdenie a reporting aktualizuje denné predajné údaje. Nie je potrebné, aby internetový obchod poznal všetky podrobné pravidlá.

To je obzvlášť výhodné, keď musí na rovnakú obchodnú zmenu reagovať viacero systémov s rôznymi životnými cyklami. Výroba, sklad, organizácia prepravy, zákaznícky servis a financie nemusia pracovať rovnakou rýchlosťou alebo v tej istej aplikácii. Udalosti môžu pomôcť, aby sa informácie neposielali e-mailom, v tabuľke alebo telefonicky.

Udalosťami riadená architektúra však neznamená, že sa všetko aktualizuje okamžite a za každých okolností. Pri niektorých procesoch je prijateľné, že stav objednávky sa v skladovom zobrazení objaví o niekoľko sekúnd neskôr. V iných prípadoch, ako je rezervácia zásob alebo schválenie platby, sú potrebné prísnejšie pravidlá. Tieto dve situácie by sa nemali riešiť rovnako.

Monolit alebo udalosťami riadená architektúra: nie je to skutočná otázka áno-nie

Tieto dva prístupy sa často považujú za falošnú voľbu. Akoby spoločnosť mohla mať buď jednu veľkú aplikáciu, alebo veľa služieb prepojených udalosťami. V skutočnosti väčšina dobre fungujúcich prostredí je hybridná.

Centrálne účtovné alebo výrobné systémy môžu zostať monolitické, pričom určité obchodné udalosti sa odovzdávajú iným systémom. Základné procesy tak fungujú na jednom mieste kontrolovaným spôsobom, ale internetový obchod, prepravné spojenie, informovanie zákazníkov alebo dátová platforma sa nestávajú väzňami vnútornej logiky centrálneho systému.

To je zvyčajne bezpečnejšia cesta vývoja ako náhle rozdelenie celého systému. Ak má spoločnosť v súčasnosti spoľahlivý, ale ťažko integrovaný systém, najprv je potrebné objasniť, aké obchodné udalosti sú dôležité. Nie technické zmeny údajov, ale skutočné obchodné stavy: výrobná dávka je dokončená, balík bol odovzdaný kuriérovi, vypršala lehota na schválenie, vznikla odchýlka v zásobách.

Kedy je opodstatnené zachovať monolit?

Monolit je vhodný, ak sú procesy úzko prepojené, zmeny sú zriedkavé a podnik nepotrebuje viacero systémov, ktoré sa vyvíjajú samostatne. Pri vnútorných účtovných aplikáciách, ktoré používajú málo, dobre definované role, má menšia prevádzková záťaž často väčšiu hodnotu ako sľub technologického rozdelenia.

Je to tiež opodstatnené, ak organizácia nemá kapacitu na prevádzkovanie zložitých integrácií. Na spracovanie udalostí nestačí len zaviesť sprostredkovateľa správ. Je potrebné monitorovanie, logovanie, správa oprávnení, stratégia opätovného odosielania, tolerancia chýb a jasná zodpovednosť. Ak spracovanie zlyhá, je potrebné vedieť, kto dostane oznámenie, ako opraví údaje a čo sa stane s čakajúcimi procesmi.

Monolit nie je dobrý preto, že ho nazývame jednoduchým, ale preto, že jeho hranice sú jasné. Funkcie, údaje a zodpovednosti sa nekombinujú nekontrolovane.

Kedy prináša udalosťami riadená prevádzka obchodnú hodnotu?

Udalosťami riadený prístup je silný, ak je v podniku veľa odovzdávania a opakujúcej sa koordinácie. Typickým znakom je, keď o tej istej zmene musí vedieť viacero tímov, ale dnes to riešia manuálne. Napríklad nákup pošle samostatný e-mail skladu, sklad vedie samostatnú tabuľku a predaj sa dozvie až neskôr, že objednávka nie je splniteľná.

Je užitočný aj tam, kde sa očakávajú nové prepojené systémy. Spoločnosť dnes používa len internetový obchod a ERP, ale budúci rok môže zaviesť zákaznícky portál, automatizovanú tlač etikiet, integráciu prepravy alebo dátovú platformu pre manažment. Ak sú základné obchodné udalosti dobre definované, nové schopnosti je možné pridať s menším rizikom.

Najdôležitejšou výhodou nie je technologická flexibilita. Ale to, že je viditeľné, čo sa stalo v procese. Na základe dobre navrhnutého reťazca udalostí je možné spätne sledovať, kedy bola objednávka prijatá, kedy sa uskutočnila rezervácia zásob, prečo sa zastavilo plnenie a v ktorom systéme vznikla odchýlka. To poskytuje lepší základ pre rozhodovanie vedenia a znižuje záťaž na zamestnancov, ktorí sa dnes snažia zostaviť príbeh z pamäte.

Skrytý náklad: zložitosť a zodpovednosť

Udalosťami riadená architektúra nie je bezplatná flexibilita. Systém môže meškať, udalosť môže prísť dvakrát, príjemca môže byť dočasne nedostupný alebo sa počas procesu môže zmeniť obchodné pravidlo. Na to je potrebné vopred plánovať.

Napríklad nestačí povedať, že pri zadávaní objednávky sa má znížiť zásoba. Je potrebné určiť, čo sa stane, ak je platba zamietnutá, ak sa objednávka zmení, ak sklad nájde menej tovaru alebo ak sa tá istá udalosť spracuje dvakrát kvôli technickej chybe. Takéto otázky sú v skutočnosti otázky obchodnej kontroly. Technológia ich môže správne spracovať len vtedy, ak sú procesný vlastník a pravidlá jasné.

Preto je nebezpečné rozhodovať sa len na základe vývojových trendov. V systéme, ktorý bol rozdelený príliš skoro, sa predchádzajúca vnútorná zložitosť jednoducho prenesie na vzťahy medzi systémami. Chyba už nebude v rámci jednej aplikácie, ale medzi dvoma alebo tromi tímami, zdrojmi údajov a hranicami zodpovednosti.

Aké otázky je vhodné položiť na začiatku?

Pred výberom architektúry je vhodné sledovať konkrétny proces od spúšťacej udalosti po uzavretie. Kto zaznamenáva údaje? Kde sa rovnaké informácie znovu vytvárajú? Ktorý krok vyžaduje e-mail, telefón alebo samostatnú tabuľku? Kto vie povedať, prečo sa prípad zastavil? A ktoré pravidlo pozná len jeden skúsený pracovník?

Ak na základe odpovedí vidno málo systémov a silne prepojené procesy, usporiadaný monolit môže byť správnym základom. Ak sa objaví veľa samostatných systémov, časté odovzdávanie a rastúca potreba integrácie, môže byť opodstatnené prepojenie na základe udalostí. Medzi týmito dvoma prístupmi existuje mnoho prechodných, postupne zavádzaných riešení.

Dobrá architektúra nie je hodnotná tým, z koľkých služieb pozostáva. Je hodnotná tým, že cesta objednávky, výrobnej úlohy alebo faktúry existuje v overiteľnom procese, nie v hlavách ľudí. Ak sa to podarí objasniť, technologické rozhodnutie už nebude otázkou viery, ale riadeným obchodným rozvojom.