Na začátku své architektonické dráhy jsem strávil nečekaně mnoho času sporem o pořadí čtyř písmen.

Většina metodik celopodnikové architektury dělí IT prostředí do čtyř vrstev: business, aplikace, informace a technologie. Na tom se shodne skoro každý. Spor ale začíná u otázky, v jakém pořadí je procházet. Buď B-A-I-T: byznys určí, jaké aplikace potřebuji, aplikace určí, s jakými daty pracují, a celé to posadím na technologie. Nebo B-I-A-T: byznys nejdřív určí, jaké informace firma potřebuje, a teprve nad nimi se stavějí aplikace.

Vypadá to jako akademická otázka, ale tak úplně akademická není a odpověď na ni může ovlivnit IT plánování na roky dopředu.

Proč jsme tehdy volili BAIT

S kolegy jsme o tom vedli spoustu plamenných diskusí, ale architektonický tým, ve kterém jsem působil, se nakonec shodl na BAIT.

Tehdy to dávalo smysl. BAIT je přímočarý a srozumitelný každému, kdo kdy seděl na poradě s byznysem. Potřebuji novou funkci, tak si pořídím aplikaci, a data si aplikace přinese s sebou. V době velkých monolitů to tak opravdu fungovalo, protože aplikace a její databáze byly jeden celek, který se kupoval, nasazoval a vyměňoval společně. Dá se říct, že informační architekturu jsme prostě odignorovali (a ani nám nijak nechyběla).

Co, jak, kde

Pak jsem měl tu čest zúčastnit se školení, které vedl Clive Finkelstein. V našem oboru mělo jeho jméno velkou váhu (bohužel už není mezi námi). Bývá označován za otce informačního inženýrství, metodiky, kterou začátkem osmdesátých let rozpracoval společně s Jamesem Martinem.

Finkelstein nevycházel z vrstev, ale z otázek. Pokud mám zodpovězeno proč, tedy co byznys potřebuje a z jakého důvodu, je správné pořadí dalších otázek co, jak, kde. „Co“ znamená data, „jak“ procesy a aplikace, které s nimi pracují, a „kde“ technologii, na které to celé běží. Zároveň připomněl, že si to pořadí nevymyslel. Zachmanův framework, jeden z nejstarších rámců celopodnikové architektury, má přesně tyto otázky jako své první tři sloupce: What, How, Where.

Jeho zdůvodnění bylo prosté. Firmy v jednom odvětví se od sebe liší hlavně procesy a aplikacemi, kdežto informace, se kterými pracují, jsou stabilní. Banka bude mít klienta, účet a transakci i za třicet let, telekomunikační operátor zákazníka, službu a fakturu. Aplikace nad nimi se za tu dobu několikrát vymění, ale informační model pod nimi zůstává.

Aplikace jako nájemníci

Od té doby se na to dívám takto: aplikace jsou jako nájemníci. Přijdou, nějakou dobu bydlí a pak se odstěhují. Data jsou dům. Kdo začne plánovat od nájemníků, skončí u Winchesterova domu, o kterém jsem psal minule (viz).

Tuto stabilitu ostatně potvrzují i odvětvové referenční modely. V telekomunikacích je to například informační model TM Forum SID, popis zákazníků, produktů a služeb, který přežil celé generace provozních systémů. Takové modely jsou užitečné ne proto, že by byly dokonalé, ale proto, že vám nemusí nikdo z byznysu vysvětlovat, co je zákazník.

Jenže realita není tak přímočará

Napsat „jednoznačně BIAT“ a tím skončit by bylo příliš jednoduché. První komplikací je SaaS. Když si dnes firma koupí CRM nebo ERP v cloudu, koupí si s ním i jeho datový model. Navrhnout ho nemůže, může se mu nanejvýš přizpůsobit. O informačním modelu tak v praxi často rozhoduje aplikace, a jsme zpátky u BAIT.

Druhou komplikací je moderní vývoj. Svět mikroslužeb a doménově řízeného návrhu záměrně nepracuje s jedním modelem pro celou firmu, ale s menšími, ohraničenými kontexty. Pokusy o jeden dokonalý datový model pro celou organizaci navíc mají pověst projektů, které se nikdy nedokončí.

Můj dnešní postoj je proto střízlivější, než byl hned po tom školení. Model do posledního atributu nepotřebujete. Potřebujete ale jasně pojmenované klíčové informační entity, jejich vlastníky a toky mezi systémy, a k tomu vědomé rozhodnutí, kde se datovému modelu aplikace podřídíte a kde ne. Tím se mimochodem blížíme k myšlenkám, na kterých stojí koncept Data Mesh, ale o tom až jindy.

Proč je to dnes zase důležité

V příspěvku o neuronových sítích (viz) jsem psal, že nejcennější věcí na trhu se nakonec staly váhy, tedy čísla, na kterých modely stojí. Ve firmách to platí podobně. AI agent, který má vyřizovat požadavky zákazníků, nepotřebuje další aplikaci. Potřebuje rozumět tomu, co je zákazník, smlouva a objednávka, a potřebuje, aby tato slova znamenala v celé firmě totéž.

Firmy, které mají informační model v pořádku, mohou s nasazováním AI začít hned. Ostatní budou muset nejdřív uklízet. Stará debata o čtyřech písmenech tak dostává docela praktický rozměr.

Takže BAIT, nebo BIAT? Jsem přesvědčený, že BIAT má být principem a BAIT jen občasným kompromisem, ovšem vždy vědomým. Aplikace si pronajímáte, data vlastníte a architektura by měla začínat u toho, co vlastníte.