Artikel

BI architecturen met toekomst?!

In Business Intelligence projecten worden BI omgevingen steeds professioneler vormgegeven. Zo wordt bijvoorbeeld de samenhang van de diverse componenten in een BI architectuur gedefinieerd. Bij veel projecten wordt er bij het ontwerp van de BI architectuur echter te veel nadruk gelegd op de wereld van vandaag en te weinig op die van morgen. De wereld van morgen is echter zeer veranderlijk. Wanneer de BI omgeving zich niet snel genoeg kan aanpassen wordt zij als verouderd gezien en niet meer gebruikt. Weer een duur BI project met oplossingen die na een paar jaar aan de kant worden gezet. TOGAF 9 kan als enterprise architectuur raamwerk handvatten bieden, zodat deze behoeften rondom het aanpassingsvermogen en de toekomstvastheid van BI omgevingen beter vastgelegd en ondersteund kunnen worden.

Waarom BI en TOGAF?

Te weinig BI projecten vinden plaats in een afgewogen context met de juiste bepaling van hun plek in de enterprise architectuur (EA) van een organisatie. Het vakgebied enterprise architectuur maakt veel gebruik van principes uit de bouwkundige architectuur; zo sprak de architect Saarinen de volgende woorden uit: “Always design a thing by considering it in its next larger context - a chair in a room, a house in an environment, an environment in a city plan.” [1]

Een enterprise architectuur raamwerk als TOGAF 9 staat daarbij bekend om zijn goede procesuitwerking, bouwsteengedachte, herbruikbaarheid, cyclische benadering en open architectuur. Laat dat nu precies de aspecten zijn waar meer aandacht aan besteed moet worden bij de analyse en ontwerp van de BI architectuur. De grotere context van een BI architectuur waar je dus rekening mee moet houden, is dus de enterprise architectuur.

Indien je hier geen rekening mee houdt dan is de kans aanwezig dat de ontworpen BI architectuur na een jaar al flink aangepast moet worden. Wanneer je namelijk niet bewust analyseert wat de plaats is van de BI omgeving in zijn grotere geheel, is de kans groot dat je belangrijke afhankelijkheden met andere omgevingen en systemen over het hoofd ziet. Daarnaast zijn er vaak al processen en systemen die een soortgelijke functionele behoefte ondersteunen welke ook gevraagd is voor de BI omgeving.

Neem bijvoorbeeld een CRM systeem waarin alle klantcontacten en -belevingen worden verzameld en men een proces heeft ingericht om gemakkelijk en op uniforme wijze bronnen van relevante klantdata aan te sluiten. Gelijktijdig is er een BI omgeving waar dan nog steeds elke unieke bron van relevante data wordt ontsloten, bewerkt en geladen met behulp van een bron specifieke ETL code . Deze bronnen van data worden in de BI omgeving als unieke gevallen behandeld en krijgen zodoende een volledig stuk maatwerk software om te ontsluiten voor analyse en rapportage. Dit laatste heeft als nadeel dat elke aanpassing in de bron of mogelijk nieuwe rapportagebehoefte, een complexe en lange zoektocht vraagt naar de onderdelen die aangepast moeten worden. De doorvoering van de gewenste aanpassing zal dus veel meer tijd en inspanning kosten dan wanneer een soortgelijk geval zou plaatsvinden bij het CRM systeem. “Hadden we nu maar goed gekeken hoe men dat bij de CRM omgeving doet, dan waren deze aanpassingen snel een gecontroleerd doorgevoerd.”

Wat is een BI architectuur?

Een business intelligence architectuur is een raamwerk voor het organiseren van de gegevens, informatiemanagement en technologische componenten die worden gebruikt om business intelligence (BI) systemen te bouwen voor de rapportage en data-analyse. De onderliggende BI architectuur speelt een belangrijke rol in business intelligence projecten en is het fundament voor een BI oplossing.

Focus van veel BI projecten

Er zijn bij BI projecten omstandigheden die leiden tot een minimale aandacht voor de BI architectuur en de plaatsing hiervan in de toekomstige enterprise architectuur. Deze omstandigheden zijn:

  1. BI projecten vinden vaak geïsoleerd plaats, d.w.z. dat de te bouwen oplossing(en) die uit de BI projecten voortkomen onvoldoende rekening houden met de bestaande enterprise architectuur.
  2. Architectuurkeuzes zijn vaak te technologie gedreven en niet zozeer business gedreven.
  3. Er is veel tijdsdruk, waardoor er weinig over de flexibiliteit en toekomstvastheid van de BI architectuur wordt nagedacht.

Bij BI projecten zal er geen nieuwe enterprise architectuur ontworpen worden, maar zal er wel rekening mee gehouden moeten worden (of die nou goed is vastgelegd of niet). De BI architectuur is onderdeel van een geheel, dit geheel is de enterprise architectuur. Deze enterprise architectuur bevat alle systemen en processen die de fundamentele operationele en functionele behoeften van een organisatie ondersteunen. Deze ‘andere’ processen en systemen ondersteunen vaak gelijksoortige behoeften en daarvan kan je dus leren om je eigen BI architectuur slimmer in te richten.

Indien de enterprise architectuur er niet is en er ook geen overzicht van de diverse componenten (o.a. systemen en processen) is, dan zul je die componenten en samenhang in kaart moeten brengen. Nu gaat het bij dit in kaart brengen van de high level enterprise architectuur niet om de details of een grote nauwkeurigheid. Het gaat om inzicht krijgen in de belangrijkste business processen, gerelateerd aan de strategische doelstellingen van de organisatie, en de belangrijkste gegevensstromen en -objecten die de besturing van die processen ondersteunen.

Als we verder kijken naar de kenmerken van BI projecten, dan beginnen deze allemaal met een business- en informatieanalyse. De diverse business vertegenwoordigers en stakeholders worden gevraagd wat de nieuwe of aangepaste informatiebehoeften zijn. Daarnaast kan het business model van het bedrijf gewijzigd zijn; men transformeert bijvoorbeeld van een productiebedrijf naar een consumentenbedrijf of men moet transparanter gaan rapporteren. Vaak is er ook een behoefte om uitgebreidere analyses te doen; waar eerst een maandrapport per land voldoende was, moet men nu per dag reageren op verkooptransacties die plaatsvinden in een specifieke stad of zelfs wijk. Dit alles om sneller te kunnen reageren dan de concurrent of sneller met de klant in contact te komen en mogelijk meer wensen of belevingen te kunnen vastleggen. Al deze business drivers worden vastgelegd en hebben vaak een directe of afgeleide relatie met de strategische doelstellingen van een organisatie en zodoende ook met de enterprise architectuur.

Wat verstaat TOGAF onder architectuur?

TOGAF definieert architectuur als de fundamentele organisatie van een systeem, uitgedrukt in zijn componenten, hun relaties tot elkaar en de omgeving, en de principes die het ontwerp en de evolutie daarvan bepalen.

TOGAF gebruikt deze definitie als basis en breidt deze verder uit. In TOGAF heeft ‘architectuur’ twee betekenissen, afhankelijk van de context:

  • Een formele beschrijving van een systeem, of een gedetailleerde weegave van het systeem op componentniveau, ten behoeve van de begeleiding van de implementatie.
  • De structuur van componenten, hun onderlinge relaties, en de principes en richtlijnen die het ontwerp en de evolutie daarvan in de tijd besturen.

De architectuurlagen die in TOGAF onderkend worden zijn: Business architectuur, Data-architectuur, Applicatiearchitectuur en Technologiearchitectuur. Het belangrijkste verschil tussen de vier lagen hangt samen met de focus die ze hebben en dat is redelijk duidelijk als je naar de namen kijkt. In tabel 1 zijn kort de belangrijkste kenmerken van deze architectuurlagen beschreven.

De business architectuur omvat een beschrijving van de zakelijke doelstellingen van een bedrijf, en de overkoepelende structuur die ervoor moet zorgen dat deze doelstellingen bereikt zullen worden. Deze structuur omvat onder andere de bedrijfsorganisatie, bedrijfsprocessen, en de eisen voor de informatiesystemen die nodig zijn om het bedrijf optimaal te laten fungeren. De data-architectuur is een onderdeel van de enterprise architectuur, en geeft een overzicht van de aanwezige en benodigde gegevens in een organisatie. De data-architectuur wordt bepaald door middel van analyse van de informatiebehoeften van een organisatie en wordt weergegeven met behulp van diverse modellen en technieken.
De applicatiearchitectuur beschrijft de samenhang van applicaties en informatiesystemen binnen een organisatie. Het is een modelmatige beschrijving van het applicatielandschap, de daadwerkelijk in productie zijnde systemen. De technologiearchitectuur relateert de applicatie componenten zoals gedefinieerd in de applicatiearchitectuur aan de technologie componenten. Deze vertegenwoordigen software en hardware componenten.

Tabel 1: Architectuurlagen TOGAF

Voorbeeld van Business architectuur en BI

Neem als voorbeeld een organisatie die als strategische doelstelling heeft om zich expliciet te gaan richten op de consument om zo de product- en merkbeleving binnen vijf jaar naar een hoger niveau te brengen. De organisatie zal alles in het werk stellen om deze doelstelling te halen, zowel op het vlak van consumentencommunicatie – klachten, customer service, vergelijkingssites, social media - als op procesmatig vlak. Denk hierbij aan sneller innovatieve producten produceren die beter aansluiten bij de verwachtingen en behoeften van de consument. De organisatie zal dus op een breed vlak de organisatie en zijn processen moeten aanpassen om deze doelstelling te kunnen halen.

Dit gehele pakket van doelstellingen, besturing, organisatie en primaire organisatieprocessen leg je in de business architectuur vast. Vervolgens moet je de data-architectuur vastleggen: welke data is nodig om de besturing en ondersteuning van de primaire processen te ondersteunen? Datzelfde traject herhaal je bij de vastlegging van de applicatiearchitectuur en technologiearchitectuur.

BI ondersteunt hierbij vooral de besturing van de organisatie. Binnen de aan te passen enterprise architectuur neemt BI vooral de aggregatie, verrijking en rapportage van de gestandaardiseerde datastructuren vanuit diverse bronnen voor zijn rekening. BI beantwoordt de vragen over de gezondheid van een organisatie en die antwoorden komen (na aggregatie en verrijking) vooral uit operationele transactiesystemen (bijvoorbeeld reserveringssystemen bij KLM of online sales systemen bij Dell).

We hebben nu kort de TOGAF architectuurlagen en de focus van BI projecten behandeld. Het wordt tijd om te kijken naar een ander element dat in beide raamwerken voorkomt, maar waar anders mee wordt omgegaan.

Niet-functionele behoeften

Er zijn bij BI projecten behoeften die niet veel met de functionele of rapportage wensen van doen hebben. Dit zijn de niet-functionele behoeften. Vanuit Business Intelligence is de analyse en vastlegging van niet-functionele behoeften vaak een ondergeschoven kindje. Waarschijnlijk komt dat omdat het beeld bestaat dat er altijd analyse- en rapportageoplossingen ‘bovenop’ een soort data warehouse moet komen. Het gaat immers om de inhoud: het beschikbaar stellen van een complete set van data-elementen die de rapportagevragen van nu en in de nabije toekomst kunnen beantwoorden.

De niet-functionele behoeften kunnen worden onderverdeeld in twee hoofdcategorieën:

  • Uitvoeringskwaliteiten zoals security, bruikbaarheid en responsetijd, die waarneembaar zijn tijdens run time.
  • Evolutiekwaliteiten zoals toetsbaarheid, onderhoudbaarheid, uitbreidbaarheid en schaalbaarheid.

De eerste categorie wordt bij BI projecten wel vaak goed beschreven, want security is belangrijk: niet iedereen mag zomaar bij de data kunnen. Wat betreft bruikbaarheid moet er een gebruiksvriendelijke user interface zijn en daarnaast moet de response tijd ook goed zijn.

De tweede categorie is precies waar het hier om gaat als we het over het ‘ondergeschoven kindje’ hebben en laat dat nou net één van de kernaspecten van TOGAF zijn. In een artikel over TOGAF legt
Nigel Balchin [2] uit waarom een organisatie TOGAF moet gebruiken als dé methodologie om haar IT visie en architectuur te definiëren. Hij geeft daar een interessant voorbeeld van:

Toen de beroemde architect Christopher Wren de Saint Paul’s Cathedral ontwierp voor Londen in 1673, voorzag hij een monument voor een enkel doel en dat doel zou generaties ongewijzigd blijven. Veel software oplossingen zijn met dezelfde gedachte in het achterhoofd gebouwd en raken overbodig binnen één generatie door één veranderende eis. In tegenstelling tot kathedralen, moeten technologische oplossingen zich aanpassen aan een omgeving waarin er constante verandering plaatsvindt.

Technologische oplossingen moeten dus volgens Balchin meer als ecosystemen fungeren dan als traditionele architecturen. Ecosystemen beschrijven omgevingen die evolueren, wat betekent dat ze klaar zijn voor veranderingen en een balans vinden tussen flexibiliteit, beheerbaarheid en aanpassingsvermogen.

Het organisatie-, data-, applicatie- en technologie landschap van een organisatie verandert in de loop der tijd. Dit is volstrekt normaal en heeft te maken met het feit dat een organisatie in de toekomst ook wil blijven bestaan en succesvol wil zijn. Indien er keuzes worden gemaakt m.b.t. één van deze componenten dan hebben die invloed op de enterprise architectuur

De missie en visie van de organisatie zullen niet zozeer veranderen in de loop der tijd, maar de strategische doelstellingen wel degelijk. Zoals eerder aangegeven moet je daar op voorbereid zijn, door goed na te denken over de noodzakelijke flexibiliteit, beheerbaarheid en aanpassingsvermogen van je enterprise architectuur.

Conclusie

De BI architectuur die geanalyseerd en ontworpen is met behulp van TOGAF 9 als architectuur raamwerk zal beter voorbereid zijn op de toekomst dan een BI architectuur die geen of nauwelijks rekening houdt met de enterprise architectuur van een organisatie.

Bij TOGAF 9 zullen vooral de onderdelen die de business architectuur en de data-architectuur beschrijven, de opdrachtgever, BI architect en business analist helpen bij het goed vastleggen van de behoeften rondom flexibiliteit, beheerbaarheid en aanpassingsvermogen. Deze toepassing van onderdelen van TOGAF 9 zullen de definitie van de niet-functionele behoeften een kwaliteitsimpuls geven, waardoor de opdrachtgever een veel beter beeld krijgt van zijn behoeften en dat ook kan plaatsen in de ondersteunende processen.

De BI architectuur is onderdeel van het ecosysteem ‘enterprise architectuur’ en zodoende afhankelijk van deze overkoepelende omgeving. Het is dus belangrijk om daar bewust rekening mee te houden bij het ontwerp van de BI architectuur.

Categorie:   
Auteur(s)
afbeelding van jorritdejonge
Jorrit de Jonge
QNH Enterprise Intelligence - Senior Business Intelligence Consultant

Jorrit de Jonge is werkzaam als Senior Business Intelligence Consultant bij QNH Enterprise Intelligence.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.