Realtime Resource Management met BI 2.0

Faculteit Ingenieurswetenschappen

Realtime Resource Management met BI 2.0 door Project Manager: Olivier Rosseel & Dries Staelens Lead Architect: Ben Abelshausen Research Manager: Brahim Al Farasi & Pieter Marchand Quality Manager: Tom De Meyer

Professor: Prof. Dr. Ir. F. Gielen Begeleider: Dhr. David Matthys

Project voor het vak Software Architecture

Academiejaar 2008–2009

Faculteit Ingenieurswetenschappen

Realtime Resource Management met BI 2.0 door Project Manager: Olivier Rosseel & Dries Staelens Lead Architect: Ben Abelshausen Research Manager: Brahim Al Farasi & Pieter Marchand Quality Manager: Tom De Meyer

Professor: Prof. Dr. Ir. F. Gielen Begeleider: Dhr. David Matthys

Project voor het vak Software Architecture

Academiejaar 2008–2009

INHOUDSOPGAVE

i

Inhoudsopgave 1 Algemene Inleiding

1

2 State Of The Art

3

2.1

2.2

2.3

2.4

Spelers op de markt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.2

Wat is BI? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.3

Commerciële BI software . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.4

Open Source BI software

. . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.1.5

Nichespelers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.1.6

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

Wetenschappelijk Onderzoek . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.2.1

Algemene artikels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.2.2

Artikels omtrent real-time . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.2.3

Artikels omtrent data mining . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.2.4

Conclusies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

Pentaho BI Platform overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

2.3.1

Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

2.3.2

Server-Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

2.3.3

Design Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

2.3.4

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

Pentaho Architectuur overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

2.4.1

Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

2.4.2

Deployment & Integration . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

2.4.3

Pentaho en operationale BI . . . . . . . . . . . . . . . . . . . . . . . . . .

32

2.4.4

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

INHOUDSOPGAVE

2.5

ii

Standard bodies & Professional Organizations . . . . . . . . . . . . . . . . . . . .

35

2.5.1

Standard bodies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

2.5.2

Professional organisations . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

2.5.3

Bronnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

2.6

Mobile BI (2.0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

2.7

Pattenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

3 Vision

43

3.1

Mission Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

3.2

Key Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

3.3

Quality Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

4 Requirements View 4.1

46

Use case scenario’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

4.1.1

Scenario 1: Uitwisselen van event informatie tijdens een interventie . . . .

46

4.1.2

Scenario 2: Behandelen van een oproep en resources bepalen aan de hand van patronen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1.3

4.2

50

Scenario 3: Real-time analyseren van de toestand ter plaatse en geven van online informatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

Quality attribute scenario’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

4.2.1

Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

4.2.2

Performance

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

4.2.3

Modifiability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

5 ADD iteratie 1: Module View

63

6 ADD iteratie 2: Module View

65

6.1

De Centrale Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

6.2

De Interventie Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

7 Infrastructure view

68

7.0.1

Centrale Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

7.0.2

Interventie Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

8 Algemeen besluit

70

ALGEMENE INLEIDING

1

Hoofdstuk 1

Algemene Inleiding In dit project proberen we een software architecture samen te stellen dat volgende zaken met elkaar in verband brengt: • BI 1.0 • BI 2.0 • Resource Management • mobile clients Als leidraad hebben we het project uitgewerkt voor hulpdiensten. De keuze voor dit thema werd in samenspraak met de groep en begeleider vastgelegd. Het laat ons toe om eens wat dieper in te gaan op een boeiend en niet alledaags onderwerp. Nadat een oproep is binnengekomen gaan we resources reserveren en beschikbaar stellen aan een interventie. Dit gebeurt op basis van rules die afkomstig zijn van een BI 1.0 platform. Via BI 2.0 kunnen we dan bijvoorbeeld real-time gegevens verzamelen over de verkeerssituatie en hiermee een gepaste route bepalen voor brandweerwagens. Uiteindelijk worden tijdens de interventie zelf mobile clients en/of GPS clients gebruikt om gericht informatie te registreren, te visualiseren, . . . Ook een bepaalde tactische opstelling van het brandweermateriaal kan beschikbaar gemaakt worden op de mobile clients. We vertrekken in dit project van een uitgebreide SOTA(State Of The Art). Hierbij werden zoveel mogelijk begrippen in kaart gebracht, nodig voor de uitwerking van dit project. Vervolgens stellen we een vision op met bijhorende key features. Het stelt ons in staat om de richting van ons project aan te duiden en vast te leggen.

ALGEMENE INLEIDING

2

Eenmaal de vision in orde is, volgen de requirements. Hierbij werden use cases uitgewerkt. Ook de keuze van de quality attributes kan hier niet ontbreken. De volgende stap is dan het ADD (Attribute Driven Design). We beperken ons hier tot 2 iteraties. Tot slot kunnen we een deployment view weergeven. Het maakt min of meer duidelijk welke devices er ongeveer nodig zijn en waar de software zal draaien. Het voorbeeld van hulpdiensten beperkt ons niet om later resource management toe te passen in een ander domein. Denken we bijvoorbeeld aan een postorderbedrijf die gericht producten/vrachtwagen/. . . ... wil inzetten en lokaliseren op een manier die zo optimaal mogelijk verloopt.

STATE OF THE ART

3

Hoofdstuk 2

State Of The Art 2.1 2.1.1

Spelers op de markt Inleiding

Deze samenvatting heeft als doel om de bestaande aanbieders van BI en in het bijzonder BI 2.0 nader te bekijken. Hierbij hebben we gekozen om een onderscheid te maken tussen enerzijds de aanbieders van commerciële software en anderzijds aanbieders van open source software. Ook worden nog een aantal nichespelers nader bekeken.

Om de lezer een beeld te geven van wat BI eigenlijk inhoudt, wordt daarom eerst een korte uiteenzetting gegeven.

2.1.2

Wat is BI?

Business Inteligence of BI is een verzamelnaam voor alles wat met de behandeling van business data te maken heeft in een organisatie. Dit is dus een ruim begrip welke kan gaan van eenvoudige spreadsheets tot gesofisticeerde analyse- en rapportagetools.

Een eerste groot probleem van BI 1.0 echter is dat - in tegenstelling tot wat de bedoeling was - dit niet toegankelijk is naar het grote publiek toe. Het merendeel van de werknemers in een bedrijf stellen zich tevreden met een eenvoudige spreadsheet om hun data te beheren. Dit is volledig te wijten aan het feit dat BI tools veel te complex zijn voor niet-technisch geschoolde mensen. Zo is het momenteel in veel organisaties de regel dat de BI tools beheerd worden door een select groepje werknemers, meestal met een technische achtergrond.

2.1 Spelers op de markt

4

Een tweede groot probleem van BI 1.0 is dat de data die in een warehouse gestockeerd zit, niet up-to-date genoeg is. Dit heeft als gevolg dat beslissingen veelal te laat worden genomen en soms volledig achterhaald zijn. Het hoeft uiteraard geen betoog dat dit leidt tot inkomstenverlies.

BI 2.0 belooft aan deze grote tekortkomingen tegemoet te komen. Mede dankzij de opkomst van SOA en Web 2.0 kan dit gerealiseerd worden. De belangrijkste vraag luidt nu: waar ligt het verschil tussen BI 1.0 en BI 2.0?

BI 2.0 wil voor iedereen even toegankelijk zijn dankzij een eenvoudige interface die de gebruiker zelf naar believen kan aanpassen (bv: dashboards). Ook wil BI 2.0 tegemoet komen aan de grote vraag om data real time te verwerken. Dit op het even welk moment, op het even welke plaats en op het even welk toestel. Heel concreet wil dit zeggen dat de data van een gebruiker dynamisch en in-process wordt verwerkt met als resultaat een automatische ’decision making’ aan de hand van gebruikerskarakteristieken of heuristieken. Het resultaat is dus onmiddelijk zichtbaar en opvraagbaar wat een grote tijdswinst oplevert en dus ook meer inkomsten.

2.1.3

Commerci¨ ele BI software

We geven hier een bondig overzicht van enkele van de grotere spelers op de markt die commerciële BI en BI 2.0 aanbieden. • http://www.cio.com/article/203900/Nine Business Intelligence Vendors to Watch

• http://www.gartner.com Business Objects en SAP Business Objects is overgenomen door SAP. Business Objects biedt een van de grootste en ruimste keuzes aan BI producten aan. Het wordt door heel wat bedrijven aanzien als de standaard op gebied van BI. Doch hebben ze laatst heel wat problemen gekend bij de upgrade naar de nieuwe XI versie.

BO biedt een waaier aan BI producten aan. Deze gaan van de installatie en onderhoud van BI te vereenvoudigen over tools voor het maken van beslissingen aan de hand van betrouwbare


5

en up-to-date informatie tot het op een eenvoudige manier presenteren, delen en toegankelijk maken van business data.

SAP van zijn kant beweert dat het al meer dan 13000 NetWeaver BI deployments heeft verricht. Hun BI Accelerator welke gebruik maakt van in-line analyse en column-based vectoring zet heel wat druk op de andere grote aanbieders van BI platform toepassingen. Dankzij de aankoop van BO is SAP nu de grootste BI platform aanbieder op de markt. De zwaktes van SAP BI worden aangevuld met de sterktes van BO vooral op gebied van ’formatted reporting’ en ’self-service report creation’.

Het nadeel volgens Gartner is dat zo’n integratie veel tijd in beslag zal nemen en dit kan op korte termijn zijn invloed hebben op de kwaliteit van de afgeleverde producten. Volgens een rondvraag in opdracht van Gartner zijn de klanten van SAP het minst te spreken over de mindere functionaliteit en moeilijkere implementatie.

• http://www.businessobjects.com • http://www.sap.com/index.epx Cognos Cognos is overgenomen door IBM. Dit heeft als gevolg dat Cognos veel sterker zal worden bij bedrijven die IBM software gebruiken. Denk maar aan Websphere. Een rapport van Gartner zegt wel dat Cognos relatief zwak scoort wat analyse en datamining tools betreft. Ook moet er iets gedaan worden aan de performantie van hun queries.

Net als bij BO en SAP is de diversiteit van de aangeboden BI tools vrij groot. Enkele voorbeelden van tools zijn: een continue opvolging van tijdsgevoelige key performance indicator (KPIs) en operationele business metingen. Ook een real time aanpak voor het bekijken van enrome hoeveelheden data behoren tot de mogelijkheden. Ook beschikt Cognos over tools die een organisatie kunnen helpen bij het sluiten en consolideren van business deals. • http://www.cognos.com


6

HP HP is een vrij nieuwe speler op de markt wat BI betreft. HP biedt oplossingen aan voor IT management, informatie management en verbetering van de communicatie. HP is de enige multinational die nog geen puur BI bedrijf heeft overgenomen. Gartner verwacht dat dit binnen de kortste keren wel het geval zal zijn. Hierdoor zal hun know-how en aanbod gevoelig stijgen. • http://welcome.hp.com/country/us/en/prodserv/software.html Information Builders Information Builders is nog een van de weinige onafhankelijke bedrijven die BI oplossingen op grote schaal aanbiedt zonder de hulp van een multinational. Het bedrijf richt zich meer naar gebruikers die analyse tools willen bouwen dan naar eindgebruikers van analyse tools. Op termijn kan dit wel een nadeel zijn zegt Gartner.

Information Builders biedt een BI platform aan, WebFOCUS genaamd. Het is een platform dat zowel beschikt over rapportage en analyse tools alsook over development en administratieve tools.

Een van de belangrijkste doelstellingen van IB is integratie. Dit wil zeggen dat ze alle systemen in een organisatie op een coherente manier willen laten samenwerken. Dit wordt gedaan door de iWay software. Het grootste voordeel van iWay is dat het verschillende systemen laat samenwerken zonder dat er 1 lijn code moet geschreven worden.

Tot slot beschikt IB ook nog over een host-based rapportage en informatie systeem. • http://www.informationbuilders.com Microsoft Omwille van het feit dat Microsoft de BI trein gemist heeft, hebben ze nog steeds een achterstand tov hun rivalen. Microsoft beweert dat het in de BI markt is gestapt met een lange termijn visie en dat hun positie alleen maar zal groeien naar mate hun aanbod toeneemt. Niettegenstaande hebben ze momenteel toch al een aantal goede producten, die vooral in de smaak vallen bij organisaties die hun infrastructuur rond Microsoft hebben opgebouwd. Een aantal van hun


7

producten zijn ingebouwd in hun Office pakket (bv: PerformancePoint server) en zijn sterk gekoppeld met SQL servers. • http://www.microsoft.com Microstrategy Een andere onafhankelijke aanbieder van BI oplossingen is Microstrategy. Microstrategy is vooral bekend doordat het zijn producten op een ’organisch’ manier opbouwt. Dit uit zich in een compacte platform integratie, een heel aanpasbare relationele OLAP architectuur en een compleet OO metadata model. De keerzijde is dat Microstrategy zich meer heeft toegespitst op BI platforms dan op performance management en data integratie. Hierdoor denkt Gartner dat ze zichzelf na verloop van tijd buitenspel zullen zetten. • http://www.microstrategy.com Oracle (Hyperion) Dankzij de overname van Hyperion door Oracle kwam deze laatste steeds nadrukkelijker in beeld in de BI wereld. Volgens Gartner is dit deels te danken door Hyperion maar ook de combinatie van Oracle’s Business platform en analyse tools zijn daar niet vreemd aan. Gartner is dan ook van mening dat Oracle dan ook over een van de betere sets van BI oplossingen beschikt. De belangrijkste zijn Oracle BI Enterprise Edition (OBIEE) en Oracle Analytic Applications.

Het probleem echter bij Oracle is volgens Gartner hun MA strategie (buy not build). Deze strategie kan er voor zorgen dat de verworven BI producten moeilijk integreerbaar zijn in de kernactiviteiten van Oracle. Ook vreest Gartner dat Oracle klanten zal verliezen door de overname van Hyperion. De gebruikers van deze laatste beschikken momenteel over de meest verouderde BI tools op de markt en het feit dat Hyperion net voor de overname heeft besloten om een fikse vergoeding te vragen voor een upgrade naar hun laatste versie zal er zeker geen deugd aan doen. • http://www.oracle.com/hyperion/index.html


8

SAS SAS is volgens Gartner een dominantie speler in het subdomein ’advanced analytic solutions’. Dus alles wat met analyse en de daarbij horende rapportering te maken heeft. Deze tools gaan veel verder dan bij de concurrentie. Zo spelen ze een belangrijke rol in specifieke business problemen zoals fraude detectie.

De keerzijde van de medaille is dat SAS-applicaties redelijk moeilijk aan te leren zijn omdat heel wat van deze tools de ’SAS Programming Language’ vereisen. Mensen met deze kennis kunnen dan ook heel wat verrichten met deze tools maar voor anderen vormen ze een grote hindernis. Hierdoor is de kans niet onbestaande dat organisaties kiezen voor meer toegankelijkere analyse en BI tools. • http://www.sas.com

2.1.4

Open Source BI software

Wie op zoek gaat naar een oplossing voor zijn BI activiteiten heeft de keuze tussen een groot aantal aanbieders. Tot voor kort waren dat vooral commerciële aanbieders (zie hierboven), die met name op het vlak van functionaliteit nog steeds ongevenaard zijn. De leveranciers van Open Source BI (OSBI) profileren zich steeds nadrukkelijker als een volwaardig alternatief. Hieronder vind je een bondig overzicht van deze spelers. Penthaho Zie samenvatting van Ben. Jaspersoft Jaspersoft brengt een nieuwe versie uit die Web 2.0 functionaliteit ondersteunt. Daardoor heeft deze versie (Jaspersoft BI Suite v3.0 Professional Edition) nieuwe functionaliteiten gekregen in de vorm van o.a. Web 2.0 interfaces, drag and drop mogelijkheden, een nieuwe meta data layer en een betere security.

Ook werkt Jaspersoft sinds korte tijd samen met Microsoft voor het optimaliseren van de BI Suite voor Windows en Office. Jaspersoft heeft samen met Microsoft hun BI Suite gecertificeerd


9

voor Windows Server 2008. Dit komt naast hun BI Suite voor Microsoft Windows en SQL Server platformen. Jaspersoft introduceert hiervoor de gratis Jaspersoft ODBO (OLE DB voor OLAP) Connect, waardoor Microsoft Excel gebruikt kan worden als frontend voor de JasperAnalysis data analysis server. Gezien het feit dat meer dan 50 procent van de BI oplossingen op Windows draait en meer dan 50 procent Excel gebruikt, kan hierdoor de inzet van Jaspersoft stijgen. • http://www.jaspersoft.com SpagoBI en Ingres SpagoBI en Ingres combineren hun technologie om sterker te staan op de markt. Beiden hebben de producten van de andere gecertificeerd ter versterking van hun oplossingen. Enkele van hun producten zijn: • Ingres IceBreaker BI Appliance De IceBreaker BI toepassing van Ingres bestaat uit een op maat gemaakt Linux besturingssysteem, de Ingres 2006 database en de Jaspersoft BI Suite. Hierdoor worden onnodige implementatie- en onderhoudskosten vermeden en geeft klanten sneller een BI oplossing. • Ingres IceBreaker for Salesforce.com IceBreaker voor Salesforce.com van Ingres is een op maat gesneden IceBreaker BI toepassing voor Salesforce.com CRM SaaS (Software as a Service). Gebruikers krijgen toegang tot CRM informatie in Salesforce.com via rapportages die voorheen door Salesforce.com niet ondersteund werden. Met behulp van trend analyses, slice and dice, drill down, dashboards en het integreren van data met andere operationele systemen, zoals Oracle en SAP ERP, krijgen ze meer inzicht in hun verkoopproces. • http://spago.eng.it/ecm/faces/public/guest/home/solutions/spagobi • http://www.ingres.com/products/icebreaker.php

2.1.5

Nichespelers

Onder nichespelers verstaan we alle aanbieders van BI software die niet onder een van bovenstaande categorie vallen. Ze bieden meestal een kleiner gamma aan producten aan en doen


10

veeal aan maatwerk. Dit in tegenstelling tot de grotere aanbieders van BI. Sommige van de nichespelers bieden ook freeware aan echter met heel wat miner functionaliteiten dan de betalende versies. Hieronder volgt een kort overzicht van enkele belangrijke nichespelers op de markt. SeeWhy SeeWhy richt zich voornamelijk op real time BI. Concreet spitst het zich toe op real time metingen, real time genereren van waarschuwingen komende van event streams, web traffiek of databases. Deze real time analyse zorgt ervoor dat acties geautomatiseerd en geoptimalizeerd worden wanneer er zich bepaalde business gebeurtenissen voordoen. Dit kan gaan van een eenvoudige ’click’ op een website tot de afwezigheid van verwachte gebeurtenissen of frauduleuze transacties. Heel wat van de tools van SeeWhy zijn ’event driven’.

SeeWhy maakt bij de architectuur onderscheid tussen 4 essentiële fases. Namelijk: • Capture De data wordt real time onderschept. • Analyze Het vergelijken van de data met eerdere gelijkaardige data of met vooropgestelde verwachtingen. • Act De analyse fase zorgt ervoor dat een bepaalde triggering plaatsvind. Dit kan gaan van het versturen van een email waarschuwing tot het plaatsen van promotionele aanbiedingen op een website. Ook kan deze data naar een data warehouse worden gestuurd voor verdere rapportage mogelijk te maken. • Optimize Tot slot worden bepaalde acties geoptimaliseerd om in de toekomst vlugger te kunnen anticiperen.

SeeWhy beschikt zowel over een open source platform als over een betalende versie. De eerste is uiteraard gratis te downloaden en de gebruiker kan zelf aanpassingen aanbrengen of


11

zaken uitwisselen met andere gebruikers. De betalende versie heeft dan weer als voordeel dat het over heel wat meer functionaliteiten beschikt en dat er een goeie support wordt voorzien. Dit is bij de freeware versie niet het geval. • http://www.seewhy.com Intellicus Intellicus is een aanbieder van BI tools die zich vooral richten naar de analyse en rapportering van business data. In tegenstelling tot SeeWhy komt er bij Intellicus minder real time event processing aan te pas. Verder dan het versturen van een sms of mail wanneer er zich een bepaalde gebeurtenis voordoet komen ze niet. Daarom dat we Intellicus laten voor wat het is. Wel voor de volledigheid nog even meegeven dat ze wel volop gebruik maken van webservices en SOA. • http://www.intellicus.com MAIA Intelligence Zelfde verhaal zoals bij Intellicus. Het aanbod van tools is echter wel groter dan bij Intellicus en duidelijker onderverdeeld naar de verschillende facetten van business analyse en rapportage. • http://www.maia-intelligence.com

2.1.6

Besluit

Het zal de aandachtige lezer waarschijnlijk niet ontgaan zijn dat het aandeel van de verkopers van BI 2.0 nog relatief beperkt is. Het merendeel biedt wel op een of andere manier een tool aan die op BI 2.0 gebaseerd is maar het overgrote deel van het aanbod is toch nog steeds gericht naar traditionele BI. Wellicht is deze overgang niet zomaar in een paar stappen gemaakt en wellicht ligt dit ook aan de gebruikers zelf. Wat men kent wil men niet zomaar opgeven voor iets nieuws. Dit heeft zijn tijd nodig.

Echter zijn er toch enkele bedrijven, denk maar aan SeeWhy die heel hun gamma aan producten hebben afgestemd op BI 2.0. Dit komt wellicht door het feit dat dit relatief kleinere spelers zijn die zich richten op een welbepaald deelsegment van BI. Daardoor kunnen ze veel vlugger inspelen op de nieuwste technologiën.


12

Ook het aandeel en de kwaliteit van open source BI neemt toe vooral dankzij de groeiende vraag vanuit de organisaties zelf om zo het kostenplaatje van hun BI tools binnen de perken te houden.

2.2 Wetenschappelijk Onderzoek

2.2

13

Wetenschappelijk Onderzoek

Volgende artikels werden gevonden op GoogleScholar. De gebruikte zoektermen waren ’Business intelligence’. Hierna werd gesorteerd op recentheid. Waar mogelijk werd een link voorzien naar de desbetreffende artikels. Een hele reeks van deze artikels zijn enkel beschikbaar in het UGent netwerk. Het volstaat dan de titel in GoogleScholar in te geven en de eerste link aan te duiden.

2.2.1

Algemene artikels

Overzicht Continental Airlines Continues to Soar with Business Intelligence Dit artikel beschrijft een case study van de evolutie van BI bij continental airlines. • Enkel beschikbaar in het Ugent netwerk. Business intelligence Dit artikel schetst de huidige ’state-of-the art’ van BI in het algemeen en stelt nieuwe onderzoeksdomeinen voor. Het dateert van 2003. • www.terry.uga.edu/˜jaronson/DSS-Readings/GrayAMCIS2003AugBITutorial.pdf The measurement of business intelligence Aan de hand van een literatuurstudie proberen ze hier de waarde van een BI systeem te bepalen. Ook de management van een BI proces in een organisatie wordt onderzocht. • Enkel beschikbaar in het Ugent netwerk. The Architecture of Business Intelligence De architectuur van een BI systeem wordt besproken. Het wijst op het feit dat veel bedrijven hun datawarehouse systeem gebruiken om data op te vragen en verslagen te genereren. Dit artikel dateert van 2007. • http://staging.accenture.com/NR /rdonlyres/15DCFF6A-4DE0-44D8-B778-630BE3A677A2/0/ArchBIAIMS.pdf Trust and reputation for service-oriented environments: Technologies for building business intelligence and consumer confidence Dit artikel wijst op het belang van vertouwen bij BI in het algemeen. Er worden (in de extended abstract) geen concrete voorstellen gedaan van technologieën.


14

• Enkel abstract bechikbaar Approach to Building and Implementing Business Intelligence Systems Over hoe het best een BI systeem op te zetten. • http://www.ijikm.org/Volume2/IJIKMv2p135-148Olszak184.pdf A Service-oriented Architecture for Business Intelligence Een artikel over service oriented BI.

Extending UML 2 Activity Diagrams with Business Intelligence Objects Artikel dat het uitbreiden van UML voorstelt met BI objecten.

Synthese van ’The Architecture of Business Intelligence’ Inleiding De auteurs wijzen erop dat nog veel bedrijven enkel transactionele en verslaggevende mogelijkheden hebben. Ze gebruiken de gigantische hoeveelheid informatie waarover ze beschikken bijvoorbeeld niet om hun meest winstgevende klanten te ontdekken, hun logistiek te verbeteren of de factoren die verantwoordelijk zijn vooor hun succes of falen te leren kennen. Ook de ondersteuning bij het naleven van de wettelijke en andere regelgevingen is een aspect van BI tools dat vaak over het hoofd gezien wordt. In het algemeen is het doel van een BI environment om de juiste informatie naar de juiste mensen te brengen op het juiste moment. Zo moet het onder andere mogelijk zijn informatie beschikbaar te maken via verscheidene kanalen zoals verslagen, analyse tools, dashboards, spreadsheets, email en pager. In het komende artikel zullen ze de verschillende elementen van een BI architectuur ontleden en bespreken. Ze onderscheiden 6 elementen in een BI architectuur: 1. Databeheer 2. Transformatietools en processen 3. Data repositories 4. Analytische tools


15

5. Presentatie tools 6. Operationele processen Volgens hun onderzoek is er een sterke link tussen de analytische mogelijkheden en de marktpostie van bedrijven. Databeheer Het doel van databeheer is het verzekeren van juiste informatie en het gepast gebruik ervan. De auterus wijzen erop dat sommige bedrijven extern verzamelde informatie aankopen van bedrijven, zoals IRI en AC Nielsen voor consumentenproducten(via barcodes van supermarkten bvb), en IMS Health voor cosmetica producten. Voorbeeld van het succes van databeheer is Continental Airlines. Ze analyseren hun informatie at realtime om bijvoorbeeld frequent vliegende klanten een ander vlucht toe te wijzen als er kans is dat hun vlucht serieuze vertraging oploopt. Logistieke medewerkers kunnen de ideale positie van werknemers(piloten, stewards,..) en vliegtuigen bepalen. Op lange termijn worden trends van prijzen, klanten en markt geanalyseerd Volgens de auteurs zijn er naar databeheer toe 5 vragen belangrijk: 1. Welke data is noodzakelijk om op analytisch niveau mee te kunnen concurreren? Sommige informatie kan men in een enkel getal samenvatten, bvb. de kredietwaardigheid van een klant. Voor andere informatie is een verslag noodzakelijk, bvb. evaluatie van een werknemer. Het zijn vooral de business en IT leider die moeten samenwerken om te bepalen welke data noodzakelijk en mogelijk is. 2. Waar kan deze data verkregen worden? Men maakt hier het onderscheid tussen interne(verkregen binnen het bedrijf) en externe informatie(van buiten het bedrijf). 3. Hoeveel data is nodig? Men moet niet te veel data willen verzamelen, just in case”. Bovendien is het ook niet ” wenselijk dat men makkelijk te verkrijgen informatie, die niet nuttig is, verzamelt. 4. Hoe kunnen we de data waardevoller maken? Kwaliteit van data is belangrijker dan de kwantiteit. Data moet correct, compleet, actueel,


16

consistent, contextueel en gecontrolleerd zijn. Contextuele informatie wordt verkregen door metadata toe te voegen. 5. Welke regels en processen zijn noodzakelijk om de data te beheren van het verkrijgen tot het verwijderen? Hier onderscheidt men verschillende fases: data vergaring, data zuivering, data organisatie en opslag, data onderhoud. Transformatietools en processen Om de verkregen data bruikbaar te maken moet er een proces genaamd ETL plaatsvinden. Dit staat voor extract, transform en load. Extract staat voor de data extraheren van de bron. Transform slaat op het omzetten van deze data in bruikbare informatie, bvb verwijderen van foutieve data, standardisatie van de data. Hier kan heel wat manuele arbeid voor nodig zijn. Load, ten slotte, slaat op de organisatie en opslag van de data. Data repositories Bedrijven hebben verschillende opties voor de organisatie en opslag van hun data. Een data warehouse slaat op regelmatig upgedate databases. Dit kan een module zijn van het gehele IT systeem van het bedrijf, of het kan een aparte database zijn. Sommige bedrijven gebruiken een ’staging database’, die gebruikt wordt om data van verschillende bronnen bruikbaar te maken voor een data warehouse. Een data mart is een aparte database of een partitie van een data warehouse. Data marts worden gewoonlijk gebruikt voor een specifiek functie of proces. Een metadata repository bevat technisch info, datadefinities, informatie over de bron, hoe het berekend is geweest..Een gemeenschappelijk metadata repository over het gehele bedrijf is noodzakelijk om de consistentie van de data te waarborgen. Analytische tools Een beslissing die hier zich in eerste instantie zal opdringen is het al dan niet automatiseren van de beslissing genomen na analyse. Er zijn heel wat analystische technologieen beschikbaar: 1. Spreadsheets Een bekend voorbeeld is excell. Deze kan enkel 3 dimensies aan. Over verschillende worksheets en in een worksheet horizontaal en verticaal. 2. Online analytical processors Ook wel gekend als OLAP. Data wordt georganiseerd in ’data cubes’, om zo analyses mogelijk te maken over meerdere dimensies. Men kan ze zien als multidemensionele spreadsheets.


17

3. Statische en quantitieve algoritmes Quantitieve data wordt geanalyseerd om hierna een optimum te bepalen. 4. Rule engines Aan de hand van condities(vaak over meerdere dimensies) kan een voorstel voor een beslissing gemaakt worden door een rule engine. 5. Data mining tools Deze tools gaan op zoek naar patronen in complexe en vaak slecht gedefinieerde datasets. 6. Text mining tools Deze doen hetzelfde als datamining tools maar dan specifiek voor textuele data. 7. Simulation tools Men kan met simulatoren nagaan wat het effect zou zijn van een bepaalde beslissing. Er moet wel een model zijn van de omgeving waarin men beslissing neemt. Presentatie tools Hiermee kan men verslagen maken van de analyses, visualiseren van de data. Deze zullen ook zorgen voor alerts via vershillende kanalen als er in de analyses excepties gevonden worden. Deze tools moeten ook het, eventueel interactief, delen van informatie mogelijk maken. Belangrijk is het dat men manipulaties op de data kan uitvoeren, voor analyses bijvoorbeeld, zonder dat de onderliggende data verandert. Operationele processen Dit zijn de handelingen noodzakelijk om de betrouwbaarheid, schaalbaarheid en veiligheid van de BI environment te waarborgen.


2.2.2

18

Artikels omtrent real-time

Moving Business Intelligence to the Operational World De auteur wijst in dit artikel op het belang van het real time aspect van BI en moedigt een ’event-driven’ en ’process-oriented’ BI aan, waarbij men ook toegang heeft tot operationele data. Hierbij kunnen EII(Enterprise information integration) en ERP(enterprise resource planning)als ondersteunende technologie gebruikt worden. EII zorgt ervoor dat verschillende heterogene databronnen als een homgene bron lijken voor degebruiker. ERP is verantwoordelijk voor het beheren van de resources van een bedrijf(materiaal, werknemers, klanten,..). Aangezien vaak verschillende departementen bestaan in grote bedrijven, wordt er geopteerd voor een centrale databank en een modulaire interface. Elk departement kan bepaalde modules kiezen die ze verkiest. Een aantal toepassingen voor BI zouden kunnen zijn: logistiek, fraude detectie, klantentevredenheid. In het geval van logistiek zou bijvoorbeeld een systeem ontwikkeld kunnen worden dat de stock analyseert en zelf orders kan plaatsen. Hier kan dan rekening gehouden worden met de prijzen van de leveranciers en opslagcapaciteiten. • Enkel abstract bechikbaar Support vector machines based on K-means clustering for real-time business intelligence systems Nieuwe techniek ontwikkeld om het versnellen van het nemen van geautomatiseerde beslissingen bij bvb beurs aangelegenheden. • Enkel abstract bechikbaar Real-time business intelligence: best practice at continental airlines Dit artikel dateert van eind 2006 en bespreekt het real-time BI systeem van Continental Airlines. Volgens dit artikel is Continental Airlines een leider op het vlak van real-time BI. • Enkel beschikbaar in het Ugent netwerk. Sense & Response Service Architecture (SARESA): An Approach towards a Real-time Business Intelligence Solution and its use for a Fraud Detection Application Een nieuwe architectuur wordt voorgesteld voor BI om real-time BI data te analyseren en gepast te reageren. Artikel dateert van 2005. • http://www.cis.drexel.edu/faculty/song/dolap/dolap05/paper/p77-thonguyen.pdf


Practical Considerations for Real-Time Business Intelligence Een aantal slides van Yahoo over BI, met voorbeelden en figuren.

• http://www.cc.gatech.edu/classes/AY2007/cs4440 fall/VLDB.pdf

19


2.2.3

20

Artikels omtrent data mining

A Matter of Opinion: Sentiment Analysis and Business Intelligence (position paper) Hier wordt uitgewijd over het laten analyseren van een tekst om te achterhalen of er een positief of negatief sentiment achterschuilt. Misschien relevant voor analyses van klantentevredenheid.

A Visual Framework for Knowledge Discovery on the Web: An Empirical Study of Business Intelligence Exploration Hier staan het visualiseren en structuren van gevonden informatie op het web centraal. Een echte link met BI blijkt niet echt uit het abstract.

Classifying credit card accounts for business intelligence and decision making: a multiplecriteria quadratic programming approach Hier wordt een techniek uitgelegd die kredietverschaffers toelaat om het gedrag van kredietkaarthouders te analyseren en proactief in te grijpen.

Web Data Extraction For BI:the lixto approach Dit artikel schets een geautomatiseerde manier om relevante, meestal ongestructureerde informatie van het web te halen en te structureren. Concreet gaat het over informatie over de markt waarin men zit en de concurrenten.

SOLAP technology: Merging business intelligence with geospatial technology for interactive spatio-temporal exploration and analysis of data Bespreekt de SOLAP technologie een uitbreiding van de olap technologie met een spatiale component. Zo kan men niet enkel in informatie van een bepaald tijdstip oproepen, maar ook informatie over een bepaalde locatie. Dit allemaal op een interactieve en visuele manier.

Natural Language Technology for Information Integration in Business Intelligence Dit arikel beschrijft een manier om verschillende bronnen van informatie te analyseren om zo risico’s te bepalen. Het wijst op het feit dat traditionele datamining technieken ontwikkeld zijn voor numerieke data en vaak niet omweg kunnen met tekstuele data. Ze maken gebuik van de XBRL standaard.


21

Intelligent profitable customers segmentation system based on business intelligence tools In dit artikel wordt de analyse van de ’profitabality’ van een klant onderzocht. Dit kan door een bedrijf gebruikt worden om een efficiëntere CRM(Customer relationship management) op te zetten.

Business intelligence for new market development: a web semantic network analysis approach Dit artikel wijst op het belang van betekenis van data, bij het analyseren van websites van klanten.

Topical Crawling for Business Intelligence Dit artikel beschrijft een manier om de dynamische en gigantische hoeveelheid informatie op het internet te doorzoeken. Dit is een techniek die uitgetest is geweest voor het opzoeken van ’business entities’ : concurrenten, partners en klanten.

Text mining system for web-based business intelligence Een patent gevonden tussen de resultaten.

Business intelligence from web usage mining Het gebruiken van informatie die voortvloeit uit de interactie van een gebruiker met het web.

Integrating Semi-structured Data into Business Applications: A Web Intelligence Example Auteurs stellen een systeem voor om relevante semi-gestructureerde informatie op te zoeken op het web. Deze automatisch om te zetten tot gestructureerde informatie. Dit kan relevant zijn voor het opzoeken van informatie over de concurrenten en marktevoluties.

Business Process Intelligence Artikel over het vergaren van informatie over meer specifiek het ’business process’ ahv BPMS(Business Process Management Systems).


2.2.4

22

Conclusies

Het onderzoek in de acamdemische wereld richtte zich in eerste instantie op het onderzoeken van bestaande business intelligence(BI) tools : het structureren van de functionaliteit van deze BI tools met bijhorende evaluatie. Vragen die beantwoord worden zijn ’Wat zijn de verschillende delen van BI tools?’, ’Zijn er hiaten in de huidige BI tools?’, ’Hoe wordt een BI environment best opgezet?’.

Huidig onderzoek werkt verder op de conclusies getrokken door dit vroeger onderzoek. Een statisch, geisoleerd BI systeem, dat gigantische hoeveelheden informatie structureert om daar rapporten van te maken is niet voldoende. Het is beter om een ’event-driven’, ’process-oriented’ en geintegreerde aanpak te hanteren. Gebruik maken van operationele data, om de verworven informatie at real-time te kunnen aanwenden, is noodzakelijk. Hier worden verschillende technologieen voor ontwikkeld, zoals OLAP, simulatoren en rule engines. Het artikel van accenture geeft onder andere hiervan een mooi overzicht. Een samenvatting van dit recent artikel, van 2007, volgt.

Het blijkt noodzakelijk om aan onderhoud en ontwikkeling van het BI systeem te doen. Het BI systeem constant evalueren en waar noodzakelijk bijsturen. Het BI systeem integreren met reeds aanwezige IT is zeker een pluspunt.

Een ander hot topic in huidig onderzoek is het filteren van relevante informatie uit gigantische hoeveelheden informatie. Dit zou toegepast kunnen worden om op het web relevante informatie op te zoeken omtrent concurrenten, klanten en huidige marktomstandigheden. Hier worden allerlei gesofisticeerde, wiskundige algoritmes voor ontwikkeld. Deze zijn initieel vooral voor numerieke data ontwikkeld. Aandacht gaat recentelijk ook naar het text-mining. En nog een stap verder, semantische analyse.

Een aantal mogelijke features zijn: • geintegreerd(ten alle tijde zichtbaar, periodiek aanspreken van gebruiker) feedback systeem, zowel numerieke feedback op een schaal als textuele feedback, zowel positief als negatief. Eventueel koppelen aan beslissingen genomen om zo een maat voor de nauxkeurigheid te generen.


23

• websites monitoren, bvb concurrenten, voor updates en eigen websites beschermen hiervan mogelijk? open source mogelijkheden? • zeer modulaire aanpak, veel aanbieden, met verschillende configuraties zodat bij installatie een meer op maat gemaakte BI tool kan opgesteld worden, overbodige modules moeten verwijderd worden. Modules moeten later, indien noodzakelijk, kunnen toegevoegd worden • mogelijk maken van plugins van recente, eventueel betalende technologieen van bvb datamining. • verschillende hierarchische rollen creeren om zo gevoelige informatie te beschermen, dit is zeker van toepassing op ’BI for the masses’ • pentaho uitbreiden voor BI voor de massa • mogelijk integratie met open source IT software. • alerts via verschillende kanalen:sms,email,pager,fax,..? • voorzien van meerdimensionale uitbreiding van informatie, visualisatie op een ’plan’, spatiale dimensie is hier voorbeeld van

2.3 Pentaho BI Platform overzicht

2.3 2.3.1

24

Pentaho BI Platform overzicht Overzicht

De kern van het pentaho-platform zijn de solutions en de solutions engine die ervoor zorgt dat rapportering, analyse, datamining etc... geintegreerd zijn in een enkele entiteit om zo complexe en complete oplossingen te bieden voor BI-problemen.

2.3.2

Server-Architectuur

Alle platform-componenten zijn open-source en geschreven in Java-code. De server-zijde is gebouwd J2EE, de server loopt dus in een J2EE-compatibele omgeving. Alles kan dus geintegreerd worden in een J2EE-compatible webserver. Hieronder is een duidelijke schematische weergave afgebeeld van de total server-architectuur van de Pentaho-omgeving. Het is best deze afbeelding in gedachten te houden tijdens het vervolg van dit document.

Figuur 2.1: Pentaho architecture overview


25

De Solution Engine is dus centraal gesitueerd in de architectuur en staat in directe verbinding met de solution-repository die de solution-metadata bevat. Toegang tot deze solutions kan via de webservices alsook via Java Server Pages. De webservices leveren services voor externe applicatie en hebben toegang tot de solution engine net als de normale user interface-elementen zoals de Java Server Pages.

De solutions, die custom gebouwd kunnen worden, kunnen gebruik maken van enkele standaard componenten reeds aanwezig in het platform. Controle/Auditing is standaard ingebouwd in alle componenten en kan de gebruiker en/of applicaties voorzien van historische gegevens, performantie informatie etc... Een kort overzichte van enkele specifieke componenten aanwezig in het pentaho-platform volgen. Dashboard Het dashboard is een component waarmee informatie over een bepaalde entiteit (een departement, een individu) kan worden georganiseerd om een overzicht te krijgen per entiteit. Integratie met de rapportering en analyse componenten zorgt ervoor dat een diepere analyse mogelijk is en dat een gebruiker een centraal overzicht krijgt met tegelijk een manier om dieper in detail te treden.

Figuur 2.2: Dashboard voorbeeld

Reporting Een rapporterings component die standaard overweg kan met verschillende soorten data van verschillende bronnen. Ondersteuning voor zowel webinterface als desktopapplicaties en verschillende output formaten (PDF, HTML,...) is al aanwezig en kan uitgebreid worden.


26

Figuur 2.3: Reporting voorbeeld Data Mining Een component om datamining te organiseren om data te analyseren en verborgen relaties te ontdekken. Bevat standaard data mining algoritmes en een rapporterings-module om alles op een presentabele manier weer te geven.

Figuur 2.4: Data Mining voorbeeld Deze componenten kunnen zowel aangepast/uitgebreid worden om extra functionaliteiten te implementeren alsook kunnen nieuwe componenten toegevoegd worden.

2.3.3

Design Studio

Pentaho bevat een design studio om custom-solutions aan te kunnen maken en te editeren. Deze design studio is gebaseerd op Eclipse. De design studio kan bijvoorbeeld gebruikt worden om activiteiten die het BI platform uitvoert te editeren. De activeiten, gedefinieerd in Action Sequence XML documenten, definieren dingen als database toegang, rapport generatie, . . .


2.3.4

27

Conclusie

Deze (korte) samenvatting van de architectuur van het pentaho BI-platform doet geen recht aan de complexiteit en veelheid aan functionaliteit in het platform. Na een eigen test, installatie van de server software, was het duidelijk dat een overvloed aan functionaliteit en vooral aanpasbaarheid aanwezig is. Het Pentaho BI Platform kan bekeken worden als een volwaardig open-source alternatief voor bestaande commerciele pakketten.

2.4 Pentaho Architectuur overzicht

2.4

28

Pentaho Architectuur overzicht

Deze uiteenzetting concentreert zich op hoog niveau op de architectuur van Pentaho om een gefundeerde keuze voor Pentaho te kunnen verantwoorden. De filosofie achter de Pentaho architectuur is gebaseerd op de eigenlijke plaats van Business Intelligence in een business-process. Business Intelligence is een inhertent onderdeel van een business-process dus een BI-systeem is enkel een deel van een process. Het BI-systeem moet dus gemakkelijk integreerbaar zijn in een bestaande architectuur alsook zeer gemakkelijk aanpasbaar om aan de noden van verschillende klanten te kunnen voldoen. Dit vertaalt zich in de architectuur door de nadruk van het Pentho BI-Platform de leggen op modifiability in de context van een extreem licht-gewicht systeem.

2.4.1

Architectuur

Solution Engine

Figuur 2.5: Solution Engine De architectuur van het platform is gebouwd rond de solution-engine. Deze solution engine zorgt er mede voor dat er gn hard-coded logica in Pentaho ingebouwd zit en alles configureerbaar is. De solution engine voert Action Sequences uit oftewel een BI-process. De Action Sequence kan zowel rapportering als analyse of andere BI gerelateerde zaken bevatten. Concreet zit deze logica in de Runtime Engine.


29

De solution repository bevat alle logic nodig om een BI-solution uit te voeren, dus de volledige definitie van een Action Sequence; queries, templates, . . . Deze data kan zowel in een traditioneel database systeem opgeslagen worden als in een gewoon file-systeem. Runtime Engine

Figuur 2.6: Runtime Engine Om het eigenlijke uitvoeren van een Action Sequence goed te laten verlopen word gebruik gemaakt van een Runtime Engine die de verantwoordelijkheid op zich neem voor het correct uitvoeren van de processen nodig om Action Sequence uit te voeren. De Runtime Engine krijgt zijn configuratie mee van de solution engine en kan gebruik maken van enorm veel bouwblokken in de vorm van BI components. Deze BI components kunnen van alle soorten en kleuren zijn, van E-mail engines tot data, printing, . . . BI components kunnen toegevoegd/verwijderd worden zoveel als nodig en kunnen ook custom ontwikkeld worden en ingeplugd in het Pentaho platform. De verschillende BI components kunnen volledig met elkaar samenwerken op allerlei verschillende manieren. Sommige van deze BI components kunnen ook beroep doen op externe applicaties of bronnen. Deze bronnen kunnen bijvoorbeeld legacy-systemen zijn. Ook de Solution Engine en de Runtime Engine zijn volledig customizable. De Configura-


30

Figuur 2.7: Runtime Engine - External Sources tion kan gebruikt worden om eigen implementaties te gebruiken ipv de bestaande Solution- of Runtime Engine. Deze manier van werken is van toepassing op alle elementen van het Pentaho platform dus niet enkel de hier beschreven engines. API

Figuur 2.8: API


31

Via een simpele API kunnen solutions in Pentaho worden uitgevoerd en ingeplugd worden in allerhande applicaties. Er is ook een ingebouwde XML-gebaseerde web interface. Dit is belangrijk bij de Deployment & Integration besproken in een volgend punt. Besluit Uit bovenstaande punten is het duidelijk dat de Pentaho architectuur inderdaad enorm de nadruk legt op modifiability. De configuratie mogelijkheden en de loskoppeling van de logica in de verschillende modules zijn hier duidelijke voorbeelden van.

2.4.2

Deployment & Integration

Het systeem kan ook op veel verschillende manieren gedeployed en geintegreerd worden met verschillende externe systemen. Ook een bijdrage tot het modifiability argument. Out-of-thebox kan Pentaho als stand-alone server gebruikt worden. Ook een web-server configuratie is mogelijk. Pentaho is dus gelukkig in een omgeving als stand-alone-server. Pentaho kan ook gewoon gebruikt worden als library en ingebed worden in een eigen custom applicatie. Het gebruik van Pentaho als library is mogelijk omdat het juist zeer licht-weight is gehouden. Het Pentaho-Platform inclusief API, zoals hierboven beschreven, neemt minder dan 2MB in beslag. Het eigenlijk pad dat gevolgd word bij het uitvoeren van een Action Sequence is zeer kort. Tussen het opstarten ervan en begin van uitvoering gaat er gemiddeld n milliseconde voorbij.

Figuur 2.9: Deployment as Lib Pentaho kan ook als externe service worden gemplementeerd. Pentaho kan ook ingezet worden als deel van een process op allerhande verschillende manieren. Het kan zowel een volledig systeem implementeren, een klein deeltje, of verschillende disjuncte delen.


32

Figuur 2.10: Deployment as Service

Figuur 2.11: Deployment - Disjunct

Figuur 2.12: Deployment - Single

2.4.3

Pentaho en operationale BI

Het pentaho platform bied ook ondersteuning voor een minder traditionele aanpak en gebruik van BI namelijk de operationele BI. Operationele BI vereist real-time informatie en kan dus gebruikt worden om processen te beinvloeden gebaseerd op informatie over het proces terwijl het nog loopt. Kort gezegd zal de operationele BI dus gebruikt worden om operationele zaken te regelen.


33

Hoe Pentaho concreet operationele BI aanpakt is de verdere focus. De grote uitdagingen van de operationele BI bestaan uit verschillende punten niet van toepassing op traditionele BI: • Latency: Hoe real-time is real-time? • Kwaliteit: Hoe kan kwaliteit verzoend worden met snelheid? • Presentatie: Wat is nuttig voor een gebruiker als real-time data en hoe snel kan een gebruiker informatie verwerken? • Integratie: Hoe kan het BI-systeem operationele processen integreren? Veel van deze punten zijn ook van toepassing op onze architectuur; bv de latency en de kwaliteit. Latency en kwaliteit Latency en kwaliteit lijken op het eerste zicht niet combineerbaar maar pentaho heeft een oplossing in deze richting. Door de pentaho data integratie (figuur) word er vanuit verschillende data sources een datawarehouse opgebouwd. Het datawarehouse bouwt als het ware een eigen versie van de waarheid op waarop snel queries kunnen uitgevoerd worden om in realtime resultaat te kunnen verkrijgen. De kwaliteit is verbeterd door ’Data Filtering’ ofwel het verwijderen van ongeldige data gebaseerd op een bepaalde set van business rules. Latency is natuurlijk ook direct afhankelijk van de opzet van het uiteindelijk fysieke systeem. Daarom is alles schaalbaar en kan alles in clusters opgezet worden. Integratie Integratie van data van verschillende, al dan niet externe, bronnen is ingebakken in Pentaho. Presentatie Flexibele presentatie is ook deel van de Pentaho BI Suite.

2.4.4

Besluit

Het is dan ook duidelijk dat Pentaho zeker geen slechte keuze zou zijn voor een operationele BI toepassing als de onze. Niet enkel het operationele BI argument maar ook onze focus op modifiability verzoent zicht bijna perfect met de filosofie en uiteindelijke implementatie en integratie


34

Figuur 2.13: Data Integration van Pentaho. Combineer dit met het gebruik van open standaarden waardoor gebruik gemaakt kan worden van verschillende technologieën bij de uiteindelijke implementatie van onze architectuur. We zijn met andere woorden door Pentaho niet gebonden aan bepaalde technologien of leveranciers. Pentaho kan dus terecht bekeken worden als een flexibel, uitbreidbaar en licht-weight BI systeem.

2.5 Standard bodies & Professional Organizations

2.5

35

Standard bodies & Professional Organizations

2.5.1

Standard bodies

W3.org Op de site van het World wide web consortium is niet veel specifiek informatie of artikels te vinden over business intelligence op zich. Wel zijn er enkele terugkerende onderwerpen die nuttig kunnen zijn voor BI-tools of waarbij Business Intelligence vermeld wordt. • Semantic web Er gebeurt tegenwoordig veel onderzoek naar semantic web. Bijgevolg zijn vele documenten en presentaties over dit onderwerp terug te vinden. Hierbij wordt telkens Business Intelligence vermeld als een sector die hier veel voordeel uit zou halen. Inderdaad is op het internet veel informatie te vinden die belangrijk kunnen zijn bij het managen van bedrijven. Deze informatie is echter in overvloed en zonder enige structuur aanwezig. Semantic Web kan een hulp zijn om precies die informatie die nuttig is voor het bedrijf te extraheren. Denken we bijvoorbeeld maar aan concrete beurscijfers die op deze manier voorzien kunnen worden. • XBRL XBRL staat voor eXtensible Business Reporting Language. Het is een XML-gebaseerde taal voor de elektronische communicatie van bedrijfsgegevens en financiële data. XBRL is een open standaard en wordt ontworpen door een internationaal non-profit consortium van ongeveer 450 grote bedrijven, organisaties en overheidsagentschappen. XBRL komt uit de familie van de XML-talen, een standaard voor de elektronische uitwisseling van data tussen organisaties en het internet. Onder XML worden items voorzien van identificerende tags zodat data efficiënt door een computer kan verwerkt worden. XBRL is een krachtige en flexibele versie van XML die speciaal gedefinieerd is voor de specifieke noden van bedrijfsgegevens en financile data. Niet alleen worden financile data-items voorzien van tags, er kan ook andere informatie over het item opgeslagen worden of hoe het item gerelateerd is met andere items. Zo kan je bijvoorbeeld ook weergeven hoe een bepaald getal berekend werd. Tags zijn leesbaar voor een computer en op deze manier kan bedrijfsinformatie automatisch worden verwerkt. XBRL is flexibel genoeg om alle huidige aspecten van rapportering uit verschillende landen en industrieën te ondersteunen. Het


36

kan aangepast worden aan specifieke eisen tot op het niveau van de individuele organisatie. XBRL biedt tal van voordelen voor iedereen die te maken krijgt met het verzamelen en verwerken van bedrijfsgegevens en financile data. Deze laten zich vooral merken in een verhoogde efficiëntie, verhoogde betrouwbaarheid en in kostenbesparing. Er hoeft immers geen tijd meer gestopt te worden in tijdrovende taken als het manueel vergelijken, opnieuw samenstellen en opnieuw ingeven van financile informatie. Eens de data in XBRL staat, kunnen er met minimale moeite verschillende analyses gebeuren die resulteren in een veelheid van verschillende rapporten. Door op die manier tijd uit te sparen kan de focus verlegd worden naar een betere en grondigere analyse van de data en kunnen er ook sneller betere beslissingen worden gemaakt. • MUSING MUSING (MUlti-industry, Semantic-based next generation business INtelliGence) is een Europees R&D initiatief van 14 internationale organisaties, ondersteund door de Europese Commissie. Het project biedt innovatieve oplossingen voor het beheer van data en de uitvoering van business intelligence activiteiten bij de eindgebruiker. Business Intelligence wordt omschreven als het interactief proces van de analyse van ” informatie om patronen te onderscheiden en hieruit inzichten te verwerven en beslissingen te nemen.” Om het verzamelen van data en het informatie halen uit grote hoeveelheden heterogene en ongestructureerde informatie te automatiseren ontwikkelde MUSING een nieuwe generatie semantisch gebaseerde BI tools en modules. Deze worden beschikbaar gesteld via een web-service, zodat bedrijven van alle groottes er onmiddellijk gebruik van kunnen maken. MUSING biedt semantisch gebaseerde BI services aan die gebruikers toelaten om enorme hoeveelheden data te verzamelen, beheren, analyseren, delen en omzetten in beschikbare kennis en beslissingsklare informatie. Het doel is om de financiële sector te begeleiden in de evaluatie van financieel beleid, financile monitoring, beslissingsondersteuning voor credit risk management; om internationale uitwisseling van kennis te vergemakkelijken, Concreet focust MUSING zich op drie domeinen: Financial Risk Management, Internationalisation en IT Operational Risk. Activiteiten die MUSING omvatten zijn onder andere: - Semantisch ondersteunde en meertalige data en text mining


37

- Automatische informatie-extractie uit verschillende, al dan niet ongestructureerde bronnen - Automatisch redeneren op vooraf gefilterde informatie - Opsporen en verminderen van operational risks - ... MUSING maakt gebruik van standaarden, zoals onder andere XBRL. IEEE.org Wanneer we op IEEE zoeken naar informatie over business intelligence, zien we dat dit onderwerp zeker aan belang wint. Het is echter een zeer breed onderwerp die op heel veel zeer specifieke domeinen kan toegepast worden. Er zijn dan vele artikels terug te vinden over welbepaalde aspecten of toepassingen van Business Intelligence. Enkele voorbeelden: • Business Intelligence Explorer: A Knowledge Map Framework for Discovering Business Intelligence on the Web In dit artikel wordt een Business Intelligence Explorer voorgesteld, een tool die op zoek gaat naar business intelligence op het internet. De tool past technieken toe bij gegevensverzameling, text-mining en documentvisualisatie om het probleem van het overaanbod aan content op het web aan te pakken. • Banking Intelligence: Application of data warehouse in bank operations Banken krijgen uiteraard ook te maken met een enorme hoeveelheid aan data. Intelligente software die hierin wat orde schept, kan een grote meerwaarde betekenen. Bank Intelligence is een methode om sleutelinformatie op die manier op te slaan en te rapporteren dat iedereen snel en gemakkelijk toegang heeft tot accurate en consistente informatie. Dit artikel beschrijft een bank intelligence framework en de implementatie ervan. • Capturing the Semantics of Online News Sources for Business Intelligence Applications In dit artikel wordt een kennisgebaseerde aanpak voorgesteld om gericht semantische informatie te halen uit online nieuwsbronnen voor Business Intelligence applicaties die vooraf het gebied van interesse kennen.


2.5.2

38

Professional organisations

heavyreading.com • Business Intelligence & Decision Support: User Perceptions & Trends Een globaal marktonderzoek bij een 200-tal professionals die te maken krijgen met de selectie, aankoop en het managen van business intelligence producten voor hun organisatie. In het onderzoek geven ze hun kijk op de effectiviteit van business intelligence producten in hun organisatie, hoe en waar ze nu en in de toekomst gebruikt worden en welke factoren een rol spelen bij de selectie van producten en verkopers. Vendors: - Actuate Corp. www.actuate.com - Applix Inc. www.applix.com - Business Objects S.A. www. businessobjects.com - CA Inc. www.ca.com - Cognos Inc. www.cognos.com - Hyperion Solutions Corp. www.hyperion.com - IBM Corp. www.ibm.com - Information Builders Inc. www.informationbuilders.com - JasperSoft Corp. www.jaspersoft.com - Microsoft Corp. www.microsoft.com - MicroStrategy Inc. www. microstrategy.com - Oracle Corp. www.oracle.com - SAP AG www.sap.com - SAS Institute Inc. www.sas.com - SPSS Inc. www.spss.com - Sybase Inc. www.sybase.com - Teradata www.teradata.com

• Webalo Webalo Mobile Dashboard is een service die rapporteerbare bedrijfsgegevens onmiddellijk beschikbaar maakt voor gelijk welk mobiel toestel. Een eenvoudige web-gebaseerde service laat een gebruiker toe te bepalen precies welke functionaliteit en gegevens beschikbaar


39

moet zijn, welke personen er toegang moeten hebben tot de gegevens en hoe ze gerechtigd zijn om de gegevens te veranderen. Op die manier wordt het mogelijk om met een mobiel toestel te interageren met de systemen en data die leiden tot het onmiddellijk managen van operaties, beantwoorden van vragen, maken van beslissingen en ondernemen van acties. De architectuur die Webalo hanteert is wat ze zelf noemen User-centric SOA”. Het is een ” uitbreiding van de Service-oriented Architecture naar een real-time bedrijfsomgeving. Het bestaat uit twee delen: - User proxy Biedt een XML Web service aan die andere services kunnen gebruiken om zo te interageren met de gebruiker. De gebruiker wordt eigenlijk een XML Web service, die alle complexiteit van gebruikersinteractie verbergt. Op elk toestel lijkt de omgeving als een applicatie die speciaal voor dat toestel gebouwd is, terwijl alle applicatie-specifieke gegevens eigenlijk dynamisch naar de klant worden upgeload. - Agenda framework Laat gebruikers en bedrijven toe om hun eigen user environments dynamisch en in real-time te controleren, creëren, aan te passen en te delen. • Overig Business Intelligence kan heel breed opgevat worden en er bestaan dan ook verschillende organisaties die zich uitvoerig met (bepaalde aspecten van) business intelligence bezighouden. Dit kan gaan van data mining, semantic web, decision support systems, data warehousing, . . . Een greep uit deze informatiebronnen: http://www.sigmod.org http://www.businessintelligencetoolbox.com http://businessintelligence.ittoolbox.com/ http://dssresources.com/ http://www.tdwi.org http://www.scip.org/ http://www.teradata.com

2.5.3

Bronnen

http://www.w3.org/2005/Incubator/mmsem/meetings/f2f-athens/2006-12-08-News-Use-Case.ppt http://www.w3.org/2005/Incubator/mmsem/wiki/News Use Case http://www.xbrl.org


40

http://www.musing.eu

http://ieeexplore.ieee.org/Xplore/defdeny.jsp?url=/stamp/stamp.jsp?arnumber=4669678&isnumber=46

http://www.ieeexplore.ieee.org/xpl/freeabs all.jsp?isnumber=4686329&arnumber=4686380&count=309& http://csdl.computer.org/comp/proceedings/hicss/2003/1874/01/187410010b.pdf http://www.heavyreading.com/enterprise/details.asp?sku id=1299&skuitem itemid=967 http://www.unstrung.com/document.asp?doc id=165246 http://www.businessintelligencetoolbox.com http://businessintelligence.ittoolbox.com/ http://dssresources.com/ http://www.tdwi.org http://www.scip.org/

2.6 Mobile BI (2.0)

2.6

41

Mobile BI (2.0)

- Er bestaat een mobiele open-source BI-client voor Pentaho die speciaal ontworpen is voor de iPhone van Apple. Deze client heet Pentaho Mobile. - Business Objects (een dochteronderneming van SAP) maakt een mobiele BI client, genaamd MoBI. Deze is geschreven in J2ME en ontwikkeld voor verschillende GSM toestellen. Deze client is ontworpen om samen te werken met de Business Object XI R2 BI server van hetzelfde bedrijf om BI data weer te geven. - Cognos (een dochteronderneming van IBM) produceert ook een mobiele BI client, genaamd Cognos Go!. Deze client is ontwikkeld om samen te werken met de de Cognos BI software. - Google produceert een mobile client voor het bekende google maps systeem. Dergelijke systemen zijn zeer bruikbaar voor mobiele geografische visualisatie. - Webalo Mobile Dashboard is een mobiele BI client voor Microsoft BI, het BI-systeem van microsoft.

2.7 Pattenten

2.7

42

Pattenten

US 7,383,252 B2: Advanced search algorithm with integrated business intelligence http://www.uspto.gov/web/patents/patog/week23/OG/html/1331-1/US07383252-20080603.html Espacenet

http://v3.espacenet.com/searchResults?locale=nl BE&AB=business+intelligence&compact=false&DB=

Espacenet: zoekwoord business intelligence” ” http://v3.espacenet.com/searchResults?locale=nl BE&TI=business+intelligence&compact=false&DB=E Espacenet: zoekwoord business intelligence 2.0” ” no results

Espacenet: zoekwoord business intelligence mobile” ” http://v3.espacenet.com/searchResults?locale=nl BE&TI=business+intelligence+mobile&compact=fals System and wireless device for providing real-time alerts in response to changes in business operational data http://www.google.com/patents?id=i0p-AAAAEBAJ&dq=Business+Intelligence+mobile Apparatus and method for report invocation and manipulation on a mobile ...

http://www.google.com/patents/pdf/Apparatus and method for report invocati.pdf?id=P1KnAAAAEB

VISION

43

Hoofdstuk 3

Vision 3.1

Mission Statement

De brandweer is zeer gedecentraliseerd en statisch georganiseerd. Een centraal en nationaal BI 2.0 systeem kan een groot stuk van de operationele werking optimaliseren met als doel tijdswinst en mensenlevens te redden. Alle essentiële informatie wordt real-time vergaard. Beslissingen kunnen dan efficinter worden genomen, ook aan de hand van analyses van vroegere gebeurtenissen. Hierbij speelt mobiele interactie een grote rol.

3.2

Key Features

• Binnenkomende oproepen verwerken, categoriseren en prioritiseren Een operator ontvangt oproepen en moet die eenvoudig kunnen ingeven in het systeem. Het systeem stelt ook vragen waarmee de oproep kan gecategoriseerd worden en geprioritiseerd worden volgens ernst. • Resource allocatie van mensen, voertuigen en materieel Aan de hand van de categorie van het incident wordt bepaald hoeveel mensen er nodig zijn, welke voertuigen en welk materieel er moet beschikbaar gesteld worden. • Dynamisch bepalen welke korpsen geschikt zijn om een interventie te doen Het systeem zoekt aan de hand van de locatie van de oproep naar de kazernes die de plaats van het incident het vlugst kunnen bereiken en het benodigde materieel ter beschikking hebben. De kazernes worden na bevestiging van een operator verwittigd.

3.2 Key Features

44

• Real-time registratie van toestand van de interventie en de positie van voertuigen en personeel De positie van alle voertuigen en personeel wordt via GPS tracking systemen bepaald en in het systeem bijgehouden. Personeel ter plaatse geeft via een mobiele interface informatie aan het systeem in verband met de ernst, de vordering en eventuele bijkomende problemen. • Automatische mobiele oproeping van manschappen Manschappen worden via een mobiel oproepingssysteem verwittigd dat ze beschikbaar moeten zijn. Als deze niet bevestigen dat ze kunnen deelnemen aan de oproep zoekt het systeem naar bijkomende manschappen. • Dynamische routebepaling aan de hand van ondermeer de verkeerssituatie Het systeem bepaalt aan de hand van de verkeerssituatie en kennis van het wegennet de snelste route naar de plaats van het incident. Deze route wordt weergegeven via de mobiele interface in elk voertuig. • Evalueren van de toestand ter plaatse en bijkomende manschappen en materieel oproepen Het systeem analyseert aan de hand van de verkregen informatie over de toestand ter plaatse of er extra manschappen of materieel moet opgeroepen worden. Na bevestiging van een operator zal het systeem dan ook extra personeel of voertuigen zoeken en oproepen. • Visualisatie van de toestand De toestand van alle personeel, voertuigen, materieel en incidenten kan aan de operators weergegeven worden door middel van een grafische weergave via een systeem gelijkaardig aan google maps. • Integratie met bestaande rampenplannen Het systeem is op de hoogte van bestaande rampenplannen en als bepaalde rampenpatronen gedetecteerd worden kan het systeem voorstellen om een rampenplan in te schakelen. • Integreerbaar met data warehouse in een klassiek BI systeem Het systeem kan gentegreerd worden met een klassiek BI systeem om informatie vergaard uit het verleden te analyseren via een OLAP interface. • Interfaces voor externe” systemen (bijvoorbeeld andere hulpdiensten) ”

3.3 Quality Attributes

45

Het systeem kan met andere systemen interageren om zo bijkomende informatie te verkrijgen over de toestand van een incident.

3.3

Quality Attributes

• Modifiability flexibiliteit omtrent veranderende mobiele technologie • Availability Zeer belangrijk, systeem moet continu beschikbaar zijn. Eventueel back-up en fallback systemen implementeren. • Performance Real-time, x oproepen/s, x interventies tegelijk, pieken opvangen. • Security Voorkomen dat het systeem gedisabled wordt en gevoelige data beschermen tegen diefstal. • Useability lage latency en eenvoudig te gebruiken • Testability Er moet een simulatiemodus zijn, ook te gebruiken voor review van nieuwe business rules. Via heuristieken moeten correctheid en crashbestendigheid geverifieerd worden. Regression tests?

REQUIREMENTS VIEW

46

Hoofdstuk 4

Requirements View 4.1

Use case scenario’s

4.1.1

Scenario 1: Uitwisselen van event informatie tijdens een interventie

Main succes scenario: Een interventie is aan de gang en de intervention server is actief bezig met het verwerken van informatie. Tijdens een interventie komen er verschillende events voor die moeten opgevangen worden door de server om later evaluaties van de interventie te kunnen uitvoeren alsook om tijdens de interventie te kunnen reageren om bepaalde stimuli. De events opgevangen door de mobile users kunnen zowel regelmatige positie-updates zijn van manschappen alsook events over de interventie. Informatie over het event word verzameld en samengesteld door de Mobile User en vervolgens verzonden naar de Intervention Server. Nadat de intervention server de info ontvangen heeft kan de server de boodschap beginnen te verwerken. De intervention server heeft interne logica die bepaald of andere Mobile Users op de hoogte moeten worden gesteld van het ontvangen event. Vervolgens zal de server eventueel de Mobile Users op de hoogte brengen en de informatie over het event verder verwerken en opslaan voor een latere evaluatie. Exceptions:

• De gekozen interventie server is niet beschikbaar. De centrale server kiest onmiddellijk een nieuwe lokale server die het best aanleunt bij de eerste gekozen lokale server. De centrale server laat dit aan de availability manager weten. Deze laatste gaat na wat het probleem met de interventie server is en onderneemt

4.1 Use case scenario’s

47

de nodige stappen om de interventie server weer online te krijgen. • De intervention server heeft de data niet, verkeerd of corrupt ontvangen. De mobile client probeert de data opnieuw te verzenden en na mislukking word de mobile user hiervan op de hoogte gebracht. • De intervention server kan een Mobile Client niet meer contacteren. De intervention server blijft tijdens de gehele interventie proberen de Mobile Client te contacteren. De informatie moet over bepaalde events moet een verval termijn bevatten waarna de boodschap niet meer van toepassing is. Dit om te voorkomen dat de Mobile Users die terug actief worden overspoeld worden met events die niet meer van toepassing zijn. Preconditions:

• Een interventie is aan de gang en de intervention server is op de hoogte hiervan. • De intervention server weet welke mobile users op welke interventie geplaats zijn. • De intervention server kan elke mobile user uniek indentificeren. • De mobile users hebben een connectie met de intervention server. Postconditions: De intervention server is volledig op de hoogte van de meest recente events en kan de mobile users van real-time informatie voorzien over deze events.


48

Case Scenario 1.jpg

Figuur 4.1: Use Case Scenario 1


49

Diagram Scenario 1.jpg

Figuur 4.2: Sequence Diagram Scenario 1


4.1.2

50

Scenario 2: Behandelen van een oproep en resources bepalen aan de hand van patronen

Main succes scenario: Een oproep komt binnen in de centrale server. Deze gaat na welke operator op dat moment beschikbaar is. De gekozen operator bevestigt dat hij de oproep kan behandelen. Vervolgens geeft hij de data in met betrekking tot de oproep. De centrale server filtert de relevante data, waarna hij deze vergelijkt met bestaande ’business rules’. Deze kunnen bestaan uit standaard rules of gegenereerde rules. Standaard rules zijn ofwel vaak voorkomend of specifiek goed omlijnd (bijvoorbeeld een rampenplan). Gegenereerde rules daarentegen zijn rules die opgesteld worden aan de hand van de analyse van eerdere interventies. Van zodra er een patroon herkent wordt uit bovenstaande standaard rules, wordt nagegaan welk korps, welke manschappen en welk materieel er op dat moment voorhanden is om de interventie te kunnen uitvoeren. Eenmaal deze set aan resources is bepaald, wordt er nagegaan of er nog extra resources nodig zijn. Deze worden zoals hierboven beschreven bepaald aan de hand van interventies uit het verleden die een gelijkaardig patroon vertonen met de huidige oproep. Eens de centrale server alle nodige resources heeft bepaald, moet de operator dit bevestigen. Van zodra deze dit gedaan heeft, contacteert de centrale server de best beschikbare interventie server. Deze interventie server laat weten of hij beschikbaar is en de toegewezen taak aankan. Daarna stuurt de centrale server alle nodige data door naar de interventie server. Tot slot bevestigt de interventie server dat alle data goed ontvangen is en laat de centrale server dit weten aan de operator. Exceptions:

• De centrale server vindt geen beschikbare operator. De centrale server gaat na welke operator op dat moment een oproep met laagste prioriteit heeft en waarschuwt deze operator. De operator zet de oproep waarmee hij op dat moment bezig was ’on hold’ en beantwoordt de binnengekomen oproep. Indien er dan een operator vrijkomt, kan de centrale server beslissen om de oproep die ’on hold’ staat aan deze operator toe te wijzen. In het slechtste geval wanneer er geen operator met lage prioriteit beschikbaar is en het dus niet aangewezen is om een operator te onderbreken of wanneer een operator nog geen prioriteit toegewezen gekregen heeft - omwille van het feit dat een oproep nog maar net begonnen is - zal de centrale server de binnengekomen oproep die dus op dat moment door geen enkele operator kan behandeld worden in een


51

wachtrij plaatsen en de oproeper op de hoogte stellen dat hij even geduld moet hebben. • De centrale server vindt geen enkel patroon terug in de standaard of gegenereerde rules. De centrale server stelt de operator hier van op de hoogte. De centrale server zal zelf een resource allocatie doen en deze ter bevestiging voorleggen aan de operator. Deze laatste moet ofwel zijn akkoord geven of eventueel aanpassingen maken in de door de centrale server voorgestelde suggestie. Belangrijk hierbij is dat de operator een controlerende rol speelt. • De gekozen interventie server is niet beschikbaar. De centrale server kiest onmiddellijk een nieuwe lokale server die het best aanleunt bij de eerste gekozen lokale server. De centrale server laat dit aan de availability manager weten. Deze laatste gaat na wat het probleem met de interventie server is en onderneemt de nodige stappen om de interventie server weer online te krijgen. • De lokale server heeft de data niet, verkeerd of corrupt ontvangen. De operator wordt hier van op de hoogte gesteld. De operator kan de centrale server de opdracht geven om een andere interventie server aan te spreken en om het proces van het versturen van data opnieuw uit te voeren. Indien de operator dit wenst kan hij dit proces ook automatiseren waardoor zijn tussenkomst niet meer nodig is. Preconditions:

• De centrale server moet online zijn (wat steeds het geval zou moeten zijn). Indien niet dan is het de taak van de availability manager om er voor te zorgen dat dit wel zo is. • Er moet minstens 1 operator aanwezig zijn (al dan niet bezet). • Er moet minstens 1 interventie server aanspreekbaar zijn. • Een minimum set aan resources moet steeds voorhanden zijn. Postconditions: De operator ontvangt een bevestiging van de centrale server dat de interventie server de data goed ontvangen heeft. Dit is het moment waarop de operator weer beschikbaar wordt voor een volgende oproep.


52

Case Scenario 2.jpg



53




4.1.3

54

Scenario 3: Real-time analyseren van de toestand ter plaatse en geven van online informatie

Main succes scenario: Een mobile client (bijvoorbeeld een commandant) kan met behulp van een mobiel toestel informatie doorgeven en opvragen met betrekking tot de interventie ter plaatse. Een interventie server staat in voor de communicatie met de mobile client. Een mobile client kan beslissen dat er voor een interventie die aan de hang is, extra resources nodig zijn. Hij kan eveneens bijkomende informatie opvragen. Hij doet deze aanvraag uiteraard via zijn mobiel toestel. De interventie server ontvangt deze aanvraag en verifieert de mobile client. Vervolgens zal hij nagaan in hoeverre deze aanvraag kan beantwoord worden met de data die momenteel in de interventie server voorhanden is. Indien dit niet het geval is, dan zal de interventie server de extra data opvragen bij de centrale server. De centrale server analyseert vervolgens de nodige data en kijkt welke resources er op dat moment (nog) beschikbaar zijn of welke data er nodig is om de aanvraag te kunnen beantwoorden. Eenmaal de set aan resources is gekend, stuurt de centrale server deze door naar de interventie server. De interventie server zal dan op zijn beurt de data doorsturen naar de mobile client. Deze moet dan bevestigen of het voorgestelde antwoord voldoet aan zijn verwachtingen. Eventueel kan hij een keuze maken uit verschillende alternatieven mocht dit het geval zijn. Merk op: resources kunnen in dit geval twee betekenissen hebben. Enerzijds kan het de informatie zijn die de commandant nodig heeft (bijvoorbeeld de dichtst bijgelegen watervoorziening in geval van een grote brand). Anderzijds kunnen het uiteraard ook extra manschappen of materieel zijn die de commandant nodig acht om de interventie tot een goed einde te brengen. Exceptions:

• De interventie server is niet bereikbaar via de mobile client. De availability manager wordt hiervan op de hoogte gesteld. Deze probeert de verbinding tussen de mobile client en de interventie server weer in orde te maken. Indien dit niet lukt vraagt hij aan de centrale server of er een andere interventie server beschikbaar is om met de mobile client verbonden te worden. • Er zijn geen resources meer beschikbaar om aan de extra vraag te voldoen of bijkomende informatie is niet gekend. De mobile client wordt hiervan op de hoogte gesteld.


55

• De mobile client krijgt verkeerde, onleesbare of corrupte data. De mobile client doet de aanvraag opnieuw. Wanneer deze poging nog eens mislukt kan de mobile client rechtstreeks contact opnemen met een operator die de mobile client dan voorziet van de nodige data. Deze nodige data wordt dan uiteraard aangeleverd door de centrale server. Preconditions:

• De mobile client moet online zijn. • De verbinding tussen de mobile client en interventie server moet aanwezig zijn. • De interventie server moet extra data kunnen opvragen aan de centrale server. • De centrale server moet online zijn. Postconditions: De mobile client kan twee soorten antwoorden op zijn aanvraag krijgen. Enerzijds dat er niet aan zijn aanvraag kan voldaan worden omdat bijvoorbeeld alle resources uitbesteed zijn of omdat er geen bijkomende informatie kan verschaft worden. Anderzijds wanneer er wel aan de vraag kan voldaan worden (al dan niet gedeeltelijk) moet de mobile client bevestigen dat het antwoord in overeenstemming is met zijn verwachtingen. Van zodra deze bevestiging er is, is dit het teken voor de interventie server om zijn data te gaan updaten.


56

Case Scenario 3.jpg



57



4.2 Quality attribute scenario’s

4.2 4.2.1

58

Quality attribute scenario’s Availability

Availability gaat over fouten en de gevolgen van deze fouten voor het systeem. Eerst en vooral kan availability uitgedrukt worden als: MTBF/(MTBF + MTTR). Gezien we hier te maken hebben met een applicatie voor de hulpdiensten moet de availability heel hoog zijn. Het systeem is 99,99% van de tijd beschikbaar. Dit komt neer op een downtime van ongeveer 50 minuten op een heel jaar.

Figuur 4.7: QA Availability Om de availability van ons systeem te garanderen hebben we een aparte module in onze architectuur opgenomen: de availability manager. Deze zorgt ervoor dat de availability van ons systeem, en meer bepaald van de centrale server en de interventieserver, zo hoog mogelijk is. Fault detection Om de liveness van de servers te controleren zendt de availability manager constant pingberichten naar de servers, die hierop moeten antwoorden met een echo-bericht. Dit is de snelste manier voor de availability manager om te weten te komen als er een server is uitgevallen. Recovery Als een server is uitgevallen, zal dit opgemerkt worden door de availability manager. Deze zal geen echo-berichten meer krijgen op zijn uitgezonden ping-berichten.


59

Een passive redundancy component kan dan echter onmiddellijk de taak van de uitgevallen server opnieuw overnemen. Uiteraard moet er dan wel gezorgd worden voor de nodige synchronisatie met deze stand-by component. Prevention Het is echter verstandig om de stand-by component al in te schakelen voor een server uitvalt. Wanneer een bepaalde server een afwijkend gedrag vertoont, kun je deze even uit operatie halen om eventuele fouten te herstellen. De stand-by component neemt dan gewoon de taken van de weggehaalde server over.

4.2.2

Performance

Performance gaat over hoe lang het duurt vooraleer het systeem gepaste actie onderneemt wanneer een evenement zich voordoet. Bij dit systeem is performance heel erg belangrijk aangezien n van de belangrijkste doelstellingen van het systeem eruit bestaat om tijdswinst te boeken. De verschillen taktieken zullen toegepast worden en gevalueerd tegen onze bestaande architectuur.

Figuur 4.8: QA Performance


60

Eerste iteratie De architectuur is opgedeeld in een centrale server en meerdere intervention servers. Eens een intervention gestart is wordt er zoveel mogelijk uitgevoerd op de intervention server waardoor de centrale server qua resources minimaal belast wordt. Doordat er geen architecturale beperking is op het aantal intervention servers is de resource consumption voor de intervention servers slechts per interventie geplafonneerd. De intervention servers zijn wel computationeel, evenwel beperkt, afhankelijk van de centrale server bij uitzonderlijke situaties waar kennis van de globale toestand vereist is (zoals bijvoorbeeld bij het vragen naar extra korpsen tijdens een interventie). De centrale ActionManager De ActionManager in de centrale server is de plaats waar een groot aantal events verwerkt worden en waar performance dus zeer kritiek is. Bij de implementatie hiervan zal dus extra aandacht moeten besteed worden aan de performance van deze module. De latency voor de verwerking van events mag niet meer dan enkele seconden bedragen. Het afhandelen van oproepen moet binnen enkele seconden kunnen gebeuren. De oproepen zullen binnenkomen als een stochastisch proces (met Poisson verdeling), maar er is een redelijke bovengrens van het aantal oproepen per seconde mogelijk, te bepalen aan de hand van een statistisch onderzoek van gebeurtenissen uit het verleden. Veel events zullen de ActionManager op de centrale server blokkeren en er zal dus resource contention plaatsvinden in die ActionManager. Een oplossing hiervoor is het prioritiseren van events zoals bijvoorbeeld het prioritiseren van oproepen boven visualisatie. De Pentaho module (BI 1.0 systeem) De Pentaho module is niet performance kritiek en heeft dus best een grote invoerbuffer zodat gebeurtenissen die moeten toegevoegd worden aan het systeem uitgespreid kunnen worden (en desnoods op kalmere momenten verwerkt kunnen worden). De informatie die het pentaho systeem genereert is niet onmiddellijk nodig aangezien dit enkel gebruikt wordt als logboek en om heurisitieken te genereren. De Intervention Servers Het aantal interventies die tegelijk aan de gang kunnen zijn mag zeer hoog zijn zonder dat de performance negatief benvloedt wordt aangezien elke interventie over eigen resources kan beschikken. Tijdens een interventie kan een redelijke bovengrens gesteld worden door het maximale aantal inzetbare manschappen en voertuigen voor een interventie na te gaan en door een statistische studie van interventies uit het verleden.


61

Daarbovenop kunnen bepaalde events geprioritiseerd worden, zoals bijvoorbeeld aanvragen voor bijkomende voertuigen en manschappen kan geprioritiseerd worden boven visualisatie. Het is dan wel belangrijk om de performance te meten zodat de gebruiker op de hoogte kan gesteld worden van eventuele latency.

4.2.3

Modifiability

De focus is hier op de Quality Attribute Modifiability en word besproken aan de hand van verschillende tactieken die gebruikt worden om goede modifiability te verzekeren. De verschillen taktieken zullen toegepast worden en gevalueerd tegen onze bestaande architectuur.

Figuur 4.9: QA Modifiability Localize Changes Deze taktiek is gebaseerd op het toewijzen van verantwoordelijkheden aan de juiste module. De verantwoordelijkheden van de modules kunnen best niet teveel gedeeld worden onder verschillende modules omdat wijzigingen in de scope van die verantwoordelijkheden dus kunnen lijden tot de wijziging van meerdere modules. Het is dus cruciaal om de juiste verantwoordelijkheid toe te wijzen aan de juiste module en de architectuur logisch om te bouwen. Dit zal wijzigingen localiseren. De opsplising van onze architectuur in zowel een locale als een centrale server verdeeld verantwoordelijkheden over het afhandelen van oproepen. De locale server kan op deze manier een verantwoordelijkheid worden toebedeeld zonder de details van de implementatie te kennen. In


62

principe kunnen zelfs locale servers met een verschillende implementatie ingezet worden. In een latere iteratie zijn de server-architecturen nog verder uitgewerkt en is er gekozen voor een logische onderverdeling van verantwoordelijkheden. Ripple Effect Bij een modificatie kan het zijn dat een wijziging op een bepaalde plaats een significate wijziging kan opleveren in een module die niets te maken heeft met de module waarin de wijzigingen moeten gebeuren. Bijvoorbeeld: Wijzigingen in de signatuur van de interface van een module kan ervoor zorgen dat een andere module, die gebruik maak van, moet aangepast worden terwijl deze misschien niets te maken heeft met de verantwoordelijkheden die gewijzigd moeten worden. Dit kan voorkomen worden op verschillende manieren, ook inherent aanwezig in onze architectuur. Een goede manier om een Ripple Effect te voorkomen is het afschermen van data. Het afschermen van data kan dus ook door de juiste verantwoordelijken toe te wijzen aan de juiste module en dus door het afschermen van data enkel gebruikt door de module met bepaalde verantwoordelijkheden. Het gebruik van onze Message Managers, zowel op de local server als de central server zorgt mede voor de modifiability door de verantwoordelijkheid van de messaging op n plaats te leggen. Door de messages te laten passeren door n module is de kans op het Ripple Effect vl kleiner en zijn de modules minder van elkaar afhankelijk. Wijzigingen of extensies op de gestuurde messages kunnen afgehandeld worden in deze module en abstratie maken van de wijzigingen voor de andere modules. Defer Binding Time Deze taktiek is van toepassing op deployment na gemaakte wijzigingen of wijzigingen zonder dat een developer effectief de module moet wijzigen.Via configuratie bestanden bijvoorbeeld. Onze architectuur ondersteund het toevoegen/verwijderen van locale servers zoveel of zo weinig als nodig.De severs kunnen dus ook in een live systeem vervangen worden. De centrale server vereist extra aandacht als het op deze taktiek aankomt.

ADD ITERATIE 1: MODULE VIEW

63

Hoofdstuk 5

ADD iteratie 1: Module View Onze key architectural drivers zijn availability, performance en modifiability. Aangezien we een applicatie voor de hulpdiensten, in dit geval de brandweer, uitwerken zetten we availability op de eerste plaats. Performance is ook belangrijk in de zin dat het belangrijk is dat deadlines gehaald worden en niet zozeer dat er gestreefd wordt naar een zeer lage latentie. Modifiability, ten slotte, is ook zeer wenselijk voor de onderhoudbaarheid van de software en integreerbaarheid met reeds bestaande software. In de eerste iteratie ziet onze architectuur er als volgt uit.

Figuur 5.1: ADD iteratie 1


64

We delen de applicatie op in 3 grote delen: een Centrale Server, een Interventie Server en een Availability Manager. De Centrale Server is verantwoordelijk voor het verwerken van de oproepen doorgegeven door de operator. De Centrale Server zorgt dus voor de globale coordinatie van alle interventies. De Interventie Server houdt zicht uitsluitend bezig met n interventie.De Availibility Manager legt zich toe op het garanderen van een zo hoog mogelijke availability, zowel van de Centrale Server als van de Interventie Server. We hebben geopteerd voor event-based system omdat er real-time interactie vereist is tussen de operator en de Centrale server en tussen de Centrale Server en de Interventie Server. De mobile en desktop clients zijn thin clients, ze worden enkel gebruikt voor input en output. Alle componenten interageren met elkaar aan de hand van messages. Naar availibility toe heeft het opdelen van de software in een Centrale Server gedeelte en een Interventie Server grote voordelen. Wanneer tijdens een interventie de Centrale Server wegvalt kan de interventie gewoon doorgaan op de Interventie Server. Ondertussen kan de Availability Manager de Centrale Server terug operationeel krijgen. Wanneer een Interventie Server uitvalt zal de Availibility Manager dit opmerken en de Centrale Server op de hoogte brengen. Deze zal dan een andere Interventie Server toekennen aan het incident. Ook voor performance heeft deze opdeling voordelen: de Centrale Server zal meer oproepen aankunnen aangezien deze zich niet meer moet bezighouden met de eigenlijke interventie. Bovendien is het garanderen van het halen van een deadline makkelijker dan zouden alle oproepen naar n centrale server gaan. De modifiability van de code wordt tevens vergroot aangezien de code van de Interventie Server onveranderd kan blijven bij aanpassingen aan de Centrale Server en vice versa. Bovendien zullen we werken met een Message Manager(zie 2e iteratie). Deze abstraheert de implementatiedetails van het versturen van berichten, zodanig dat de software niet aangepast moet worden indien de technologie van het communicatiemedium verandert. In de tweede iteratie zullen we dieper ingaan op de architectuur van de Centrale Server en de Interventie Server.


65

Hoofdstuk 6

ADD iteratie 2: Module View 6.1

De Centrale Server

Figuur 6.1: ADD iteratie 2 - centrale server De Centrale Server is het hart van de software. Deze bevat Pentaho en dus alle mogelijke informatie die over de jaren is verzameld. De Centrale Server is een rule-based system. Het

6.2 De Interventie Server

66

is hier dat de intelligentie van het systeem gecentraliseerd is. De Action Manager neemt, aan de hand van de regels en gegevens in de Knowledge Base, de nodige beslissingen. Hij is zowel verantwoordelijk voor het verwerken van oproepen van operators als voor het verwerken van oproepen van Interventie Servers (bvb. de aanvraag van nieuwe data of extra resources). De Update Manager is verantwoordelijk voor het verzamelen van alle mogelijke informatie. Op het einde van elke interventie zal de Interventie Server de verzamelde gegevens van die Interventie doorsturen naar de Centrale Server. De kazernes beheren hun resources ook door met de Centrale Server te communiceren. De Update Manager moet al deze gegevens op gepaste wijze in Pentaho inbrengen. Bij elke belangrijke verandering(bvb. nieuwe kazerne of verhuizen van een kazerne), of wanneer fouten gedetecteerd worden, kunnen nieuwe regels gecreerd worden vanuit Pentaho en opgeslagen in de Knowledge Base. Het genereren van regels gebeurt dus off-line, wat zeer belangrijk is voor performance. Deze regels bepalen, bij het toekomen van een incident, welke kazerne wordt opgeroepen en hoeveel wagens, personeel en materiaal moet vertrekken bij het binnenkomen van een incident. Het is de bedoeling dat enkel desktop clients en de Interventie servers met de Central server kunnen communiceren. De desktop clients zijn de operators, die de noodoproepen ontvangen en doorsturen naar de Centrale Server. Per kazerne is er nog een desktop om de resources ervan(hoeveelheid aanwezige personeel, materiaal,) te beheren. Deze gegevens worden in Pentaho en in de Knowledge Base van de Centrale Server opgeslagen.

6.2

De Interventie Server

Nadat beslist is welke kazerne opgeroepen wordt, wordt door de Centrale Server een Interventie Server toegekend aan het incident. Deze heeft een Pipes and Filters architectuur. We hebben hiervoor geopteerd omdat de Interventie Server geen echte intelligentie bevat. Het moet gewoon binnenkomende berichten parsen en de nodige acties ondernemen. De Registration Manager registreert alle mogelijke informatie over het incident: gps coordinaten, berichten die verstuurd zijn geweest en beslissingen die genomen zijn geweest. Hij is ook verantwoordelijk om na de interventie al deze informatie naar de Centrale Server te sturen op een passend moment. De Execution Manager voert instructies uit die het krijgt van de centrale server of de

6.2 De Interventie Server

67

Figuur 6.2: ADD iteratie 2 - interventie server mobile clients. Wanneer de Centrale Server niet reageert op een oproep zal de Execution Manager gewoon kunnen verder werken. Wanneer de Availability Manager te kennen geeft dat de Centrale Server terug beschikbaar is zal deze zijn oproep terug opsturen. Het is de bedoeling dat de real-time interactie met de mobile clients in de Interventie Server plaatsvindt. Er is zowel interactie tussen de mobile clients als tussen de Interventie Server en de mobile Clients. Elke mobile client krijgt alle nodige informatie over de interventie die aan de gang is. Zoals hierboven ook impliciet duidelijk was: de Interventie Servers kunnen communiceren met de Central Server. Dit zal bijvoorbeeld nodig zijn om extra materiaal op te roepen als blijkt dat het incident erger was dan verwacht.

INFRASTRUCTURE VIEW

68

Hoofdstuk 7

Infrastructure view Diagram1.jpg

Figuur 7.1: Deployment Diagram

7.0.1

Centrale Server

Op de centrale server worden alle intelligente beslissingen genomen door de server applicatie. Hier wordt beslist welke data naar welke interventie server moet nadat een oproep is binnengekomen en bevestigd. De server bevat de centrale applicatie alsook de pentaho omgeving. Met de centrale server kan een client computer verbonden worden opdat de oproepen afge-

INFRASTRUCTURE VIEW

69

handeld zouden kunnen worden. Ook visualisatie van de verschillende lopende interventies en bezetting van brandweer resources is hierbij mogelijk. Het besturingssysteem is niet verder opgegeven. Die beslissing kan later in een fase van implementatie genomen worden.

7.0.2

Interventie Server

De interventie server ontvangt alle nodige data van de centrale server om tijdens een interventie actief te kunnen zijn. De interventie server staat in onmiddellijke verbinding met de mobiele clients, alsook de GPS clients. Via de intervention application stuurt de interventie server visualisatiegegevens door naar de clients. De clients zelf sturen info door over de interventie, zoals bijvoorbeeld GPS-cordinaten. Een real-time database zorgt er hier voor dat alles snel kan verlopen. Ook hier kan het besturingssysteem later bepaald worden tijdens de implementatiebeslissingen.

ALGEMEEN BESLUIT

70

Hoofdstuk 8

Algemeen besluit Dit project heeft ons duidelijk gemaakt dat de software architecture voor een bepaald probleem niet van vandaag op morgen is samengesteld. Het heeft ons de mogelijkheid gegeven om op een zo goed mogelijk manier, in groep, gedachten uit te wisselen en die op een gepaste manier, met de gepaste tools/moddellen/views/. . . in kaart te brengen. We hebben geprobeerd om onze gedachtengang zo goed mogelijk neer te pennen. Bij deze zou het mogelijk moeten zijn om iemand te informeren over het project die er totaal niet van op de hoogte is. Anderzijds proberen we ook ons concept verkoopbaar te maken. We zoeken met onze uiteenzetting mogelijke genteresseerden die met ons op de kar kunnen springen om tot een eventuele implementatie en verdere uitdieping van dit project over te gaan. Hulpdiensten als thema was slechts een leidraad om de problematiek wat specifieker, niet alledaagse en boeiend te maken. Van het vrij abstract begrip BI 2.0 hebben we gepoogd een leuk project in elkaar te stoppen. Niets houdt ons echter tegen om het project toe te passen op een ander domein waar ook aan resource management gedaan moet worden. Een aantal concepten van de cursus werden hier uitgewerkt met als doel vertrouwd te raken met de knepen van het vak software architecture”. Ik hoop dat we er hierbij, als groep, in ” geslaagd zijn enige kennis van dergelijke concepten voor te leggen. Tot slot wil ik mijn teamleden, alsook onze begeleider, bedanken voor de energie die ze in dit project hebben gestopt. Na heel wat brainstorm sessies, stress, moeilijke bijeenkomsten omwille van de niet normale samenstelling van de groep, . . . ben ik enigszins toch tevreden over de deliverable die we nu mogen afleveren. Project Manager, Olivier Rosseel.

BIBLIOGRAFIE

71

Bibliografie [1] Zie SOTA... [2] L. Bass, P. Clements, R. Kazman, “Software Architecture in Practice Second Edition”, Pearson Education, ISBN 0-321-15495-9.

LIJST VAN FIGUREN

72

Lijst van figuren 2.1

Pentaho architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

2.2

Dashboard voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

2.3

Reporting voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

2.4

Data Mining voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

2.5

Solution Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

2.6

Runtime Engine

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

2.7

Runtime Engine - External Sources . . . . . . . . . . . . . . . . . . . . . . . . . .

30

2.8

API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

2.9

Deployment as Lib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

2.10 Deployment as Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

2.11 Deployment - Disjunct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

2.12 Deployment - Single . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

2.13 Data Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

4.1

Use Case Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

4.2

Sequence Diagram Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

4.3


52

4.4


53

4.5


56

4.6


57

4.7

QA Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

4.8

QA Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

4.9

QA Modifiability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

5.1

ADD iteratie 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

LIJST VAN FIGUREN

73

6.1

ADD iteratie 2 - centrale server . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

6.2

ADD iteratie 2 - interventie server . . . . . . . . . . . . . . . . . . . . . . . . . .

67

7.1

Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

Realtime Resource Management met BI 2.0

Recommend Documents