Monolitická nebo událostmi řízená architektura?

V internetovém obchodě přijde objednávka a někdo pak přepíše údaje do podnikové aplikace. Sklad dostane zvláštní oznámení a fakturace začne až po kontrole zásob kolegou. V takovém případě není otázka teoretická: monolitická nebo událostmi řízená architektura by skutečně pomohla? Než však dáme technologickou odpověď, je dobré pochopit, kde se informace zadrhává a který ruční krok má ještě skutečný obchodní účel.

U mnoha rostoucích společností není problémem samotný systém. Problém je, že přenos dat mezi jednotlivými systémy, týmy a odpovědnostmi provádějí lidé. To je pomalé, náchylné k chybám a obtížně sledovatelné. Úkolem architektury není vypadat moderně, ale zajistit, aby obchodní proces fungoval předvídatelně i při nárůstu počtu objednávek, rozšíření sortimentu nebo změně organizace.

Co znamená monolit v praxi?

V monolitické aplikaci fungují hlavní obchodní funkce v jednom systému. Například stejná aplikace zpracovává objednávky, zákazníky, informace o zásobách, oprávnění a přípravu fakturace. Databáze, obchodní pravidla a uživatelské rozhraní jsou obvykle úzce propojeny.

To není chyba ani synonymum pro zastaralý přístup. Dobře navržený monolit je pro mnoho společností výborným rozhodnutím. Pravidla jsou na jednom místě, provoz je jednodušší, je méně chyb mezi systémy a v jedné transakci lze zpracovat více kroků procesu. Pokud je při zaznamenání objednávky potřeba současně rezervovat zásoby, zkontrolovat úvěrový limit a vytvořit úkol pro plnění, monolit může poskytnout jasnou funkčnost.

Problém nastává, když systém již neslouží jasně odděleným obchodním oblastem, ale všechny nové požadavky se dostávají na stejné místo. Malá změna ve fakturaci může neočekávaně ovlivnit skladový proces. Kvůli vydání vývoje je třeba nasadit celou aplikaci. Pokud na stejném kódu pracuje více týmů, koordinace může sama o sobě zpomalit změny.

To je však také otázka návrhu a organizace. Ne každý velký monolit je nezvládnutelný a ne každý menší systém si zaslouží okamžité rozdělení.

Jak funguje událostmi řízená architektura?

Při událostmi řízeném provozu posílá obchodní událost signál ostatním dotčeným systémům. Takovou událostí může být například „objednávka podána“, „zboží přijato“, „výrobní operace dokončena“ nebo „faktura zaplacena“. Systém, který událost vytvoří, nemusí nutně provádět všechny následující úkoly. Místo toho zveřejní, co se stalo, a ostatní systémy na to reagují ve svém vlastním rozsahu odpovědnosti.

Uveďme si jednoduchý příklad. Internetový obchod zaznamená, že přišla nová objednávka. Systém pro správu zásob rezervuje zboží, logistický systém vytvoří úkol pro vychystávání, řešení pro komunikaci se zákazníky pošle potvrzení a reporting aktualizuje denní prodejní údaje. Není nutné, aby internetový obchod znal všechny podrobné pravidla.

To je zvláště výhodné, když musí na stejnou obchodní změnu reagovat více systémů s různými životními cykly. Výroba, sklad, organizace dopravy, zákaznický servis a finance nemusí nutně pracovat stejnou rychlostí nebo ve stejné aplikaci. Události mohou pomoci, aby se informace nepředávaly e-mailem, tabulkou nebo telefonem.

Událostmi řízená architektura však neznamená, že se vše aktualizuje okamžitě a za všech okolností. U některých procesů je přijatelné, že se stav objednávky objeví ve skladovém pohledu o několik sekund později. V jiných případech, například při rezervaci zásob nebo schválení platby, jsou potřebná přísnější pravidla. Obě situace by se neměly řešit stejně.

Monolit nebo událostmi řízená architektura: není to skutečná otázka ano-ne

Oba přístupy se často považují za falešnou volbu. Jako by společnost mohla mít buď jednu velkou aplikaci, nebo mnoho služeb propojených událostmi. Ve skutečnosti většina dobře fungujících prostředí je hybridní.

Centrální podnikový nebo výrobní systém může zůstat monolitický, zatímco předává určité obchodní události jiným systémům. Základní procesy tak fungují na jednom místě kontrolovaným způsobem, ale internetový obchod, spojení s dopravci, oznámení zákazníkům nebo datová platforma se nestávají zajatci vnitřní logiky centrálního systému.

To je obvykle bezpečnější cesta rozvoje než náhlé rozdělení celého systému. Pokud má společnost v současnosti spolehlivý, ale obtížně integrovatelný systém, je nejprve třeba vyjasnit, které obchodní události jsou důležité. Ne technické změny dat, ale skutečné obchodní stavy: výrobní dávka je dokončena, balíček byl předán kurýrovi, schvalovací lhůta vypršela, došlo k odchylce v zásobách.

Kdy je opodstatněné zachovat monolit?

Monolit je vhodný, pokud jsou procesy úzce propojené, změny jsou vzácné a podnik nepotřebuje více samostatně se vyvíjejících systémů. U interní podnikové aplikace, kterou používá několik dobře definovaných rolí, je menší provozní zátěž často cennější než slib technologického oddělení.

Může být také opodstatněné, pokud organizace nemá kapacitu pro provozování složitých integrací. Pro zpracování událostí nestačí zavést zprostředkovatele zpráv. Je třeba monitorování, protokolování, správa oprávnění, strategie opětovného odeslání, odolnost proti chybám a jasná odpovědnost. Pokud zpracování selže, je třeba vědět, kdo dostane oznámení, jak opraví data a co se stane s čekajícími procesy.

Monolit není dobrý proto, že ho nazýváme jednoduchým, ale proto, že jeho hranice jsou jasné. Funkce, data a odpovědnosti se nekombinují nekontrolovaně.

Kdy přináší událostmi řízený provoz obchodní hodnotu?

Událostmi řízený přístup je silný, pokud je ve společnosti mnoho předávání a opakované koordinace. Typickým znakem je, když o stejné změně musí vědět více týmů, ale dnes to řeší ručně. Například nákup posílá zvláštní e-mail skladu, sklad vede zvláštní tabulku a prodej se dozvídá až později, že objednávka není splnitelná.

Je užitečný i tam, kde se očekávají nové propojené systémy. Společnost dnes používá pouze internetový obchod a ERP, ale příští rok může zavést zákaznický portál, automatizovaný tisk štítků, integraci s dopravci nebo datovou platformu pro vedení. Pokud jsou základní obchodní události dobře definovány, nové schopnosti lze přidat s menším rizikem.

Nejdůležitější výhodou však není technologická flexibilita. Je to to, že je viditelné, co se v procesu stalo. Na základě dobře navrženého řetězce událostí lze zpětně sledovat, kdy byla objednávka přijata, kdy došlo k rezervaci zásob, proč se zastavilo plnění a ve kterém systému došlo k odchylce. To poskytuje lepší základ pro rozhodování vedení a snižuje zátěž na zaměstnance, kteří se dnes snaží skládat příběh z paměti.

Skryté náklady: složitost a odpovědnost

Událostmi řízená architektura není bezplatná flexibilita. Systém může mít zpoždění, událost může dorazit dvakrát, příjemce může být dočasně nedostupný nebo se během procesu může změnit obchodní pravidlo. Na to je třeba se připravit předem.

Například nestačí říci, že při zadání objednávky by se měly snížit zásoby. Je třeba určit, co se stane, pokud je platba zamítnuta, pokud je objednávka změněna, pokud sklad najde méně zboží nebo pokud se stejná událost zpracovává dvakrát kvůli technické chybě. Takové otázky jsou ve skutečnosti otázkami obchodní kontroly. Technologie je může správně zpracovat pouze tehdy, pokud jsou procesní vlastník a pravidla jasná.

Proto je nebezpečné rozhodovat se pouze na základě vývojových trendů. V systému, který byl příliš brzy rozdělen, se předchozí vnitřní složitost jednoduše přenese do vztahů mezi systémy. Chyba již nebude uvnitř jedné aplikace, ale mezi dvěma nebo třemi týmy, zdroji dat a hranicemi odpovědnosti.

Jaké otázky je dobré si položit na začátku?

Před výběrem architektury je dobré sledovat konkrétní proces od spouštěcí události až po uzavření. Kdo zaznamenává data? Kde se znovu objevují stejné informace? Který krok vyžaduje e-mail, telefon nebo zvláštní tabulku? Kdo může říci, proč se případ zastavil? A které pravidlo zná pouze jeden zkušený zaměstnanec?

Pokud odpovědi ukazují na málo systémů a silně propojené procesy, může být dobře uspořádaný monolit vhodným základem. Pokud se objeví mnoho samostatných systémů, časté předávání a rostoucí potřeba integrace, může být oprávněné propojení na základě událostí. Mezi těmito dvěma přístupy existuje mnoho přechodných, postupně zaváděných řešení.

Dobrá architektura není hodnotná tím, z kolika služeb se skládá. Je hodnotná tím, že cesta objednávky, výrobního úkolu nebo faktury neexistuje v hlavách lidí, ale v ověřitelném procesu. Pokud se to podaří vyjasnit, technologické rozhodnutí již nebude otázkou víry, ale řízeným obchodním rozvojem.