Deze blogpost gaat over een algemene onderschatting van het nut en de noodzaak van metadata in business intelligence omgevingen (nota bene: in mijn definitie van een business intelligence omgeving ga ik er van uit dat er tussen bronnen en rapporten allerlei architectuurcomponenten kunnen bestaat, zoals bijvoorbeeld operationele data stores, data warehouses en/of één of meer datamarts).
Veel organisaties zijn nog niet metadata aware, het onder controle hebben en praktische toepassing van metadata, staat bij hen nog in de kinderschoenen. We hebben het over medio 2011! Ik heb deze post als volgt ingedeeld: eerst beschrijf ik simpele 3-vragenmethode als indicatie van metadata volwassenheid in business intelligence omgeving. Vervolgens beschrijf ik -beknopt- drie ‘must-have’ architectuurcomponenten die in elke business intelligence architectuur aanwezig zouden moeten zijn. Tenslotte rond ik af met het geven van ‘mijn’ 7 tips waarmee metadata management in een business intelligence omgeving significant wordt verbeterd.
DE DRIE VRAGENMETHODE
Heppu metadata voor me?
Met de eerste vraag probeer ik metadata zelf te achterhalen door simpelweg de vraag te stellen: “welke metadata heeft u allemaal voor mij”?. In de regel krijg ik reacties die uiteenlopen van “wat zeur je nou, de gebruikers zijn toch tevreden” ,”dat zit toch in de tools die we gebruiken“, “daar hebben we geen tijd voor gehad, het moest snel” of, erger nog, “wat bedoel je precies?“.Vervolgens begin ik uit te leggen wat ik denk dat metadata is en wat en hoe dit wordt vastgelegd, gegenereerd, kan/moet worden gebruikt. De blikken zijn vervolgens veelzeggend en variëren van: “jij leeft in een ideale wereld (academicus)” tot “jij beschrijft de verre toekomst (de NASA wil ooit naar Mars“). Zucht.
Hoe goed is metadata verankerd in de business intelligence omgeving?
Tekentechniek logische architectuur (Ordina's BI&DWH Architectuur & Infrastructuur Raamwerk).
Met de tweede vraag tracht ik het ontwerp (architectuur) van de business intelligence omgeving c.q. landschap te achterhalen. Idealiter een architectuurontwerp (“blauwdruk”) daar ik een betrouwbare beschrijving wil bemachtigen van hetgeen ooit gepland was. Uiteraard mag hier ook de (nog altijd) gewenste situatie bij zitten. Zo’n ontwerp zou een heldere beschrijving moeten geven van beleid, (ontwerp)principes, richtlijnen, eisen en wensen die ten grondslag liggen aan de door de organisatie gewenste business intelligence omgeving (of landschap). Soms komt het er op neer dat men mij de blauwdruk schuldig moet blijven. “Tja, die zat tussen de oren van de architect/ontwikkelaar/…. en die is helaas vertrokken“. Soms komt men terug met het zoeken naar een naald in een hooiberg verhaal: “zoek eens even in portal x, $hare y of mailbox z“. Soms krijg ik daadwerkelijk een architectuurontwerp in handen, maar dan blijkt -tot mijn teleurstelling- dat metadata in het architectuurontwerp nauwelijks aandacht krijgt. Zowel architectuurdenken als metadata (management) zijn nog steeds zeer ondergewaardeerd. Help.
Waarmee wordt metadata de business intelligence omgeving onderhouden en beheerd?
Met de derde vraag stel ik vast in welke mate er expliciet instrumentarium wordt gebruikt, van home-made tools tot kant-en-klare softwarepakketten, om metadata vast te leggen, te genereren, en te gebruiken. Analoog aan de twee eerste vragen hoop ik op een antwoord waarin een onderscheid wordt gemaakt tussen business metadata, technische metadata en operationele metadata! Business metadata behelst onder meer begrippen en definities, bedrijfsregels, controles, gebruikers en autorisatiematrix, oftewel de gebruikerscontext. Technische metadata behelst onder meer de specificatie en naamgeving van alle objecten in de gehele business intelligence omgeving. Operationele metadata behelst onder meer het bijwerken en het gebruiken van de business intelligence omgeving. Dataverwerking leidt tot audittrail en datalogging, generatie van statistieken, en (operationele) foutafhandeling. Helaas hoor ik zelden wat ik zou willen horen. Soms blijft het stil, soms wordt een handjevol tools genoemd, variërend van BI-/OLAP-tool, ETL-tool, soms een datamodelleertool en heel soms zowaar een metadata management tool. Oef.
DE DRIE ‘VERGETEN’ ARCHITECTUURCOMPONENTEN
In verreweg de meeste business intelligence omgevingen missen drie componenten in de logische architectuur: de Beheerapplicatie, de Metadata repository en de Informatiecatalogus. Deze drie componenten vormen samen het bovenste deel van de bovenstaande architectuurplaat: linksboven staat de beheerapplicatie, midden boven de metadata repository, rechtsboven de informatie catalogus. We lichten de architectuurcomponenten beknopt toe:
De onderwerpen in de informatie catalogus.
De beheerapplicatie is nodig om parameters voor de inrichting, de configuratie en de werking van de business intelligence omgeving te beheren. Dit geldt niet alleen voor de productieomgeving, maar feitelijk voor de gehele OTAP-inrichting (van ontwikkelomgeving tot en met productieomgeving). In de praktijk kom ik zo’n (professionele) beheerapplicatie niet tegen. In plaats hiervan worden parameters in allerlei configuratiebestand geplaatst dicht bij het besturingssysteem of hardcoded opgenomen in allerlei (scheduling)scripts. Afgezien van het feit dat je dan snel omkomt in het aantal bestanden is versiebeheer meestal niet geregeld. Laat staan dat je over metadata rapportages beschikt die je inzicht geven in wie wat wanneer aan parameters heeft gewijzigd (audit trail!) en welk effect dit heeft gehad op de kwaliteit van de verwerking. Zo’n beheerapplicatie legt parameters vast als (meta)data en deze metadata wordt frequent overgenomen in de metadata repository.
De metadata repository, ook wel een metadata warehouse, is deels een fysieke en deels een virtuele omgeving waar alle metadata van de business intelligence omgeving bij elkaar worden gebracht. Alle relevante business metadata, technische metadata en operationele metadata is via de metadata repository te benaderen. Kortgezegd houdt dit in dat met behulp van de metadata repository overzichten beschikbaar zijn van alle objecten, van het moment dat deze zijn aangemaakt tot en met het moment dat objecten zijn gemanipuleerd (geladen, geschoond) en bevraagd. Alle objecten in de business intelligence omgeving zijn gedefinieerd, beschreven, hebben een eigenaar, en zijn te raadplegen/bevragen. Een metadata repository is bij uitstek geschikt voor impactanalyses en biedt niet alleen informatie in separate rapportagevorm, de beschikbare metadata kan ook worden bevraagd vanuit de reguliere eindgebruikersrapporten en via de BI- en OLAP-tools waarmee deze en andere output tot stand komt.
De informatiecatalogus is de rapportage en analyseschil via welke de metadata repository voor eindgebruik beschikbaar wordt gesteld. Eindgebruikers vinden een scala aan metadata rapporten, analyses en dashboards met verversbare informatie over de data-aanlevering vanuit de bronsystemen, de kwaliteit, volledigheid en status van de (periodieke) verwerking, indien van toepassing mogelijke verwerkingsproblemen en als gevolg hiervan optredende uitval. Indien voor aanlevering (bron) en/of ontsluiting (afnemer) afspraken zijn gemaakt en mogelijk normen zijn vastgelegd (SLA!) dan kunnen deze -via de beheerapplicatie- worden vastgelegd en worden meegenomen in te genereren SLA-rapportage of zelfs een SLA-dashboard.
Ondanks het feit dat
- een beheerapplicaties niet meer is dan een aantal simpele schermen (bijvoorbeeld ontwikkeld in APEX, .NET, JAVA) en database tabellen
- een metadata repository voor 75-85% bestaat uit al bestaande onderdelen (namelijk de repositories van de verschillende tools die worden gebruikt, denk aan BI-, OLAP-, ETL-, DBMS-, datamodellering, versiebeheer en schedulingtools) aangevuld met een aantal tabellen voor het generiek vastleggen van niet automatisch verzamelde metadata zoals technische, functionele en plausibiliteitscontroles.
- de informatiecatalogus in principe kan worden gerealiseerd met al in gebruik zijnde BI-/OLAP-tooling. Kortom, beter hergebruik van tooling kun je je niet wensen….
komt het haast niet voor dat deze architectuurcomponenten worden aangetroffen. Bedenk dat we het hier nog niet eens hebben over centrale metadata management tooling die, hoewel soms functioneel wel veel biedt, vaak tamelijk duur is, lange inregel- en inleertijden met zich meebrengt, terwijl een volledig werkende in-house ontwikkelde metadata in een paar weken al staat (dit zou intern goed moeten zijn te verkopen als pilot). We hebben het dus over een beperkte inspanning op een business intelligence omgeving waarvan het jaren duurt alvorens deze is opgebouwd.
MIJN ZEVEN METADATA TIPS
Metadata …
- … is verankerd in een VISIE op data- en informatiemanagement
- … dient te worden opgenomen in de ARCHITECTUUR
- … ontwerp je in harmonie, waarbij ONTWERP/FUNCTIONALITEIT zijn key, niet de tooling
- …, als onderdeel van data/informatie, vereist EIGENAARSCHAP/GOVERNANCE
- … vereist APPLICATIES, INSTRUMENTEN, RAPPORTEN
- … vereist kwalitatief hoogwaardige infrastructuur, SOFTWARE en ONDERSTEUNENDE TOOLING
- … bed je in de ORGANISATIE, de PROCESSEN en de PRODUCTEN in
Rest mij de vraag aan u: hoe volwassen is metadata management in uw organisatie?
REFERENTIES
Voor meer informatie, zie:
- The Business Intelligence Guide
- Learningdatamodeling.com
- Selecting the “Right” metadata to manage, TDAN
- Metadata en master data management, Element61
- The metadata enigma
- David Marco: Advanced Metadata Management
- Align Metadata and Business Initiatives
- De zin en onzin van metadata, Computable
- Meta Data Management
- An Integrative and Uniform Model for Metadata Management in Data Warehousing Environments
- On Metadata Interoperability in Data Warehouses
- Adrienne Tannenbaum, Metadata Solutions: Using Metamodels, Repositories, XML, and Enterprise Portals to Generate Information on Demand
- Generiek A&I-raamwerk bewijst zijn nut, Database Magazine
Foto’s:
Cover: MrB-MMX (Flickr)
Alle informatie op deze blog heeft Martin op persoonlijke titel geplaatst. 'Over Martin' vind je meer informatie via het hoofdmenu bovenaan de pagina.