Kde se nacházíme v rámci moderního projektu umělé inteligence nebo cloudu? Obvykle už máme za sebou první obchodní jednání, ale ještě nejsme připraveni na samotnou výstavbu. V tu chvíli tým zná obchodní cíl, ale příliš mnoho technických detailů je stále nejasných. Riziko je vysoké, protože architektura ještě nebyla testována vůči skutečným požadavkům systému.
Proto se práce přesouvá do fáze objevování (discovery). Objevování přeměňuje širokou představu na architektonickou vizi. Definuje cílový tvar systému, cestu k němu, tým potřebný pro jeho podporu a rozsah prací pro implementaci. Jednoduše řečeno, odpovídá na jednoduchou otázku: jaký systém vlastně stavíme a co musí splňovat?
Architektura řízená atributy (Attribute Driven Design, zkráceně ADD) je jednou z nejjasnějších cest, jak tuto otázku zodpovědět. Jde o metodu navrhování softwarové architektury, která začíná u klíčových kvalitativních vlastností a omezení systému. Místo toho, aby se nejprve hádala struktura a doufalo se, že později zapadne, ADD vychází z podnětů, které jsou pro byznys a systém nejdůležitější.
Tyto podněty pocházejí z fáze objevování. Obchodní workshop může odhalit případy použití a práci, kterou systém musí vykonat. Workshop příležitostí může ukázat, proč systém vůbec existuje, například vstup na nový trh, modernizace produktu nebo zlepšení času uvedení na trh. Technické workshopy přidávají omezení ze strany sítě, infrastruktury, bezpečnosti a integrace. Workshopy kvality přidávají měřitelné vlastnosti, které systém musí splňovat, jako jsou dostupnost, výkon, škálovatelnost, bezpečnost a možnost testování.
Tohle je jádro metody. Každá volba při návrhu by měla vést zpět k jednomu nebo více architektonickým podnětům. Pokud nějaká komponenta existuje, měl by existovat důvod spojený s obchodní potřebou, technickým omezením nebo cílem kvality. Tato disciplína brání tomu, aby se návrh propadl do návyků, módy nebo nadějí ve lepší budoucnost.
Proč objevování přichází jako první
Objevování má význam, protože architektura se nestaví na předpokladech. Staví se na známých podnětech. Tým může postupovat rychle pouze tehdy, když sníží neznámé proměnné, které by jinak donutily k přepracovávání.
U systémů AI a cloudu to platí ještě více. Stejná platforma může selhat různými způsoby v závislosti na skutečných potřebách, které za ní stojí. Systém nasazující modely, který musí odpovídat v reálném čase, potřebuje jiný design než dávkový analytický pipeline. Regulovaný datový platforma vyžaduje odlišné kontroly než interní nástroj pro automatizaci. Cloudová aplikace s přísnými očekáváním ohledně uptime potřebuje jinou strukturu než ta, která si může dovolit pauzy.
ADD pomáhá týmům rozlišit tyto rozdíly včas. Poskytuje strukturu procesu, který by jinak mohl působit vágně. Místo vnímání architektury jako sady preferencí ji ADD vnímá jako reakci na konkrétní podněty.
To je také důvod, proč se ADD nejpřirozeněji používá pro zelené louky (greenfield projekty). Když je systém nový, architekturu lze od začátku tvarovat kolem podnětů. Když systém již existuje, jiné metody jsou vhodnější pro posouzení toho, co tam už je, a kde vykazuje nedostatky. Bod je jednoduchý. Různé počáteční body vyžadují různé metody.
Jak ADD funguje v praxi
ADD je iterativní. Nevyrábí celou architekturu najednou. Postupuje krok po kroku, zdokonaluje jednu část systému a poté využívá získané poznatky k tvarování další části.
Praktický způsob, jak číst tuto metodu, je tento: nejprve si zvolte část systému k navržení. Poté identifikujte nejdůležitější architektonické podněty pro tuto část. Poté načrtněte strukturu, která je uspokojí. Následně zaznamenejte, co je stále nevyřešené, a přeneste zbývající obavy do dalšího kola.
Tato metoda je užitečná, protože nutí kompromisy vynést na povrch. Pokud musí systém reagovat rychle, design může zvýhodnit ukládání do mezipaměti, předpočítávání nebo jednodušší hranice služeb. Pokud je bezpečnost hlavním zájmem, design může zvýhodnit silnější izolaci, přísnější kontrolu identit nebo explicitnější pravidla zpracování dat. Jeden design zřídka uspokojí každý cíl stejným způsobem, takže architektura musí dělat volby.
Uvažujme malý příklad. Společnost chce asistenta zákaznické podpory, který využívá AI k navrhování odpovědí z interních dokumentů. Obchodním cílem je snížit prodlevu v odpovědi a zlepšit konzistentnost. Kvalitativní podněty zahrnují bezpečnost, protože dokumenty mohou obsahovat soukromé informace, a dostupnost, protože asistent musí být užitečný během pracovní doby.
Při návrhu ve stylu ADD by tým nezačal náhodným vybíráním nástrojů. Nejprve by se zeptal, jak by se asistent měl chovat pod těmito podněty. To by mohlo vést k designu s kontrolovaným přístupem k dokumentům, vrstvou pro vyhledávání, protokolováním pro revizi a hranicí služby kolem volání modelu. Architektura existuje proto, aby uspokojila podněty, nikoliv proto, aby demonstrovala technický vkus.
Co to znamená pro systémy AI a cloudu
Moderní systémy AI jsou vzácně izolované. Závisí na zdrojích dat, službách modelů, síťových cestách, pravidlech identity a cloudových zdrojích. To dělá architektonické podněty důležitějšími, nikoliv méně. Slabý design může chvíli zůstát skrytý, ale selže, když poroste využití nebo se objeví nová pravidla.
ADD dává vedoucím pracovníkům a architektům jasnější způsob, jak diskutovat o systému před zahájením stavebních prací. Zvyšuje konkrétnost rozhovorů. Místo toho, aby tým řekl, že systém by měl být „škálovatelný” nebo „bezpečný” vágním způsobem, musí říct, jakou škálu, jaké hrozby, jakou latenci a jaké podmínky dat považuje za důležité. To vede k lepším rozhodnutím, protože design je svázán se skutečnými potřebami.
Také to zlepšuje předání informací mezi fází objevování a implementace. Dokument architektonické vize může zaznamenat cílovou strukturu, plán, složení týmu a hranice prací na jednom místě. To dává inženýrům pevnější základ pro plánování výstavby. Také to dává obchodním zájemcům jasnější pohled na to, k čemu je systém navrhován.
Pro EuroOp LLC je to praktické ponaučení. Dobrá architektura začíná fakty, které systém musí splňovat. ADD je cenné, protože činí tyto fakta viditelnými a používá je jako vstup pro návrh. To je druh vzoru, který obstojí v práci s AI, cloudem a podnikovými systémy, kde se cena vágní struktury projeví později a obvykle ve špatný čas.
EuroOp Insights sleduje stejný redakční záměr: jeden aplikovaný vzorec výzkumu a vývoje, jedno praktické ponaučení, vytažené z práce, která stojí za reálnými systémy.