To iste podla vyskumov Gavilan Research Associates plati aj o metadatach. Primarna uloha BI/DW projektov (tak isto ako lubovolneho ineho projektu ;) je “dodat” v definovanom case a rozpocte. V takom momente si casto povieme - naco mam robit logicky model, ked mozem nakreslit rovno fyzicky, preco sa tu mam rozpisovat v popisu tabulky, ked aj tak vsetci vedia, ze su tam zostatky na uctoch alebo naco mam pracne vyklikavat transformacie, ked SQL dotazom to urobim na dve doby!!!
Vsetkym tymto situacia a rozhodnutiam rozumiem, ale po par rokoch pouzivania riesenia sa zacnu ukazovat “kazy”. Konkretne sa objavuju v momente ked sa menia ludia, legislativa alebo systemy. V tom momente sa cas a energia usetrena na pociatku obrovskym sposobom negativne zuroci a napr. zmena sposobena patchom zdrojoveho systemu moze trvat mesiace kym sa vyhodnotenia mozne dopady na zavisle systemy, lebo je potrebne prechadzat SQL dotazy, ktorym nikto nerozumie nad tabulami, ktore netusime co znamenaju.
Problemy suviace s metadatami podla cetnosti vyskytu
Systemy alebo aplikacie najviac postihnute problemami s metadatami
Urcite nebudem nikoho presvedcat, ze ma od zajtra vsetko robit cisto a dokumentovat kazdu entitu, na ktoru narazi. Co moze uplne bohate stacit je naucit sa plnohodnotne pouzivat modelovacie nastroje. Vacsina z nich umoznuje automaticke generovanie dokumentacie, ale malokto si da tu pracu. A co je asi najcastejsi moment - nestiha sa jadro projektu a tak na jeho dopracovanie sa pouzije nielen kalkulovana rezerva, ale aj cas kedy sa malo dokumentovat a testovat t.j. myslite na metadata pri tvorbe projektoveho planu nech mozete za sebou nechat dielo, ktore moze zit dlhy a zdravy zivot.
BTW kedy ste boli naposledy u zubara? (^_^)
Peter Hora (Semanta)
Žádné komentáře:
Okomentovat