Podniková a softwarová architektura: k čemu je plán, který není kód

Architektura je seznam rozhodnutí, která se později mění draze. Proto se vyplatí sepsat je ve chvíli, kdy jsou ještě levná — tedy dřív, než se začne stavět.

Většina firem architekturu má. Jen ji nikdo nenapsal: vznikla sama z desítek malých rozhodnutí, která v dané chvíli dávala smysl. Problém se ukáže až tehdy, když je potřeba vyměnit jeden systém a zjistí se, že na něm nepřímo visí čtyři další.

Dvě úrovně, které se pletou

Podniková architektura odpovídá na otázku, jak firma funguje a které systémy který proces podporují. Mluví jazykem byznysu: objednávka, reklamace, sklad.

Softwarová architektura odpovídá na otázku, jak je postavené konkrétní řešení — z jakých částí, jak spolu komunikují a kde jsou hranice. Mluví jazykem technologie.

Když chybí ta první, vzniká software, který řeší nesprávný problém velmi dobře. Když chybí ta druhá, vzniká řešení, které po roce nejde rozšířit bez přepsání.

Co architektura reálně rozhoduje

• Kde jsou hranice. Co patří do kterého systému a co se nikdy nesmí rozlézt napříč. Hranice, která není napsaná, se do roka rozmaže.
• Kdo vlastní který údaj. Totéž rozhodnutí, které drží integrace při smyslech — ale udělané jednou pro celou firmu, ne zvlášť u každého propojení.
• Co se smí změnit bez dohody. Vnitřek komponenty ano, kontrakt mezi komponentami ne. Bez této hranice se každá změna stává poradou.
• Co zůstane, když se vymění dodavatel. To je otázka, na které se pozná, jestli architektura existuje, nebo se jen kreslila do nabídky.

TOGAF a ArchiMate — a proč na nich záleží

TOGAF je metodika, která popisuje postup: jak zmapovat současný stav, jak popsat cílový a jak naplánovat cestu mezi nimi. ArchiMate je notace — domluvený způsob, jak to nakreslit, aby to znamenalo totéž pro všechny.

Architekturu popisujeme v souladu s TOGAF a modelujeme v ArchiMate. Důvod je praktický, ne formální: výstup v domluvené notaci přečte i jiný dodavatel a i váš vlastní tým za tři roky. Vlastní styl kreslení je srozumitelný přesně do chvíle, kdy je ve firmě jeho autor.

To neznamená, že každý projekt potřebuje plný formální model. U malého řešení je přiměřeným výstupem několik stran a jeden diagram. Metodika říká, na co nezapomenout — ne kolik papíru vyrobit.

Kdy se architektura vyplatí

Ne vždy. U první verze produktu, který teprve hledá tvar, je podrobná architektura brzdou — rozhodnutí se dělají na základě domněnek, které se za měsíc ukážou jako mylné.

Vyplatí se tehdy, když je ve hře aspoň jedno z tohoto:

• Systémů je víc než pár a navzájem si předávají data.
• Plánuje se výměna nebo migrace něčeho, na čem běží provoz.
• Na řešení bude pracovat více týmů nebo více dodavatelů.
• Rozhodnutí je těžko vratné — výběr platformy, datového modelu, způsobu integrace.

Jak to děláme

Začneme současným stavem, ne cílovým. Zmapujeme, co běží, kdo to používá a kudy tečou data — včetně toho, co se řeší ručně a v oficiální dokumentaci nikde není. Teprve pak má smysl bavit se o cíli.

Z rozdílu mezi dnešním a cílovým stavem vznikne posloupnost kroků seřazená podle dopadu a rizika, aby se dalo začít tím, co přinese nejvíc a pokazí nejmíň. Rozhodnutí s důsledkem zapisujeme i s tím, co jsme zamítli a proč — právě to je část, kterou za rok někdo v dobré víře zruší, pokud není napsaná.

Pokud zvažujete větší změnu a chcete na ni nejdřív nezávislý pohled, ozvěte se. Architektonický review umíme udělat i bez toho, abychom následnou realizaci dělali my — víc na stránce služeb.