Při vývoji a nasazování aplikací typu business intelligence (a to bez ohledu na jejich složitost, počet vrstev, použité nástroje, přítomnost či nepřítomnost relačního či jiného datového skladu a ETL) jsme měli tendenci používat klasický vodopádový přístup. To znamená, že jsme začali pečlivým soupisem požadavků všech uživatelů, navrhli datový model a potřebné výstupy, analyzovali potřebné datové zdroje a navrhli způsob získávání všech potřebných dat. Potom jsme implementovali jednotlivé komponenty (datové i uživatelské), načetli prvotní data, testovali a ověřovali správnost, a teprve poté vše ukázali uživatelům. Ti se pak nestačili divit. Jeden z nich přitom prohlásil: „Kdybych to viděl dřív, býval bych chtěl na začátku něco jiného.“ To byla vcelku klíčová věta, která nás nutila hledat jiné cesty, jež výsledný „produkt“ dostanou ke svému uživateli mnohem rychleji, aby byla možnost provést případné korekce výrazně dříve. To se pak dělaly prototypy, celé řešení se rozdělovalo na menší a menší přírůstky, počítalo se s velkou rezervou na následné úpravy dle požadavků vyplývajících z reálného použití a mnoho dalšího. Stále to však byla snaha o dodržení precizního a předem definovaného postupu, který měl za úkol vést k jednoznačně definovanému cíli, tedy dokonalému BI.

Ale dokonalost sama je v oblasti BI prakticky nedosažitelná. Požadavky se mění, stejně jako zdrojová data a cíle uživatelů, jejichž dosažení má BI pomáhat. Přínosy takto dokonalého řešení pak musíme pečlivě poměřovat s časem a souvisejícími náklady. Ukazuje se, že je možná lepší nabídnout padesát procent funkcionality za pětinové náklady než stoprocentní funkcionalitu za pětinásobek ceny. A současně připouštíme, že nutně nemusíme detailně definovat finální požadovaný stav řešení. Stačí postupovat po velmi malých částech, kdy je každá z těchto částí samostatně použitelná a přináší svým uživatelům konkrétní užitek. Cílem je cesta složená z dílčích kroků. Na její konec vidět nemusíme a nesmíme se trápit tím, že předem nevíme, jak bude ještě dlouhá.

Agilní vývoj

Vývojový cyklus je nutné rapidně zkrátit a skutečně trvat na tom, aby uživatelé dostali své řešení po malých částech, které bude možné okamžitě používat. Jestli budeme tyto části nazývat „sprinty“ (například dle metodiky Scrum) nebo jakkoliv jinak, není podstatné. Důležité je, aby byl do definice obsahu těchto částí i do jejich zprovozňování maximálně zainteresován uživatel či zákazník. Jedině ten je schopen rozhodovat o prioritách dalšího postupu, revidovat průběžný stav a akceptovat výsledek. Ve výsledku by měla být každá realizovaná část reálně použitelná a pro uživatele přínosná a potřebná. Nutné přitom je, aby byla doba a rozsah těchto částí ve dnech či týdnech, nikoliv měsících či letech.

Agilní vedení projektu

Způsob vedení takového projektu přímo ovlivňuje vlastní vývojový cyklus. Nemá smysl plánovat celek, klíčový je plán pouze pro aktuální etapu. Priority se mohou časem měnit, proto musí být možné operativně měnit i plán. A to jak z věcného pohledu, kdy k realizaci vybíráme požadavky dle aktuální potřeby, tak z formálního pohledu, kdy můžeme jednotlivé podpůrné činnosti (například testování či školení) uzpůsobit momentální situaci. Je zřejmé, že takový způsob řízení výrazně snižuje uživatelská rizika, protože kontinuálně zajišťuje, že uživatel neustále dostává to, co skutečně potřebuje, nikoliv jen to, co na začátku formálně požadoval. Navíc lze celou spolupráci v případě nespokojenosti velmi snadno ukončit, přičemž hodnota dodaná dosavadními etapami zůstává. Na druhou stranu, sponzoři zákazníka z takového přístupu nadšení nebývají, protože nemusí být zcela jasná výše celkové investice a současně i cílový stav celého záměru. Jedná se však jen o jiný úhel pohledu, zde je nutné posuzovat návratnost postupné investice, tj. dílčí přínosy každé jednotlivé části, nikoliv celku.

Agilní infrastruktura

Tradiční infrastruktura BI aplikace vypadá nejčastěji takto: datové zdroje, ETL, relační datový sklad, vybraná datová tržiště, reporty, komplexní uživatelský portál a navíc možná další nadstavbové aplikace (třeba mobilní BI). Je zřejmé, že budování takového množství vrstev není moc rychlé a pružné a že taková infrastruktura skutečně vyhovuje spíše vodopádovému přístupu, kdy se postupně buduje jedna vrstva za druhou, a teprve tu poslední nebo předposlední lze předvést uživatelům, kteří v ní budou vnímat nějakou hodnotu. V případě agilního přístupu je však tato tradiční infrastruktura nevhodná. Je nutné pokusit se o její optimalizaci, tedy ideálně snížit počet a složitost všech vrstev. Některá fyzická úložiště dat lze vynechat a pracovat jen s virtuálními, možná se zbytečně netrápit s úplnou optimalizací s ohledem na velikost a dotazovací výkon (vzhledem k dnešním technickým parametrům a možnostem infrastruktury) a přitom všem používat vhodné nástroje, které budování toho nezbytně nutného maximálně zjednoduší či odstíní.

Agilní nástroje

Ideální agilní BI aplikace či nástroj je takový, u kterého tvorba jednoduchého BI výstupu (reportu/dashboardu) včetně napojení na dostupná zdrojová data spolu s vybudováním fyzické nebo virtuální datové vrstvy nezabere v ideálním případě více než třicet minut. Hovoříme zde o tzv. all-in-one nástrojích, které jsou schopné všechny logické vrstvy výsledného řešení pokrýt v jediném uživatelskonávrhovém prostředí. Odpadá zde nutnost integrace více nástrojů pro jednotlivé dílčí vrstvy a současně potřeba specifických znalostí každého takového nástroje. Kompletní proces návrhu a vývoje jedné dílčí části či jednoho výstupu pak může po zaškolení zvládat i sám uživatel (tzv. self-service BI). Samozřejmě se musíme smířit s tím, že naplnění některých požadavků bývá pouhým kompromisem, nicméně právě ona možnost velmi rychlé a v případě potřeby samoobslužné implementace musí vše vyvážit.

Kromě vhodné funkčnosti používaných nástrojů se musíme zamýšlet i nad neméně důležitou škálovatelností. Dimenzování použitých nástrojů v každé etapě celého projektu by mělo být úměrné rozsahu aktuálního používání, a to z pohledu licenčního (počet uživatelů, velikost dat, používané komponenty), tak i z pohledu technického (navýšení výkonu v souvislosti s rostoucím zatížením a objemem zpracovávaných dat). A že musí být možné celé řešení velmi snadno nainstalovat a spravovat, je zcela zřejmé, neboť se jedná o činnosti, jejichž přínos koncový uživatel přímo nepocítí. Je nasnadě, že provoz takového řešení, například formou pronájmu v cloudu, je více než výhodný, byť v našich krajích speciálně pro BI aplikace, kde by únik dat mohl mít fatální důsledky, prozatím ne úplně žádaný.

Agilní zákazník

Zákazník musí agilní přístup sám chtít a musí v dílčích fázích aktivně vystupovat, protože on je ten, který řídí obsah a rozsah celého řešení. Jeho zástupci bývají již součástí vývojového týmu, uživatelé dostávají velmi rychle dílčí výstupy, které testují a ihned reálně používají, nikoliv dávají do šuplíku a jen čekají na další. Samozřejmě musí mít všichni zúčastnění k takové spolupráci dostatečný prostor a musí jí dávat dostatečnou prioritu.

V případě segmentu SMB se agilní přístupy, nebo alespoň některé jejich prvky ukazují jako nanejvýš výhodné. Důvodem je především fakt, že je takto možné za poměrně nízkých nákladů získat konkrétní použitelné řešení, a to navíc za použití nástrojů a technologií, které případný další vývoj a rozvoj umožní vykonávat přímo na straně zákazníka, nezávisle na původním dodavateli. Přesto se tohoto přístupu zákazníci často bojí, protože chtějí mít jistotu, že své peníze nevyhodí a že za ně opravdu získají „pořádný kus“ hodnoty.

Petr Šprungl