BI analyse en modellering

Het doel van de analyse fase: het verkrijgen van goede specificaties en randvoorwaarden op basis waarvan de benodigde BI en DWH producten kunnen worden ontwikkeld, gebruikt en beheerd. Maar wat zijn goede specificaties en hoe zorgen we er voor dat we met minimale inspanning maximaal rendement halen?  

Enerzijds hebben we te maken met het proces, “het verkrijgen”, anderzijds hebben we te maken met de vastlegging van de analyse resultaten, “de analyse producten”.

De analyse producten beschrijven de gewenste BI en DWH producten. We spreken hier dan ook over metaproducten (meta informatie). 

Dit thema behandelt de uitgangspunten die de standaarden en methoden van de BI analyse fase bepalen:

Uitgangspunt 1: Agile modellering en ontwikkeling

Business intelligence en datawarehouse-ontwikkeling leent zich uitstekend voor een agile methodiek, omdat:

• door samen met de eindgebruiker te ontwerpen én te ontwikkelen het eindproduct beter aansluit bij de initiële en veranderende behoefte,
• ook tijdens het gebruik in de beheerfase de BI producten continue moeten meebewegen met de veranderende eisen en wensen van de organisatie. Dus is het goed een methode te hanteren die we ook in de beheerfase kunnen toepassen, 
• de eindgebruiker betrokken wordt bij, en daardoor ook mede-eigenaar wordt van, gegevenskwaliteit, modellerings- en definitie-issues. (Denk aan onvolledige of onjuiste registraties in de bron),
• methoden en technieken het toelaten om ontwikkelde DWH- en BI- producten continue aan te passen en uit te breiden.

Scott Ambler (http://www.agilemodeling.com/) heeft een model ontwikkeld met de best practises voor agile modelling. Deze gelden ook voor BI-analyse als uitgangspunten voor een goed resultaat. “Participation”, “continuously” en “architecture” zijn hierin de kernwoorden. Ze leiden tot een “single source information”, de registratie van de specificaties.  

Uitgangspunt 2: Metadata gestuurd model

De specificaties moeten leiden tot DWH- en BI- producten die gezamenlijk de eindoplossing (applicatie) vormen. Het proces 'verkrijgen' moet dan ook, voor wat betreft de overdracht van meta-informatie,  zo op de processen 'ontwikkelen', 'beheren' en 'gebruiken' aansluiten, dat deze met minimale inspanning kunnen plaatsvinden. Bij voorkeur ondersteunen we de overdracht van meta-informatie door modellering- en ontwikkeltools. Dit leidt vervolgens tot automatisering van het ontwikkel-/beheerproces en daarmee tot efficiency. 

• beperk beheer last van documentatie;
• verhoog consistentie;
• verhoog eenduidigheid;
• verhoog bruikbaarheid.

De specificaties kunnen ook in het proces 'gebruik' een optimale bijdrage leveren. Namelijk als eindgebruikers worden ondersteund door de meta-informatie bij het lezen en interpreteren van de eindproducten. Denk hierbij aan de definities van indicatoren die op een rapport worden getoond. Als de gebruikte BI-tools dit ondersteunen, kan de gebruiker tijdens het lezen van het rapport eenvoudig de definitie en de wijze van afleiden bekijken. Dit draagt bij aan het begrip en de juistheid van de acties die de gebruiker op basis van de cijfers initieert.

In onderstaand schema staan de verschillende componenten van de DWH- en BI-applicatie.

• Van boven naar beneden staan de diverse stadia van ontwikkeling, van logisch ontwerp naar fysieke objecten. 
• Van links naar rechts zien we de gegevens uit de bronnen die opgenomen worden in het datawarehouse (‘gegevens’ en ‘informatie’) en uiteindelijk leiden tot presentatievormen als rapportages. 

Per stadium, per component is meta-informatie beschikbaar. Deze moet ergens en in enige mate gedurende de verschillende processen beschikbaar zijn. 

In de analyse fase werken we het ontwerp op logisch niveau uit, in de rode componenten. We zien logische gegevensmodellen, transformatieregels (afleidingen, business rules) en de rapportageontwerpen. De analyse producten hebben tot doel:

• acceptatie van het ontwerp door de opdrachtgever;
• input voor het ontwikkelproces;
• uitgangspunt voor het testproces;
• basis voor het beheer proces;
• ondersteuning van het gebruiksproces.

Ook voor het metadata-gestuurde model geldt dat meer niet altijd beter is. Nee: less is more!  Daarnaast zijn de wijze van registratie en de tooling cruciaal voor een optimaal resultaat.

Uitgangspunt 3: Registratie behoefte

Dus voor de agile-aanpak en het metadata-gestuurde model is het van belang dat we in de analysefase alleen die specificaties verzamelen en registreren die direct bedragen aan het ontwikkel- en beheerproces en het begrip (acceptatie en gebruik) van de eindproducten.  

Ook de registratie van deze meta-informatie kunnen we modelleren om te kunnen vaststellen wat de optimale (lees: minimale) registratiebehoefte is.

Onderstaand objecten model is hiervan een weergave: 

Aan de linker (rode) kant staan de business-objecten die een rol spelen bij de analyse: 

• Het 'bedrijfsproces' heeft 'brongegevens' als output. 
• Om het 'bedrijfsproces' te kunnen monitoren/sturen zijn 'rapportages' nodig.

Aan de rechterkant vinden we een metaweergave van de informatie opgenomen in het DWH :

• De 'rapportages' bouwen we op met 'meetwaarden' (indicatoren) afgezet tegen 'dimensies' uit het DWH informatiemodel.
• De 'meetwaarden' (indicatoren) en 'dimensies' worden afgeleid uit de 'brongegevens'.
• De logica om te komen van 'brongegevens' naar 'meetwaarden'/ 'dimensies' noemen we afleidingsregels (business rules).

Dit model kunnen we vereenvoudigen door de objecten weg te halen die geen direct onderwerp zijn voor de DWH / BI analyse. 

• Hoe interessant het bedrijfsproces ook is in het kader van business intelligence, we beschrijven het niet in de BI analysefase. Alleen het feit dat rapportages worden gebruikt in bedrijfsprocessen is vanuit een BI-gezichtspunt vooralsnog van belang.
  Bij organisatie- of procesmodellering, dus bij andere disciplines dan BI,  wordt de relatie tussen de rapportages en de bedrijfsprocessen verder beschreven. Denk aan de interpretatie van de rapportages en de acties die op basis hiervan in het bedrijfsproces uitgezet kunnen worden.   
  
• Ook de bron wordt in principe niet in de BI-analysefase beschreven. Dit is een onderdeel van het ontwikkelproces van de applicatie zelf. Voor BI is het wel van belang te weten welke gegevens nodig zijn om te komen tot het informatiemodel. Ook de betekenis, het waardebereik, de kwaliteit, etc. van de betreffende brongegevens zijn van belang voor het DWH-/BI-ontwerp. 
  Als dit niet afdoende beschreven is in de documentatie van de bronapplicatie zelf, moeten we deze informatie vergaren en beschrijven in de BI-analysefase.

De overige vereenvoudigingen hebben te maken met de wijze waarop en op welk niveau de betreffende meta-informatie minimaal beschreven moet zijn: 

• Zo kunnen we de uitwerking van rapporten in deelrapporten beschrijven bij het betreffende rapport, of deelrapporten worden beschreven als rapporten met een aantekening dat ze bij elkaar horen.
• Ook kunnen we de modellering van meetwaarden en dimensies op vergelijkbare wijze beperken.
• Wel zijn de afleidingsregels zo belangrijk dat we ze als aparte meta-objecten beschrijven moeten worden. Hierdoor worden de beschrijvingen van de meetwaarden en dimensies eenvoudiger en hoeven ze maar één keer te worden beschreven wanneer ze bij meerdere afleidingen betrokken zijn.

Daarmee is het volgende objecten model hetgeen we in de BI-analysefase minimaal moeten beschrijven.   

Uitgangspunt 4: Functionele en niet-functionele specificaties

Naast de functionele specificaties, zoals 'welke meetwaarden op welk rapport afgezet moeten worden tegen welke dimensies',  zijn er ook niet-functionele specificaties. Denk hierbij aan 'de frequentie van rapporten', 'performance-eisen', 'tijdigheid van de rapportage', etc.

Deze niet-functionele eisen gelden over het algemeen voor de gehele DWH-/BI-oplossing. Deze beschrijven we dan ook in de architectuurdocumentatie, onder de noemer kwaliteitseisen.

In de BI-analysefase toetsen we continu of de niet-functionele eisen en wensen van de te realiseren of te wijzigen BI-producten passen binnen deze algemene kwaliteitseisen. Is dat niet het geval, dan moeten we ze analyseren en beschrijven.  Op basis hiervan kunnen we een architectuur change doorvoeren, maar dan geldt het voor de gehele architectuur.  Als de betreffende eisen alleen gelden voor een specifiek object nemen we ze bij de registratie ervan op. Let er in dat geval wel op dat alle onderliggende DWH-objecten en de infrastructuur invulling moeten voldoen aan de betreffende eisen. Zo niet, dan moeten we ook hier een change doorvoeren in ontwerp en fysieke componenten.

Contact

Wilt u meer informatie? Neemt u dan contact met ons op via Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken. of bel met Martin Genuit, tel. +31 (0)6 304 18 297.

Euclides - de juiste beslissing.