Väčšie IT systémy v bankovníctve, poisťovníctve či verejnej správe už dávno nie sú jeden monolit. Typicky ide o mobilnú aplikáciu, portál, desiatky mikroservisov, integračnú platformu a dátové systémy, ku ktorým sa ešte pridáva napojenie na externé služby tretích strán. A čo je podstatné – málokedy to celé stavia jeden dodávateľ. O jednotlivé časti sa zvyčajne stará niekoľko špecializovaných tímov alebo firiem, pričom každý zodpovedá za svoj kus.
Riadiť takýto projekt je niečo úplne iné než viesť vývoj jednej aplikácie. Ak chýba dobrá organizácia, projekt sa skôr či neskôr zasekne – na koordinácii, na integráciách alebo na tom, že nikto presne nevie, kto má daný problém vyriešiť.
Prečo je to s viacerými dodávateľmi ťažšie
Každý dodávateľ si prináša vlastný tím, vlastný spôsob práce aj vlastné priority. Dôsledok? Jednotlivé časti systému nevznikajú synchrónne. Celkom bežne sa stane, že mobilná appka je hotová skôr než backend, ktorý potrebuje na to, aby vôbec fungovala.
K tomu sa pridávajú závislosti, ktorých je v takýchto systémoch neúrekom. Mobil volá API mikroservisov, portál sa opiera o integračnú vrstvu, mikroservisy zdieľajú spoločné dátové modely. Keď sa tieto väzby neriešia systematicky, stačí málo a vývoj sa zablokuje.
A napokon je tu otázka zodpovednosti. Keď niečo nefunguje, spustí sa hľadanie vinníka: je chyba v mobile, v integračnej vrstve, alebo až v backendovej službe? Bez jasnej architektúry a dohodnutých integračných pravidiel sa aj banálny problém rieši zbytočne dlho.
Všetko stojí a padá na architektúre
Prvá vec, ktorá musí byť jasná ešte pred písaním kódu, je architektúra celého systému. Nie je to formalita do dokumentácie – je to spoločný jazyk, vďaka ktorému každý dodávateľ stavia svoj komponent tak, aby zapadol do zvyšku. Dobrá architektúra popisuje, ako sú navrhnuté mikroservisy, akými mechanizmami sa systémy integrujú, aké platia API štandardy, ako vyzerajú dátové modely a ako je riešená bezpečnosť.
Súčasťou tejto úvahy je aj rozhodnutie, kde bude komunikácia medzi systémami sústredená. Vo väčších riešeniach sa oplatí mať centrálnu integračnú vrstvu – typicky s API gateway, integračnými mikroservismi, transformačnou logikou a bezpečnostnými mechanizmami. Namiesto toho, aby sa každý systém integroval s každým priamo a vzniklo klbko závislostí, ktoré nikto nerozmotá, prechádza komunikácia cez jedno miesto. Keď máte toto podchytené, dodávatelia nepracujú každý na svojom ostrove, ale na kompatibilných častiach jedného celku.
API kontrakty ako spoločná dohoda
Asi najdôležitejším koordinačným nástrojom sú API kontrakty. Kontrakt presne hovorí, ako endpoint vyzerá – aké má vstupy a výstupy, aké dátové modely používa, čo vráti pri chybe a ako funguje autentifikácia. Jeho hlavná výhoda je v tom, že keď sa dohodne vopred, tímy môžu vyvíjať paralelne. Frontend nemusí čakať na hotový backend, lebo presne vie, čo od neho môže očakávať.
Mockovanie a PoC moduly
S API kontraktmi úzko súvisí mockovanie. Mock backend napodobní správanie reálnej služby a umožní vyvíjať frontend, testovať integrácie v skorých fázach a simulovať rôzne scenáre – vrátane tých, ktoré sa v reálnom systéme ťažko vyvolávajú. Tímy tak môžu bežať súbežne, bez toho, aby jeden čakal na druhého.
Ešte o krok ďalej idú mock moduly, ktoré spoja mock backend, zjednodušený frontend a základnú integračnú logiku do jedného malého celku. Slúžia ako proof of concept navrhnutej architektúry: overíte na nich integračný model, odhalíte riziká a otestujete komunikáciu medzi komponentmi skôr, než sa naplno rozbehne vývoj. Chyba, ktorú takto zachytíte v PoC, pritom stojí zlomok toho, čo by stála o pol roka neskôr.
DevOps a spoločné prostredia
Žiadny multi-vendor projekt sa dnes nezaobíde bez poriadnej automatizácie. CI/CD pipeline, automatizované testy, artefaktové repozitáre a kontajnerové registre nie sú luxus – sú to veci, ktoré držia konzistentné buildy, umožňujú rýchle nasadzovanie a robia spoluprácu medzi tímami znesiteľnou. Bez nich sa čas topí v manuálnom nasadzovaní a v debatách typu „u mňa to funguje“.
Do rovnakej kategórie patria spoločné prostredia – development, integration, testing a staging. Práve na nich sa dá krok za krokom overovať, či do seba integrácie medzi systémami naozaj zapadajú, skôr než sa čokoľvek dostane k reálnym používateľom.
Ako to vyzerá v praxi
Vezmite si systém pre banku alebo verejnú správu: mobilná aplikácia pre klientov, portál, backendové mikroservisy, integračná platforma a napojenie na externé registre. Na každej z týchto častí môže sedieť iný dodávateľ – jeden robí mobil, druhý portál, tretí integračnú vrstvu, štvrtý backend. Ak celý projekt stojí na jasnej architektúre, dohodnutých API kontraktoch, mock backendoch, PoC moduloch a slušnom DevOps zázemí, všetky tieto tímy môžu pracovať súbežne a navzájom sa neblokovať. Presne o to ide.
Kde to najčastejšie padne
Chyby, ktoré sa v týchto projektoch opakujú, sú takmer vždy tie isté. Integráciami sa niekto začne zaoberať príliš neskoro, keď už je drahé čokoľvek meniť. API nie sú poriadne definované, takže si ich každý vykladá po svojom. Chýba centrálna architektúra a každý dodávateľ tlačí vlastné štandardy. A k tomu absentuje automatizácia. Výsledok býva zakaždým rovnaký – sklz a rastúce náklady.
Záver
Riadiť vývoj komplexného systému s viacerými dodávateľmi je jednoducho ťažšie než dodať jeden produkt a nemá zmysel tváriť sa inak. Rozdiel medzi projektom, ktorý dobehne v termíne, a tým, ktorý sa vlečie, sa väčšinou skrýva v pár veciach: v pevnej architektúre, jasných API kontraktoch, rozumnom využívaní mockov a PoC modulov, modernom DevOps a priebežnom integračnom testovaní. Ak sa na to myslí od prvého dňa, riziko integračných problémov výrazne klesá – a dodávatelia dokážu reálne spolupracovať na jednom celku, nie len fungovať vedľa seba.