Stavíte Titanic?

Titanic – dnes oblíbené synonymum pro fatální selhání zdánlivě dokonalé myšlenky. V případě Enterprise Framework, který je sám o sobě jistě správnou ideou, jde především o uvědomění si komplexnosti řešeného problému. Fatální neodhadnutí nákladů a mizivý business přínos jsou u podobných akcí běžným průvodním jevem.

Frameworky znamenají v oblasti informačních technologií sadu podpůrných komponent, struktur, nástrojů a pravidel, které stanovují rámec pro vytváření dalších softwarových aplikací. Framework by ve své podstatě měl pomoci realizovat firemní informační systémy efektivněji. Snížit náklady na realizaci a provoz, definovat a udržet standard kvality a bezpečnosti podnikových aplikací. Má pomoct vyvarovat se opakování vývoje stejných nebo podobných součástí, prohřešků proti bezpečnosti a umožnit businessu rychleji realizovat své záměry. Nicméně praxe bývá často jiná.

O frameworcích v českých podmínkách uvažují především velké společnosti. S trochou nadsázky se dá říct, že jde o takové firmy, kde samotné IT oddělení už tvoří firmu ve firmě. A každý člověk trpí soutěživostí. Bez výjimky téměř každá obdobná firmička ve firmě si řekne, že to, co zvládnou velké softwarové firmy jako Microsoft nebo Sun, to přeci zvládneme taky.

Původní záměr může být samozřejmě i chvályhodný: Zlepšit služby poskytované IT oddělením vůči ostatním částem firmy. A to především v oblasti implementace nových systémů. IT je pod tlakem zapracování nových nutností. Jedno business oddělení vymyslí produkt, s obchodníky rozpracují, jak se bude dále prodávat. K tomu pravidelně potřebují buď úpravu systému, nebo často nový systém.

Obsloužit nový produkt znamená nejen uchovávat nové informace, ale i s nimi nějak pracovat. Zatímco obchod a marketing vymyslí svou část za dva měsíce, IT může prohlásit: Doděláváme minulé požadavky, přijďte za půl roku a za rok bude řešení. Nezřídka kdy dojde následně k výměně IT ředitele. Je neměnnou praxí, že nástupce musí provést změny. Někdy podpoří vznik frameworku, jindy už přijde k hotovému. Zdůvodnění je opět nasnadě a zní navíc velmi přesvědčivě: Není přeci nutné vyvíjet vyvinuté a vždy se postavit na začátek. Většinou je všem jasné, že se to netýká jen softwarových komponent, ale i metodik a infrastruktury. Firma musí postupovat systematicky. Realizace business požadavků do informačních systémů bude mnohem rychlejší.

V čem je tedy problém?

Zlaté české ručičky ovšem v těchto disciplínách nestačí. Pro frameworky nebývá v rámci firmy dost zkušených architektů. To má logicky drtivý dopad na cenu a často i použitelnost frameworků. Protože je iniciátorem frameworku IT oddělení, vzniká nemalé riziko, že technický pohled převládne nad business přínosy. Frameworkové strategie často nemají dobře propracovaný přístup k začlenění „balíkových“ softwarových řešení, které jsou hojně zastoupeny v enterprise IT prostředí.

A cena začne nikoli vzdáleně připomínat ledovec. Zdánlivě jasný prvotní odhad nákladů se za pár let vývoje a používání vyhoupne na několikanásobek. Ne zřídka se stane, že cena za zpracování nové aplikace do firemního informačního systému je v rámci frameworku vyšší, než-li cena aplikace vytvořené externím dodavatelem doslova od nuly. Do podobných ledovců už narazila kariéra nejednoho manažera. Mimo jiné to znamená problematické nalezení a udržení sponzora projektu ve firmě. Pro obchodní část firmy je framework často něco těžko uchopitelného s nejasným přínosem. Zvlášť komplikovaná situace nastává ve chvíli, kdy se z pohledu businessu nedostavují slibované přínosy frameworku, především zrychlení realizace požadavků na nové funkčnosti systému.

Kde je chyba? V drobném detailu: Vývoj frameworku se může pohybovat v rozmezí mnoha měsíců až let. Pokud chce firma obstát v konkurenčním prostředí, musí být dynamická a akceschopná. Je obtížné odhadnout, kde bude z business pohledu za dva, ne-li za pět let. Jaké budou potřeby obchodních, finančních, marketingových oddělení? Právě úroveň business komponent je často kámen úrazu. Úspěšnost realizace business komponent je navíc úměrná schopnosti obchodu definovat své procesy a obchodní strategii.

Logicky by tedy cesta měla být v maximální univerzálnosti frameworků. To s sebou ovšem nese obrovskou daň v nižší uživatelské přívětivosti, složitých konfiguracích. Samotné řešení je následně natolik komplikované, že přesahuje gramotnost běžného uživatele.

Na nepříjemné otázky se obvykle ani nedostane. Z úst managementu obvykle nezazní pro IT specialistu logické dotazy: Co stojí kontinuita? Jaká je běžná fluktuace IT zaměstnanců? Kolik z lidí, kteří pracují na frameworku je klíčových? Jsou nositelem know-how zaměstnanci nebo externí firma?
Naučit se využívat framework totiž není nijak jednoduché a něco to stojí. Pokud firma nedisponuje stabilním týmem lidí, připomíná realizace frameworku paralympiádu. Projekt na jakoukoli novou aplikaci je tak často podfinancovaný. Přišli noví lidé, kteří se musí framework naučit. Rychle musejí absorbovat, co vznikalo ve velkém týmu i rok nebo dva. Úspěch se de facto ve většině případů nedostaví.

Zajímavým problémem u vyčíslení nákladů na framework je způsob vykazování nákladů ve firmách. V případech dodavatelů a externích nákladů je situace jasná. Často zůstávají skryté interní náklady. Nezřídka kdy bývají i nekorektně vyčíslené. Interní náklady se jaksi nepočítají. Kdyby se na vývoj frameworku, údržbu, provoz a implementací nových aplikací korektně vyčíslovaly interní náklady, byla by cena vskutku překvapivá.

Všichni ovšem jdou už jedním směrem - za frameworkem. Často si migrace stávajících aplikací vynucuje další náklady a pozornost businessu. Nezřídka se předělávají aplikace, které by normálně mohly dál pracovat. Nové aplikace se samozřejmě implementují ve frameworku. To znamená, že se vývoj nad samotný framework může stát úzkým hrdlem.

Neúspěch navrženého řešení následně samozřejmě nikdo nepřizná. Špatně se vysvětluje, proč je aplikované řešení dražší a z pohledu businessu neuchopitelné. Obvykle totiž silná část IT managementu podporuje vývoj firemního frameworku. Jak přiznat, že se slibované přínosy nedostavují? Odpověď na otázku, zda-li mají firmy opravdu tak kvalitní kontrolní mechanismy, aby bylo možné reálně vyhodnotit přínos frameworku, je nasnadě. Zvláště, pokud jeho přínosy vyhodnocují ti, kteří framework vyvíjeli.

Framework může být i přínos

Základním předpokladem pro úspěšné řešení otázky vlastního vývoje frameworku je volba té správné technologie. Postup tedy přesně opačný, než je v tuzemsku zvykem. Český trend je spíš v tom, že se technologie vybírá podle profesních dispozic vlastních zaměstnanců. Správné je samozřejmě rozmyslet si, co je technologicky vyhovující. Management firmy musí zvážit, jestli má v IT zkušeného architekta, který má dobré technické zázemí a který je schopný sám o takto kompetentních věcech rozhodovat. Pokud ne, měl by požádat o konzultaci. Je pravděpodobné, že firma zjistí, že zaměstnanci, kterými disponuje, jsou pro projekt vzhledem k vybrané platformě nevhodní. Bude potřeba dále započítat náklady na vytvoření nového týmu.
Druhé pravidlo úspěchu je také veskrze logické a samozřejmé, stejně často ovšem zůstává pouze ve sféře běžné fráze. Jde o prosté zvolení přiměřených cílů. Pokud se zachová rozsah frameworku v realizovatelné míře, tak se dostaví dílčí a adekvátní úspěchy. Varianty, kdy framework má ambice absorbovat řešení obchodních procesů a nabídnout businessu vizuální nástroj, aby si mohli svoje produkty do informačního systému namodelovat, až na nemnohé vyjímky nefungují.

Další vývoj frameworku se musí nějak postavit k aplikacím, které ve frameworku už běží. A zabránit situacím, kdy v souvislosti se změnami ve frameworku stoupá riziko nefunkčnosti již používaných aplikací. Nezřídka je tyto nutné přetestovat. Cena opět roste – náklady na testování šplhají vzhůru. Aplikace totiž fungují úžasně na první verzi frameworku. Za rok po spuštění je ovšem na světě verze dva, která má pravidelně nějaký háček. Průběžná synchronizace verzí používaných aplikací s verzemi frameworků je elementární, ovšem ne vždy využívané pravidlo. Ruku v ruce s tímto aspektem jde i nutnost udržet v rámci IT oddělení stabilní vývojový tým.

Obecně se dá říct, že frameworky se vyplatí, pokud se podaří zachovat kontinuitu, stabilní tým a udržet očekávání na reálné úrovni. V praxi už jde ovšem o neúměrné množství kdyby. Tak jako vývoj vlastního frameworku zkušený odborník obvykle nedoporučí, tak vývoj vlastních IT komponent, standardizace platforem ve firmě jsou samozřejmostí. Často je jednodušší cestou komponenty nakoupit.

Stále si chcete framework pořídit? Máte „framework“, jak jste na tom? Jakou si položit otázku v případě, že si framework chcete pořídit: Dokážete dosáhnout reálného přínosu pro váš business?

Uvědomte si, že ideální enterprise framework zahrnuje potenciálně široké spektrum oblastí – vlastně celou firmu. Měl by reflektovat obchodní plány, vize a strategie, principy řízení, potřeby provozu, organizační struktury, požadavky na automatizaci prostřednictvím informačních systémů a databází.


Autor je Senior Project Manager společnosti Logos.


Ilustrační foto: Twentieth Century Fox