Podniková a softvérová architektúra: na čo je dobrý plán, ktorý nie je kód

Architektúra je zoznam rozhodnutí, ktoré sa neskôr menia draho. Preto sa oplatí spísať ich vtedy, keď sú ešte lacné — teda pred tým, než sa začne stavať.

Väčšina firiem architektúru má. Len ju nikto nenapísal: vznikla sama z desiatok malých rozhodnutí, ktoré v danej chvíli dávali zmysel. Problém sa ukáže až vtedy, keď treba vymeniť jeden systém a zistí sa, že na ňom nepriamo visia štyri ďalšie.

Dve úrovne, ktoré sa pletú

Podniková architektúra odpovedá na otázku, ako firma funguje a ktoré systémy ktorý proces podporujú. Hovorí jazykom biznisu: objednávka, reklamácia, sklad.

Softvérová architektúra odpovedá na otázku, ako je postavené konkrétne riešenie — z akých častí, ako spolu komunikujú a kde sú hranice. Hovorí jazykom technológie.

Keď chýba tá prvá, vzniká softvér, ktorý rieši nesprávny problém veľmi dobre. Keď chýba tá druhá, vzniká riešenie, ktoré sa po roku nedá rozšíriť bez prepísania.

Čo architektúra reálne rozhoduje

• Kde sú hranice. Čo patrí do ktorého systému a čo sa nikdy nesmie rozliezť naprieč. Hranica, ktorá nie je napísaná, sa do roka rozmaže.
• Kto vlastní ktorý údaj. To isté rozhodnutie, ktoré drží integrácie pri zmysloch — ale urobené raz pre celú firmu, nie zvlášť pri každom prepojení.
• Čo sa smie zmeniť bez dohody. Vnútro komponentu áno, kontrakt medzi komponentmi nie. Bez tejto hranice sa každá zmena stáva poradou.
• Čo zostane, keď sa vymení dodávateľ. Toto je otázka, na ktorej sa pozná, či architektúra existuje, alebo sa len kreslila do ponuky.

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

TOGAF je metodika, ktorá popisuje postup: ako zmapovať súčasný stav, ako opísať cieľový a ako naplánovať cestu medzi nimi. ArchiMate je notácia — dohodnutý spôsob, ako to nakresliť, aby to znamenalo to isté pre všetkých.

Architektúru popisujeme v súlade s TOGAF a modelujeme v ArchiMate. Dôvod je praktický, nie formálny: výstup v dohodnutej notácii vie prečítať aj iný dodávateľ a aj váš vlastný tím o tri roky. Vlastný štýl kreslenia je zrozumiteľný presne dovtedy, kým je vo firme jeho autor.

To neznamená, že každý projekt potrebuje plný formálny model. Pri malom riešení je primeraným výstupom niekoľko strán a jeden diagram. Metodika hovorí, na čo nezabudnúť — nie koľko papiera vyrobiť.

Kedy sa architektúra oplatí

Nie vždy. Pri prvej verzii produktu, ktorý ešte hľadá tvar, je podrobná architektúra brzdou — rozhodnutia sa robia na základe domnienok, ktoré sa o mesiac ukážu ako nesprávne.

Oplatí sa vtedy, keď je v hre aspoň jedno z tohto:

• Systémov je viac než pár a navzájom si odovzdávajú dáta.
• Plánuje sa výmena alebo migrácia niečoho, na čom beží prevádzka.
• Na riešení bude pracovať viac tímov alebo viac dodávateľov.
• Rozhodnutie je ťažko vratné — výber platformy, dátového modelu, spôsobu integrácie.

Ako to robíme

Začneme súčasným stavom, nie cieľovým. Zmapujeme, čo beží, kto to používa a kadiaľ tečú dáta — vrátane toho, čo sa rieši ručne a v oficiálnej dokumentácii nikde nie je. Až potom má zmysel baviť sa o cieli.

Z rozdielu medzi dnešným a cieľovým stavom vznikne postupnosť krokov zoradená podľa dopadu a rizika, aby sa dalo začať tým, čo prinesie najviac a pokazí najmenej. Rozhodnutia s dôsledkom zapisujeme aj s tým, čo sme zamietli a prečo — práve to je časť, ktorú o rok niekto v dobrej viere zruší, ak nie je napísaná.

Ak zvažujete väčšiu zmenu a chcete na ňu najprv nezávislý pohľad, ozvite sa. Architektonický review vieme urobiť aj bez toho, aby sme následnú realizáciu robili my — viac na stránke služieb.