Monolit vagy eseményvezérelt architektúra?

Egy webshopban beérkezik a rendelés, majd valaki átmásolja az adatokat az ügyviteli rendszerbe. A raktár külön értesítést kap, a számlázás pedig csak akkor indul, amikor egy kolléga ellenőrizte a készletet. Ilyenkor a kérdés nem elméleti: monolit vagy eseményvezérelt architektúra segítene valóban? Mielőtt azonban technológiai választ adunk, érdemes megérteni, hol akad el az információ, és melyik kézi lépés szolgál még valódi üzleti célt.

Sok növekvő vállalatnál nem maga a rendszer okozza a problémát. A gond az, hogy az egyes rendszerek, csapatok és felelősségi körök között emberek végzik az adatátadást. Ez lassú, hibára érzékeny, és nehezen követhető. Az architektúra feladata nem az, hogy modernnek tűnjön, hanem hogy az üzleti folyamat kiszámíthatóan működjön akkor is, amikor nő a rendelésszám, bővül a termékválaszték vagy változik a szervezet.

Mit jelent a monolit a gyakorlatban?

A monolit alkalmazásban a fő üzleti funkciók egy rendszerben működnek. Például ugyanaz az alkalmazás kezeli a megrendeléseket, ügyfeleket, készletinformációkat, jogosultságokat és számlázási előkészítést. Az adatbázis, az üzleti szabályok és a felhasználói felület jellemzően szorosan összetartozik.

Ez nem hiba, és nem egy elavult megközelítés szinonimája. Egy jól megtervezett monolit sok vállalat számára kifejezetten jó döntés. Egy helyen vannak a szabályok, egyszerűbb az üzemeltetés, kevesebb a rendszerközi hibahelyzet, és egy tranzakcióban kezelhető egy folyamat több lépése. Ha egy rendelés rögzítésekor egyszerre kell foglalni készletet, ellenőrizni hitelkeretet és létrehozni a teljesítési feladatot, a monolit egyértelmű működést adhat.

A probléma akkor kezdődik, amikor a rendszer már nem egyértelműen elkülönített üzleti területeket szolgál, hanem minden új igény ugyanoda kerül be. Egy kisebb változtatás a számlázásban váratlanul érintheti a raktári folyamatot. Egy fejlesztési kiadás miatt az egész alkalmazást kell telepíteni. Ha több csapat dolgozik ugyanazon a kódbázison, a koordináció önmagában lassíthatja a változást.

Ez azonban tervezési és szervezési kérdés is. Nem minden nagy monolit kezelhetetlen, és nem minden kisebb rendszer érdemel azonnal szétbontást.

Hogyan működik az eseményvezérelt architektúra?

Eseményvezérelt működésnél egy üzleti történés jelzést küld a többi érintett rendszernek. Ilyen esemény lehet például az, hogy „rendelés leadva”, „áru beérkezett”, „gyártási művelet lezárva” vagy „számla kifizetve”. Az eseményt létrehozó rendszer nem feltétlenül végzi el az összes következő feladatot. Ehelyett közzéteszi, mi történt, a többi rendszer pedig a saját felelősségi körében reagál rá.

Vegyünk egy egyszerű példát. A webshop rögzíti, hogy új megrendelés érkezett. A készletkezelő rendszer lefoglalja az árut, a logisztikai rendszer létrehozza a komissiózási feladatot, az ügyfélkommunikációs megoldás visszaigazolást küld, a riporting pedig frissíti a napi értékesítési adatokat. Nem szükséges, hogy a webshop minden részletszabályt ismerjen.

Ez különösen akkor előnyös, amikor több, eltérő életciklusú rendszernek kell ugyanarra az üzleti változásra reagálnia. A gyártás, raktár, fuvarszervezés, ügyfélszolgálat és pénzügy nem feltétlenül ugyanazzal a sebességgel vagy ugyanazon alkalmazásban dolgozik. Az események segíthetnek abban, hogy az információ ne e-mailben, táblázatban vagy telefonon induljon tovább.

Az eseményvezérelt architektúra ugyanakkor nem azt jelenti, hogy minden azonnal és minden körülmények között frissül. Egyes folyamatoknál elfogadható, hogy a rendelés státusza néhány másodperc múlva jelenik meg a raktári nézetben. Más esetekben, például készletfoglalásnál vagy fizetési jóváhagyásnál, szigorúbb szabályokra van szükség. A két helyzetet nem szabad ugyanúgy kezelni.

Monolit vagy eseményvezérelt architektúra: nem valódi igen-nem kérdés

A két megközelítést gyakran hamis választásként kezelik. Mintha egy vállalatnak vagy egyetlen nagy alkalmazása lehetne, vagy sok, eseményekkel összekötött szolgáltatása. A valóságban a legtöbb jól működő környezet hibrid.

Egy központi ügyviteli vagy termelési rendszer maradhat monolitikus, miközben meghatározott üzleti eseményeket ad át más rendszereknek. Így az alapfolyamatok egy helyen, ellenőrzött módon működnek, de a webshop, a fuvarozói kapcsolat, az ügyfélértesítés vagy az adatplatform nem válik a központi rendszer belső logikájának foglyává.

Ez általában biztonságosabb fejlődési út, mint egy teljes rendszer hirtelen felbontása. Ha a vállalatnak jelenleg egy megbízható, de nehezen integrálható rendszere van, először azt kell tisztázni, milyen üzleti események számítanak. Nem technikai értelemben vett adatváltozások, hanem valódi üzleti állapotok: elkészült a gyártási tétel, átadták a csomagot a futárnak, lejárt egy jóváhagyási határidő, eltérés keletkezett a készletben.

Mikor indokolt a monolit megtartása?

A monolit mellett szól, ha a folyamatok szorosan összefüggenek, a változások ritkák, és az üzletnek nincs szüksége több, önállóan fejlődő rendszerre. Egy belső ügyviteli alkalmazásnál, amelyet kevés, jól definiált szerepkör használ, a kisebb üzemeltetési terhelés gyakran többet ér, mint a technológiai szétválasztás ígérete.

Akkor is indokolt lehet, ha a szervezetnek nincs kapacitása összetett integrációk üzemeltetésére. Az események kezeléséhez nem elég egy üzenetközvetítő bevezetése. Kell monitorozás, naplózás, jogosultságkezelés, újraküldési stratégia, hibatűrés és egyértelmű felelősség. Ha egy feldolgozás sikertelen, tudni kell, ki kap értesítést, hogyan javítja az adatot, és mi történik a függő folyamatokkal.

A monolit nem attól jó, hogy egyszerűnek nevezzük, hanem attól, hogy a határai tiszták. A funkciók, az adatok és a felelősségek nem keverednek ellenőrizetlenül.

Mikor hoz üzleti értéket az eseményvezérelt működés?

Az eseményvezérelt megközelítés akkor erős, ha a vállalatban sok az átadás és az ismétlődő koordináció. Tipikus jel, amikor ugyanarról a változásról több csapatnak kell tudnia, de ezt ma manuálisan oldják meg. Például a beszerzés külön e-mailt küld a raktárnak, a raktár külön táblázatot vezet, az értékesítés pedig csak később értesül arról, hogy egy rendelés nem teljesíthető.

Hasznos ott is, ahol új kapcsolódó rendszerek várhatók. Egy cég ma csak webshopot és ERP-t használ, de jövőre bevezethet ügyfélportált, automatizált címkenyomtatást, fuvarozói integrációt vagy vezetői adatplatformot. Ha az alapvető üzleti események jól meghatározottak, az új képességeket kisebb kockázattal lehet hozzáadni.

A legfontosabb előny mégsem a technológiai rugalmasság. Hanem az, hogy láthatóvá válik, mi történt egy folyamatban. Egy jól kialakított eseménylánc alapján visszakövethető, mikor érkezett be a rendelés, mikor történt készletfoglalás, miért állt meg a teljesítés, és melyik rendszerben keletkezett eltérés. Ez jobb döntési alapot ad a vezetésnek, és kevesebb terhet tesz azokra a munkatársakra, akik ma emlékezetből próbálják összerakni a történetet.

A rejtett költség: összetettség és felelősség

Az eseményvezérelt architektúra nem ingyenes rugalmasság. Egy rendszer késhet, egy esemény kétszer érkezhet meg, a címzett ideiglenesen nem elérhető, vagy a folyamat közben módosulhat egy üzleti szabály. Ezekre előre kell tervezni.

Például nem elég azt mondani, hogy egy rendelés leadásakor csökkenjen a készlet. Meg kell határozni, mi történik, ha a fizetés elutasított, ha a rendelést módosítják, ha a raktár kevesebb árut talál, vagy ha ugyanazt az eseményt egy technikai hiba miatt kétszer dolgozzák fel. Az ilyen kérdések valójában üzleti kontrollkérdések. A technológia csak akkor tudja helyesen kezelni őket, ha a folyamat gazdája és szabályai világosak.

Ezért veszélyes pusztán a fejlesztési trendek alapján dönteni. Egy túl korán szétbontott rendszerben a korábbi belső bonyolultság egyszerűen átkerül a rendszerek közötti kapcsolatokba. A hiba többé nem egy alkalmazáson belül lesz, hanem két vagy három csapat, adatforrás és felelősségi határ között.

Milyen kérdésekkel érdemes kezdeni?

Az architektúra kiválasztása előtt érdemes végigkövetni egy konkrét folyamatot a kiváltó eseménytől a lezárásig. Ki rögzíti az adatot? Hol keletkezik újra ugyanaz az információ? Melyik lépéshez kell e-mail, telefon vagy külön táblázat? Ki tudja megmondani, miért állt meg egy ügy? És melyik szabályt csak egyetlen tapasztalt munkatárs ismeri?

Ha a válaszok alapján kevés rendszer és erősen összefüggő folyamat látszik, egy rendezett monolit lehet a megfelelő alap. Ha sok különálló rendszer, gyakori átadás és növekvő integrációs igény jelenik meg, az események mentén történő kapcsolódás indokolttá válhat. A kettő között pedig sok átmeneti, fokozatosan bevezethető megoldás létezik.

A jó architektúra nem attól értékes, hogy hány szolgáltatásból áll. Attól az, hogy a rendelés, a gyártási feladat vagy a számla útja nem emberek fejében, hanem ellenőrizhető folyamatban létezik. Ha ezt sikerül tisztázni, a technológiai döntés már nem hitvita lesz, hanem irányított üzleti fejlesztés.