Před časem jsme pro jednoho z našich zákazníků uspořádali workshop jako úvod do nepříliš populárního oboru označovaného „BI Governance“. Volně přeloženo do systému interních procesů pro provoz a průběžný rozvoj datového skladu, jako je změnové řízení, konfigurační řízení, release management a další. Mluvili jsme o potřebě atomické architektury, která rozdělí celý datový sklad na nejmenší stavební kostičky, bavili jsme se o verzování těchto kostiček, rozebírali jsme způsoby jejich nasazování na různá produkční a neprodukční prostředí, o testování, zamykání částí systému s probíhajícími změnami atd. Odborníci na straně zákazníka pokyvovali hlavou, souhlasili i nesouhlasili, dotazovali se, plánovali další kroky. Shodli jsme se, že klíčovým z těchto kroků bude přesvědčit širší publikum v dané organizaci, že BI Governance je opravdu potřeba, a tak jim znovu a možná přístupnější formou znovu vysvětlit, o čem se to vlastně bavíme.
Analogie jsou vždy nepřesné a zavádějící. Přesto neodolám a jednu si vypůjčím: provoz a rozvoj datového skladu (a vlastně jakéhokoliv robustního SW systému) si můžeme představit jako hodně zvláštní vytrvalostní a tak trochu štafetový závod. Jako doping je povolena pouze dobrá káva, klidně si jednu dopřejte, než se dáte do čtení.
Pravidla jsou docela jednoduchá. Našimi závodníky budou základní (až bychom řekli „atomické“) prvky SW systému (pro jednoduchost si u DWH představme třeba jednotlivé SQL skripty). Všem těmto prvkům přiřadíme něco jako startovní číslo, pokud prvek změníte nebo přidáte nový, přiřadíme mu nové startovní číslo. Kdo nemá startovní číslo, nezávodí a není součástí systému, může to být maximálně divák podél trati nebo pořadatel (a je opravdu potřeba dávat dobrý pozor, aby se diváci a pořadatelé nepřipletli mezi závodníky). Změny ve „startovní listině“ je možné provádět jenom na něčí formální žádost, a to tak, aby ke každé (řádně označené a očíslované) žádosti bylo možné přiřadit konkrétní změny ve startovních číslech. To je sice pro všechny závodní týmy poměrně administrativně náročné a neoblíbené, ale na oplátku jim můžeme povolit dělat změny hodně často (tj. nejen před novým ročníkem závodu nebo jen před novou etapou, ale třeba v rámci každého kola a v případě havárií a technických problémů výjimečně vlastně kdykoliv). To je celé, závod může vyrazit.
Ve skutečnosti to bude ještě trochu složitější, protože závod se pojede zároveň také na několika testovacích okruzích, kde budou promícháni naklonovaní závodníci z hlavního pole (z nějakého důvodu mu říkáme „produkční“) s vylepšenými klony některých svých kolegů a novými posilami. Tyto vylepšené a nové posily musí nejprve projít všemi testovacími okruhy, než se stanou součástí toho hlavního a opravdového závodu.
Dalším specifikem je, že to vlastně není závod, nejde o vítězství – jde o to, aby systém držel pohromadě a jako celek fungoval ke všeobecné spokojenosti. Podobně jako u Tour de France, Formule 1, Rallye Dakkar, Ski Classics a dalších podobných „létajících cirkusů“ je u datového skladu naprosto klíčové, aby podívaná nepřetržitě běžela dál – sponzoři už utratili neuvěřitelné peníze a hodlají pumpovat další sumy), sledovanost je vysoká, na celý podnik je navázáno mnoho partnerů, odběratelů i dodavatelů a opravdu nikdo nechce každé ráno poslouchat „už to zase nejede“…
Jak to tedy celé zařídit (a uřídit)? V případě těch slavných závodů nevím, v případě datových skladů trochu tuším. V první řadě je to Architektura – musí umožnit dekompozici systému na atomické jednotky (naše závodníky), čím elementárnější, tím lépe. Architektura se ale nemůže zabývat každým atomem, bude definovat jen základní stavební bloky a z nich vyplynou kategorie, do kterých atomy budou patřit. Těch stavebních bloků by mělo být spíš méně než více. Typickými stavebními bloky datového skladu tak typicky jsou datové objekty (tj. většinou databázové tabulky nebo datové soubory) a jejich datové elementy (tj. typicky sloupce v tabulkách), potom datové transformace (tj. třeba SQL scripty nebo jejich přesně definované útržky) a orchestrační pravidla (tj. instrukce, co se musí zpracovat dříve, co později, co může „běžet“ současně atd.). To je vše, více typových stavebních bloků nepotřebujeme, přestože jednotlivých atomů, tedy přesněji artefaktů, mohou v cílovém řešení být až deseti nebo statisíce. (Pokud by vám nějaký typový stavební blok chyběl, řekněme třeba „kontroly datové kvality“, zkusme jej zařadit pod ten, co už máme – zrovna třeba „datovou transformací“).
Jeden „stavební blok“ jsme ale opomenuli, jsou to Metadata. Metadata jsou úzce svázána s Architekturou, která definuje potřebný metadatový model, ale zároveň bude konkrétní metadatový obsah sám o sobě sadou artefaktů, která systém tvoří. Metadata, ať už popisná (definují sytém) nebo třeba procesní a provozní (v naší analogii nesou informace o průběhu „závodu“, jeho výsledky a mezivýsledky apod.), musí podporovat základní pravidla pro rozvoj systému – tedy evidenci artefaktů, přiřazování „startovních čísel“, evidenci „startovních listin“ na všech prostředích (produkční, testovací…), evidenci všech požadovaných změn a provázání změn na změny ve „startovních číslech“ (verzích) artefaktů.
Pokud máme Architekturu a Metadata, vše ostatní už je jen mechanika, ta záleží na zvolených Nástrojích. Možná se obejdeme bez speciálního nástroje na řízení vlastní architektury (postačíme si s textovou a obrázkovou dokumentací), určitě ale budeme potřebovat nástroj na datové (a metadatové modelování) a řízení obsahu zejména metadat (s Excelem si vystačíme asi jen v začátku a u jednodušších řešení). Ponechám stranou vlastní vývojové prostředí (vývoj vlastních artefaktů a jejich „šablon“). Důležitá bude také volba nástrojů na vlastní správu verzí artefaktů, přípravu nasazovacích balíčků a nástroj na evidenci změnových požadavků a jejich propojení s verzemi artefaktů a metadat.
Tolik tedy k pokusu vysvětlit trochu neobvykle základy BI Governance. Znovu říkám, všechny analogie jsou nepřesné a zjednodušující. Moc ocením, pokud skuteční odborníci na softwarový engineering pošlou kritické komentáře, a stejně tak, pokud se ozvou čtenáři z řad business uživatelů. Naprosto klíčové totiž je, aby si zástupci obou dvou, někdy i hodně polarizovaných táborů, co nejvíce porozuměli.
Autor: Petr Hájek
Information Management Advisor