applied_ai_automation

Dizajn riadený atribútmi tvaruje modernú architektúru AI a cloudu

Where are we now in a modern AI or cloud project? We are usually past the first sale conversation, but not yet ready to build.

Dizajn riadený atribútmi tvaruje modernú architektúru AI a cloudu

Photo: www.kartenetui.info / Wikimedia Commons / CC BY 4.0

Kde sa nachádzame v rámci moderného projektu pre umeleckú inteligenciu (AI) alebo cloud? Zvyčajne už máme za sebou prvú obchodnú konverzáciu, no ešte nie sme pripravení na výstavbu. V tomto bode tím pozná biznis cieľ, ale príliš veľa technických detailov je stále nejasných. Riziko je vysoké, pretože architektúra ešte nebola testovaná voči skutočným požiadavkám systému.

Preto sa práca presunie do fázy objavovania (discovery). Fáza objavovania premieňa širokú myšlienku na architektonickú víziu. Definuje cieľový tvar systému, cestu k nemu, tím potrebný na jeho podporu a vyhlásenie o rozsahu prác (statement of work) pre implementáciu. Jednoducho povedané, odpovedá na jednoduchú otázku: aký typ systému vlastne budujeme a čo musí spĺňať?

Dizajn riadený atribútmi (Attribute Driven Design, ADD) je jednou z najjasnejších ciest, ako túto otázku zodpovedať. Je to metóda navrhovania softvérovej architektúry, ktorá začína dôležitými kvalitami a obmedzeniami systému. Namiesto toho, aby ste najprv odhadovali štruktúru a dúfali, že neskôr zapadne, začína ADD s tými hnacími silami, ktoré sú pre biznis a systém najdôležitejšie.

Tieto hnacie sily pochádzajú z fázy objavovania. Biznis workshop môže priniesť prípadové použitia (use cases) a prácu, ktorú systém musí vykonávať. Workshop príležitostí môže ukázať, prečo systém vôce existuje, napríklad vstup na nový trh, modernizácia produktu alebo zlepšenie času uvedenia na trh. Technické workshopy pridávajú obmedzenia zo strany siete, infraštruktúry, bezpečnosti a integrácie. Workshupy kvality pridávateľ merateľné vlastnosti, ktoré systém musí mať, ako sú dostupnosť, výkon, škálovateľnosť, bezpečnosť a testovateľnosť.

Toto je jadro metódy. Každé rozhodnutie dizajnu by malo viesť späť k jednému alebo viacerým architektonickým hnacím silám. Ak nejaká komponenta existuje, mal by existovať dôvod viazaný na biznis potrebu, technické obmedzenie alebo cieľ kvality. Táto disciplína zabraňuje tomu, aby sa dizajn odklonil do zvyku, módy alebo nádejných predstáv.

Prečo prichádza discovery ako prvá

Discovery má význam, pretože architektúra sa nestavia na základe predpokladov. Stavia sa na známych hnacích silách. Tím môže postupovať rýchlo až po tom, čo znížil neistoty, ktoré by inak nútili k opakovanej práci (rework).

V systémoch AI a cloudu je to ešte dôležitejšie. Tá istá platforma môže zlyhať rôznymi spôsobmi v závislosti od skutočných potrieb, ktoré za ňou stoja. Systém na poskytovanie modelov, ktorý musí odpovedať v reálnom čase, potrebuje inú architektúru ako pipeline pre dávkovú analytiku. Regulovaný dátový platforma potrebuje iné kontroly ako interný nástroj na automatizáciu. Cloudová aplikácia s prísnymi očakávaniami dostupnosti potrebuje inú štruktúru ako tá, ktorá si môže dovoliť pauzy.

ADD pomáha tímom rozlíšiť tieto rozdiely včas. Poskytuje štruktúru procesu, ktorý inak môže pôsobiť vágne. Namiesto toho, aby sa architektúra brala ako sada preferencií, berie ju ako reakciu na konkrétne hnacie sily.

To je tiež dôvod, prečo sa ADD používa prirodzenejšie pri zelených poliach (greenfield work). Keď je systém nový, architektúra môže byť od začiatku tvarovaná okolo hnacích síl. Keď systém už existuje, iné metódy sú lepšie vhodné na posúdenie toho, čo už je tam, a kde má nedostatky. Bod je jednoduchý. Rôzne štartovacie body potrebujú rôzne metódy.

Ako ADD funguje v praxi

ADD je iteratívny. Nevyrába celú architektúru naraz. Pohybuje sa krok za krokom, zdokonaľuje jednu časť systému a potom vyučuje to, čo sa naučil, na tvarovanie ďalšej časti.

Praktický spôsob, ako čítať túto metódu, je tento: najprv vyberte časť systému na dizajn. Potom identifikujte najdôležitejšie architektonické hnacie sily pre túto časť. Potom nakreslite štruktúru, ktorá ich spĺňa. Po tom zaznamenajte, čo je stále neriešené, a preneste zvyšné obavy do ďalšieho kola.

Táto metóda je užitočná, pretože núti kompromisy na povrch. Napríklad, ak musí systém reagovať rýchlo, dizajn môže uprednostniť ukladanie do vyrovnávacej pamäte (caching), predpočítavanie alebo jednoduchšie hranice služieb. Ak je bezpečnosť vedúcim obavy, dizajn môže uprednostniť silnejšiu izoláciu, prísnější kontrolu identity alebo explicitnejšie pravidlá spracúvania dát. Jeden dizajn zriedka spĺňa každý cieľ rovnakým spôsobom, takže architektúra musí robiť voľby.

Zvážme malý príklad. Spoločnosť chce asistenta zákazníckej podpory, ktorý používa AI na návrh odpovedí z interných dokumentov. Biznis cieľom je znížiť oneskorenie odpovede a zlepšiť konzistentnosť. Kvalitné hnacie sily zahŕňajú bezpečnosť, pretože dokumenty môžu obsahovať súkromné informácie, a dostupnosť, pretože asistent musí byť užitočný počas pracovného času.

Pri dizajne v štýle ADD by tím nezačal náhodným výberom nástrojov. Najprv by sa pýtal, ako by sa asistent mal správať pod týmito hnacími silami. To by mohlo viesť k dizajnu s kontrolovaným prístupom k dokumentom, vrstvou na vyhľadávanie, protokolovaním na prehliadku a hranicou služby okolo volania modelu. Architektúra existuje na splnenie hnacích síl, nie na ukazovanie technického vkusu.

Čo to mení pre systémy AI a cloudu

Moderné systémy AI sú zriedka izolované. Závisia na zdrojoch dát, službách modelov, sieťových cestách, pravidlách identity a cloudových zdrojoch. To robí architektonické hnacie sily dôležitejšími, nie menej. Slabý dizajn sa môže chvíľu skrývať, potom zlyhať, keď sa zvýši používanie alebo keď sa objavia nové pravidlá.

ADD dáva lídrom a architektom jasnejší spôsob diskusie o systéme pred tým, než sa začne stavebná práca. Robí konverzáciu konkrétnou. Namiesto toho, aby systém mal byť „škálovateľný“ alebo „bezpečný“ vo vagnom zmysle, musí tím povedať, aká škála, aké hrozby, aké oneskorenie a aké podmienky dát majú význam. To produkuje lepšie rozhodnutia, pretože dizajn je viazaný na skutočné potreby.

Tiež to zlepšuje předávku práce medzi discoverym a implementáciou. Dokument architektonickej vízie môže zaznamenať cieľovú štruktúru, roadmapu, tvar tímu a hranice prác na jednom mieste. To dáva inžinierom pevnejší základ pre plánovanie stavby. Tiež to dáva biznis stakeholderom jasnejší pohľad na to, na čo je systém navrhovaný.

Pre EuroOp LLC je to praktická lekcia. Dobrá architektúra začína faktami, ktoré systém musí spĺňať. ADD je cenný, pretože robí tieto fakty viditeľnými a používa ich ako vstup pre dizajn. Toto je typ vzoru, ktorý vydrží v AI, cloude a enterprise práci, kde sa cena vagnej štruktúry objaví neskôr a zvyčajne v ten najhorší čas.

EuroOp Insights sleduje tú istú editoriálnu myšlienku: jeden aplikovaný vzor výskumu a vývoja, jeden praktický výstup, vychádzajúci z práce, ktorá stojí za skutočnými systémami.

Diskutovať o tejto téme