Literatuurstudie naar de bekendste raamwerken voor...
Transcript of Literatuurstudie naar de bekendste raamwerken voor...
UNIVERSITEIT GENT
FACULTEIT ECONOMIE EN BEDRIJFSKUNDE
ACADEMIEJAAR 2011 – 2012
Literatuurstudie naar de bekendste raamwerken voor enterprise architectuur
Masterproef voorgedragen tot het bekomen van de graad van
Master of Science in de
Toegepaste Economische Wetenschappen: Handelsingenieur
Astrid Van Acker
onder leiding van
Prof. Dr. G. Poels
PERMISSION
Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of
gereproduceerd worden, mits bronvermelding.
Astrid Van Acker
I
WOORD VOORAF
Het schrijven van deze masterproef heeft mij veel tijd en inspanning gekost, maar mij tegelijk
ook veel voldoening geschonken. Hierbij zou ik dan ook graag gebruik willen maken van de
gelegenheid om alle mensen te bedanken. Hun steun en hulp was voor mij heel belangrijk bij de
totstandkoming van deze masterproef.
Op de eerste plaats wil ik een speciaal woordje van dank richten aan mijn promotor Prof. Dr. G.
Poels en begeleidster Mevrouw E. Dequidt voor de goede opvolging en begeleiding van mijn
thesis.
Daarnaast gaat mijn dankwoord uit naar het bedrijf AE. Dankzij enkele mensen van dit bedrijf
kreeg ik de kans om een workshop over enterprise architectuur bij te wonen. Dit heeft mij heel
wat inzicht in het onderwerp bijgebracht.
Verder wil ik ook graag Sylvie Van Acker, Annabelle De Blieck en Peter Depypere bedanken. Zij
waren bereid mijn masterproef grondig na te lezen, wat enorm werd geapprecieerd.
Een woord van dank gaat tevens uit naar mijn ouders voor hun morele en financiële steun
gedurende mijn volledige academische opleiding aan de Universiteit van Gent.
Tot slot wil ik ook mijn vrienden bedanken. Hun steun was essentieel.
II
INHOUDSOPGAVE
Algemene inleiding ............................................................................................................................................................ 1
DEEL I: Literatuurstudie.................................................................................................................................... 3
Hoofdstuk 1: Enterprise Architectuur toegelicht ................................................................................................. 4
1.1. Positionering en definitie .................................................................................................................................. 4
1.2. Drijfveren en voordelen van EA ...................................................................................................................... 6
1.3. EA: product of proces .......................................................................................................................................... 7
Hoofdstuk 2: EA raamwerken ....................................................................................................................................... 8
2.1. Definitie..................................................................................................................................................................... 8
2.2. Eigenschappen ....................................................................................................................................................... 8
2.3. Overzicht EA raamwerken ............................................................................................................................. 10
2.4. Optimaal blended raamwerk ........................................................................................................................ 11
Hoofdstuk 3: EA raamwerken toegelicht .............................................................................................................. 12
3.1. Zachman ................................................................................................................................................................ 12
3.1.1. Opbouw ......................................................................................................................................................... 12
3.1.1.1. Perspectieven ..................................................................................................................................... 13
3.1.1.2. Inhoudsdimensies ............................................................................................................................ 14
3.1.1.3. Cellen ...................................................................................................................................................... 15
3.1.1.4. Regels ..................................................................................................................................................... 16
3.1.2. Voordelen en tekortkomingen ............................................................................................................. 16
3.2. TOGAF ..................................................................................................................................................................... 18
3.2.1. Opbouw ......................................................................................................................................................... 18
3.2.1.1. Architecture development method ........................................................................................... 18
3.2.1.2. Enterprise continuüm ..................................................................................................................... 20
3.2.1.3. Resource base ..................................................................................................................................... 22
3.2.2. Voordelen en nadelen .............................................................................................................................. 22
3.3. Integrated Architecture Framework ......................................................................................................... 22
3.3.1. Opbouw ......................................................................................................................................................... 22
III
3.3.2. Voordelen en nadelen .............................................................................................................................. 24
3.4. Federal Enteprise Architecture Framework (FEAF) .......................................................................... 24
3.4.1. Opbouw ......................................................................................................................................................... 24
3.4.1.1. Algemene methode .......................................................................................................................... 24
3.4.1.2. FEAF matrix ......................................................................................................................................... 26
3.4.1.3. Referentiemodellen ......................................................................................................................... 26
3.4.2. Voordelen en nadelen .............................................................................................................................. 27
Hoofdstuk 4: EA raamwerken vergeleken ............................................................................................................ 28
4.1. Zachman ................................................................................................................................................................ 28
4.1.1. Type informatie .......................................................................................................................................... 28
4.1.2. Bereik ............................................................................................................................................................. 28
4.1.3. Detailniveau ................................................................................................................................................. 28
4.1.4. Aard ................................................................................................................................................................. 29
4.1.5. Belanghebbenden ...................................................................................................................................... 29
4.1.6. Taxonomie- en procesvolledigheid .................................................................................................... 29
4.2. The Open Group Architecture Framework (TOGAF) .......................................................................... 29
4.2.1. Type informatie .......................................................................................................................................... 29
4.2.2. Bereik ............................................................................................................................................................. 30
4.2.3. Detailniveau ................................................................................................................................................. 30
4.2.4. Aard ................................................................................................................................................................. 30
4.2.5. Belanghebbenden ...................................................................................................................................... 30
4.2.6. Taxonomie- en procesvolledigheid .................................................................................................... 30
4.3. Integrated Architecture Framework (IAF).............................................................................................. 30
4.3.1. Type informatie .......................................................................................................................................... 30
4.3.2. Bereik ............................................................................................................................................................. 31
4.3.3. Detailniveau ................................................................................................................................................. 31
4.3.4. Aard ................................................................................................................................................................. 31
4.3.5. Belanghebbenden ...................................................................................................................................... 31
IV
4.3.6. Taxonomie- en procesvolledigheid .................................................................................................... 32
4.4. Federal Enterprise Architecture Framework (FEAF) ......................................................................... 32
4.4.1. Type informatie .......................................................................................................................................... 32
4.4.2. Bereik ............................................................................................................................................................. 32
4.4.3. Detailniveau ................................................................................................................................................. 32
4.4.4. Aard ................................................................................................................................................................. 33
4.4.5. Belanghebbenden ...................................................................................................................................... 33
4.4.6. Taxonomie- en procesvolledigheid .................................................................................................... 33
4.5. Vergelijking .......................................................................................................................................................... 33
4.6. Besluit van de vergelijking ............................................................................................................................. 35
Hoofdstuk 5: Besluit literatuurstudie ..................................................................................................................... 37
DEEL II: Gevallenstudie ................................................................................................................................... 38
Hoofdstuk 6: Inleiding Gevallenstudie ................................................................................................................... 39
6.1. KwaliCar ................................................................................................................................................................ 40
6.2. Assumpties ........................................................................................................................................................... 40
Hoofdstuk 7: Het Zachman Raamwerk uitgewerkt ........................................................................................... 41
7.1. Assumptie ............................................................................................................................................................. 41
7.2. Integratie gap ...................................................................................................................................................... 42
7.3. Methode van Pereira & Sousa ....................................................................................................................... 43
7.3.1. Stap 1: Het bereik ...................................................................................................................................... 45
7.3.2. Stap 2: Conceptuele gegevensmodellering ..................................................................................... 48
7.3.3. Stap 3: Business proces modellering en logische data modellering .................................... 51
7.3.4. Stap 4: Business locaties, functies van het informatiesysteem, tijdsequentie van de
business activiteiten en business motivatie ............................................................................................... 55
7.3.5. Stap 5: Organogram, systeemcontext, systeemtriggers en business rules ....................... 67
7.3.6. Stap 6: Systeemgebruikers .................................................................................................................... 70
7.4. Overzicht gebruikte artefacten .................................................................................................................... 71
7.5. Alternatieve artefacten .................................................................................................................................... 71
V
Hoofdstuk 8: Overzicht van de gaps in het Zachman raamwerk ................................................................. 74
8.1. Integratie gap ...................................................................................................................................................... 74
8.2. Representatie gap .............................................................................................................................................. 75
8.3. Proces gap ............................................................................................................................................................. 75
Hoofdstuk 9: Integreren van het Zachman raamwerk en de ADM van TOGAF ..................................... 77
9.1. Het Zachman raamwerk .................................................................................................................................. 77
9.2. De ADM van TOGAF .......................................................................................................................................... 77
9.3. Complementariteit van Zachman en de ADM van TOGAF ................................................................ 78
9.3.1 Algemeen ....................................................................................................................................................... 78
9.3.2 Fasen ................................................................................................................................................................ 79
Hoofdstuk 10: Het overkoepelend raamwerk uitgewerkt ............................................................................. 83
10.1. Preliminary fase ............................................................................................................................................... 83
10.2. Architecture vision fase ................................................................................................................................ 84
10.3. Business/ IS / Technology architecture fase ....................................................................................... 84
10.4. Opportunities & solutions fase .................................................................................................................. 85
10.5. Migration planning fase ................................................................................................................................ 86
10.6. Implementation governance ...................................................................................................................... 87
10.7. Architecture change management ........................................................................................................... 87
10.8. Volgende iteraties ........................................................................................................................................... 87
DEEL III: Algemeen Besluit .......................................................................................................................... 88
Lijst van figuren .............................................................................................................................................................. VII
Lijst van tabellen .............................................................................................................................................................. IX
Lijst van de geraadpleegde werken ............................................................................................................................ X
Bijlagen .............................................................................................................................................................................. XVI
Bijlage 1: TOGAF content framework .............................................................................................................. XVI
Bijlage 2: TOGAF content metamodel .............................................................................................................XVII
VI
Bijlage 3: De balanced score card van Kwalicar ....................................................................................... XVIII
Bijlage 4: Business motivation model ............................................................................................................. XXII
VII
LIJST VAN FIGUREN
Figuur 1.1: EA gesitueerd in het Amsterdam Information Management Model (AIM) van Rik
Maes ......................................................................................................................................................................................... 5
Figuur 1.2: Enterprise architectuur als management instrument ................................................................. 6
Figuur 1.3: Architectuurdomeinen ............................................................................................................................. 7
Figuur 2.1: Gebruik van EA raamwerken in ondernemingen (IFEAD, 2005) ........................................ 11
Figuur 3.1: Het Zachman raamwerk........................................................................................................................ 13
Figuur 3.2: Artefacten in het Zachman raamwerk (Pereira & Sousa, 2004) .......................................... 15
Figuur 3.3: Structuur en componenten van TOGAF .......................................................................................... 18
Figuur 3.4: De ADM ........................................................................................................................................................ 19
Figuur 3.5: Relatie tussen het enterprise continuüm en de ADM ............................................................... 21
Figuur 3.6: Integrated Architecture Framework ............................................................................................... 23
Figuur 3.7: Federal Enterprise Architecture Framework .............................................................................. 25
Figuur 3.8: FEAF matrix ............................................................................................................................................... 26
Figuur 4.1: De besproken EA raamwerken: taxonomie of proces .............................................................. 35
Figuur 7.1: Methode van Pereira & Sousa ............................................................................................................. 43
Figuur 7.2: Set van voorgestelde artefacten door Pereira & Sousa ............................................................ 45
Figuur 7.3: EER diagram .............................................................................................................................................. 50
Figuur 7.4: BPMN diagram .......................................................................................................................................... 52
Figuur 7.5: e3 value model ........................................................................................................................................... 53
Figuur 7.6: Data map ..................................................................................................................................................... 55
Figuur 7.7: Schema van locaties en connecties ................................................................................................... 56
Figuur 7.8: Het intern informatiesysteem in contact met de file server en met haar gebruikers . 58
Figuur 7.9: Use case diagram ..................................................................................................................................... 60
Figuur 7.10: Gantt chart ............................................................................................................................................... 62
Figuur 7.11: Strategy map ........................................................................................................................................... 63
Figuur 7.12: BMM van KwaliCar ............................................................................................................................... 65
Figuur 7.13: Organogram van KwaliCar ................................................................................................................ 67
VIII
Figuur 7.14: Systeem context diagram ................................................................................................................... 68
Figuur 7.15: UML sequence diagram voor de use case ‘Creëer nieuwe klantfile’ ................................ 69
Figuur 7.16: Use case diagram ................................................................................................................................... 70
Figuur 9.1: Relatie tussen de ADM en het Zachman Raamwerk .................................................................. 79
Figuur 9.2: De ADM en de methode van Pereira & Sousa ............................................................................... 81
Figuur 10.1: Architectuurprincipes: rij 0 .............................................................................................................. 83
Figuur 10.2: Het bereik van de architectuuromschrijvingen: rij 1 ............................................................. 84
Figuur 10.3: Business/IS/Technologie architectuur: rij 2 tot 4 .................................................................. 85
Figuur 10.4: Gedetailleerde representaties: rij 5 ............................................................................................... 86
Figuur 11.1: EA methodologie en taxonomie in het AIM ................................................................................ 88
IX
LIJST VAN TABELLEN
Tabel 7.1: Overzicht BMM termen en hun BSC tegenhangers ...................................................................... 66
Tabel 7.2: Overzicht gebruikte artefacten ............................................................................................................ 71
Tabel 7.3: Alternatieve modelleernotaties voor de 2e en 3e rij van het Zachman raamwerk .......... 72
1
ALGEMENE INLEIDING
Context en onderzoeksvraag
Ondernemingen worden zich meer en meer bewust van het belang van ICT en de afstemming
daarvan op de onderneming in het bijzonder.
Aangezien informatiesystemen echter steeds complexer worden, is deze afstemming vaak geen
eenvoudige opgave. Daarom is er nood aan een manier om alle elementen (de business
processen, de informatiestromen, de technologie infrastructuur en het organisatorisch
management) van een onderneming gestructureerd weer te geven.
Het antwoord hierop wordt geboden door enterprise architectuur (EA). EA ontwerpt en
implementeert deze gestructureerde weergave, architectuur genoemd, van een onderneming op
een geïntegreerde, consistente en coherente manier. Hierdoor is een onderneming in staat haar
business op een effectieve manier te ondersteunen en bekomt ze een competitief voordeel, ook
op lange termijn.
Een leidraad voor het opstellen van een EA is een enterprise architectuur raamwerk (EA
raamwerk). Tegenwoordig zijn er enorm veel EA raamwerken beschikbaar. Bedoeling van dit
onderzoek is om enkele van de belangrijkste EA raamwerken te bespreken en onderling te
vergelijken. Op basis van deze vergelijking kan nagegaan worden of de EA raamwerken alle
componenten bevatten om te kunnen voldoen aan de benaming van een ‘compleet’ EA
raamwerk. Er wordt met andere woorden nagegaan wat er nog nodig is om tot een echte,
complete enterprise architectuur te komen. Is hiervoor een combinatie van EA raamwerken
nodig? En zo ja, op welke manier kunnen deze EA raamwerken dan gecombineerd worden?
Structuur en methodologie
Deze masterproef bestaat uit drie delen: een literatuurstudie, een gevallenstudie en een
algemeen besluit.
In het eerste deel wordt zowel het begrip enterprise architectuur, als het begrip EA raamwerk
ingeleid. Enkele belangrijke EA raamwerken worden bondig toegelicht en onderling vergeleken
aan de hand van enkele eigenschappen. Op basis van deze vergelijkingen wordt nagegaan op
welke manier een ‘complete’ enterprise architectuur kan bekomen worden.
In de gevallenstudie wordt het resultaat hiervan, de blended methodology, uitgewerkt aan de
hand van een praktijkvoorbeeld. Hierdoor wordt de relatie tussen de verschillende EA
raamwerken die deel uitmaken van dit overkoepelend raamwerk duidelijk.
2
Tot slot, worden in het algemeen besluit de belangrijkste elementen van deze masterproef
samengevat en worden enkele conclusies getrokken. Verder worden ook nog enkele
beperkingen aangehaald en aanbevelingen gedaan naar toekomstig onderzoek.
Beperkingen
Voor deze masterproef werd een beperkte selectie gemaakt van vier EA raamwerken om verder
toe te lichten. Er zijn echter nog tal van andere EA raamwerken die eveneens interessant zijn
voor verdere uitwerking. Door de beperking in tijd en ruimte van de masterproef kan hier
jammer genoeg niet verder op ingegaan worden.
Bijdrage
In het verleden is reeds heel wat onderzoek gedaan naar de verschillen en gelijkenissen tussen
de belangrijkste EA raamwerken. Vaak werd gewezen op het feit dat geen enkel EA raamwerk
compleet is en dat enkel door het combineren (van delen) van verschillende EA raamwerken een
compleet EA raamwerk kan bekomen worden. Het concept blended methodology (of het
combineren van EA Raamwerken) is met andere woorden zeker geen nieuw gegeven in de
literatuur.
Toch werd er nooit dieper op deze blended methodology ingegaan. Daarom gaat dit onderzoek
een stap verder en zoekt het naar een manier om een compleet EA raamwerk te bekomen door
het combineren van enkele belangrijke EA raamwerken. Het praktijkvoorbeeld uit de
gevallenstudie gaat hier dieper op in.
3
DEEL I: LITERATUURSTUDIE
|Hoofdstuk 1
4
HOOFDSTUK 1: ENTERPRISE ARCHITECTUUR TOEGELICHT
In dit hoofdstuk wordt het begrip enterprise architectuur (EA) algemeen ingeleid. Eerst en
vooral wordt gekeken binnen welk vakgebied dit begrip gepositioneerd kan worden. Vervolgens
worden de drijfveren van EA toegelicht. Verder worden ook enkele voordelen van EA
verduidelijkt. Ten slotte wordt in het laatste deel van dit hoofdstuk ingegaan op een veel
gemaakt discussiepunt over EA in de literatuur: sommige auteurs zien EA als product, terwijl
anderen het eerder als proces zien.
1.1. POSITIONERING EN DEFINITIE
De meeste ondernemingen hebben informatiesystemen nodig om te kunnen functioneren.
Informatiesystemen ondersteunen immers de bedrijfsprocessen van een onderneming of toch
delen ervan.
Over de jaren heen is de complexiteit van informatiesystemen echter meer en meer toegenomen.
Hierdoor werd het voor bedrijven steeds moeilijker om hun processen, organisatie, informatie
en informatietechnologie als coherent geheel te ontwerpen. Het afstemmen van business en IT,
kortweg business-IT alignment genoemd, werd door de toegenomen complexiteit in
informatiesystemen een lastige opgave. Dit alles zorgde voor een stijging in IT kosten die niet
resulteerde in een hogere waarde voor de bedrijven (Sessions, 2007).
Bedrijven konden dit probleem van misalignment niet langer ontkennen en gingen op zoek naar
oplossingen. Business-IT alignment werd met andere woorden een centraal begrip.
De noodzaak om business en IT op elkaar af te stemmen, zowel op strategisch als op
operationeel vlak, werd door Henderson & Venkatraman weergegeven in hun alignment model
(1993). Later werd dit model uitgebreid tot het Information Management Enneahedron, ook wel
Amsterdam Information Management Model (AIM) genoemd (Maes, 2003). Dit model neemt het
oorspronkelijk model van Henderson & Venkatraman als basis en vult het aan met een
informatie/communicatiekolom en structuurrij. Het zijn juist deze kolom en rij die de kern van
het informatiemanagement territorium voorstellen (zie figuur 1.1).
|Hoofdstuk 1
5
Figuur 1.1: EA gesitueerd in het Amsterdam Information Management Model (AIM) van Rik Maes
Informatiemanagement is een belangrijk begrip. Het legt immers de link tussen business en IT
en zorgt voor business-IT alignment, zowel op strategisch als op operationeel vlak.
Het is binnen dit begrip dat enterprise architectuur gesitueerd kan worden. EA maakt immers
deel uit van informatiemanagement en is gecentreerd rondom de middelste rij van het
Enneahedron (zie figuur 1.1). Het betreft de consistente ontwikkeling van de business,
informatie- en IT architectuur. Op die manier zorgt EA voor business-IT alignment op structureel
vlak. Dit kan verduidelijkt worden aan de hand van de definitie die Lankhorst et al. (2009) aan
EA geven: “Enterprise architectuur is een coherent geheel van principes, methodes en modellen
die gebruikt worden in het ontwerp en de realisatie van de organisatiestructuur,
businessprocessen, informatiesystemen en infrastructuur van een onderneming. Deze
architecturale modellen, views, presentaties en analyses helpen de communicatiekloof tussen
architecten en belanghebbenden van een onderneming te overbruggen.”
Volgens Lankhorst et al. (2009) is bovendien niet de enterprise architectuur op zichzelf, maar
wel de combinatie van de enterprise architectuur en de cultuur van de onderneming (mensen,
leiding,…) belangrijk voor het bereiken van haar doelen. In die zin positioneren Lankhorst et al.
EA binnen de managementcontext van een onderneming. Het managen van een onderneming
wordt voorgesteld door een piramide met bovenaan, als startpunt, de beschrijving van de missie
en vervolgens de visie van een onderneming. Eens deze twee elementen op punt staan, worden
ze vertaald in een strategie. Voor het uitvoeren van die strategie dienen er duidelijke doelen
opgesteld te worden. Verschillende acties kunnen ondernomen worden om deze doelen te
bereiken. Deze acties komen op hun beurt tot uiting in de dagelijkse operaties van de
onderneming.
|Hoofdstuk 1
6
Zoals weergegeven in figuur 1.2 komt EA in het spel bij het vertalen van doelen naar concrete
veranderingen in de dagelijkse operaties van het bedrijf. EA is dus een belangrijk instrument bij
het geven van richting bij de implementatie van een strategie (Dietz, Go, Lee, 2007).
Figuur 1.2: Enterprise architectuur als management instrument
1.2. DRIJFVEREN EN VOORDELEN VAN EA
Buiten de toegenomen complexiteit van informatiesystemen (cfr. supra), lagen er eveneens tal
van andere factoren aan de basis van de rijzende interesse in business-IT alignment en dus ook
EA.
De evolutie naar een zogenaamde boundaryless organisation is volgens Van Sante et al. (2008)
één van deze factoren. Aangezien informatie niet alleen binnen een organisatie maar ook buiten
een organisatie stroomt, is het aanbrengen van veranderingen in informatiesystemen een
riskante opgave. EA ondersteunt deze veranderingsbeslissingen door modellen vanuit
verschillende perspectieven op te stellen voor de organisatie, haar informatiesystemen en haar
infrastructuur.
Verder deden ook problemen met betrekking tot het hanteren van een multi-channel
benadering, de vraag naar EA alleen maar toenemen. Veel organisaties streven immers naar een
consistente interactie met hun klanten via verschillende kanalen. In de praktijk krijgen ze
daarbij te maken met verschillende afdelingen, processen, gegevensbestanden en systemen. Een
consistent architectuurbeleid is dan ook het begin van een consistente klantenbenadering.
Ten slotte deed ook een externe drijfveer de interesse in EA groeien. De Clinger-Cohen wet
(1996) legde immers elke overheidsinstelling in Amerika op om over een IT-architectuur te
beschikken en stimuleerde aldus de ontwikkeling van EA als discipline. Dit niet alleen binnen
overheidsinstellingen, maar ook binnen bedrijven.
|Hoofdstuk 1
7
De interesse in EA steeg niet enkel omwille van deze drijfveren, maar ook omwille van de vele
voordelen die verbonden zijn aan het toepassen ervan. Op korte termijn biedt EA grip: project-
en investeringsvoorstellen kunnen worden getoetst aan de hand van EA (Van Dullemen et al.,
2008). Op lange termijn kan EA ervoor zorgen dat de business en IT van een onderneming beter
op elkaar zijn afgestemd. Hierdoor is een onderneming niet alleen in staat snel te reageren op
marktopportuniteiten (wendbaarheid: cfr. supra), maar ook om te groeien zonder exponentieel
toenemende operationele kosten. Verder bekomt men door deze business-IT alignment een
hogere kwaliteit, een betere time-to-market en een hogere klanttevredenheid. Een laatste
belangrijk voordeel is dat ook belanghebbenden een beter inzicht krijgen in de structuur en de
werking van de onderneming.
1.3. EA: PRODUCT OF PROCES
Onder auteurs rijst vaak de discussie of EA dan wel als product, dan wel als proces kan gezien
worden. Sessions (2007) houdt zich vast bij dit laatste. Volgens hem is architectuur geen
zelfstandig naamwoord maar wel een werkwoord. Het mag niet gezien worden als een stijve
bundeling van artefacten.
Een meer alomvattend antwoord wordt gegeven door Lankhorst et al.(2009), die EA vanuit al
zijn facetten bekijken. Volgens hen kan EA zowel een product, als een proces genoemd worden.
Als product dient het om managers te helpen in het ontwerpen van processen en
systeemontwikkelaars te helpen in het uitbouwen van applicaties, die in lijn zijn met de business
objectieven en het beleid van de onderneming. Het is een blauwdruk waarop men de
strategische competentie van een bedrijf kan uitbouwen.
Als proces ziet het toe op het onderhouden van de
architectuur, want business en IT zijn onderhevig aan continue
verandering. Door het onderhouden van de architectuur is de
organisatie wendbaar en kan ze de concurrentie voor zijn.
Zo een wendbare organisatie is namelijk in staat de vier
architectuurdomeinen (business, IT, technologie en
organisatie) geïntegreerd te ontwerpen. Dit maakt snelle
verandering in een organisatie mogelijk (Dietz et al., 2007).
Hierdoor bekomt men een competitief voordeel, wat cruciaal
is gezien de toegenomen business dynamiek (Hoogervorst,
2004).
Figuur 1.3: Architectuurdomeinen
|Hoofdstuk 2
8
HOOFDSTUK 2: EA RAAMWERKEN
Dit hoofdstuk leidt het begrip enterprise architectuur raamwerken in .
Eerst en vooral wordt dit begrip gedefinieerd. Vervolgens wordt een overzicht gegeven van alle
relevante eigenschappen op basis waarvan EA raamwerken vergeleken kunnen worden. In de
derde paragraaf van dit hoofdstuk wordt een overzicht gegeven van de belangrijkste EA
raamwerken. Hieruit wordt een selectie gemaakt van vier EA raamwerken die in het volgende
hoofdstuk verder toegelicht zullen worden.
Aangezien geen enkel EA raamwerk compleet is, dienen meerdere raamwerken gecombineerd te
worden om een optimaal EA raamwerk te bekomen. Dit concept wordt verduidelijkt in de laatste
paragraaf.
2.1. DEFINITIE
“Een enterprise architectuur (EA) raamwerk is een communicatiemodel voor het ontwikkelen
van een enterprise architectuur. […]Het stelt een set van modellen, principes, standaarden,
componenten,[…] voor die de ontwikkeling van bepaalde architectuuraspecten leiden.”
(Schekkerman, 2004, p.85)
EA raamwerken passen meestal gelijkaardige definities van het begrip architectuur toe, maar
verschillen wat betreft focus, bereik en opzet. Het is een techniek om de architectuur van een
onderneming samenhangend te ontwerpen en over te brengen naar haar belanghebbenden.
Aangezien het domein van EA de laatste jaren zo snel gegroeid is, zijn er enorm veel EA
raamwerken voorhanden. Deze methodes hebben vaak niet veel gemeenschappelijk, buiten dat
ze onder de gemeenschappelijke noemer EA raamwerk vallen.
2.2. EIGENSCHAPPEN
Deze paragraaf geeft een overzicht van alle relevante eigenschappen op basis waarvan EA
raamwerken kunnen vergeleken worden. Eerst en vooral worden zes kenmerkende
eigenschappen of basisdimensies van EA raamwerken besproken. Daarna worden twee
algemene eigenschappen van EA raamwerken besproken die relevant zijn in het kader van dit
thesisonderzoek. Op basis van deze acht eigenschappen zullen in hoofdstuk 4 enkele EA
raamwerken onderling vergeleken worden.
|Hoofdstuk 2
9
Een kenmerkende eigenschap of dimensie is een criterium op basis waarvan een
architectuurbeschrijving kan opgedeeld worden in gezichtspunten. Greefhorst, Koning en Van
Vliet (2003) stelden een lijst op van negen basisdimensies voor EA raamwerken. Hieruit werd
een selectie gemaakt van de zes meest relevante:
Type informatie
Deze basisdimensie heeft betrekking op de onderwerpen, areas of concern, die in een EA
raamwerk aan bod komen. Het slaat op de mate waarin business, organisatie, informatie en
techniek terugkomen in het raamwerk. Business heeft te maken met de context waarin de
onderneming zich bevindt, organisatie met de bedrijfsprocessen en andere activiteiten binnen
de onderneming, informatie met de informatiestromen van de onderneming en techniek met de
hulpmiddelen die ingezet kunnen worden ter ondersteuning van de bedrijfsprocessen en
informatiestromen (Janssen, 2005).
Bereik
Het bereik is het gebied waarop de architectuurinformatie betrekking heeft. Dit kan zijn op
niveau van een bedrijfstak, onderneming of business unit.
Detailniveau
Deze dimensie geeft de variatie aan in detailniveau van de onderdelen van een
architectuurbeschrijving. Het detailniveau kan hoog, midden of laag zijn.
Aard
Deze eigenschap heeft betrekking op wat voor soort informatie in de beschrijvingen wordt
opgenomen. Dit kunnen principes, regels, richtlijnen (beleidlijnen), standaarden of modellen zijn.
Belanghebbenden
Architectuurbeschrijvingen kunnen opgedeeld worden naar belanghebbenden. Bij het
vergelijken van raamwerken kan gezegd worden of ze wel of geen onderscheid maken om de
beschrijvingen in te delen naar stakeholders.
Representatie
Representatie is de manier waarop architectuurinformatie is weergegeven in een gezichtspunt.
Dit kan informeel (dagelijks taalgebruik), semi-formeel (bijvoorbeeld UML) of formeel zijn.
Doorgaans verschilt de representatie niet alleen erg tussen raamwerken onderling, maar ook
binnen de raamwerken zelf. Vaak hangt de representatie binnen een raamwerk af van de
persoonlijke voorkeur van de belanghebbende(n).
|Hoofdstuk 2
10
Buiten deze lijst van basisdimensies, zijn er ook twee algemene eigenschappen op basis waarvan
EA raamwerken kunnen vergeleken worden (Sessions, 2007):
Taxonomievolledigheid
Hoe hoger het raamwerk hierop scoort, hoe beter het raamwerk in staat is de verschillende
architecturale artefacten te classificeren. Deze eigenschap weerspiegelt hoe statisch het
raamwerk is.
Procesvolledigheid
Hoe hoger het raamwerk hierop scoort, hoe beter het raamwerk een stap-voor-stap proces
weergeeft voor het creëren van een enterprise architectuur. Deze eigenschap heeft eerder
betrekking op de dynamiek van het raamwerk.
2.3. OVERZICHT EA RAAMWERKEN
Een groot aantal EA raamwerken is tegenwoordig voorhanden. Zowel het institute for enterprise
architecture developments (IFEAD), als Sessions R. geven een overzicht van de voornaamste EA
raamwerken.
Het overzicht van het IFEAD werd opgesteld aan de hand van een enquête bij 79 respondenten
(IFEAD, 2005). Hierin werd onder andere nagegaan welk EA raamwerk de respondenten
toepasten in hun onderneming. De resultaten hiervan zijn zichtbaar in figuur 2.1. Het meest
gebruikte EA raamwerk is, volgens de enquête, het Zachman raamwerk. Een EA raamwerk dat
door de onderneming zelf ontwikkeld wordt, staat op de tweede plaats. Andere belangrijke EA
raamwerken zijn het Department of Defense Architecture Framework (DoDAF), The Open Group
Architecture Framework (TOGAF), het Federal Enterprise Architecture Framework (FEAF) en het
Extended Enterprise Architecture Framework (E2AF).
De resultaten van de IFEAD enquête, worden deels bevestigd door Sessions R. (2007). Volgens
hem wordt er in het vakgebied meer dan negentig procent gebruik gemaakt van één van de
volgende vier raamwerken: het Zachman raamwerk, TOGAF, het FEAF of de Gartner methode.
|Hoofdstuk 2
11
Figuur 2.1: Gebruik van EA raamwerken in ondernemingen (IFEAD, 2005)
Op basis van de resultaten van de IFEAD- enquête en de vaststellingen van Sessions, werden de
volgende raamwerken geselecteerd voor verdere uitwerking in hoofdstuk 3: het Zachman
raamwerk, TOGAF en het FEAF. Verder zal ook het Information architecture framework (IAF)
toegelicht worden aangezien het een belangrijke variant is van het Zachman raamwerk.
2.4. OPTIMAAL BLENDED RAAMWERK
Geen enkel EA raamwerk is compleet. Elk raamwerk heeft zijn sterktes en zwaktes (Sessions,
2007). Volgens Van Sante et al. (2008) is een enterprise architectuur pas ‘compleet’ indien het
de volgende concepten inhoudt:
1. een raamwerk voor het ordenen van concepten.
2. een methode voor het geven van structuur aan de relevante objecten; Het definieert de
creatie en het management van een architectuur, evenals de controle op de realisatie en het
onderhoud van het gerealiseerde systeem volgens de principes van die architectuur.
3. een verzameling principes om een grens te leggen op de oplossingen. Deze worden meestal
neergeschreven in wetten of reglementen.
4. een plan (blueprint) van de onderneming met al zijn onderdelen en zijn onderlinge relaties.
5. een ontwerp van de constructie van één enkele oplossing.
Om zo een complete enterprise architectuur te bekomen, moeten meerdere EA raamwerken
gecombineerd worden. Dit wordt een blended methodology genoemd (Sessions, 2007).
|Hoofdstuk 3
12
HOOFDSTUK 3: EA RAAMWERKEN TOEGELICHT
In dit hoofdstuk worden de vier geselecteerde EA raamwerken uit hoofdstuk 2 verder toegelicht.
Voor elk van deze EA raamwerken zal ingegaan worden op de opbouw ervan. Ook de voordelen
en eventuele nadelen van de raamwerken worden besproken.
3.1. ZACHMAN
“ The Zachman framework is actually the best one.” (Fatolahi & Shams, 2006, p.133)
Het Zachman raamwerk is wellicht het meest gekende EA raamwerk. Het is dan ook niet
verwonderlijk dat de meeste andere raamwerken voor enterprise architectuur hieruit afgeleid
zijn.
3.1.1. OPBOUW
Het Zachman raamwerk is genoemd naar haar uitvinder John A. Zachman. In 1987 publiceerde
hij de basisideeën van het raamwerk in een baanbrekend artikel over enterprise architectuur,
getiteld ‘A framework for information systems architecture’ (Zachman, 1987). Zoals de titel van
het artikel duidelijk maakt, wordt er nog niet over een enterprise architectuur gesproken, maar
wel over een information systems architecture.
In het artikel hamert Zachman op het feit dat er dringend nood is aan een logische structurering
van informatiesystemen in een onderneming omdat die steeds omvangrijker en complexer
worden. Hier bovenop gelooft Zachman dat, net zoals een gebouw, eender welk object (zoals
bijvoorbeeld een onderneming) door middel van verschillende architecturale representaties
beschreven kan worden. Onder architecturale representaties worden de verschillende
gezichtspunten verstaan van waaruit naar een object gekeken kan worden. In het Zachman
raamwerk worden deze representaties perspectieven genoemd.
Er wordt onderscheid gemaakt tussen zes perspectieven: de planner, de owner, de designer, de
builder, de subcontractor en het systeem zelf. Verder kan een object voor elk van die
perspectieven nog eens beschreven worden vanuit verschillende inhoudsdimensies. Die
dimensies stelt Zachman voor aan de hand van zes vragen: what, how, where, who, when en why.
Gebaseerd op deze twee ideeën, zijnde de perspectieven en inhoudsdimensies, wordt het
raamwerk voorgesteld als een tweedimensionale matrix bestaande uit zes rijen en zes
kolommen (zie figuur 3.1). Het Zachman raamwerk is dus louter een taxonomie, een
|Hoofdstuk 3
13
classificatieschema voor het ordenen van descriptieve representaties die een onderneming (of
eender welk object) omschrijven (Sessions, 2007). Om te verzekeren dat er consistentie is bij de
opbouw van het raamwerk, definieert Zachman een aantal regels die in acht moeten worden
genomen.
Figuur 3.1: Het Zachman raamwerk
Hieronder wordt een kort overzicht gegeven van de inhoud van elke rij en elke kolom. Tevens
worden ook de cellen en de regels van het raamwerk verder toegelicht.
3.1.1.1. Perspectieven
De rijen van het raamwerk stellen de onderneming voor vanuit verschillende
stakeholdersperspectieven (Hay, 2000).
1. Scope (contextual) - Planner
In deze rij wordt de context van de onderneming uiteengezet.
2. Business model (conceptual) - Owner
Deze rij definieert verschillende businessaspecten. Voorbeelden zijn de functies,
organisatie, structuur, ... van de business.
3. System model (logical) - Designer
De systeem analist vertaalt het business model naar ICT termen. De data- elementen en
softwarefuncties van het informatiesysteem worden gespecificeerd.
|Hoofdstuk 3
14
4. Technology model (physical) - Builder
Deze rij beschrijft de samenstelling en constructie van het systeem. Het bepaalt welke
programmeertaal, welke programmastructuren en welke andere ondersteunende
technologie vereist is om het informatiesysteem te kunnen toepassen.
5. Detailed representations (out-of-context) - Subcontractor
De subcontractant begrijpt de gedetailleerde representaties van specifieke onderdelen in
de business. Individuele, onafhankelijke modules worden toegewezen aan contractanten
om te implementeren. Aangezien deze rij buiten de context van EA valt, wordt ze niet
door de onderneming zelf uitgevoerd, maar uitbesteed (Fatolahi & Shams, 2006).
6. Functioning enterprise - User
Deze rij geeft, vanuit het perspectief van de eindgebruiker, de onderneming weer zoals
ze in de realiteit functioneert. Het is de bedoeling dat deze rij een weergave is van wat de
owners (rij 2) in gedachten hadden. Deze rij behoort echter strikt gezien ook niet tot de
architectuur, aangezien het geen representatie, maar wel het ding op zich is. Het is wel
nuttig om het in het raamwerk op te nemen, aangezien het de architecturale weergave in
het raamwerk vervolledigt (Zachman, 2003).
3.1.1.2. Inhoudsdimensies
De kolommen van het raamwerk stellen de verschillende interessegebieden voor van elk
perspectief (Schekkerman, 2004).
1. Data (what)
Deze kolom beschrijft de entiteiten die betrokken zijn in elk perspectief van de
onderneming.
2. Function (how)
Deze dimensie definieert de functies, processen en activiteiten van de onderneming voor
elk perspectief.
3. Network (where)
Deze kolom toont de locaties en onderlinge relaties tussen de activiteiten van de
onderneming.
4. People (who)
De mensen die betrokken zijn in de onderneming en hun onderlinge relaties worden in
deze dimensie beschreven.
|Hoofdstuk 3
15
5. Time (when)
Deze dimensie beschrijft het effect van tijd op de onderneming. Het is moeilijk om deze
kolom afzonderlijk van de andere te beschrijven, zeker voor wat betreft de functiekolom
(Hay, 2000).
6. Motivation (why)
Deze dimensie beschrijft de motivatie van de onderneming. Ze onthult de strategie en
doelstellingen van de onderneming.
3.1.1.3. Cellen
Elke cel van het raamwerk bevat minstens één primitief model of artefact (Bahill, Botta &
Daniels, 2006). Onder artefact verstaan we elke vorm van representatie, model of diagram die de
celinhoud ondersteunt. Zachman beperkt de gebruiker niet tot een bepaalde set
voorgedefinieerde artefacten en is daarom een erg flexibel raamwerk. Om toch iets van houvast
te kunnen bieden voor het gebruik van het raamwerk, stellen vele auteurs een set artefacten
voor die de celinhoud van elke cel kan weergeven.
Pereira C. en Sousa P. (2004) geven een voorbeeld van zo’n set voor de eerste drie rijen van het
raamwerk (zie figuur 3.2). Deze set artefacten legt echter geen verplichting op tot het gebruik
van een bepaalde opgelegde notatie. Algemeen geldt er dat elke cel gemodelleerd moet worden
op de manier die het meest geschikt lijkt voor de onderneming (Bahill, Botta & Daniels, 2006).
Figuur 3.2: Artefacten in het Zachman raamwerk (Pereira & Sousa, 2004)
|Hoofdstuk 3
16
3.1.1.4. Regels
Om voor consistentie te zorgen bij de opbouw van het raamwerk, definieert Zachman een aantal
regels. De belangrijkste zijn de volgende (Zachman, 2003):
Elke cel is uniek.
Alle cellen zijn horizontaal en verticaal geïntegreerd. Dit betekent dat een model uit een
bepaalde cel moet worden opgesteld, rekening houdend met de andere cellen in dezelfde rij
en dezelfde kolom. Elke cel is met andere woorden gerelateerd aan de cellen in dezelfde rij
en kolom.
Voeg geen rijen of kolommen toe. Het raamwerk is een genormaliseerd schema. De zes rijen
en kolommen beslaan immers de volledige kennisbasis van het object dat beschreven wordt.
Het detailniveau wordt bepaald binnen in een cel en niet over de rijen. Volgens Bahill, Botta &
Daniels (2006) is dit echter niet zo. Gestaafd op praktijkvoorbeelden beweren zij dat de
laagste rijen in het raamwerk een hoger detailniveau hebben dan de hoogste rijen.
Elke kolom heeft een eenvoudig, algemeen model. Elke kolom beschrijft één enkele,
onafhankelijke variabele van de onderneming. De basismodellen voor de kolommen zijn de
volgende: entiteit- relatie- entiteit (kolom 1), proces- input/output- proces (kolom 2),
knooppunt- lijn- knooppunt (kolom 3), mensen- werk- mensen (kolom 4), gebeurtenis-
cyclus- gebeurtenis (kolom 5) en doel- middelen- doel (kolom 6).
Elk celmodel specificeert het generiek model van zijn kolom.
Creëer geen diagonale relaties tussen de cellen. De cellen dienen enkel horizontaal en
verticaal geïntegreerd te zijn.
Verander de namen van de rijen en kolommen niet. In dit geval wordt immers de logische
structuur van het raamwerk veranderd.
De logica van het raamwerk is zeer algemeen en is recursief. Het kan immers gebruikt worden
voor het representeren van eender welk object.
3.1.2. VOORDELEN EN TEKORTKOMINGEN
Het Zachman raamwerk wordt enorm veel toegepast in de praktijk (cfr. supra: figuur 2.1.). Het
succes is te wijten aan het feit dat het Zachman raamwerk verschillende
stakeholdersperspectieven erkent. Volgens het raamwerk is het onmogelijk om de behoeften
van alle belanghebbenden van de onderneming te representeren in één enkele
architectuurbeschrijving (Hay, 1997).
Door te realiseren dat verschillende mensen andere, doch complementaire perspectieven
hebben op de architectuur van de onderneming, wordt een rijkere set van
|Hoofdstuk 3
17
architectuurbeschrijvingen bekomen. Deze set definieert dan de totale architectuur van de
onderneming.
Ondanks het grote voordeel van het in beschouwing nemen van verschillende
stakeholdersperspectieven, wordt het raamwerk niet gespaard van kritiek. In totaal kunnen drie
grote tekortkomingen geconstateerd worden.
Een eerste heeft betrekking op de procesfocus van het raamwerk. Het Zachman raamwerk is
louter een structuur voor het classificeren van verschillende ondernemingsperspectieven. Het
voorziet geen proces voor het stapsgewijs ontwikkelen van een enterprise architectuur (Hay,
2000). Een transitie kan met andere woorden niet weergegeven worden in het raamwerk.
Transitie is het gaan van een as-is situatie naar een to-be situatie. Of zoals Zachman (2003) het
zelf zegt: “Mijn raamwerk DEFINIEERT architectuur. Het beschrijft niet HOE iemand
architectuur kan doen. Dat is namelijk het domein van een methodologie. Mijn raamwerk
definieert de elementaire componenten die bestaan. Een methodologie is een proces dat
sommige elementen omvormt in verschillende andere elementen of samenstellingen.”
Verder is er ook een gebrek aan een methode voor het opvullen van de cellen van het raamwerk.
In het Zachman raamwerk wordt immers geen enkele beschrijving gegeven over hoe de invoer
van artefacten aangepakt moet worden. Op deze tekortkoming wordt tegemoet gekomen door
Pereira & Sousa (2004). Zij geven een gestructureerde, top-down manier weer voor het invullen
van het raamwerk. Cellen moeten in een welbepaalde volgorde ingevuld worden. Sommige
cellen kunnen immers slechts ingevuld worden indien de cellen van wie zij afhankelijk zijn reeds
zijn ingevuld.
Een laatste punt van kritiek betreft het dialoog tussen de theoretische en praktische wereld. In
de literatuur is er namelijk veel te vinden over de theoretische kant van het Zachman raamwerk.
Vele auteurs hebben echter klachten wat betreft de praktijk van het raamwerk. Er zijn volgens
hen te weinig analytische resultaten voorhanden betreffende het toepassen van het raamwerk.
Dit is deels het gevolg van een onvoldoende en onvolledige definiëring van de cellen van het
raamwerk, evenals van een onvoldoende analyse van de inter-connecties tussen de cellen.
Auteurs pleiten dan ook voor meer dialoog tussen de theoretische en praktische wereld (Ylimäki
& Halttunen, 2006).
In de gevallenstudie (cfr. infra) zal verder ingegaan worden op deze leemtes van het raamwerk.
|Hoofdstuk 3
18
3.2. TOGAF
Tegenwoordig wordt The Open Group Architecture Framework gezien als de standaard voor
enterprise architectuur in de private sector. Aangezien het een open standaard is, wordt er
verwacht dat ook haar aandeel in de publieke sector snel zal groeien.
3.2.1. OPBOUW The Open Group Architecture Framework (TOGAF) is een raamwerk dat ontwikkeld werd door
The Open Group in 1995 en sindsdien vrij beschikbaar is. Het wordt gebruikt door organisaties
om een EA te ontwikkelen, te onderhouden en te gebruiken (Van Sante et al., 2008). Hoewel het
de benaming framework krijgt, is TOGAF eerder een architecturaal proces. Het ultieme doel van
TOGAF is niet het voortbrengen van een architectuur, maar wel de organisatie tegoed laten doen
door het gebruik van de architectuur.
Figuur 3.3: Structuur en componenten van TOGAF
TOGAF bestaat uit drie kerncomponenten: de architecture development method (ADM), het
enterprise continuüm en de resource base. De laatste twee kerncomponenten dienen als
ondersteuning voor de eerste kerncomponent, de ADM.
3.2.1.1. Architecture development method
De architecture development method (ADM) is het hart van TOGAF. Het is een proces voor het
ontwikkelen van een EA, afgestemd op de behoeften van de organisatie (Van Sante et al., 2008).
De ADM bestaat uit 8 fasen die iteratief doorlopen worden. Het is een stappenplan waarin is
aangegeven welke activiteiten moeten worden uitgevoerd en wat hun invoer en uitvoer is. In de
|Hoofdstuk 3
19
vorige versie van TOGAF (TOGAF 8) waren er geen richtlijnen omtrent welke activiteiten in
welke fase dienden uitgevoerd te worden, evenals geen richtlijnen betreffende de input en
output van elke fase. Daarom introduceerde TOGAF 9 het content framework (zie bijlage 1). Dit
raamwerk geeft een overzicht van de artefacten die in elke fase van de ADM gebruikt kunnen
worden voor het opbouwen van een architecturaal model. Wat een architectuurtraject (=één
ADM cyclus) uiteindelijk oplevert is niets anders dan een verzameling artefacten, ook wel
delivrables genoemd. Deze artefacten kunnen de vorm aannemen van een diagram, lijst of
matrix. Meerdere artefacten samen beschrijven bouwblokken. Dit zijn eenheden waarin
architectuurelementen worden gedefinieerd (Greefhorst, 2009). Een overzicht van TOGAFs
bouwblokken en hun onderlinge relatie wordt weergegeven in het content metamodel (zie
bijlage 2). Dit metamodel is de basis voor het content framework.
Figuur 3.4: De ADM
In figuur 3.4 is de architectuurmethode grafisch weergegeven. De methode start met de
preliminary phase. Hierin wordt gedefinieerd hoe de architectuur geïmplementeerd zal worden
in de organisatie. Verder worden de architectuurprincipes opgesteld die richting zullen geven
aan alle vervolgfasen.
A. Architecture vision – In deze fase worden de hoofdlijnen van de architectuur bepaald. Er
wordt gebruik gemaakt van business scenario’s om de business visie, strategie en
drijfkrachten weer te geven.
|Hoofdstuk 3
20
B. Business architecture – In deze fase worden de bedrijfsaspecten beschreven. Dit resulteert in
een set van bouwblokken en views die de architectuur beschrijven.
C. Information systems architectures – In deze fase worden de data– en applicatie- architectuur
beschreven. Ook hier is de output een verzameling bouwblokken en views.
D. Technology architecture – In deze fase worden de data– en applicatie- architectuur vertaald
naar een technologiearchitectuur, rekening houdend met de business architectuur.
E. Opportunities and solutions – Hier wordt de architectuur vertaald naar een verzameling
projecten. Uit deze verzameling worden de beste projecten geselecteerd, die zullen bijdragen
tot het bereiken van de doelstaat van de onderneming.
F. Migration planning – In deze fase worden de projecten die geselecteerd werden voor
implementatie, geprioriteerd en gepland in de tijd.
G. Implementation governance – In deze fase wordt de architectuur vertaald naar richtlijnen
voor projecten. Al de informatie die nodig is voor het succesvol managen van de
verschillende implementatieprojecten wordt verzameld.
H. Architecture change management – In deze fase worden de omstandigheden bepaald
waaronder de enterprise architectuur, of een deel ervan, dient veranderd te worden na
implementatie.
Requirements management – Dit is geen fase, maar wel een centrale link tussen de verschillende
fasen van de methode. Het is de plaats waar alle eisen worden beheerd die aan de architectuur
worden gesteld.
3.2.1.2. Enterprise continuüm
De ADM is sterk gelinkt aan het enterprise continuüm, hetgeen een tweede kerncomponent is van
het raamwerk. TOGAF vertrekt immers vanuit het principe dat er niet zoiets bestaat als één
enkele universele architectuur die geschikt is voor alle doeleinden op elk moment. Daarentegen
is het wel een continuüm van architecturen, een proces waarin men van een zeer generieke
architectuur naar een specifieke architectuur gaat afgestemd op de bedrijfsspecifieke business,
data, applicaties en technologie. Dit wordt het enterprise continuüm genoemd. Het meest
generieke niveau van het enterprise continuüm, waarop meer specifieke architecturen gebaseerd
kunnen worden, is de foundation architectuur. Die is opgebouwd uit algemeen beschikbare
architecturale bouwblokken waarop de ADM beroep doet om een organisatiespecifieke
architectuur te ontwikkelen.
Figuur 3.2.2: ADM
|Hoofdstuk 3
21
In totaal zijn er 4 niveaus in het enterprise continuüm, respectievelijk gaande van meest generiek
naar meest specifiek: foundation architecture, common system architecture, industry architecture
en de organizational architecture.
Figuur 3.5: Relatie tussen het enterprise continuüm en de ADM
De kennis die binnen de foundation architecture aanwezig is, wordt voorgesteld door het
Technical Reference Model (TRM) en de Standards Information Base (SIB). Het Technical
Reference Model (TRM) is een model dat een algemene IT-architectuur beschrijft. De Standards
Information Base (SIB) geeft een collectie van standaarden weer die gebruikt kunnen worden
voor het opstellen van een ondernemingsspecifieke architectuur (Sessions, 2007).
Het enterprise continuüm op zich is nog eens opgedeeld in een architectuur continuüm en
solution continuüm. Dat laatste geeft weer hoe het architectuur continuüm kan worden
geïmplementeerd (Van Sante et al., 2008). Het architectuur continuüm en solution continuüm
ondersteunen en sturen elkaar.
Een belangrijke toevoeging in TOGAF 9, een nieuwere versie van het raamwerk, is het verder
onderscheid dat gemaakt wordt in soorten architecturen. TOGAF noemt dit het ‘partitioneren’
van architectuur. Afhankelijk van het detailniveau wordt onderscheid gemaakt tussen strategic
architectures, segment architectures en capability architectures. Een onderneming kan haar
architectuur dus op verschillende niveaus bespreken, afhankelijk van de maturiteit van de
onderneming en haar architecturale praktijken. De strategische architectuur geeft de
langetermijnvisie weer van de onderneming. Op een lager niveau, en dus deel van de
strategische architectuur, bevinden zich segmentarchitecturen. Deze kunnen op hun beurt
opgedeeld worden in capability architecturen.
|Hoofdstuk 3
22
3.2.1.3. Resource base
De derde en laatste kerncomponent van TOGAF is de resource base. Dit is louter een
verzameling documenten zoals richtlijnen, whitepapers, templates en achtergrondinformatie om
architecten te helpen bij het gebruik van de ADM (Van Sante et al., 2008). Het beschrijft een
aantal best-practices op het gebied van architectuur, bijvoorbeeld: business scenario’s, case
studies, architectuur principes,…
3.2.2. VOORDELEN EN NADELEN
Tal van voordelen zijn betrokken bij het gebruik van TOGAF. Een eerste voordeel is het open
karakter van het raamwerk. Het is een open source raamwerk, wat betekent dat het raamwerk
vrij beschikbaar is en door ondernemingen aangepast kan worden om te voldoen aan haar
noden. Dit grote aanpassingsvermogen maakt het raamwerk uniek. Het ultieme doel van TOGAF
is om een onderneming voordeel te laten halen uit het gebruik van EA en niet om louter een
architectuur te produceren, wat bij vele andere raamwerken wel het geval is. Om een
onderneming voordeel te laten halen uit het gebruik van EA, dient volgens TOGAF een enterprise
architectuur stapsgewijs ontwikkeld te worden. Dit is dan ook de reden waarom in TOGAF
vooral gefocust wordt op het procesmatige aspect van enterprise architectuur. Het tweede grote
voordeel van het raamwerk is dat door deze procesaanpak een enterprise architectuur
ontwikkeld wordt die volledig op maat gemaakt is van de onderneming.
Het grote nadeel van het raamwerk is dat het geen taxonomie bevat waarin
architectuurbeschrijvingen geordend kunnen worden.
3.3. INTEGRATED ARCHITECTURE FRAMEWORK
3.3.1. OPBOUW
Het Integrated Architecture Framework (IAF) is een EA raamwerk dat ontworpen werd door
Capgemini, een consultancybedrijf gespecialiseerd in IT. De ontwikkeling van het raamwerk
begon in 1993. Het raamwerk is sterk beïnvloed door Zachman en sommigen zien het als een
vereenvoudiging ervan. Het IAF wordt voorgesteld als een matrix waarvan de rijen de
verschillende abstractieniveaus en de kolommen de verschillende architectuurdomeinen
voorstellen. Ook hier bestaat elke cel uit een gedefinieerde set artefacten. Verschillende views
laten toe om de architectuur over te brengen naar verschillende belanghebbenden. Voorbeelden
|Hoofdstuk 3
23
van views die voorgesteld worden door het IAF zijn governance views, models & cross reference
views, distribution views, security views,…
Zoals zichtbaar in figuur 3.6 is het IAF geen tweedimensionaal raamwerk zoals Zachman, maar
wel een driedimensionaal raamwerk. Toch bestaat het IAF slechts uit twee
basisonderverdelingen.
Figuur 3.6: Integrated Architecture Framework
De eerste onderverdeling zijn de architectuurdomeinen. Vier van deze zes
architectuurdomeinen representeren de kern van de architectuur: het business-, informatie-,
informatiesysteem- en technologie infrastructuur- architectuurdomein. De overige twee
domeinen, namelijk governance en security, stellen de derde dimensie voor. Ze hebben
betrekking op de andere vier architectuurdomeinen maar kunnen ook autonoom gebruikt
worden. Deze twee architectuurdomeinen gebruiken artefacten van de andere domeinen om
zichzelf te beschrijven.
Via een tweede basisonderverdeling wordt elk van deze architectuurdomeinen nog eens verder
opgedeeld in vier abstractieniveaus, namelijk why, what, how en with what. Enkele van deze
(why, what, how) refereren naar de abstractieniveaus van het Zachman raamwerk.
Het contextueel niveau wordt gekenmerkt door de why- vraag en beschrijft de context van de
organisatie en het bereik van de architectuurdomeinen. Het conceptueel niveau wordt
gekenmerkt door de what- vraag. Het beschrijft de vereisten van de architectuur. Een derde
|Hoofdstuk 3
24
abstractieniveau is het logisch niveau, gekenmerkt door de how- vraag. Deze heeft als doel een
aantal oplossingsalternatieven te ontwikkelen, waaruit uiteindelijk een optimale oplossing
gekozen kan worden. Een vierde en laatste abstractieniveau is het fysiek niveau. Dit
abstractieniveau wordt gekenmerkt door de with what- vraag, die in tegenstelling tot de rest van
de vragen uit het IAF niet terug te vinden is in het Zachman raamwerk. Deze laag beschrijft met
welke fysieke componenten de ideale oplossing geïmplementeerd kan worden. Zoals zichtbaar
in figuur 3.6 worden enkel de abstractieniveaus what, how en with what onderverdeeld voor de
verschillende architectuurdomeinen. Het contextuele niveau (why) heeft geen verdere
onderverdeling en geldt dus voor de gehele architectuur.
Het nut van deze onderverdeling in vier abstractieniveaus kan verduidelijkt worden aan de hand
van een eenvoudig praktisch voorbeeld uitgewerkt door Van ’t Wout et al. (2010). Veronderstel
een stad die door het toenemend aantal verkeer nood heeft aan het bouwen van een extra brug.
Het doel van de brug is dus om meer verkeer toe te laten in de stad (why). De brug moet modern
zijn, ze moet passen binnen het imago van de stad (what). Een aantal mogelijke plannen van
bruggen worden getoond, maar natuurlijk zullen er maar enkele van deze voldoen aan de
vereisten van het jong en modern imago (how). Ten slotte worden de materialen gekozen voor
elk deel van de brug (with what). Na deze stappen is de architectuur voor de brug opgebouwd en
kan die overhandigd worden aan de ingenieurs die de brug zullen ontwikkelen.
Het Capgemini raamwerk wordt aangevuld met tools, technieken en roadmaps voor het gebruik
ervan. Veel gebruikte tools binnen het IAF zijn Microsoft Word en Powerpoint. Focusinterviews
en workshops zijn voorbeelden van technieken om informatie te verzamelen voor het
raamwerk. Ten slotte definiëren engagement roadmaps de delivrables van het werk.
3.3.2. VOORDELEN EN NADELEN
Aangezien het IAF volledig is afgeleid van het Zachman raamwerk, zijn dezelfde voor– en
nadelen hier van toepassing (cfr. supra 3.1.2., p.16).
3.4. FEDERAL ENTEPRISE ARCHITECTURE FRAMEWORK (FEAF)
3.4.1. OPBOUW
3.4.1.1. Algemene methode
De Clinger Cohen act (cfr. supra) lag aan de basis voor de ontwikkeling van het Federal
Enterprise Architecture Framework (FEAF). Elke overheidsinstelling in Amerika was immers
|Hoofdstuk 3
25
sinds de intrede van die wet verplicht om over een EA te beschikken. Het raamwerk werd
opgesteld om de processen in de Amerikaanse overheidsinstellingen en tussen de
overheidsinstellingen onderling te vereenvoudigen. Het verbetert de operabiliteit binnen een
overheidssysteem.
De inhoud van het FEAF kan duidelijk weergegeven worden aan de hand van het schematisch
overzicht in figuur 3.7. De stroom van links naar rechts stelt het continue proces voor van de
FEA (Sayles, 2003).
Het proces vertrekt vanuit de as is state van de onderneming en werkt richting het bereiken van
een to be state. De as is state en de to be state refereren respectievelijk naar de huidige en
doelarchitectuur van een onderneming, die beiden bestaan uit de business architectuur, data
architectuur, applicatie architectuur en technologie architectuur. Die zijn op hun beurt elk
opgebouwd uit architecturale modellen die de documentatie voorzien voor het managen en
implementeren van veranderingen in de onderneming. Classificatie van deze
architectuurinformatie gebeurd in een FEAF matrix (cfr. infra).
Transitieprocessen zorgen voor de overgang tussen de huidige architectuur en de
doelarchitectuur in overeenstemming met de architectuurstandaarden en in lijn met de
gewenste strategische richting. Het gaan van een as is state naar een to be state binnen het FEAF
gebeurt iteratief. Elke iteratie resulteert in nieuwe segmenten die afgeleverd worden en die
bijdragen tot het bereiken van de doelarchitectuur. Elke transitie wordt geïnitieerd door
zogenaamde architecture drivers. Dit zijn externe stimuli die verandering veroorzaken in de
FEA.
Figuur 3.7: Federal Enterprise Architecture Framework
|Hoofdstuk 3
26
In totaal zijn er dus acht basiscomponenten die onontbeerlijk zijn voor het ontwikkelen en
onderhouden van de FEAF: architecture drivers, de strategische richting, de huidige
architectuur, de doelarchitectuur, de transitieprocessen, architectuurmodellen, standaarden en
architectuursegmenten.
3.4.1.2. FEAF matrix
Om de architectuurinformatie te classificeren definieert het FEAF een matrix die gebaseerd is op
het Zachman raamwerk. Meer bepaald drie aspecten van het Zachman raamwerk komen hierin
terug: de what- kolom stelt de data architectuur voor, de how- kolom stelt de applicatie
architectuur voor en de where- kolom stelt de technologie architectuur voor (Sayles, 2003). Op
de horizontale as van de FEAF matrix worden de perspectieven van Zachman overgenomen:
planner, owner, designer, builder en subcontractor. Aldus wordt er een 5x3 matrix bekomen
waaruit elke cel bestaat uit een EA- model. Deze modellen zijn de basis voor het managen en
implementeren van verandering in een onderneming en dus de basis voor het bereiken van de to
be state van de organisatie.
Figuur 3.8: FEAF matrix
3.4.1.3. Referentiemodellen
Om standaardisatie van terminologie te verkrijgen over de verschillende
overheidsdepartementen en aldus samenwerking te vergemakkelijken binnen de federale
overheid, worden er binnen het FEAF vijf referentiemodellen gedefinieerd, namelijk: het
performance reference model (PRM), business reference model (BRM), technical reference model
(TRM), data reference model (DRM) en service reference model (SRM).
Het performance reference model (PRM) definieert standaarden voor het meten van de prestatie
van grote IT- investeringen. Het business reference model (BRM) geeft de verschillende functies
|Hoofdstuk 3
27
weer van de federale overheid vanuit een businessstandpunt. Het technical reference model
(TRM) definieert verschillende technologieën en standaarden die gebruikt kunnen worden in
het opbouwen van IT- systemen. Het data reference model (DRM) definieert standaarden voor
het beschrijven van data. Het vijfde en laatste referentiemodel is het service component
reference model (SRM). Dit model identificeert en classificeert servicecomponenten die de
federale agentschappen helpen hun IT- investeringen en activa te ondersteunen.
Samen omvatten de referentiemodellen een raamwerk dat de belangrijkste elementen beschrijft
van de FEA op een algemene en consistente manier.
3.4.2. VOORDELEN EN NADELEN
Een groot voordeel van het FEAF is dat het een zeer compleet EA raamwerk is. Meer nog, het is
het meest complete EA raamwerk van de vier besproken EA raamwerken. Het bestaat immers
zowel uit een taxonomie, zoals Zachman (weergegeven door de FEAF matrix), als een
architecturaal proces, zoals TOGAF (Sessions, 2007).
Een nadeel is echter wel dat het domein waarin dit raamwerk wordt toegepast,
overheidsinstellingen zijn. Ondernemingen kunnen dit EA raamwerk maar moeilijk toepassen.
|Hoofdstuk 4
28
HOOFDSTUK 4: EA RAAMWERKEN VERGELEKEN
Over het algemeen zijn EA raamwerken erg verschillend, zowel in doelstelling als in aanpak.
In hoofdstuk 2 werden een aantal kenmerkende en algemene eigenschappen van EA
raamwerken uiteengezet. Deze eigenschappen zullen nu voor elk van de geselecteerde EA
raamwerken uit hoofdstuk 3 besproken worden met uitzondering van de eigenschap
representatie. Gezien deze eigenschap vaak afhangt van de persoonlijke voorkeur van de
belanghebbenden van het raamwerk en dus erg verschillend is van raamwerk tot raamwerk,
wordt hier niet verder op ingegaan.
Aan de hand van de uiteenzetting van de eigenschappen voor elk raamwerk, zal vervolgens een
algemeen vergelijkende conclusie opgesteld worden. Ten slotte zal op basis van deze conclusie
een blended methodology gecreëerd worden.
4.1. ZACHMAN
4.1.1. TYPE INFORMATIE
In het Zachman raamwerk wordt gekeken naar de onderneming vanuit zes perspectieven: het
bereik van de onderneming, het business model, het informatiesysteem model, het technologie
model, de gedetailleerde representatie en de functionerende onderneming. De eerste twee rijen
van het raamwerk zijn business georiënteerd. De derde rij van het raamwerk vertaalt de
businessvereisten naar ICT- termen. De vierde rij beschrijft de technologische vereisten van het
informatiesysteem. De codering en uiteindelijke implementatie wordt uitgewerkt in rij 5.
De informatie die over de verschillende rijen van het raamwerk aan bod komt, heeft met andere
woorden betrekking op de organisatie, business, informatie en techniek van de onderneming.
4.1.2. BEREIK
Wat betreft bereik, kan het raamwerk zowel betrekking hebben op de volledige onderneming als
op een welbepaalde business unit zonder dat de context uit het oog verloren gaat. Het raamwerk
heeft immers een holistisch karakter. Het bereik wordt uiteengezet in de eerste rij van het
raamwerk (Schekkerman, 2004).
4.1.3. DETAILNIVEAU
Het detailniveau in het raamwerk is een functie van de cel. In elke cel kan je een hoog
detailniveau, middelmatig detailniveau of laag detailniveau hebben (Zachman, 2003).
|Hoofdstuk 4
29
Over het algemeen is het raamwerk zelf ook zeer gedetailleerd: het biedt immers gedetailleerde
beschrijvingen voor de gehele enterprise. Eerst en vooral wordt er vanuit zes perspectieven
naar de onderneming gekeken. Verdere detaillering wordt verkregen door elk perspectief nog
eens te bekijken vanuit zes verschillende abstractieniveaus.
4.1.4. AARD
De inhoud van de cellen bestaat voornamelijk uit modellen en tekstuele beschrijvingen.
4.1.5. BELANGHEBBENDEN
In het Zachman raamwerk worden de architectuurbeschrijvingen opgedeeld naar de
verschillende belanghebbenden. Elke rij geeft namelijk een heldere weergave van de organisatie
weer, vanuit het perspectief van een belanghebbende van de onderneming. De belanghebbenden
die in het Zachman raamwerk zijn opgenomen zijn: de planner, de eigenaar (owner), de
ontwerper (designer), de ontwikkelaar (builder) en de onderaannemer (subcontractor).
4.1.6. TAXONOMIE- EN PROCESVOLLEDIGHEID
Het Zachman raamwerk scoort heel erg hoog op de eigenschap taxonomievolledigheid. Zoals
reeds eerder vermeld, is het Zachman raamwerk louter een structuur voor het classificeren van
verschillende artefacten. Het is een descriptief raamwerk. Het definieert architectuur, maar
beschrijft niet hoe iemand architectuur kan doen.
Het Zachman raamwerk mist een procesomschrijving voor het creëren van een enterprise
architectuur en scoort dus zeer laag op de eigenschap procesvolledigheid.
4.2. THE OPEN GROUP ARCHITECTURE FRAMEWORK (TOGAF)
4.2.1. TYPE INFORMATIE
TOGAF deelt een enterprise architectuur op in vier categorieën: de business architectuur,
applicatie architectuur, data architectuur en technische architectuur. Elk van deze wordt
uiteengezet in een fase van de ADM. De business architectuur wordt gespecificeerd in de
businessarchitectuurfase, de data– en applicatiearchitectuur worden gespecificeerd in de
informatie systeem architectuur fase en de technische architectuur ten slotte wordt
gespecificeerd in de technologie architectuur fase.
|Hoofdstuk 4
30
4.2.2. BEREIK
TOGAF kan toegepast worden op eender welke organisatie die producten en services levert in
een business– of industriedomein (Van Sante et al., 2008).
4.2.3. DETAILNIVEAU
Om een consistent detailniveau te bekomen over de verschillende architectuurdomeinen, wordt
het detailniveau bepaald per iteratie van de ADM. Het is onmogelijk om reeds na de eerste
iteratie een gedetailleerde architectuurbeschrijving te voltooien. Echter, hoe meer iteraties
reeds doorlopen zijn, hoe groter het detailniveau van de architectuurbeschrijving. Bij elke
iteratie neemt het detailniveau immers toe.
4.2.4. AARD
De manier waarop informatie in The Open Group Architecture Framework wordt weergegeven is
aan de hand van modellen, principes, richtlijnen en standaarden. In alle fases van de ADM wordt
de output overwegend weergegeven aan de hand van modellen en principes. De resource base
op haar beurt bestaat uit een set van richtlijnen, modellen, principes, standaarden en
achtergrondinformatie.
4.2.5. BELANGHEBBENDEN
In TOGAF worden de architectuurbeschrijvingen niet opgedeeld naar de verschillende
belanghebbenden van de onderneming. Voor elke fase van de ADM kunnen de belanghebbenden
echter wel impliciet bepaald worden. Bender (2009) definieert voor elk van deze
belanghebbenden die artefacten (diagrammen, lijsten en matrices) die tot hun interessegebied
behoren.
4.2.6. TAXONOMIE- EN PROCESVOLLEDIGHEID
Op deze eigenschappen scoort TOGAF net andersom dan Zachman. TOGAF scoort immers heel
hoog op de eigenschap procesvolledigheid, maar mist een structuur voor het ordenen van de
artefacten van de ADM. In die zin zou het Zachman raamwerk een perfecte aanvulling kunnen
zijn op TOGAF (Sessions, 2007).
4.3. INTEGRATED ARCHITECTURE FRAMEWORK (IAF)
4.3.1. TYPE INFORMATIE
Vier architectuurdomeinen voegen informatie toe aan de globale architectuur in het IAF:
business, informatie, informatiesystemen en technologie infrastructuur. Eerst en vooral is er
|Hoofdstuk 4
31
informatie nodig over de structuur van de business, zodanig dat men zicht kan krijgen over
welke technologie nodig is om de business te ondersteunen of mogelijk te maken. De
informatievoorziening heeft betrekking op de manier waarop de businessinformatie wenst
verwerkt te worden: wie heeft welke informatie nodig en wanneer, welke relaties bestaan
tussen informatiestromen,… In een derde architectuurdomein wordt er informatie verschaft
over de structuur van de informatiesystemen die de business ondersteunen. Er wordt gekeken
welke informatiesystemen gebouwd en welke gekocht moeten worden (build vs. buy decision).
Ten slotte zorgt de technologie- infrastructuur dan voor de ondersteuning in het gebruik van de
informatiesystemen en applicaties (Van ’t Wout et al., 2010).
4.3.2. BEREIK
Het raamwerk moet gebruikt kunnen worden op alle niveaus in een organisatie. Het IAF moet
met andere woorden van toepassing kunnen zijn op eender welk systeem, gaande van een
organisatie, een business unit tot specifieke projecten. Voor elk systeem kan er een architectuur
ontworpen worden. Het bereik van het IAF is dus sterk vergelijkbaar met dat van het Zachman
raamwerk en gaat eveneens uit van een holistische benadering, waarbij een organisatie gezien
wordt als een vervlochten geheel van facetten.
4.3.3. DETAILNIVEAU
Net zoals dit in het Zachman raamwerk het geval is, wordt ook in het IAF een hoog detailniveau
verkregen. Elk systeem wordt beschreven vanuit vier architectuurdimensies, die op hun beurt
nog verder gedetailleerd worden over verschillende abstractieniveaus. Het raamwerk heeft in
totaal twintig cellen waardoor een architectuurbeschrijving zeer gedetailleerd kan worden
opgesteld.
4.3.4. AARD
Het raamwerk levert voornamelijk principes, standaarden, richtlijnen en modellen op.
4.3.5. BELANGHEBBENDEN
In het IAF wordt de architectuurbeschrijving niet opgedeeld naar belanghebbenden. Om de
architectuur over te brengen naar de verschillende belanghebbenden van de onderneming
definieert het raamwerk echter wel enkele views. Zo een view is een verzameling
architectuurartefacten die in overeenstemming zijn met bepaalde criteria; voorbeelden zijn
governance view, performance view, …
|Hoofdstuk 4
32
4.3.6. TAXONOMIE- EN PROCESVOLLEDIGHEID
Hoewel het IAF en het Zachman raamwerk sterk op elkaar lijken, is er toch een klein verschil in
opvatting van architectuur tussen de twee. Zachman ziet architectuur eerder als een ‘one-shot’
proces. Het IAF benadrukt meer het feit dat architectuur een nooit stoppend proces is en is
daarom zodanig ontworpen dat het raamwerk makkelijk haar inhoud aan andere raamwerken
kan uitlenen die eerder procesgericht zijn, zoals TOGAF. Dit raamwerk (of meer specifiek de
ADM van TOGAF) geeft dan het proces voor IAF’s inhoud. Het IAF is dus een heel flexibel
raamwerk: het kan zowel op zichzelf gebruikt worden, als samen met andere methoden. Dit is
tevens het geval voor Zachman, alleen wordt bij deze laatste de samenspraak met andere
raamwerken minder benadrukt.
4.4. FEDERAL ENTERPRISE ARCHITECTURE FRAMEWORK (FEAF)
4.4.1. TYPE INFORMATIE
Het FEAF maakt onderscheid tussen vier architectuurgebieden: business architectuur, data
architectuur, applicatie architectuur en technologie architectuur.
4.4.2. BEREIK
Het bereik van het FEAF betreft alle organisaties die deel uitmaken van de federale overheid van
een land en al haar partners, waaronder (Schekkerman, 2004):
- Grote federale departementale systemen
- Departementale subagentschappen -en kantoorsystemen
- Andere federale agentschapsystemen
- Systemen waar substantiële federale investeringen betrokken zijn bij internationale, staats-
of lokale overheden
4.4.3. DETAILNIVEAU
Het FEAF laat toe om belangrijke delen van de federale onderneming, zijnde de architecturale
segmenten, individueel te ontwikkelen, terwijl ze ondertussen geïntegreerd worden in de
ruimere enterprise architectuur. Een segment is niets anders dan een onderneming binnen de
totale federale onderneming. Het detailniveau is vrij hoog aangezien de
architectuurbeschrijvingen voor elk segment opgedeeld zijn aan de hand van twee dimensies,
namelijk verschillende perspectieven en verschillende abstractieniveaus.
|Hoofdstuk 4
33
4.4.4. AARD
Informatie in het FEAF wordt voornamelijk weergegeven aan de hand van modellen,
standaarden en richtlijnen.
4.4.5. BELANGHEBBENDEN
Aangezien de FEAF-matrix volledig gebaseerd is op de eerste drie kolommen van het Zachman
raamwerk, wordt ook de architectuurbeschrijving op dezelfde manier opgedeeld naar
belanghebbenden als bij Zachman. Volgende belanghebbenden worden onderscheiden: de
planner, de eigenaar (owner), de ontwerper (designer), de ontwikkelaar (builder) en de
onderaannemer (subcontractor).
4.4.6. TAXONOMIE- EN PROCESVOLLEDIGHEID
Het FEAF is een zeer complete methodologie. Het bestaat immers zowel uit een taxonomie,
zoals Zachman (weergegeven door de FEAF matrix), als een architecturaal proces, zoals TOGAF
(Sessions, 2007).
4.5. VERGELIJKING
Zoals eerder vermeld is geen enkel EA raamwerk compleet. Elk raamwerk heeft zijn sterktes en
zwaktes. In dit hoofdstuk werden enkele belangrijke EA raamwerken (het Zachman raamwerk,
TOGAF, het IAF en het FEAF) vergeleken op basis van de volgende zes eigenschappen: type
informatie, bereik, detailniveau, aard, belanghebbenden, taxonomie- en procesvolledigheid. Uit
deze analyse kunnen voor elk van de zes eigenschappen een aantal conclusies getrokken
worden.
Eerst en vooral is het opvallend dat de informatie die aanwezig is in elk van de besproken EA
raamwerken evenwichtig verdeeld is over alle vier de architectuurdomeinen: business,
informatie, organisatie en techniek. Dit verklaart waarschijnlijk waarom de besproken EA
raamwerken zoveel toegepast worden in de praktijk. Immers, een raamwerk dat bijvoorbeeld
vooral focust op het informatie- architectuurdomein in vergelijking met de andere
architectuurdomeinen is veel minder compleet en zal bijgevolg veel minder populariteit en dus
praktische toepasbaarheid genieten.
Een tweede conclusie die getrokken kan worden is dat de architectuurinformatie van de
besproken EA raamwerken zowel betrekking kan hebben op de volledige onderneming, als op
een bedrijfstak of businessunit van de onderneming. De raamwerken gaan uit van een
|Hoofdstuk 4
34
holistische benadering, wat betekent dat een onderneming gezien wordt als een vervlochten
geheel van onderdelen.
Het detailniveau wordt bij de verschillende EA raamwerken op een andere manier bepaald.
Zowel in het Zachman raamwerk, het IAF, als het FEAF is het detailniveau in functie van de
cellen van het raamwerk. Bij TOGAF daarentegen is het in functie van de iteraties van de ADM.
Geen enkel van de besproken EA raamwerken is prescriptief van aard. Ze zijn allen onafhankelijk
van bepaalde modelleernotaties waardoor ze de gebruiker met andere woorden geen enkele
verplichting opleggen wat betreft notatie. Deze flexibiliteit inzake notatie kan zowel een
voordeel als een nadeel zijn.
Van de besproken EA raamwerken, delen zowel het Zachman raamwerk als het FEAF de
architectuurbeschrijvingen op naar de verschillende belanghebbenden van de onderneming. Bij
TOGAF is dit niet het geval, hier kunnen de belanghebbenden enkel impliciet bepaald worden.
Ook bij het IAF is er geen expliciete indeling van architectuurbeschrijvingen naar
belanghebbenden van de organisatie.
Op vlak van taxonomie– en procesvolledigheid, treden er grote verschillen op tussen de EA
raamwerken. De vraag is namelijk of een raamwerk dan wel meer naar een taxonomie, dan wel
meer naar een methodologie toeneigt. Een methodologie beschrijft de processen voor het
ontwikkelen van een enterprise architectuur. Een taxonomie daarentegen, is een classificatietool
voor het ordenen van EA- artefacten. Idealiter bestaat een EA raamwerk uit een koppeling van
deze twee componenten (Abdallah & Galal-Edeen, 2006). Voor de besproken EA raamwerken
kan het volgende vastgesteld worden:
Het Zachman raamwerk documenteert EA- artefacten, het geeft de huidige staat weer op een
gestructureerde manier. Het raamwerk geeft echter geen richtlijnen over hoe een enterprise
architectuur ontwikkeld kan worden, of over hoe verandering geïntroduceerd kan worden. Dit is
eveneens het geval voor het IAF.
Juist de omgekeerde situatie doet zich voor bij TOGAF. De ADM van TOGAF is immers een
gedetailleerde methode voor het ontwikkelen en afleveren van architectuurbeschrijvingen. Het
raamwerk geeft met andere woorden wel een gedetailleerd proces voor enterprise architectuur,
maar mist een structuur voor het ordenen van architectuurartefacten.
Slechts één van al de geselecteerde EA raamwerken voldoet aan beide componenten: het FEAF
bevat zowel een taxonomie, als een proces. Het proces van het FEAF specificeert hoe een
|Hoofdstuk 4
35
doelarchitectuur ontwikkeld kan worden, maar is echter wel veel minder specifiek dan de ADM
van TOGAF. Een taxonomie wordt in het FEAF voorzien aan de hand van de FEAF matrix.
In figuur 4.1 worden de besproken EA raamwerken weergegeven op een schaal die specificeert
of het raamwerk dan wel meer naar een taxonomie, dan wel meer naar een proces toeneigt.
Figuur 4.1: De besproken EA raamwerken: taxonomie of proces
4.6. BESLUIT VAN DE VERGELIJKING
Het is duidelijk dat de besproken EA raamwerken enkele leemtes bevatten. Het ene raamwerk
mist immers een proces voor het ontwikkelen van een enterprise architectuur, het andere een
taxonomie voor het ordenen van artefacten,…
Een compleet EA raamwerk zal met andere woorden slechts bekomen kunnen worden door het
combineren van enkele EA raamwerken. Het resultaat hiervan wordt een blended methodology
genoemd (cfr. supra).
Soms is er zelf geen combinatie van EA raamwerken nodig om tot een complete enterprise
architectuur te komen. Bewijs hiervan is het FEAF: dit EA raamwerk leunt vrij dicht aan bij wat
verstaan wordt onder een complete enterprise architectuur. Aangezien dit raamwerk zich echter
voornamelijk toespitst op overheidsinstellingen, zal het niet verder van toepassing kunnen zijn
voor de gevallenstudie.
Het zou met andere woorden interessant zijn mocht er ook zo een optimaal EA raamwerk
gecreëerd kunnen worden voor bedrijven in het algemeen. Aan de hand van de besproken EA
raamwerken zal getracht worden zo’n blended methodology samen te stellen.
|Hoofdstuk 4
36
De vereisten waaraan zo’n blended methodology moet voldoen (cfr. supra 2.4., p.11), worden
nogmaals overlopen. Dit keer worden ze ingevuld door EA raamwerken die antwoord bieden op
de vereisten.
1) Raamwerk: Het Zachman raamwerk ordent architecturale artefacten in een 6x6 matrix.
2) Methode: De architecture development method (ADM) van TOGAF is een methode voor het
ontwikkelen van een enterprise architectuur.
3) Principes: Architectuurprincipes worden neergeschreven in de preliminary phase van de
ADM van TOGAF.
4) Een blueprint van de onderneming kan weergegeven worden door het Zachman raamwerk.
Deze deelt de architectuurbeschrijvingen van een onderneming namelijk in, op basis van zes
stakeholdersperspectieven en zes inhoudsdimensies. In die zin bevat elke cel dus een deel
van de blueprint van een onderneming.
5) Een ontwerp van één enkele oplossing wordt weergegeven in de laatste rij van het Zachman
raamwerk. Daar wordt immers weergegeven hoe de onderneming of een onderdeel van de
onderneming in de realiteit functioneert.
Uit dit overzicht kan met andere woorden besloten worden dat het Zachman raamwerk en
TOGAF elkaar perfect zouden kunnen aanvullen om een compleet EA raamwerk te vormen. De
twee EA raamwerken zouden dus een optimale blended methodology kunnen vormen. In de
gevallenstudie zal hierop verder ingegaan worden. Er zal gekeken worden hoe deze twee EA
raamwerken in combinatie met elkaar gebruikt kunnen worden.
|Hoofdstuk 5
37
HOOFDSTUK 5: BESLUIT LITERATUURSTUDIE
Het belang van EA is over de laatste jaren sterk toegenomen. Bedrijven hebben vaak te maken
met complexe informatiesystemen, waardoor het onderling afstemmen van business en IT een
moeilijke kwestie wordt.
Om deze complexiteit op een gecontroleerde manier aan te pakken, hebben ondernemingen EA
nodig. Met EA worden de relevante aspecten van de organisatie inrichting – zowel die van de
business als die van de IT – in samenhang ontworpen en geïmplementeerd in de organisatie. EA
wordt op een gestructureerde manier gedocumenteerd aan de hand van een EA raamwerk.
Tegenwoordig zijn er enorm veel EA raamwerken in omloop. Slechts enkele van deze worden
veelvuldig toegepast in de praktijk: het Zachman raamwerk, TOGAF, het FEAF en het IAF.
Echter, geen enkel van deze EA raamwerken is compleet. Daarom moeten stukjes en beetjes van
verschillende EA raamwerken gecombineerd worden om te kunnen komen tot een compleet EA
raamwerk. Het resultaat van zo een combinatie wordt een blended methodology genoemd.
Twee van de meest bekende EA raamwerken - het Zachman raamwerk en TOGAF - zouden
geïntegreerd kunnen worden met elkaar om zo een optimale blended methodology te vormen.
38
DEEL II: GEVALLENSTUDIE
|Hoofdstuk 6
39
HOOFDSTUK 6: INLEIDING GEVALLENSTUDIE
Uit de literatuurstudie werd besloten dat een compleet enterprise architectuur raamwerk enkel
kan bekomen worden door meerdere EA raamwerken te combineren. Meer bepaald het
Zachman raamwerk en TOGAF zouden elkaar perfect kunnen aanvullen om een optimale
blended methodology te vormen.
In deze gevallenstudie zal nagegaan worden op welke manier deze twee EA raamwerken kunnen
gecombineerd worden met elkaar.
Eerst en vooral wordt in hoofdstuk 7 ingegaan op het Zachman raamwerk. Enkele architecturale
modellen zullen voor elke cel van dit raamwerk opgesteld worden. Het is van essentieel belang
dat deze architecturale modellen zo optimaal mogelijk worden opgesteld. Daarom zal bij
uitwerking rekening worden gehouden met de inhoudelijke gaps van het raamwerk.
Niet enkel op inhoudelijk vlak, maar ook op algemeen vlak zijn er enkele gaps in het Zachman
raamwerk. In hoofdstuk 8 wordt een overzicht gegeven van deze gaps.
Hieruit wordt duidelijk dat de architectuurbeschrijvingen van het Zachman raamwerk op zich
niet voldoende zijn om te kunnen spreken van een complete enterprise architectuur. Meer
bepaald is er nood aan een architectuurmethode voor het implementeren van de architectuur
van een onderneming. De ADM van TOGAF is zo een architectuurmethode.
In hoofdstuk 9 komen we uiteindelijk tot de kern van deze gevallenstudie: hierin gaan we na hoe
het Zachman raamwerk en de ADM van TOGAF kunnen geïntegreerd worden met elkaar.
Het overkoepelend raamwerk dat hieruit bekomen wordt, zal ten slotte verder toegelicht
worden in hoofdstuk 10.
Zowel de uitwerking van de modellen van het Zachman raamwerk in hoofdstuk 7, als de
uitwerking van het overkoepelend raamwerk in hoofdstuk 10 zijn gebaseerd op een fictieve
onderneming KwaliCar. In de eerste paragraaf van dit hoofdstuk wordt deze onderneming kort
ingeleid. Dit hoofdstuk rond af met enkele assumpties die relevant zijn in het kader van deze
gevallenstudie.
|Hoofdstuk 6
40
6.1. KWALICAR
De gevallenstudie wordt gebaseerd op een fictieve onderneming, namelijk KwaliCar.
KwaliCar is een garage die instaat voor de reparatie en het onderhoud van personenwagens. Het
is een dochteronderneming van KwaliGroep. Deze laatste bestaat in totaal uit drie garages: een
garage voor personenwagens (KwaliCar), een garage voor vrachtwagens (KwaliTruck) en een
garage voor bromfietsen en motorfietsen (KwaliMotor). KwaliGroep is met andere woorden de
moederonderneming van deze drie garages.
Wat deze ondernemingen onderscheid van andere ondernemingen in dezelfde sector is hun
diepgaande oog voor kwaliteit. Deze wordt verzekerd door een team van bekwame werknemers,
zowel voor als achter de schermen. Ook de onderdelen die nodig zijn voor reparatie zijn van
superieure kwaliteit aangezien zij enkel afkomstig zijn van topleveranciers.
De interne werking en structuur van KwaliCar zullen in de loop van de gevallenstudie
verduidelijkt worden.
6.2. ASSUMPTIES
Voor wat betreft de gevallenstudie, dienen een aantal assumpties in acht genomen te worden:
- Deze gevallenstudie heeft enkel betrekking op de onderneming KwaliCar (cfr. supra) en niet
op de andere, soortgelijke ondernemingen KwaliTruck en KwaliMotor.
- De werkcultuur van KwaliCar moedigt het gebruik van een enterprise architectuur aan.
- Er is toewijding van het (top)management in het architectuur ontwikkeltraject. Volgens Toet
(2007) is deze toewijding uiterst noodzakelijk.
|Hoofdstuk 7
41
HOOFDSTUK 7: HET ZACHMAN RAAMWERK UITGEWERKT
Een eerste EA raamwerk dat deel uitmaakt van de blended methodology is het Zachman
raamwerk. Zoals reeds toegelicht werd in de literatuurstudie, is het Zachman raamwerk geen
methodologie, maar wel een taxonomie. Het raamwerk is een blueprint van de organisatie, een
logische structuur voor het classificeren en organiseren van descriptieve representaties van de
organisatie die van belang zijn voor het management van de organisatie, als ook voor de
ontwikkeling van de ondernemingssystemen (Lankhorst et al., 2009).
In dit hoofdstuk wordt het Zachman raamwerk uitgewerkt voor de onderneming KwaliCar. Voor
elke cel van het raamwerk wordt gezocht naar de modelleernotatie die het meest geschikt is
voor het weergeven van de inhoud van die cel.
Bij de uitwerking van het Zachman raamwerk dient er rekening gehouden te worden met een
belangrijke gap: het raamwerk legt geen enkele methode op voor het invullen van haar cellen.
Het gevolg hiervan is een tekort aan samenhang tussen de cellen van het raamwerk. Pereira &
Sousa (2004) stellen een methode voor om deze gap, de integratie gap genoemd, te voorkomen.
Hiermee rekening houdende, zullen de cellen van het Zachman raamwerk in dit hoofdstuk
uitgewerkt worden aan de hand van verschillende modelleernotaties.
Het hoofdstuk vangt aan met een assumptie die van belang is voor de verdere uitwerking van
het Zachman raamwerk. In de tweede paragraaf van dit hoofdstuk wordt ingegaan op de
integratie gap en wordt de methode van Pereira & Sousa ingeleid. De derde paragraaf werkt het
Zachman raamwerk uit aan de hand van deze methode. Een overzicht van de gebruikte
modelleernotaties of artefacten voor het uitwerken van de cellen van het raamwerk wordt
weergegeven in de voorlaatste paragraaf van dit hoofdstuk. Ten slotte zullen in de laatste
paragraaf ook nog enkele alternatieve modelleernotaties voor de cellen toegelicht worden.
7.1. ASSUMPTIE
Een belangrijke assumptie dient in acht genomen te worden voor wat betreft de uitwerking van
het Zachman raamwerk: in deze gevallenstudie worden enkel de eerste drie rijen van het
raamwerk verder uitgewerkt.
|Hoofdstuk 7
42
Het Zachman raamwerk telt in totaal zes rijen, waarvan de bovenste twee business georiënteerd
en de onderste drie technisch georiënteerd zijn. De derde rij van het raamwerk legt een brug
tussen dit business –en technisch domein.
Aangezien de vierde en vijfde rij doorgaans veel technischere lagen zijn ,worden deze vaak door
een software leverancier verder uitgewerkt (Fatolahi & Shams, 2006). Meestal worden de
modellen echter niet allemaal uitgewerkt. Vaak zal er voor het raamwerk enkel een rij vier en
vijf zijn voor de what- en de how kolommen. De andere inhoudsdimensies worden doorgaans
niet verder uitgewerkt voor deze rijen.
De vierde en vijfde rij van het raamwerk vallen met andere woorden buiten het takenpakket van
de enterprise architect en worden geoutsourced naar een software leverancier. Ook de zesde rij
van het raamwerk valt buiten het takenpakket van de enterprise architect aangezien dit de
functionerende onderneming zelf voorstelt.
Er kan dus geconcludeerd worden dat het bereik van het Zachman raamwerk in deze
gevallenstudie zal gaan van de eerste tot de derde rij.
7.2. INTEGRATIE GAP
Een belangrijke vereiste van het Zachman raamwerk is dat de cellen verticaal en horizontaal
geïntegreerd zijn. Juist aan deze vereiste lijkt het Zachman raamwerk niet te voldoen. De relatie
tussen de cellen is immers niet duidelijk gespecificeerd (Lankhorst et al., 2009). Hierdoor is er
een gebrek aan samenhang in het raamwerk.
Globaal gezien liggen hier twee factoren van aan de basis. Eerst en vooral legt het raamwerk
geen methode op voor het invullen van de cellen van het raamwerk. Het gevolg hiervan is dat bij
het willekeurig invullen van de cellen, de celinhoud weinig op elkaar zal afgestemd zijn. Ten
tweede is er een gebrek aan definiëring van de artefacten voor elke cel. Ook hierdoor zal
duidelijke samenhang in het raamwerk vaak ontbreken.
Stel immers dat een onderneming het Zachman raamwerk uitwerkt; hoe kan zij verzekeren dat
de modellen, opgesteld in een bepaalde cel, afgestemd zijn op de modellen uit andere cellen?
Indien de blueprint van een onderneming geen samenhang vertoont, kan er onmogelijk business-
IT alignment bekomen worden. In dat geval heeft enterprise architectuur dus maar weinig zin.
Het is duidelijk dat er een methode nodig is om deze integratie gap te voorkomen.
“There is an inadequate definition of the Zachman framework cells, as well as an insufficient
analysis of the interconnections between the cells.” (Ylimäki & Halttunen, 2006, p.206)
|Hoofdstuk 7
43
Een oplossing hiervoor wordt gegeven door Pereira & Sousa (2004). Deze auteurs hebben een
methode opgesteld voor het invullen van de cellen van het raamwerk. De methode geeft meer
bepaald de volgorde weer waarin de cellen dienen ingevuld te worden. Sommige cellen kunnen
immers slechts ingevuld worden indien de cellen van wie zij afhankelijk zijn reeds zijn ingevuld.
Door het toepassen van deze methode wordt aldus samenhang bekomen tussen de cellen van
het raamwerk.
Verdere samenhang wordt ook bekomen door het gebruik van de juiste artefacten voor elke cel.
Onder ‘juiste artefacten’ worden artefacten verstaan die aanvaard worden als algemene
modelleernotatie voor die cel. Bewust van dit feit, definieerden Pereira & Sousa een mogelijke
set van artefacten voor de eerste drie rijen van het raamwerk.
Integratie gap: Gebrek aan samenhang, integratie tussen de cellen, waardoor de modellen niet
onderling op elkaar zijn afgestemd.
Oplossing: Methode van Pereira & Sousa (2004).
7.3. METHODE VAN PEREIRA & SOUSA
In deze paragraaf wordt het Zachman raamwerk uitgewerkt aan de hand van de methode van
Pereira & Sousa (2004). Dit, om samenhang tussen de cellen te verzekeren. De methode van
Pereira & Sousa is een topdown methode die vertrekt vanuit de eerste rij, eerste kolom en
daaruit verder werkt. De volgorde van invullen wordt aangetoond in figuur 7.1.
Voor het verduidelijken van de methode, is elke cel in figuur 7.1. genoteerd in de vorm X,Y,Z.
Waarbij X de identificatie van de cel is, Y de volgorde van invullen is (1e stap, 2e stap,…) en Z de
cellen zijn waarvan cel X afhankelijk is.
Figuur 7.1: Methode van Pereira & Sousa
|Hoofdstuk 7
44
In deze gevallenstudie zal elke cel verkort genoteerd worden in de vorm XY, tevens gevolgd door
het rijnummer (Rx) en kolomnummer (Ky) om extra duidelijkheid te brengen. Enkele
voorbeelden ter illustratie: cel A1 (R1K1), cel K4 (R2K5), enzovoort.
De methode is als volgt opgebouwd:
- Stap 1: De eerste stap bestaat uit het invullen van de eerste rij van het raamwerk. Hiervoor
dient de kolomvolgorde bekend te zijn. Volgens Zachman is er geen kolomvolgorde, volgens
Bahill, Botta & Daniels (2006) wel. Zij definiëren de kolomvolgorde als volgt: what, how,
where, who, when en why. (In deze paragraaf wordt uitgegaan van de kolomvolgorde van
Bahill, Botta & Daniels.)
- Stap 2: Op basis van de artefacten uit cel A1 (R1K1), kan het Entity Diagram in cel G2 (R2K1)
ingevuld worden.
- Stap 3: De artefacten van cel B1 (R1K2) en cel G2 (R2K1) worden als input gebruikt voor het
opstellen van het business proces model in cel H3 (R2K2). De inhoud van cel G2 (R2K1)
dient als input voor het opstellen van de artefacten in cel M3 (R3K1).
- Stap 4: Voor elk van de cellen uit de vierde stap geldt dat hun inhoud afhankelijk is van de
inhoud van cel H3 (R2K2) in combinatie met de inhoud van hun bovenliggende cel.
- Stap 5: Op basis van de artefacten uit cel D1 (R1K4) en I4 (R2K3) kan cel J5 (R2K4)
opgesteld worden. In stap vijf worden eveneens de cellen O5 (R3K3) en Q5 (R3K5)
opgesteld, beiden hebben ze cel N4 (R3K2) als input. Tot slot wordt ook cel R5 (R3K6) in
deze stap opgesteld aan de hand van de output komende van cel N4 (R3K2) en cel L4
(R2K6).
- Stap 6: De laatste cel uit de methode van Pereira & Sousa is cel P6 (R3K4). De input van deze
cel zijn de cellen J5 (R2K4) en N4 (R3K2).
Zoals eerder vermeld (cfr. supra) stellen Pereira & Sousa voor elke cel uit de eerste drie rijen van
het raamwerk ook een mogelijke set van artefacten voor (zie figuur 7.2).
Op basis van deze artefacten en op basis van enkele artefacten voorgesteld door andere auteurs,
zullen alle cellen uit de eerste drie rijen van het raamwerk gemodelleerd worden. Dit, in de
volgorde bepaald door de methode van Pereira & Sousa (2004). De volgende paragrafen zijn
genummerd volgens de volgorde van invullen van het raamwerk; met achtereenvolgens stap 1,
stap 2, stap 3, stap 4, stap 5 en stap 6.
|Hoofdstuk 7
45
Figuur 7.2: Set van voorgestelde artefacten door Pereira & Sousa
7.3.1. STAP 1: HET BEREIK
De eerste stap uit de methode van Pereira & Sousa bestaat erin de cellen van de eerste rij van het
raamwerk in te vullen. Deze rij stelt de onderneming voor vanuit het gezichtspunt van de
planner en definieert op een hoog aggregatieniveau het bereik, of ook wel de grenzen genoemd,
van de onderneming. Deze rij bestaat louter uit tekstuele beschrijvingen en niet uit modellen.
- A1 (R1K1): Scope (contextual)/Data (what)
De cel die het bereik beschrijft in de data kolom wordt voorgesteld door een lijst van dingen
(objecten, middelen,…) waarin de onderneming geïnteresseerd is. Deze dingen worden
entiteiten genoemd. Het is belangrijk dat alle mogelijke entiteiten van de onderneming
vernoemd worden in deze lijst (Zachman, 1987). Immers, later wordt uit deze entiteitenlijst een
selectie gemaakt van de entiteitsklassen waarin geïnvesteerd zal worden voor het
informatiesysteem.
|Hoofdstuk 7
46
Volgende lijst van entiteiten kan opgesteld worden voor de onderneming KwaliCar:
- Klant - AutoKlant - Werknemer
Arbeider Bediende
- Directeur KwaliCar - Werk
Reparatie Onderhoud
- Onderdelen/uitrusting - Leverancier onderdelen - Concurrent - Doelstellingen - Factuur - Promotie
Er wordt vanuit gegaan dat de klanten van KwaliCar hun factuur onmiddellijk betalen en dat ook
omgekeerd KwaliCar haar leveranciers onmiddellijk vergoed. Daarom zijn er geen accounts
receivable- en accounts payable entiteiten opgenomen in bovenstaande lijst.
- B1 (R1K2): Scope (contextual)/Function (how)
Deze scope/functie- cel bestaat uit een lijst van processen die de onderneming uitvoert. Onder
processen worden activiteiten verstaan die input transformeren in output.
KwaliCar is enkel en alleen gespecialiseerd in de volgende processen:
- Reparatieproces - Onderhoudsproces
- C1 (R1K3): Scope (contextual)/Network (where)
Deze scope/network- cel bestaat uit een lijst van locaties waar de onderneming opereert. Deze
lijst bakent de locatie context af en moet dus op een voldoende hoog aggregatieniveau
beschreven zijn.
Aangezien de onderneming KwaliCar deel uit maakt van KwaliGroep, dienen ook de andere
dochterondernemingen van KwaliGroep weergegeven te worden in deze cel. Immers, deze
|Hoofdstuk 7
47
ondernemingen voeren dezelfde processen uit als KwaliCar, maar dan gericht op een ander
klantensegment (vrachtwagens, motorfietsen). Elk van deze ondernemingen zal voor het
uitvoeren van reparaties onderdelen nodig hebben. Deze worden geleverd door een vaste
leverancier van KwaliGroep, Bucar Parts. Aldus wordt de volgende lijst van business locaties
bekomen:
- KwaliGroep Corneel Heymanslaan 123, 9000 Gent
- KwaliCar Charles de Kerckhovelaan 45, 9000 Gent
- KwaliTruck Corneel Heymanslaan 123, 9000 Gent
- KwaliMotor Kortrijksesteenweg 245, 9000 Gent
- Leverancier onderdelen: Bucar Parts Spieveldstraat 25, 9160 Lokeren
- D1 (R1K4): Scope (contextual)/People (who)
Deze cel bakent de context af van mensen die betrokken zijn in de onderneming en moet aldus
op een voldoende hoog aggregatieniveau beschreven worden. Het wordt weergegeven door een
lijst van mensen die betrokken zijn bij de taken van de onderneming.
De volgende lijst van betrokkenen kan opgesteld worden voor de onderneming KwaliCar:
- CEO KwaliGroep - Directeur KwaliCar - Hoofd arbeidersdepartement - Hoofd bediendedepartement - Arbeiders - Bedienden
- E1 (R1K5): Scope (contextual)/Time (when)
De context/tijd- cel geeft de triggers weer die de business processen initiëren.
Voor KwaliCar kan volgende lijst met triggers opgesteld worden:
Met betrekking tot onderhoud:
- een klant maakt een afspraak voor onderhoud
- een klant brengt zijn auto naar de garage voor onderhoud
|Hoofdstuk 7
48
Met betrekking tot reparatie:
- een klant maakt een afspraak voor reparatie
- een klant brengt zijn auto naar de garage voor reparatie
Andere:
- een klant dient een klacht in
- F1 (R1K6): Scope (contextual)/Motivation (why)
Deze cel bestaat uit een lijst van de belangrijkste business doestellingen die significant zijn voor
de onderneming. Deze doelstellingen zijn afgeleid uit de visie en missie van de onderneming.
Missie:
Wij wensen onze klanten een excellente service te verlenen in de reparatie of het onderhoud van personenwagens. Om dit te garanderen, nemen wij enkel de meest gekwalificeerde werknemers in dienst. Verder zijn de onderdelen, nodig voor reparatie, enkel afkomstig van topleveranciers, waardoor een superieure kwaliteit verzekerd wordt.
Visie:
Bekend staan als de beste garage in de regio Gent wat betreft kwaliteit en service voor de reparatie en het onderhoud van personenwagens.
Strategie:
1) Nummer 1 klantvoorkeur zijn 2) Focus op kwaliteit 3) Winstgevendheid verhogen 4) Het verbeteren van de informatie uitwisseling tussen bedienden en arbeiders 5) Mee zijn met de nieuwste technologieën en technieken 6) Rekruteer gekwalificeerd personeel
7.3.2. STAP 2: CONCEPTUELE GEGEVENSMODELLERING
- G2 (R2K1): Business model (conceptual)/Data (what)
Deze business model/data- cel bevat een model dat een beeld geeft van de dingen (objecten,
middelen, verbanden, …) die van belang zijn voor de business van de onderneming (Zachman,
2003). Typisch gezien wordt deze voorgesteld aan de hand van een entity relationship diagram
(ER diagram).
Dit is een conceptueel datamodel dat genoteerd is volgens de UML notatie. Het is een
gegevensmodel dat qua opbouw nauw aansluit bij de werkelijkheid. In deze paragraaf wordt
|Hoofdstuk 7
49
echter niet verder gewerkt met een ER diagram, maar wel met een EER diagram (extended entity
relationship diagram). Dit is een ER diagram dat gebruik maakt van een aantal extra
abstractiemechanismen. Deze zijn nodig om het conceptueel datamodel van de onderneming
KwaliCar te kunnen opstellen.
De input voor het opstellen van het EER diagram van KwaliCar zijn de entiteiten die
gespecificeerd werden in cel A1 (R1K1) (Pereira & Sousa, 2004) (cfr. supra, p.45). Vooraleer te
starten met het opstellen van dit diagram, kan een scenario uitgeschreven worden. Dit is een
tekstuele beschrijving van het probleemdomein. Het is dus ook, net zoals het EER diagram, een
conceptueel model van de werkelijkheid. Alleen is dit scenario eerder informeel en bestaat het
gevaar op meerdere interpretaties ervan. Het scenario van KwaliCar kan als volgt uitgeschreven
worden: “Garage KwaliCar heeft werknemers in dienst. Deze zijn ofwel bedienden, ofwel
arbeiders. Arbeiders verdienen een uurloon, bedienden verdienen een wedde. De klant wordt
geregistreerd door een bediende. Een klant kan in het bezit zijn van één of meerdere auto’s. Deze
zijn elk gekenmerkt door een unieke nummerplaat. Arbeiders kunnen toegewezen zijn aan
meerdere werken. Een werk kan ofwel een reparatie ofwel een onderhoud zijn. Er kunnen
meerdere arbeiders werken aan één werk. Voor elk werk dat door de arbeiders wordt
uitgevoerd, wordt het aantal uren werk bijgehouden. Voor de reparatie van auto’s zijn er soms
onderdelen nodig. Deze worden geleverd door een leverancier. Voor elke reparatie of elk
onderhoud wordt een factuur opgesteld waarbij de kostprijs is afgeleid van de kostprijs van de
reparatie of het onderhoud, de kostprijs van de onderdelen, het aantal uren gewerkt en het
aantal arbeiders. De factuur wordt betaald door de klant.”
Het EER diagram van KwaliCar werd opgesteld aan de hand van de Rational Software Modeler
tool en wordt weergegeven in figuur 7.3.
|Hoofdstuk 7
50
Figuur 7.3: EER diagram
|Hoofdstuk 7
51
7.3.3. STAP 3: BUSINESS PROCES MODELLERING EN LOGISCHE DATA MODELLERING
- H3 (R2K2): Business model (conceptual)/Function (how)
Deze business model/functie- cel wordt weergegeven aan de hand van een model dat de
business processen van een onderneming in kaart brengt. Een standaardnotatie voor het
modelleren van bedrijfsprocessen is de Business Process Modeling Notation (BPMN). Het BPMN
model voor de onderneming KwaliCar werd opgesteld aan de hand van de Aris tool (zie figuur
7.4).
De input voor het opstellen van zo’n model zijn de artefacten uit de cellen B1 (R1K2) en G2
(R2K1) (Pereira & Sousa, 2004). Cel B1 (R1K2) definieert de business processen die de
onderneming uitvoert (cfr. supra, p.46). Het zijn juist deze business processen die moeten
voorgesteld worden in het BPMN diagram. Uit het EER diagram van cel G2 (R2K1) (cfr. supra,
p.48) kan afgeleid worden welke entiteiten iets ‘uitvoeren’ in de onderneming: een bediende
registreert een klant, een arbeider werkt aan een werk, een klant betaalt een factuur. De pools
van het BPMN diagram geven weer wie er verantwoordelijk is voor het uitvoeren van een
bepaald proces. Pools worden met andere woorden getypeerd met entiteiten uit het EER
diagram. In dit geval zijn dat de entiteiten arbeiders, bedienden en klanten uit het EER diagram.
Op deze manier kunnen procesgerichte en gegevensgerichte modellen gelinkt worden en
ontstaat er aldus horizontale integratie tussen de modellen. Om de business processen van
KwaliCar volledig in kaart te kunnen brengen in het BPMN diagram dient buiten de arbeiders,
bedienden en klanten, ook de leveranciers van de onderdelen in een pool opgenomen te worden.
Een ander model dat eveneens thuis kan gebracht worden in deze business model/functie-cel is
een value model. Dit model toont hoe in een onderneming waarde gecreëerd, overgebracht en
verbruikt wordt. Het geeft een beeld van de verschillende actoren die middelen uitwisselen
waardoor economische waarde kan gecreëerd worden.
Voor het visualiseren van een dergelijk value model zal er gebruik gemaakt worden van de e3
value methode, ontwikkeld door Professor Jaap Gordijn van de Vrije Universiteit Amsterdam.
Figuur 7.5 toont zo een e3 value model voor de onderneming KwaliCar.
|Hoofdstuk 7
52
Figuur 7.4: BPMN diagram
|Hoofdstuk 7
53
Figuur 7.5: e3 value model
Hieruit blijkt dat KwaliCar twee activiteiten uitvoert: de reparatie van auto’s en het onderhoud
van auto’s. Een leverancier staat in voor het leveren van onderdelen die nodig zijn voor
reparatie. Het pad, weergegeven door een stippellijn, start bij de klant. Hij/Zij heeft namelijk de
behoefte om zijn/haar auto binnen te brengen voor reparatie of onderhoud. De keuze die de
klant heeft tussen onderhoud of reparatie wordt weergegeven door de OR-fork. Indien de auto
van de klant binnengebracht wordt voor onderhoud, zal het pad na uitvoering van de
onderhoudsactiviteit stoppen. Indien de auto van de klant wordt binnengebracht voor reparatie
zijn er twee mogelijkheden: ofwel kan de reparatie uitgevoerd worden zonder de levering van
extra onderdelen, ofwel heeft de reparatie onderdelen nodig die geleverd moeten worden door
de leverancier. Ook hier wordt deze keuze in het e3 value model aangegeven door een OR-fork.
KwaliCar kan winst maken indien de inkomsten die ze ontvangt van haar klanten voor reparatie
en onderhoud groter zijn dan de uitgaven die ze moet betalen aan haar leverancier. Of met
andere woorden: winst kan gemaakt worden indien fee 1+ fee2 > fee 31.
1Onder de assumptie dat andere kosten (zoals bijv. loonkosten) niet inbegrepen zijn
- M3 (R3K1): System model (logical)/Data (what)
Deze cel bestaat uit een logisch model van de entiteiten (objecten, middelen,…) uit de
onderneming. Typisch gezien wordt ze weergegeven door een genormaliseerd ER type model.
Een genormaliseerd EER - model is niets anders dan een geheel van aan elkaar gekoppelde
relaties, waarbij de attribuuttypen van elke relatie een logisch geheel vormen. Het grote
|Hoofdstuk 7
54
voordeel is dat in een volgende stap een database kan opgesteld worden die gestructureerd is
volgens zo’n model en dat in deze database elk gegeven slechts één keer voorkomt.
Indien we het EER diagram uit cel G2 (R2K1) (cfr. supra, p.48) normaliseren, bekomen we een
relationeel database schema. Het eindresultaat van het normalisatieproces wordt weergegeven
in onderstaande kader. De grafische weergave van zo’n relationeel database schema wordt een
data map genoemd en wordt weergegeven in figuur 7.6.
Vereistleveringvan(werknr, bestnrlev)
werknr is een vreemde sleutel die verwijst naar werknr in Reparatie, NULL niet
toegelaten
bestnrlev is een vreemde sleutel die verwijst naar bestnrlev in Onderdelen_leverancier,
NULL niet toegelaten
Werktaan( wnr, werknr, urenGewerkt, aantal arbeiders)
wnr is een vreemde sleutel die verwijst naar wnr in Arbeider, NULL niet toegelaten
werknr is een vreemde sleutel die verwijst naar werknr in Werk, NULL niet toegelaten
Factuur(factuurnr, /kostprijs, klantnr)
klantnr is een vreemde sleutel die verwijst naar klantnr in Klant, NULL niet toegelaten
AutoKlant(nrplaat, automerk, ouderdom, klantnr)
klantnr is een vreemde sleutel die verwijst naar klantnr in Klant, NULL niet toegelaten
Klant(klantnr, naam, adres, geboortedatum, geslacht, wnr)
wnr is een vreemde sleutel die verwijst naar wnr in Bediende, NULL niet toegelaten
Werknemer(wnr, naam, adres, geboortedatum, geslacht)
Arbeider(wnr,uurloon)
wnr is een vreemde sleutel die verwijst naar wnr in Werknemer, NULL niet toegelaten
Bediende(wnr, maandwedde)
wnr is een vreemde sleutel die verwijst naar wnr in Werknemer, NULL niet toegelaten
Werk(werknr, nrplaat, probleem, datum, factnr)
factnr is een vreemde sleutel die verwijst naar factuurnr in Factuur, NULL niet toegelaten
Onderhoud(werknr, kostprijsonderhoud)
werknr is een vreemde sleutel die verwijst naar werknr in Werk , NULL niet toegelaten
Reparatie(werknr, kostprijsreparatie, benodigdeonderdelen)
werknr is een vreemde sleutel die verwijst naar werknr in Werk , NULL niet toegelaten
Onderdelen_leverancier(bestnrlev, kostprijsonderdelen, aantalonderdelen)
|Hoofdstuk 7
55
Figuur 7.6: Data map
Er dient opgemerkt te worden dat in de data map (figuur 7.6) een verlies aan informatie optreedt. Er
zijn immers vijf structuurbeperkingen die wel opgenomen werden in het EER diagram (cfr. supra,
p.50), maar niet langer tot uitdrukking komen in deze verzameling van relaties:
Het verplichte bezit van een auto door een klant.
Een factuur wordt opgesteld voor elk werk.
Een factuur hoort toe tot maximum één werk.
Onderdelen van de leverancier die enkel kunnen geleverd worden indien er een bestelling is.
Er moet verplicht gewerkt worden aan een werk. (= de verplichte deelname van werk aan
werktAan.)
7.3.4. STAP 4: BUSINESS LOCATIES, FUNCTIES VAN HET INFORMATIESYSTEEM,
TIJDSEQUENTIE VAN DE BUSINESS ACTIVITEITEN EN BUSINESS MOTIVATIE
- I4 (R2K3): Business model (conceptual)/Network (where)
Deze cel wordt weergegeven aan de hand van een model dat de verschillende locaties van de
onderneming weergeeft en haar onderlinge connecties. Voorbeelden van connecties zijn
gesprekken, data, post, spoorwegverkeer, vrachtwagenverkeer of scheepvaart.
|Hoofdstuk 7
56
De lijst van business locaties uit cel C1 (R1K3) (cfr. supra, p.46) en het BPMN model uit cel H3
(R2K2) (cfr. supra, p.51) dienen als input voor het opstellen van het model uit deze cel (Pereira
& Sousa, 2004). De input van het BPMN model is echter vrij summier: uit dit model kan immers
enkel opgemaakt worden dat KwaliCar haar onderdelen bestelt bij een leverancier. Voor de
andere dochterondernemingen KwaliTruck en KwaliMotor wordt er vanuit gegaan dat zij
eveneens hun onderdelen bestellen bij dezelfde leverancier als KwaliCar.
In de literatuur is weinig informatie te vinden betreffende het model dat gebruikt kan worden
om deze cel weer te geven. Daarom zal deze cel gemodelleerd worden aan de hand van een
schema dat de locaties van de onderneming weergeeft, evenals de onderlinge connecties en
communicatiekanalen die ertussen bestaan.
De onderneming die in deze gevallenstudie wordt uitgewerkt (KwaliCar), maakt deel uit van
KwaliGroep. Deze is de moederonderneming van in totaal drie ondernemingen: KwaliCar,
KwaliTruck en KwaliMotor. De dochterondernemingen hebben dezelfde leverancier waar ze
onderdelen bij bestellen en onderdelen van ontvangen. De pijlen uit figuur 7.7. geven de
onderlinge connecties weer die bestaan tussen enerzijds de moederonderneming en de
dochterondernemingen en anderzijds tussen de dochterondernemingen en de leverancier.
Figuur 7.7: Schema van locaties en connecties
- N4 (R3K2): System model (logical)/Function (how)
In deze cel dienen de functies van het informatiesysteem van de onderneming gemodelleerd te
worden. Dit is de taak van de systeemontwerper. De functionele vereisten van een systeem
worden doorgaans gedocumenteerd aan de hand van use cases (Radwan & Majid, 2011). Deze
|Hoofdstuk 7
57
tonen de interactie tussen het systeem en haar gebruikers. Een use case op zich is niets anders
dan een opeenvolging van transacties die in dialoogvorm worden uitgevoerd door het systeem
en een gebruiker. De relatie tussen de gebruikers en de use cases van een systeem kunnen
gevisualiseerd worden aan de hand van een use case diagram. Dit is een samenvatting van al de
functionaliteiten die een systeem moet bezitten voor de gebruikers ervan.
Voor het opstellen van het use case diagram dient het BPMN model uit cel H3 (R2K2) in acht
genomen te worden (Pereira & Sousa, 2004) (cfr. supra, p.51). Hoewel een use case diagram en
een BPMN model niet echt afhankelijk zijn van elkaar, bestaat er toch een zeker verband tussen
de twee. Immers, systeemsoftware wordt ontwikkeld om enkele business processen of
activiteiten te automatiseren of optimaliseren. Juist daarom kunnen reeds heel wat
functionaliteiten van het systeem uit het BPMN model afgeleid worden.
Voor de functionaliteiten van het systeem te verduidelijken, wordt hieronder de situatie van
KwaliCar geschetst voor en na implementatie van het intern informatiesysteem.
Hoe gebeurde het werk vroeger?
- De klant contacteerde KwaliCar telefonisch om een afspraak te maken voor
reparatie/onderhoud.
- Een bediende keek in het klantenbestand op de computer of de klant reeds geregistreerd
was.
- De afspraak werd in de agenda geplaatst.
- Op de dag wanneer de auto werd binnengebracht voor reparatie/onderhoud moest het
probleem (waarvoor het onderhoud of de reparatie van de auto nodig was) mondeling
overgebracht worden van de bediende naar de arbeiders die aan de auto zouden werken.
- De bedienden dienden bij te houden hoe lang aan het onderhoud of de reparatie gewerkt
werd.
Verder dienden de arbeiders, in geval van reparatie, aan de bediendeafdeling mee te delen of
er nieuwe onderdelen gebruikt werden. De bediendeafdeling kon dan aan de hand van de
aankoopfactuur van deze onderdelen nagaan wat hun kostprijs was.
- Aan de hand van het aantal uren gewerkt, het aantal arbeiders en de benodigde onderdelen
werd een factuur opgemaakt door de bediendeafdeling.
|Hoofdstuk 7
58
Samengevat:
Probleem: Er was continu dialoog nodig tussen de bediendeafdeling en de arbeidersafdeling om
informatie uit te wisselen.
Behoefte aan: Een systeem dat de informatie uitwisseling tussen bedienden en arbeiders zou
vergemakkelijken.
Hoe werkt het systeem vandaag?
Figuur 7.8: Het intern informatiesysteem in contact met de file server en met haar gebruikers
Vandaag de dag maakt KwaliCar gebruik van een intern informatiesysteem. Het systeem staat in
verbinding met een file server (zie figuur 7.8). Op deze file server worden alle gegevens van de
klanten en het werk (reparatie of onderhoud) bijgehouden. Per klant houdt de file server een
klantfile bij, gekenmerkt door een uniek klantnummer. Deze klantfile bestaat op haar beurt uit
meerdere werkfiles, ook gekenmerkt door een uniek werknummer. In het systeem kan zowel door
arbeiders als bedienden ingelogd worden. Zij hebben elk hun persoonlijke log in voor het systeem.
Hieronder wordt weergegeven hoe het werk vandaag verloopt door middel van het intern
informatiesysteem:
- De klant contacteert KwaliCar telefonisch.
- De bediende (die ingelogd is in het systeem) kijkt of de klant reeds geregistreerd is. Dit doet
hij door de klantnaam in te geven. Indien er meerdere klanten zijn met dezelfde naam, toont
het systeem een scroll list van deze namen samen met hun adres.
- Elke klantfile wordt in de file server opgeslagen onder een uniek nummer (klantnummer).
|Hoofdstuk 7
59
- Bij het aanmaken van een nieuwe klantfile, worden de gegevens van de klant in een blanco
klantfile ingevuld door de bediende. Na het invullen zal het systeem deze nieuwe klantfile
doorsturen naar de file server, waar het wordt opgeslagen onder een uniek klantnummer.
- Aan een bestaande klantfile kan een nieuwe werkfile toegevoegd worden. In zo een
werkfile worden verschillende gegevens geregistreerd: nummerplaat auto, probleem,
onderhoud of reparatie, datum van onderhoud of datum van reparatie. Nadat dit alles
geregistreerd is, zal het systeem de werkfile, die gekenmerkt wordt door een uniek
werknummer, doorsturen naar de file server. Van hieruit kan het opgehaald worden door de
arbeider die voor het uitvoeren van zijn werk deze gegevens zal nodig hebben.
- Op de werkplaats van de arbeiders gebeurt het volgende: indien een auto binnenkomt op de
werkplaats, geeft de arbeider de nummerplaat van deze auto in. Het systeem zal door de
combinatie van de unieke nummerplaat en de datum van die dag (die het systeem
automatisch zelf ingeeft) de werkfile van die klant kunnen ophalen. Hierin staat wat er juist
moet gebeuren (reparatie of onderhoud, probleem,…). Indien er nieuwe onderdelen nodig
zijn voor het uitvoeren van de reparatie, dient dit door de arbeider in de werkfile ingevuld
te worden. In de file server is er een aparte leveranciersfile waarin alle onderdelen van
de leverancier vermeld staan samen met hun prijs. Indien door de arbeider een onderdeel
wordt geselecteerd, zal het systeem automatisch de prijs van het onderdeel uit deze
leveranciersfile kunnen ophalen en vervolgens invullen in de werkfile waar de arbeider mee
bezig is. Verder geeft het systeem ook weer of het onderdeel in voorraad is in KwaliCar of
niet. Indien niet, zal het systeem automatisch een mail versturen naar de
onderdelenleverancier Bucar parts met een aanvraag tot bestelling. De gewenste onderdelen
worden dan standaard binnen de dag geleverd.
Als de reparatie of het onderhoud is afgerond, dient de arbeider het aantal gewerkte uren
(en eventueel het aantal arbeiders) van het werk in te vullen in de werkfile. De status van de
werkfile is ‘niet betaald’. Dit blijft zo totdat de factuur is opgesteld én betaald.
Assumptie: Onder ‘uren gewerkt’, worden enkel de uren verstaan waarin de arbeiders actief
met de reparatie of het onderhoud bezig zijn. Hieronder vallen dus niet de uren waarin niet
actief gewerkt wordt, zoals bijvoorbeeld wanneer de onderdelen nog moeten besteld en
geleverd worden (wat één dag in beslag neemt).
- Voor het opmaken van een factuur, geeft de bediende de naam (eventueel aangevuld met
het adres) van de klant in, evenals de nummerplaat van zijn of haar auto. Het systeem kan de
naam (en het adres) van de klant aan een uniek klantnummer koppelen waarvan de klantfile
zich in de file server bevindt. Aan de hand van de nummerplaat worden alle werkfiles uit
deze klantfile gehaald die als status ‘niet betaald’ hebben. Het systeem toont een scroll list
|Hoofdstuk 7
60
van deze werkfiles. De bediende kiest de werkfile waar hij of zij een factuur wenst van te
maken. Het systeem stelt nu automatisch een factuur op aan de hand van de gegevens uit de
werkfile (aantal uren gewerkt, aantal arbeiders, uurloon, kostprijs onderhoud, kostprijs
reparatie, kostprijs onderdelen). Het systeem voegt de factuur toe aan de werkfile en
verandert de betaalstatus van de werkfile van ‘niet betaald’ naar ‘factuur opgesteld’. Het
systeem stuurt de werkfile (met daarin de factuur) naar de file server, waar hij wordt
opgeslagen. Van hieruit kan het opgehaald worden door de bediende om het door te sturen
naar de klant of om de factuur af te printen.
- Indien de onderneming de betaling heeft ontvangen van de klant, zal de bediende de
werkfile van die klant opvragen en de betaalstatus veranderen naar ‘betaald’.
- Verder dient er nog opgemerkt te worden dat bedienden op elke moment de klantfile of
werkfile van een klant kunnen aanpassen. (Indien bijvoorbeeld het adres gewijzigd is van
de klant, de datum voor reparatie gewijzigd wordt,…)
Wat hierboven beschreven staat is niets anders dan het resultaat van interviews met bedienden
en arbeiders van KwaliCar over de functionele vereisten van het systeem. Dit is louter informeel.
Uit deze tekst kunnen we de use cases van het systeem afleiden en weergeven in volgend use case
diagram (figuur 7.9):
Creëer een nieuwe
klantfile
Bediende Arbeider
Pas bestaande
klantfile aan
Creëer een nieuwe
werkfile
Pas bestaande
werkfile aan
Stel factuur op
Voeg gegevens toe
aan werkfile
Figuur 7.9: Use case diagram
|Hoofdstuk 7
61
- K4 (R2K5): Business model (conceptual)/Time(when)
Om de tijd of de duur van activiteiten in een business cyclus van de onderneming uit te drukken
kan een Gantt chart gebruikt worden. Het toont hoe activiteiten elkaar opvolgen, wanneer de
activiteiten starten en hoelang ze duren.
De lijst van triggers die de business processen initiëren uit cel E1 (R1K5) (cfr. supra, p.47) en het
BPMN diagram uit cel H3 (R2K2) (cfr. supra, p.51) dienen als input voor deze cel. Een duidelijke
link tussen deze cellen en cel K4 (R2K5) is er echter niet, aangezien deze cellen op geen enkele
manier de activiteiten van de onderneming weergeven rekening houdend met het systeem van
KwaliCar.
Bij wijze van voorbeeld wordt in figuur 7.10 een Gantt chart opgesteld voor het
onderhoudsproces van KwaliCar vanuit het gezichtspunt van een arbeider. Een dergelijke Gantt
chart is handig omdat hierin de verwachte tijd van elke activiteit in het onderhoudsproces wordt
weergegeven. Het is een soort richtschema waar arbeiders hun werk kunnen op baseren. Aan de
hand hiervan weten ze hoe lang elke activiteit ongeveer zou mogen innemen.
Het onderhoudsproces bestaat uit vier opeenvolgende activiteiten. Voor elk van de activiteiten
werd de verwachte tijdsduur (V) berekend aan de hand van de optimistische (O), normale (N) en
pessimistische tijdsduur (P): V= (O+4M+P)/6. De grafiek in figuur 7.10 geeft een duidelijk
overzicht van hoe de activiteiten elkaar opvolgen en wat de verwachte tijdsduur is per activiteit.
Wanneer een auto binnenkomt voor onderhoud, zal een arbeider eerst de werkfile controleren
om te zien wat de werkomschrijving juist is voor die wagen. Pas hierna kan gestart worden met
het uitvoeren van het onderhoud. Als het onderhoud is afgerond, zal de arbeider vervolgens de
werkfile terug aanvullen (met onder andere het aantal uren gewerkt, aantal arbeiders,…). Op
basis van deze gegevens zal ten slotte door een bediende de factuur kunnen opgesteld worden.
|Hoofdstuk 7
62
Figuur 7.10: Gantt chart
- L4 (R2K6): Business model (conceptual)/Motivation (why)
Vooraleer in te gaan op de modelleernotatie van deze cel, dient een algemeen probleem van de
motivatiedimensie besproken te worden:
Terwijl de contextuele beschrijving van de motivatie dimensie kan voorgesteld worden door een
lijst bestaande uit de visie, missie en strategieën van de onderneming, dringt er zich een
probleem op bij de representatie van de andere perspectieven in de motivatiedimensie.
Één van de basisregels van het raamwerk is immers dat de cellen verticaal geïntegreerd dienen
te zijn. Verschillende cellen van eenzelfde kolom moeten met andere woorden aan elkaar
gerelateerd zijn (cfr. supra). Juist aan deze regel lijkt het Zachman raamwerk in het motivatie
abstractieniveau niet tegemoet te kunnen komen, aangezien er momenteel geen algemeen
aanvaarde notatie is voor de representatie van de motivatie concepten (Zachman, 2003). Er is
met andere woorden nood aan een overkoepelende methode voor de motivatiedimensie die
duidelijk het verband en de connectie kan aantonen tussen de visie, missie, strategie, doelen en
doelstellingen van een onderneming. Van hieruit kan vervolgens voor elke cel in de
motivatiedimensie een model opgesteld worden. Gokhale (2010) stelt als oplossing voor deze
gap het gebruik van de Balanced Score Card (BSC) voor. De BSC, ontwikkeld door Kaplan en
|Hoofdstuk 7
63
Norton, bekijkt de prestatie van een onderneming vanuit vier perspectieven: financieel, klanten,
interne bedrijfsvoering en ontwikkeling en groei. De BSC definieert de visie, missie, strategie,
doelstellingen, doelen, maatstaven en initiatieven van een onderneming afgestemd op de
algemene ondernemingsvereisten. In bijlage 3 wordt de BSC in detail uitgewerkt voor de
onderneming KwaliCar.
De BSC is een overkoepelende methode op basis waarvan de modellen uit de motivatiedimensie
van het raamwerk kunnen opgesteld worden. Op deze manier wordt verticale integratie tussen
de cellen in de motivatiekolom gegarandeerd.
Gebaseerd op de output van de BSC worden hieronder twee mogelijke modelleernotaties
uitgewerkt voor het weergeven van de business model/motivatie – cel van het raamwerk. Deze
cel wordt gemodelleerd aan de hand van een model dat de business doelstellingen en
strategieën (de ends en means) van de onderneming weergeeft.
Een eerst mogelijke manier om de business doelstellingen en strategieën van KwaliCar voor te
stellen is aan de hand van strategy maps. Deze drukken de causale verbanden uit tussen de
verschillende strategieën en verbinden op deze manier de vier perspectieven van de BSC. Ze
laten een onderneming toe de prestatie van hun BSC te visualiseren (Wu, 2011). Op basis van de
BSC output (uit bijlage 3) kan voor de onderneming KwaliCar de volgende strategy map
opgesteld worden:
Figuur 7.11: Strategy map
|Hoofdstuk 7
64
Zoals zichtbaar in figuur 7.11 bestaat de hoofdstrategie van KwaliCar erin om de
winstgevendheid te verhogen. Dit kan enkel indien de onderneming veel klanten kan aantrekken
en behouden. Het is met andere woorden belangrijk om nummer één in de klantvoorkeur te zijn.
Om dit te bereiken focust KwaliCar in haar bedrijfsvoering enerzijds op het bereiken van
kwaliteit en anderzijds op het verbeteren van de informatie uitwisseling. KwaliCar tracht
kwaliteit te garanderen door gekwalificeerd personeel te rekruteren en door continu mee te zijn
met de nieuwste technieken en technologieën.
Een ander model aan de hand waarvan de business model/motivatie- cel kan voorgesteld
worden, is het Business Motivation Model (BMM) (S. Ostadzadeh, Aliee & A. Ostadzadeh, 2007).
Het gebruik van het BMM voor deze motivatiecel wordt bevestigd in een paper uitgebracht door
de Business Rules Group (BRG, 2010). Zij definiëren het BMM als volgt: “Het is een schema voor
het ontwikkelen, communiceren en managen van business plannen op een georganiseerde
manier”. Het basisidee is om een business model van het business plan van de onderneming te
ontwikkelen, vooraleer de systeemontwikkeling gestart wordt. De belangrijkste elementen van
het model zijn onder te brengen in twee grote areas. Een eerste definieert de ends en means van
de business plannen. Dingen die de onderneming wil bereiken zijn ends. De manier waarop een
onderneming deze ends tracht te bereiken, worden means genoemd. Een tweede area bestaat uit
de interne en externe factoren die de onderneming beïnvloeden, evenals een assessment van de
impact die deze influencers hebben op de ends en means van de onderneming. Een assessment is
niets anders dan een SWOT analyse die gemaakt wordt van deze influencers. Al de elementen
waaruit het BMM bestaat (ends, means, influencers, assessment of influencers) zijn onderling
gerelateerd aan elkaar. In bijlage 4 wordt een algemeen BMM weergegeven. Hierin zijn duidelijk
de verschillende elementen te zien waaruit een BMM bestaat, evenals de onderlinge relaties
tussen deze elementen. Een vereenvoudigd BMM voor het fictief bedrijf KwaliCar is hieronder
weergegeven in figuur 7.12.
|Hoofdstuk 7
65
Figuur 7.12: BMM van KwaliCar
Means End
Vision Bekend staan als de beste garage in de regio Gent wat betreft kwaliteit en service voor de reparatie en het onderhoud van personenwagens.
Desired result
Goal -Verbeteren van de relatie met de klanten -Ontwikkelen van toepassingen die de kwaliteit verbeteren -Verhogen van inkomsten -Vastleggen van de USP -Ontwikkeling van informatiesystemen- en infrastructuur voor de interne informatie uitwisseling -Oudere technologieën vervangen door nieuwe indien nodig - Verbeteren van de selectie procedure
Objective -Zorgen dat het percentage tevreden klanten tegen 2015 groter is dan 85% -Zorgen dat de rentabiliteit van het eigen vermogen tegen 2015 met 3% is toegenomen. -Tegen 2015 een SWOT-analyse bekomen waarbij #sterktes/#zwaktes > 1 -De processing time tegen 2015 doen verminderen met 10%
Mission Wij wensen onze klanten een excellente service te verlenen in de reparatie of het onderhoud van personenwagens. Om dit te garanderen, nemen wij enkel de meest gekwalificeerde werknemers in dienst. Verder zijn de onderdelen, nodig voor reparatie, enkel afkomstig van topleveranciers, waardoor een superieure kwaliteit verzekerd wordt.
Course of action
Strategy -Implementeren van CRM technieken -Implementeren van six sigma training -Uitwerken van een marketingstrategie -Het toepassen van een SWOT analyse -Implementeren van een intern computerprogramma dat zowel door arbeiders als bedienden kan gebruikt worden -Halfjaarlijkse controle van de machines door expert -Beroep doen op rekruteringsbureau
Tactic -Bel nieuwe klanten persoonlijk op -Organiseer een aantal marketingevents voor de klanten -Schaf extra computers aan voor in de werkruimte -Werk samen met Randstad voor het rekruteren van gekwalificeerd personeel -Plan een vergadering met het management voor het uiteenzetten van de SWOT analyse van KwaliCar
Influencer
External influencer Competitie: laag (weinig garages in het centrum van de stad) Internal influencer -hoog opgeleid personeel -beperkte mogelijkheid tot uitbreiden
Assessment -Strength Hoog opgeleid personeel -Weakness Beperkte mogelijkheid tot uitbreiden -Opportunity Weinig competitie -Threat /
Directive
Business Policy Een business verantwoordelijke neemt persoonlijk contact op met elke klant die een klacht indient.
Business Rule Een onderhoud mag niet langer duren dan twee uren.
|Hoofdstuk 7
66
Het BMM voor de onderneming KwaliCar kan grotendeels opgesteld worden aan de hand van de
output van de BSC. Alleen is er soms verwarring betreffende de termen die in het BMM gebruikt
worden en de termen die in de BSC gebruikt worden. Tabel 7.1 geeft een overzicht van enkele
belangrijke termen in het BMM en hun BSC tegenhanger.
Busines Motivation Model Balanced Score Card
Goals = Doelstellingen
Objectives = Maatstaven en doelwaarden die
vooropgesteld werden voor de
doelstellingen van de onderneming
Strategy = Initiatieven
Tactics = /
Tabel 7.1: Overzicht BMM termen en hun BSC tegenhangers
De dingen die de onderneming wil bereiken, ends genoemd, worden gedefinieerd aan de hand
van de visie en de desired results van de onderneming. De desired results bestaan uit goals en
objectives. De goals uit het BMM komen overeen met wat in de BSC doelstellingen worden
genoemd. Ze drukken kwalitatief uit wat de onderneming wenst te bereiken. De objectives
daarentegen, drukken kwantitatief uit wat de onderneming wenst te bereiken en komen overeen
met de maatstaven en doelwaarden uit de BSC.
De manier waarop de onderneming haar ends tracht te bereiken, worden means genoemd. Deze
means worden gedefinieerd aan de hand van de missie, de courses of action en de directives. Net
zoals de desired results opgedeeld worden in goals en objectives, worden ook de courses of action
opgedeeld in strategies en tactics. Een strategy definieert hoe goals kunnen bereikt worden. Het
wordt in de BSC weergegeven aan de hand van initiatieven die bijdragen tot het bereiken van de
doelstellingen van de onderneming. De kwantitatieve tegenhanger van de strategies zijn de
tactics. Deze geven de acties weer die op korte termijn ondernomen worden om de objectives te
bereiken. Tactics zijn specifieke acties die ondernomen worden om de strategies te
implementeren. Zij hebben geen tegenhanger in de BSC.
Bijkomstige elementen van het BMM zijn onder andere de directives, de influencers en een
assessment van deze influencers. Deze worden ook kort besproken voor de onderneming
KwaliCar. De relatie tussen de elementen van het BMM wordt weergegeven door de dikke
zwarte lijnen in figuur 7.12.
|Hoofdstuk 7
67
7.3.5. STAP 5: ORGANOGRAM, SYSTEEMCONTEXT, SYSTEEMTRIGGERS EN BUSINESS
RULES
- J5 (R2K4): Business model (conceptual)/People (who)
Deze cel bestaat uit een model waarin de verantwoordelijkheden worden weergegeven die
binnen de onderneming bestaan. Typisch gezien wordt deze cel gemodelleerd aan de hand van
een organogram.
Figuur 7.13: Organogram van KwaliCar
Een organogram geeft de hiërarchische structuur van een organisatie weer. Idealiter specificeert
het ook de taakomschrijving van elke functie binnen de onderneming. Het organogram kan
opgesteld worden aan de hand van de artefacten komende uit de cellen D1 (R1K4) en I4 (R2K3)
(Pereira & Sousa, 2004). Figuur 7.13 toont het organogram voor de onderneming KwaliCar. Voor
elke functie worden duidelijk de verantwoordelijkheden en taken vermeld waaruit ze bestaan.
- O5 (R3K3): System model (logical)/Network (where)
Deze cel dient weergegeven te worden aan de hand van een technologie neutraal model dat de
faciliteiten van het systeem (storage devices, gebruikers,…) definieert. Volgens Radwan & Majid
|Hoofdstuk 7
68
(2011) kan deze cel gemodelleerd worden aan de hand van een systeem context diagram. Zo een
diagram visualiseert het systeem en al de spelers (systemen of personen) die ermee interageren.
In een systeem context diagram worden geen details over de interne structuur van het systeem
weergegeven. Het toont daarentegen wel de interacties die plaatsvinden tussen het systeem en
de spelers waarmee het systeem interageert. Input van deze cel is het use case diagram uit cel
N4 (R3K2) (Pereira & Sousa, 2004) (cfr. supra, p.60).
In figuur 7.14 wordt het systeem context diagram van het intern systeem van de onderneming
KwaliCar weergegeven. Het systeem interageert met de file server, met bedienden en met
arbeiders. Hetgeen wat het systeem met haar actoren uitwisselt zijn verschillende klantfiles en
werkfiles.
Figuur 7.14: Systeem context diagram
- Q5 (R3K5): System model (logical)/Time(when)
Het model van deze cel dient de triggers te beschrijven die ervoor zorgen dat het systeem van de
ene staat naar de andere staat overgaat. Volgens Fatolahi & Shams (2006) kan dit weergegeven
worden aan de hand van UML sequence diagrams. Deze beschrijven de communicatie en de
volgorde van communicatie tussen het systeem en haar actoren. Het enigste nadeel van zo een
diagram is echter wel dat het niet in staat is om de duur van iets weer te geven.
|Hoofdstuk 7
69
De input van deze cel is het use case diagram uit cel N4 (R3K2) (cfr. supra, p.60). Voor elke use
case uit het use case diagram kan een UML sequence diagram opgesteld worden. Bij wijze van
voorbeeld wordt hieronder het UML sequence diagram uitgewerkt voor de use case ‘Creëer een
nieuwe klantfile’ (zie figuur 7.15).
Vooraleer een bediende een nieuwe klantfile kan aanmaken in het systeem, dient hij/zij ingelogd
te zijn in het systeem. De trigger die de activiteit ‘Creëer een nieuwe klantfile’ initialiseert in het
systeem, is de bediende die in het menu van het systeem ‘Creëer een nieuwe klantfile’ aanklikt.
Hierna presenteert het systeem een blanco veld waarin de bediende de klantgegevens (naam,
adres, geboortedatum, geslacht, nummerplaat auto, automerk, ouderdom auto) kan invullen. Om
er zeker van te zijn dat deze klant niet reeds geregistreerd werd, maakt het systeem connectie
met de file server: het systeem controleert of de net ingegeven klantgegevens niet overeen
komen met reeds bestaande klantgegevens. Indien dit het geval is, dient het systeem een error
message weer te geven en wordt de activiteit ‘Creëer een nieuwe klantfile’ afgebroken. Indien er
geen overeenkomstige klantgegevens in de file server worden teruggevonden, zal het systeem
de nieuwe klantfile doorsturen naar de file server waar het wordt opgeslagen onder een uniek
klantnummer. Vanuit de file server kan deze klantfile later opgevraagd worden om de gegevens
van de klant te wijzigen of om er een werkfile aan toe te voegen.
User (bediende) Systeem File server
Get klantgegevens
Confirm
Confirm
Klantgegevens
Login
Check klantgegevens
Store klantfile
Figuur 7.15: UML sequence diagram voor de use case ‘Creëer nieuwe klantfile’
|Hoofdstuk 7
70
- R5 (R3K6): System model (logical)/Motivation(why)
Deze cel bevat een model dat de business rules van de onderneming weergeeft. Echter, tot op
heden is er nog geen algemeen aanvaarde modelleernotatie gedefinieerd voor het weergeven
van deze business rules.
Merk op dat in het BMM van cel L4 (R2K6) (cfr. supra, p.65) ook reeds enkele business rules
geformuleerd werden. Deze hebben echter enkel betrekking op de structuur en werking van de
business - en niet op het informatiesysteem of de technologie van de onderneming.
Enkele voorbeelden van business rules die betrekking hebben op het informatiesysteem van
KwaliCar zijn:
- Elke gebruiker van het systeem moet eerst inloggen vooraleer hij/zij toegang krijgt tot
het systeem.
- Het systeem moet 24 /24 uur en 7/7 dagen beschikbaar zijn voor de werknemers van
KwaliCar.
7.3.6. STAP 6: SYSTEEMGEBRUIKERS
- P6 (R3K4): System model (logical)/People (who)
In deze cel dienen de gebruikers van het systeem gespecificeerd te worden. Doorgaans kunnen
deze weergegeven worden aan de hand van een use case diagram. Een use case diagram
visualiseert immers de relatie tussen de gebruikers en de use cases van het systeem. Dit diagram
werd reeds uitgewerkt in de systeem model/functie- cel (R3K2) (cfr. supra, p.60). De gebruikers
van het systeem bij KwaliCar zijn arbeiders en bedienden.
Creëer een nieuwe
klantfile
Bediende Arbeider
Pas bestaande
klantfile aan
Creëer een nieuwe
werkfile
Pas bestaande
werkfile aan
Stel factuur op
Voeg gegevens toe
aan werkfile
Figuur 7.16: Use case diagram
|Hoofdstuk 7
71
7.4. OVERZICHT GEBRUIKTE ARTEFACTEN
Tabel 7.2 geeft een overzicht van alle artefacten die hierboven werden toegelicht voor de
verschillende cellen van het raamwerk.
7.5. ALTERNATIEVE ARTEFACTEN
In paragraaf 7.3. werd meestal per cel slechts één modelleernotatie uiteengezet. Echter, vele
cellen kunnen ook door een ander soort model gemodelleerd worden. De belangrijkste zullen
kort in deze paragraaf besproken worden.
Voor de eerste rij van het raamwerk bestaan er geen alternatieve modelleernotaties. Deze rij
bestaat immers enkel en alleen uit tekstuele beschrijvingen en niet uit modellen.
Voor de tweede en derde rij van het raamwerk zijn er wel alternatieve modelleernotaties
voorhanden. Volgens Fatolahi & Shams (2006) kunnen bijna alle cellen uit de tweede en derde
rij van het raamwerk in UML (Unified Modeling Language) notatie gemodelleerd worden. In de
Data (what)
Function (how)
Network (where)
People (who)
Time (when)
Motivation (why)
Scope (contextual)
Lijst Lijst Lijst Lijst Lijst Lijst
Business model (conceptual)
EER diagram -BPMN -Value model
Locatie & connectie schema
Organogram Gantt chart
-Strategy maps -BMM
System model (logical)
Genormaliseerd EER diagram
Use case diagram
Systeem context diagram
Use case diagram
UML sequence diagram
/
Technology model (physical)
Detailed representations (out of context)
Functioning enterprise
Tabel 7.2: Overzicht gebruikte artefacten
|Hoofdstuk 7
72
vorige paragraaf werden reeds enkele cellen gemodelleerd aan de hand van deze notatie: cel G2
(R2K1) aan de hand van een EER diagram, cel M3 (R3K1) aan de hand van een genormaliseerde
data map, cel J5 (R2K4) aan de hand van een organogram, de cellen N4 (R3K2) en P6 (R3K4) aan
de hand van een use case diagram en ten slotte cel Q5 (R3K5) aan de hand van een sequentie
diagram.
Data
(what)
Function
(how)
Network
(where)
People
(who)
Time
(when)
Motivation
(why)
Scope
Business
Model
/ -Activity
diagram
-Petri nets
/ / P.E.R.T
schema
/
System
Model
/ / / / -Petri nets
-Harel state
chart
/
Tabel 7.3: Alternatieve modelleernotaties voor de 2e en 3e rij van het Zachman raamwerk
Ook de business model/functie- cel zou gemodelleerd kunnen worden aan de hand van de UML
notatie. Deze cel werd in paragraaf 7.3. weergegeven aan de hand van een BPMN diagram. Een
alternatief hiervoor zou een UML activity diagram zijn. Hoewel het BPMN diagram en activity
diagram sterk op elkaar gelijken, is de syntax van deze modellen toch licht verschillend.
Verwacht wordt dat BPMN zal uitgroeien tot de internationale standaardtaal voor
procesmodellering en dat ze geïntegreerd zal worden in de Unified Modeling Language.
Nog een andere manier om deze business model/functie- cel voor te stellen is aan de hand van
Petri nets. Deze geven de transitierelaties weer waaruit een bedrijfsproces bestaat. Vergeleken
met het BPMN diagram en het activity diagram is dit echter een veel minder voor de hand
liggende methode. Ze wordt dan ook weinig toegepast in de praktijk.
Voor wat betreft het weergeven van de business cyclussen uit cel K4 (R2K5) kan ook een P.E.R.T
chart gebruikt worden. Deze methode heeft tot doel om de benodigde minimale tijd te
|Hoofdstuk 7
73
berekenen om een project te realiseren. Net zoals in een Gantt chart, wordt de verwachte
tijdsduur berekend aan de hand van de optimistische, normale en pessimistische tijdsduur.
De laatste cel waarvoor ook nog enkele alternatieve artefacten kunnen vermeld worden is cel
Q5 (R3K5). Deze systeem model/tijd- cel werd in paragraaf 7.3. weergegeven aan de hand van
UML sequence diagrams. Het grote probleem van deze diagrammen is dat ze niet expliciet de
duur van iets kunnen uitdrukken (Fatolahi & Shams, 2006).
Daarom zou deze cel ook kunnen weergegeven worden aan de hand van Petri nets of Harel state
charts (Zachman, 2003).
Voor al deze alternatieve modelleernotaties geldt dat ze veel minder worden toegepast in de
praktijk in vergelijking met de modelleernotaties die gespecificeerd werden in tabel 7.2.
|Hoofdstuk 8
74
HOOFDSTUK 8: OVERZICHT VAN DE GAPS IN HET ZACHMAN
RAAMWERK
Het Zachman raamwerk is allesbehalve perfect en heeft zowel op inhoudelijk, als op algemeen vlak
enkele tekortkomingen. Dit hoofdstuk geeft een overzicht van deze gaps.
In de eerste twee paragrafen van dit hoofdstuk wordt ingegaan op twee inhoudelijke gaps van het
raamwerk: de integratie gap en de representatie gap.
De eerste gap, namelijk de integratie gap, werd in hoofdstuk 7 reeds uitvoerig toegelicht. Ze werd
opgelost door het toepassen van de methode van Pereira & Sousa.
Één van de factoren die aan de basis ligt van deze integratie gap, is het tekort aan een algemeen
aanvaarde modelleernotatie voor het representeren van sommige cellen van het raamwerk. Dit
tekort wordt de representatie gap genoemd, en wordt besproken in de tweede paragraaf van dit
hoofdstuk.
Ten slotte wordt in de laatste paragraaf ingegaan op een meer algemene gap van het Zachman
raamwerk. Het raamwerk is louter een stijve bundeling van artefacten en houdt geen rekening met
het feit dat architectuur onderhevig is aan continue verandering. Het raamwerk mist met andere
woorden een architectuurproces dat verandering in de architectuur initieert en de architectuur
implementeert in de organisatie. Gebaseerd op deze proces gap zal in volgend hoofdstuk gezocht
worden naar een manier om het Zachman raamwerk te integreren in een architectuurproces.
8.1. INTEGRATIE GAP
Een belangrijke tekortkoming in het Zachman raamwerk is dat de cellen op geen enkele manier
horizontaal of verticaal geïntegreerd zijn met elkaar. Dit komt ten eerste omdat het raamwerk geen
enkele methode oplegt die de volgorde bepaalt om de cellen van het raamwerk in te vullen. Ten
tweede komt dit omdat er een tekort is aan definiëring van de artefacten voor elke cel. Hierdoor is
het onmogelijk om duidelijke samenhang te bekomen in het raamwerk.
In hoofdstuk 7 werd op deze integratie gap reeds uitgebreid ingegaan. Daar werd deze tekortkoming
opgelost aan de hand van de methode van Pereira & Sousa. Deze methode geeft immers de volgorde
weer waarin de cellen van het raamwerk dienen ingevuld te worden. Op deze manier wordt de
inhoud van de cellen van het raamwerk optimaal op elkaar afgestemd.
|Hoofdstuk 8
75
Aangezien volledige samenhang pas bekomen kan worden indien er artefacten voorhanden zijn voor
elke cel van het raamwerk, werd in hoofdstuk 7 ook op zoek gegaan naar de meest voor de hand
liggende modelleernotaties voor elke cel van het raamwerk. Een overzicht hiervan wordt
weergegeven in tabel 7.2. (cfr. supra, p.71).
8.2. REPRESENTATIE GAP
Een onderdeel van de integratie gap is de representatie gap. De cellen van het raamwerk kunnen
immers pas geïntegreerd worden met elkaar indien er een duidelijke modelleernotatie voorhanden is
voor elke cel van het raamwerk. Dit is echter niet steeds het geval.
Wat opvalt is dat de ontwikkelingsgraad van de modelleernotaties in de laatste drie kolommen van
het Zachman raamwerk veel meer gelimiteerd is dan in de eerste drie kolommen (Zachman, 2003).
Dit is waarschijnlijk te wijten aan het feit dat deze kolommen pas later aan het Zachman raamwerk
werden toegevoegd (Zachman, 1987).
Het gevolg hiervan is dat in de laatste drie kolommen van het raamwerk nog steeds enkele cellen
aanwezig zijn waarvoor nog geen algemene modelleernotatie voorhanden is.
Dit geldt bijvoorbeeld voor de zesde kolom van het raamwerk, beter bekend als de
motivatiedimensie. Aanvankelijk was er zowel voor de tweede als de derde rij van deze
inhoudsdimensie geen algemeen aanvaarde modelleernotatie voorhanden. De Business Rules Group
bracht hier echter verandering in door de introductie van het Business Motivation Model als
modelleernotatie voor cel L4 (R2K6) van het raamwerk (BRG, 2010). Dit betekent dat er enkel nog
onderzoek nodig is naar een algemene modelleernotatie voor het weergeven van de business rules
uit cel R5 (R3K6).
8.3. PROCES GAP
Business en IT zijn onderhevig aan continue verandering. Daarom dient de architectuur van een
onderneming continu aangepast te worden. Enterprise architectuur is met andere woorden een
continu proces dat de architectuur van een onderneming up to date houdt en keer op keer
vertaalt in projecten die kunnen geïmplementeerd worden in de organisatie.
Aangezien het Zachman raamwerk niets anders is dan een stijve bundeling van artefacten, komt
dit raamwerk juist tekort aan zo een methode die zorgt dat de architectuur onderhouden wordt
|Hoofdstuk 8
76
en vervolgens vertaald wordt in projecten die geïmplementeerd kunnen worden in de
organisatie. Idealiter, zou het Zachman raamwerk ingebed moeten worden in een
architectuurproces om te kunnen spreken van een compleet EA raamwerk.
Op deze proces gap zal verder ingegaan worden in volgend hoofdstuk waar er gezocht wordt
naar een manier om het Zachman raamwerk te integreren in een architectuurmethode.
|Hoofdstuk 9
77
HOOFDSTUK 9: INTEGREREN VAN HET ZACHMAN RAAMWERK
EN DE ADM VAN TOGAF
Dit hoofdstuk biedt een antwoord op de proces gap die gedefinieerd werd in hoofdstuk 8.
Aangezien business en IT continu in verandering zijn, is het belangrijk voor een onderneming
om een architectuurproces te hebben dat in staat is haar architectuur up to date te houden en te
vertalen in projecten die kunnen geïmplementeerd worden in de organisatie. Het Zachman
raamwerk classificeert wel architectuurbeschrijvingen, maar houdt op geen enkele manier
rekening met de ontwikkeling en implementatie van architectuur. Uit de literatuurstudie werd
dan ook de conclusie getrokken dat slechts door een combinatie van het Zachman raamwerk en
TOGAF een complete enterprise architectuur kan bekomen worden.
In dit hoofdstuk wordt er op zoek gegaan op welke manier deze twee EA raamwerken
geïntegreerd kunnen worden met elkaar. Het resultaat hiervan is de blended methodology.
In de eerste twee paragrafen wordt beschreven wat het Zachman raamwerk en de ADM van
TOGAF juist mankeren. Op basis hiervan wordt in de laatste paragraaf toegelicht hoe de twee
geïntegreerd kunnen worden met elkaar.
9.1. HET ZACHMAN RAAMWERK
Het Zachman raamwerk is een taxonomie die de huidige staat van de onderneming weergeeft.
Het bestaat meer bepaald uit architecturale artefacten die de onderneming beschrijven.
Waar het raamwerk echter geen rekening mee houdt, is het feit dat de architectuur van een
onderneming onderhevig is aan continue verandering. Verder zegt het raamwerk ook niets over
hoe de architectuur juist kan geïmplementeerd worden in een onderneming.
9.2. DE ADM VAN TOGAF
De architecture development method van TOGAF is een architectuurmethode die in staat voor het
managen van de architectuur van een onderneming en die zorgt voor de implementatie van de
architectuur.
Wat de ADM mist is een structuur om de architecturale artefacten van elke iteratie schematisch
in weer te geven.
|Hoofdstuk 9
78
9.3. COMPLEMENTARITEIT VAN ZACHMAN EN DE ADM VAN TOGAF
9.3.1 ALGEMEEN
Uit de vorige twee paragrafen kan besloten worden dat het Zachman raamwerk en de ADM van
TOGAF perfect complementair zijn: terwijl de ene nood heeft aan een architectuurmethode,
heeft de andere nood aan een classificatieschema voor het weergeven van de
architectuurartefacten. Dé grote vraag blijft echter op wélke manier het Zachman raamwerk en
de ADM geïmplementeerd kunnen worden met elkaar.
De functie van het Zachman raamwerk is duidelijk: het is louter een taxonomie die de huidige
staat van de architectuur van de onderneming weergeeft.
De ADM van TOGAF bestaat in totaal uit acht fasen. Enkel de eerste vier fasen van de methode
zijn verantwoordelijk voor het opstellen van de eigenlijke architectuur van de onderneming. Het
is juist de output van deze fasen die gestructureerd dient weergegeven te worden in een
classificatieschema zoals het Zachman raamwerk.
Nadat de architectuur van de onderneming is opgesteld, volgen in de ADM een aantal fasen die
de implementatie van de architectuur optimaal begeleiden.
Elke iteratie van de ADM wordt geïnitieerd door een verandering in de onderneming zelf of in de
omgeving van de onderneming die de behoefte creëert om de architectuur van de onderneming
aan te passen. Voor elke iteratie van de ADM geldt dat de architectuur kan voorgesteld worden
aan de hand van een classificatieschema zoals het Zachman raamwerk.
Op de vraag, hoe het Zachman raamwerk en de ADM met elkaar geïmplementeerd kunnen
worden, kan dus als volgt geantwoord worden:
De ADM van TOGAF biedt de methode voor het onderhouden en het implementeren van de
architectuur van de onderneming, terwijl het Zachman raamwerk de architecturale
representaties vastlegt voor elke iteratie van de ADM.
Of korter verwoord:
Zachman brengt elke iteratie van de ADM in kaart (Graves, 2007).
|Hoofdstuk 9
79
9.3.2 FASEN
De output van enkele fasen van de ADM kan weergegeven worden in een bepaald deel van het
Zachman raamwerk. Hieronder wordt voor elke fase gespecificeerd wat de output is en op welke
plaats in het Zachman raamwerk (welke rij(en)) deze output kan weergegeven worden (zie
figuur 9.1). Onder output worden architecturale artefacten verstaan.
Figuur 9.1: Relatie tussen de ADM en het Zachman Raamwerk
Preliminary phase
In deze fase worden de architectuurprincipes uiteengezet. Dit zijn een soort uitspraken die
richting geven aan de ontwikkeling van de architectuur. Aangezien architectuurprincipes
doorgaans niet weergegeven worden in het Zachman raamwerk, dient een nieuwe rij
toegevoegd te worden aan het raamwerk. De rij voor architectuurprincipes (rij 0) is
zichtbaar in figuur 9.1.
Architecture vision phase
In deze fase wordt het bereik bepaald waarover de architectuur dient beschreven te worden.
Dit wordt weergegeven aan de hand van de artefacten uit de eerste rij van het Zachman
raamwerk (de scope rij).
Business/Information Systems/ Technology architecture phase
In deze fasen worden respectievelijk de business, informatiesysteem- en technologie
architectuur van de onderneming opgesteld. Deze business/IS/technologie architectuur kan
weergegeven worden aan de hand van enkele architecturale artefacten in rij twee tot vier
van het Zachman raamwerk.
|Hoofdstuk 9
80
De output van bovenstaande fasen kan aldus weergegeven worden in de eerste vijf rijen van het
Zachman raamwerk (rij 0 tot rij 4). Voor elke iteratie van de ADM is deze output verschillend,
wat betekent dat voor elke iteratie een ander Zachman raamwerk kan opgesteld worden.
Elk van bovenstaande fasen van de ADM heeft enkele architecturale artefacten als output.
Mogelijke artefacten voor het weergeven van deze fasen worden gedefinieerd in het content
framework. De methode legt de gebruiker echter niet op tot het gebruik van deze artefacten.
Daarom kan de output voor elke fase ook weergegeven worden aan de hand van andere
artefacten. Zo kan er voor de eerste vier fasen van de ADM gebruik gemaakt worden van de set
artefacten die in tabel 7.2. gedefinieerd werd voor het opstellen van het Zachman raamwerk:
- De artefacten van de eerste rij van het raamwerk beschrijven het bereik uit fase A.
- De business model artefacten van de tweede rij beschrijven de business architectuur uit
fase B.
- De systeem model artefacten van de derde rij beschrijven de informatiesysteem
architectuur uit fase C.
- De technologie model artefacten van de vierde rij beschrijven de technologie
architectuur uit fase D.
Om er voor te zorgen dat deze artefacten ook nog eens allemaal op elkaar zijn afgestemd kunnen
de artefacten opgesteld worden volgens de methode van Pereira & Sousa (cfr. supra). Met
andere woorden: het bepalen van de fasen A tot D in de ADM is eigenlijk niets anders dan het
toepassen en uitwerken van de methode van Pereira & Sousa!1
1 Onder de assumptie dat de technologie architectuur geoutsourced wordt.
|Hoofdstuk 9
81
Figuur 9.2: De ADM en de methode van Pereira & Sousa
Deze methode werd uitgebreid toegelicht in paragraaf 7.3. (cfr. supra). Zoals zichtbaar in figuur
9.2 komt fase A overeen met de eerste stap van de methode van Pereira & Sousa en komen fasen
B en D overeen met de tweede tot zesde stap van de methode1.
Nadat de architectuur van de onderneming is opgesteld volgens de methode van Pereira &
Sousa, kan begonnen worden met de vertaling van deze architectuur naar een verzameling
projecten die kunnen geïmplementeerd worden in de organisatie.
Opportunities & solutions phase
Deze fase vertaalt de architectuur naar een verzameling projecten. Uit deze verzameling
worden de beste projecten geselecteerd die zullen bijdragen tot het bereiken van de
doelstaat van de onderneming.
Migration planning phase
In deze fase worden de projecten uit de vorige fase gerangschikt volgens prioriteit.
Implementation governance phase
In deze fase wordt de architectuur vertaald naar richtlijnen voor projecten en worden de
projecten begeleid.
1 Onder de assumptie dat de technologie architectuur geoutsourced wordt.
|Hoofdstuk 9
82
Architecture change management phase
In deze fase worden de omstandigheden gedefinieerd, waaronder de enterprise architectuur
(of een deel ervan) dient veranderd te worden na implementatie. Met andere woorden:
onder welke omstandigheden moet een nieuwe iteratie doorlopen worden?
|Hoofdstuk 10
83
HOOFDSTUK 10: HET OVERKOEPELEND RAAMWERK UITGEWERKT
In het vorige hoofdstuk werd gedefinieerd hoe de ADM van TOGAF en het Zachman raamwerk
met elkaar geïntegreerd kunnen worden.
Om dit verband tussen Zachman en de ADM van TOGAF aan te tonen, wordt in dit hoofdstuk een
vereenvoudigd voorbeeld gegeven voor de onderneming KwaliCar. Er wordt vanuit gegaan dat
dit de eerste iteratie is in het EA proces van KwaliCar.
Elke iteratie van de ADM wordt door het Zachman raamwerk in kaart gebracht. Daarom zal in
onderstaande paragrafen voor elke fase (van de ADM) toegelicht worden welke rij van het
Zachman raamwerk de output van die fase weergeeft. Voor de specifieke output van de eerste
vier fasen van de iteratie, wordt verwezen naar hoofdstuk 7 van deze gevallenstudie waar de
architecturale artefacten van het Zachman raamwerk in detail werden uitgewerkt.
Er dient opgemerkt te worden dat de fasen van elke iteratie niet in sequentiële volgorde worden
opgelost, maar wel in iteratieve volgorde. Dit betekent dat de fasen elkaar overlappen.
10.1. PRELIMINARY FASE
Architectuurprincipes zijn een soort uitspraken die richting geven aan de ontwikkeling van de
architectuur. Architectuurmodellen, die in de volgende fasen van de ADM opgesteld zullen
worden, geven invulling aan deze architectuurprincipes. Voor alle vier de architectuurdomeinen
(business, organisatie, informatie en techniek) dienen architectuurprincipes opgesteld te
worden (Dietz, Go & Lee, 2007). Deze worden weergegeven in rij 0 van het Zachman raamwerk.
Figuur 10.1: Architectuurprincipes: rij 0
|Hoofdstuk 10
84
Hieronder worden enkele voorbeelden van business principes voor de onderneming KwaliCar
weergegeven. Wat in het cursief staat is een meer gedetailleerde omschrijving van het business
principe.
-Reparatie moet zo kwalitatief mogelijk uitgevoerd worden.
Door enkel de meest competente mensen voor reparatie aan te nemen in de onderneming (mensen
met >1 jaar werkervaring in de sector)
-Het financieel model moet gebaseerd zijn op de ‘lifetime value’ van de klant.
Hoe meer reparaties de klant reeds liet uitvoeren, hoe meer korting hij krijgt.
10.2. ARCHITECTURE VISION FASE
Elke iteratie start met het bepalen van het bereik waarover de architectuur beschreven dient te
worden. Typisch gezien is het bereik van de eerste iteratie vrij algemeen. Hoe meer iteraties
reeds doorlopen zijn, hoe specifieker het bereik waarover de architectuur bepaald wordt.
Figuur 10.2: Het bereik van de architectuuromschrijvingen: rij 1
Het bereik van deze iteratie is op niveau van de volledige organisatie KwaliCar. Het bereik kan
beschreven worden aan de hand van de artefacten uit de eerste rij van het Zachman raamwerk.
Deze werden bepaald in de eerste stap van de methode van Pereira & Sousa (cfr. supra 7.3.1).
10.3. BUSINESS/ IS / TECHNOLOGY ARCHITECTURE FASE
De fasen B tot D van de architectuurmethode stellen de business, informatiesysteem- en
technologie architectuur op van de onderneming.
De business, informatiesysteem- en technologie architectuur van een organisatie kan
weergegeven worden aan de hand van de architecturale artefacten uit rij twee tot vier van het
|Hoofdstuk 10
85
Zachman raamwerk (cfr. supra tabel 7.2). Om samenhang tussen deze artefacten te verzekeren,
dienen ze opgesteld te worden in de volgorde bepaald door de methode van Pereira & Sousa.
De output van de fasen B tot D is met andere woorden niets anders dan stap 2 tot 6 van de
methode van Pereira & Sousa die in hoofdstuk 7 uiteengezet werd (cfr. supra 7.3.2 tot 7.3.6)1.
Figuur 10.3: Business/IS/Technologie architectuur: rij 2 tot 4
De methode van Pereira & Sousa bevestigt overigens het iteratief karakter van de fasen B tot D
van de ADM. Het is immers niet zo dat deze methode eerst de business architectuur en daarna
pas de systeem architectuur opstelt, maar wel dat de business en systeem architectuur in een
bepaalde, afwisselende volgorde opgesteld worden.
10.4. OPPORTUNITIES & SOLUTIONS FASE
Deze fase vertaalt de architectuur van KwaliCar (die opgesteld werd in de fasen B tot D) naar
een verzameling projecten. Uit deze verzameling worden de beste projecten geselecteerd die
geïmplementeerd zullen worden in de organisatie en aldus zullen bijdragen tot het bereiken van
de doelstaat van de onderneming.
Mogelijke projecten die binnen KwaliCar kunnen geïmplementeerd worden, kunnen afgeleid
worden uit het business motivation model (cfr. supra 2.3.4). In dit model wordt immers nagegaan
welke means kunnen ondernomen worden voor het bereiken van de ends van de onderneming.
Means zijn dan niets anders dan projecten voor het bereiken van de doelstaat (=ends) van de
onderneming.
Uit het BMM kan volgende lijst van mogelijke projecten afgeleid worden voor de onderneming
KwaliCar:
1 Ook hier weer onder de assumptie dat de technologie architectuur geoutsourced wordt.
|Hoofdstuk 10
86
-Implementeren van CRM technieken
-Implementeren van six sigma training
-Uitwerken van een marketingstrategie
-Het toepassen van een SWOT analyse
-Implementeren van een intern computerprogramma dat zowel door arbeiders als bedienden
kan gebruikt worden
-Halfjaarlijkse controle van de machines door expert
-Beroep doen op rekruteringsbureau
Uit deze lijst koos KwaliCar het project dat volgens hen de hoogste prioriteit heeft, namelijk: het
implementeren van een intern computerprogramma dat zowel door arbeiders als bedienden kan
gebruikt worden. Voor het ontwikkelen van dit intern computersysteem besloot KwaliCar
beroep te doen op een software leverancier.
Hij is degene die verantwoordelijk wordt gesteld voor het opstellen van de gedetailleerde
representaties van de onderdelen van het intern computerprogramma. Dit wordt weergegeven
in rij vijf van het Zachman raamwerk.
Figuur 10.4: Gedetailleerde representaties: rij 5
10.5. MIGRATION PLANNING FASE
In deze fase worden de geselecteerde projecten uit de opportunities & solutions fase gerangschikt
volgens prioriteit.
Aangezien KwaliCar slechts één project uitkoos om te implementeren, kan de migration planning
fase in dit voorbeeld overgeslagen worden.
|Hoofdstuk 10
87
10.6. IMPLEMENTATION GOVERNANCE
Voor het implementeren van het intern informatiesysteem wordt beroep gedaan op een
software leverancier. Hij wordt verantwoordelijk gesteld voor het uitwerken van de
gedetailleerde representaties van het systeem (rij 5 van het Zachman raamwerk), evenals de
uiteindelijke implementatie van het systeem in de organisatie.
10.7. ARCHITECTURE CHANGE MANAGEMENT
In deze fase stellen de enterprise architecten enkele voorwaarden op waaronder de architectuur
van de onderneming verandert dient te worden. Een nieuwe iteratie dient doorlopen te worden
indien er zich omstandigheden voordoen die voldoen aan deze voorwaarden.
10.8. VOLGENDE ITERATIES
In elk van de volgende iteraties zal de architectuur van KwaliCar geüpdatet worden en meer
verfijnd worden uitgewerkt.
88
DEEL III: ALGEMEEN BESLUIT
Conclusies
In deze masterproef werden enkele belangrijke enterprise architectuur raamwerken vergeleken.
Voor elk van deze EA raamwerken werd nagegaan in welke mate ze voldoen aan de definitie van
een ‘compleet’ EA raamwerk.
De twee belangrijkste componenten waaruit een ‘compleet’ EA raamwerk bestaat zijn een
taxonomie en een methodologie. Een taxonomie geeft de architectuurbeschrijvingen van een
onderneming weer op een gestructureerde manier. Een methodologie daarentegen is een
methode voor het opstellen van de architectuur, voor het up-to-date houden van de architectuur
en voor het implementeren van de architectuur in de dagelijkse operaties van de onderneming.
Idealiter bestaat een EA raamwerk uit een koppeling van deze twee componenten. Dit kan
voorgesteld worden in het Amsterdam Information Management Model (AIM) van Rik Maes (zie
figuur 11.1), waarin het concept EA gesitueerd is rondom de tweede rij van het model.
Figuur 11.1: EA methodologie en taxonomie in het AIM
Uit de vergelijkende studie kon opgemaakt worden dat geen enkel van de besproken EA
raamwerken voldoet aan de definitie van een compleet EA raamwerk, met uitzondering van het
Federal Enterprise Architecture Framework. Dit raamwerk is echter voornamelijk toegespitst op
overheidsinstellingen. Daarom zou het interessant zijn mocht er ook zo een optimaal EA
89
raamwerk kunnen gecreëerd worden voor bedrijven in het algemeen. Hiertoe zouden twee van
de meest bekende EA raamwerken gecombineerd kunnen worden: het Zachman raamwerk en
The Open Group Architecture Framework (TOGAF).
Om na te gaan op welke wijze deze twee EA raamwerken kunnen gecombineerd worden met
elkaar, werd in de gevallenstudie een praktisch voorbeeld uitgewerkt.
Het Zachman raamwerk is uniek omdat geen enkel ander EA raamwerk
architectuurbeschrijvingen opstelt vanuit zoveel verschillende stakeholdersperspectieven en ze
op hun beurt dan ook nog eens kan voorstellen in een overzichtelijk classificatieschema.
TOGAF’s sterkte ligt niet in haar architectuurbeschrijvingen, maar wel in de stap voor stap
methode voor het opstellen en implementeren van EA. Door van deze twee EA raamwerken een
blended methodology te maken, kunnen de sterktes van beide EA raamwerken gecombineerd
worden.
Het Zachman raamwerk kan geïntegreerd worden in de architectuurmethode van TOGAF.
In het overkoepelend raamwerk dat door deze integratie tot stand komt, zorgt het Zachman
raamwerk voor een duidelijke definitie van de architecturale artefacten die moeten
voortgebracht worden. Elk artefact is hierbij gericht op een bepaalde doelgroep en een bepaalde
doelstelling en wordt weergegeven in een bepaalde cel van het Zachman raamwerk. Door de
architecturale artefacten in het Zachman raamwerk op te stellen aan de hand van de volgorde,
bepaald door de methode van Pereira & Sousa (2004), worden de relaties tussen de
verschillende artefacten duidelijk. Op deze manier ontstaat een samenhangende
architectuurbeschrijving van de onderneming. Om het Zachman raamwerk te vervolledigen,
dient het idealiter uitgebreid te worden met een additionele rij die de architectuurprincipes
weergeeft.
De architectuurbeschrijvingen uit het Zachman raamwerk zijn echter op zich niet voldoende om
te kunnen spreken van een ‘complete’ enterprise architectuur. De ADM van TOGAF gaat er van
uit dat een onderneming slechts voordeel kan halen uit enterprise architectuur indien de
architectuurbeschrijvingen vertaald worden naar projecten die daadwerkelijk geïmplementeerd
kunnen worden in de organisatie. Hoe deze implementatie juist in zijn werk gaat wordt
gespecificeerd in een aantal fasen van de ADM van TOGAF. Verder houdt TOGAF ook rekening
met het feit dat architectuur onderhevig is aan continue verandering. Daarom dient de
architectuur van een onderneming regelmatig geüpdatet te worden.
90
De ADM van TOGAF is met andere woorden een nooit stoppend proces waarbij telkens opnieuw
een iteratie doorlopen wordt. Elke iteratie bestaat uit een aantal stappen waarin de
architectuurbeschrijving van de onderneming opgesteld of geüpdatet wordt en daarna
geïmplementeerd wordt in de onderneming. Voor elke iteratie wordt de
architectuurbeschrijving weergegeven in het Zachman raamwerk.
Er dient opgemerkt te worden dat zowel het opstellen of updaten van de architectuur, als het
implementeren van de architectuur, heel wat tijd in beslag neemt.
Beperkingen en aanbevelingen voor toekomstig onderzoek
Uit deze masterproef kunnen enkele belangrijke beperkingen geconcludeerd worden. Tevens
kunnen enkele aanbevelingen gedaan worden naar toekomstig onderzoek.
Een eerste beperking heeft betrekking op het Zachman raamwerk. Dit raamwerk staat bekend
omwille van zijn rijke set van architectuurbeschrijvingen. Hoewel dit een voordeel is, speelt het
eveneens in het nadeel van het raamwerk: het opstellen van alle cellen van het raamwerk is
immers een hele karwei die veel tijd in beslag neemt. Hoewel het raamwerk in staat is een heel
complete architectuurbeschrijving weer te geven, blijft het een vrij bombastisch EA raamwerk.
Een andere beperking van het Zachman raamwerk is dat de algemeen aanvaarde
modelleernotatie niet voor alle cellen even duidelijk is. Daarom dient in verder onderzoek voor
sommige cellen van het raamwerk gezocht te worden naar een algemeen aanvaarde
modelleernotatie.
In deze gevallenstudie werd enkel ingegaan op het Zachman raamwerk en TOGAF als blended
methodology. Het zou interessant zijn om in toekomstig onderzoek na te gaan of er eventueel
nog andere EA raamwerken zijn die ook gecombineerd kunnen worden ten einde een compleet
EA raamwerk te bekomen. Indien dit het geval is, kunnen de verschillende blended
methodologies vergeleken worden en kunnen voor- en nadelen bepaald worden van elk.
X
LIJST VAN DE GERAADPLEEGDE WERKEN
Wetenschappelijke artikels
Abdallah, S. and G. H. Galal-Edeen (2006). Towards a framework for enterprise architecture
frameworks comparison and selection. Proceedings of the Fourth International Conference on
Informatics and Systems.
Bahill, A. T., R. Botta, et al. (2006). The Zachman framework populated with baseball models.
Journal of enterprise architecture 2(4): 50-68.
Bender, G. (2009). Designing a Stakeholder-Specific Enterprise Architecture Management based
on Patterns. Master’s thesis, Technische Universität Munchen. Munich, Germany.
Dietz, J. L. G., A. Go, et al. (2007). Enterprise Architecture in de praktijk. Via Nova Architectura: 1-
9.
Erder, M. and P. Pureur (2006). Transitional architectures for enterprise evolution. It
Professional 8(3): 10-17.
Fatolahi, A. and F. Shams (2006). An investigation into applying UML to the Zachman framework.
Information Systems Frontiers 8(2): 133-143.
Gokhale, A. (2010). Increasing Effectiveness Of The Zachman Framework Using The Balanced
Scorecard. Master’s thesis, Purdue University. Indiana ( the U.S.).
Greefhorst, D. (2009). Een volgende stap in de ontwikkeling van architectuur. Via Nova
Architectura: 1-11.
Greefhorst, D., H. Koning, et al. (2003). De dimensies in architectuur-beschrijvingen. Informatie
45(11): 22-27.
XI
Hoogervorst, J. A. P. (2004). Strategie: enterprise engineering en architectuur: een antwoord op
falende strategie-implementaties. Belgium management review 98: 20-31.
Janssen, J. (2005). Digitale Architectuur: Selectiemodel Enterprise Architectuur Raamwerken.
Master’s thesis, Radboud Universiteit Nijmegen. Nijmegen, Nederland.
Jovanovic, V., S. Mrdalj, et al. (2006). A Zachman Cube. Issues in Information Systems 7(2): 1-6.
Leist, S. and G. Zellner (2006). Evaluation of current architecture frameworks. Proceedings of the
2006 ACM symposium on Applied computing ACM, Dijon: 1546-1553.
McCarthy, R. V. (2006). Toward a unified enterprise architecture framework: An analytical
evaluation. Issues in Information Systems 7(2): 14-17.
Oene, L. (2009). Zaakgericht werken-Een architectuurbeschrijving met behulp van bedrijfsregels
in ADL (A Description Language). Master’s thesis, Open Universiteit Nederland. Heerlen,
Nederland.
Ostadzadeh, S., F. Aliee, et al. (2007). A method for consistent modeling of Zachman Framework
cells. Advances and Innovations in Systems, Computing Sciences and Software Engineering: 375-
380.
Panetto, H., S. Baïna, et al. (2007). Mapping the IEC 62264 models onto the Zachman framework
for analysing products information traceability: a case study. Journal of Intelligent Manufacturing
18(6): 679-698.
Pereira, C. M. and P. Sousa (2004). A method to define an Enterprise Architecture using the
Zachman Framework, ACM. Proceedings of the Symposium on Applied Computing (SAC), Nicosia,
Cyprus: 1366-1371.
XII
Radwan, A. and M. Aarabi (2011). Study of Implementing Zachman Framework for Modeling
Information Systems for Manufacturing Enterprises Aggregate Planning. Simulation 16: 18.
Sessions, R. (2007). A comparison of the top four enterprise-architecture methodologies. Journal
available on www.objectwatch.com/white_papers.htm 466232(May): 1-28.
Shah, H. and M. E. Kourdi (2007). Frameworks for enterprise architecture. It Professional 9(5):
36-41.
Toet, R. (2007). Een referentiearchitectuur voor de waterschappen: de realisatie en de invloed
van een integraal model. Proefschrift doctoraat, Universiteit van Amsterdam. Amsterdam,
Nederland.
Urbaczewski, L. and S. Mrdalj (2006). A comparison of enterprise architecture frameworks.
Issues in Information Systems 7(2): 18-23.
Wu, H. Y. (2011). Constructing a strategy map for banking institutions with key performance
indicators of the balanced scorecard. Evaluation and Program Planning 35(3): 303-320.
Ylimäki, T. and V. Halttunen (2006). Method engineering in practice: A case of applying the
Zachman framework in the context of small enterprise architecture oriented projects.
Information, Knowledge, Systems Management 5(3): 189-209.
Yu, E., M. Strohmaier, et al. (2006). Exploring intentional modeling and analysis for enterprise
architecture. In Proc. EDOC 2006 Conference Workshop on Trends in Enterprise Architecture
Research (TEAR 2006). IEEE Computer Society.
Zachman, J. A. (1987). A framework for information systems architecture. IBM systems journal
26(3): 276-292.
XIII
Zarvic, N. and R. Wieringa (2006). An integrated enterprise architecture framework for
business-IT alignment. Proceedings of Workshop of Business/IT Alignment and Interoperability
(BUSITAL’06) at CAiSE’06.: 262—270.
Boeken
Lankhorst, M. (2009). Enterprise architecture at work: Modelling, communication and analysis.
Springer-Verlag New York Inc.
Schekkerman, J. (2004). How to survive in the jungle of enterprise architecture frameworks:
Creating or choosing an enterprise architecture framework. Trafford.
Van Sante, T., H. Van Den Bent, et al. (2007). Togaf the Open Group Architectural Framework: A
Management Guide. Van Haren Pub.
Wout, J., M. Waage, et al. (2010). The integrated architecture framework explained: why, what,
how. Springer Verlag.
Internetbronnen
Graves, T. (2007). Integrating Zachman and TOGAF-ADM. (Tetradian Consulting). URL: <
http://www.slideshare.net/tetradian/integrating-zachman-and-togafadm>. (20/02/2012).
Hay, D. C. (2000). A Different Kind of Life Cycle: The Zachman Framework. Essential Strategies
Inc. URL: < www. essentialstrategies. com/documents/zachman20 00. pdf>. (10/11/2011)
Loche, S. (2007). The Zachman Enterprise Framework. URL: < http://www.technical-
communicators.com/articles/zachman_framework.pdf>. (10/11/2011)
Mulholland, A. and A. L. Macaulay (2006) Architecture and the Integrated Architecture
Framework. URL:
XIV
<http://www.au.capgemini.com/resources/solution_material/architecture_and_the_integrated_
architecture_framework/?d=1>. (22/12/2011).
Polgreen, J. (2010). Using TOGAF to develop and implement enterprise architecture in
government – U.S. Federal agencies as example. URL : < http://www.architecting-the-
enterprise.com/enterprise_architecture/articles/using_togaf_to_develop_and_implement_enterp
rise_architecture_in_government_-_u.s._federal_agencies_as_example.php>. (18/10/11).
Sayles, A. (2003). Development of Federal Enterprise Architecture Framework using the IBM
Rational Unified Process and the Unified Modeling Language. URL: <
http://www.ibm.com/developerworks/rational/library/content/03July/2500/2787/2787_arc
h_framework.pdf>. (18/02/2012) .
Schekkerman, J. (2005). Trends in Enterprise Architecture. Trends in Enterprise Architecture
2005: How are organizations progressing? Web-based survey, Institute for Enterprise Architecture
Developments. URL: < http://www.enterprise-
architecture.info/Images/EA%20Survey/Enterprise%20Architecture%20Survey%202005%20I
FEAD%20v10.pdf> . (18/02/2012).
The Business Rules Group (2010). The Business Motivation Model: Business Governance in a
Volatile World. URL: <http://www.businessrulesgroup.org/second_paper/BRG-BMM.pdf>.
(10/04/2012).
Van Dullemen et al. (2008). Enterprise Architectuur: Een managementinstrument voor business
transformatie. URL:
<http://www.be.atosconsulting.com/NR/rdonlyres/0E873E92-47C0-49EC-882F-
4F384B6A6939/0/AtosConsulting_Whitepaper_Enterprise_Architecture_nl.pdf>. (11/10/2011).
Zachman, J. A. (2003). The Framework for Enterprise Architecture Cell Definitions. URL:
<https://apps.adcom.uci.edu/EnterpriseArch/Zachman/ZIFA03.pdf>. (08/11/2011).
XV
Zachman, J. A. (2003). The Zachman Framework: A Primer For Enterprise Architecture: Primer
for Enterprise Engineering and Manufacturing. URL:
<http://www.businessrulesgroup.org/BRWG_RFI/ZachmanBookRFIextract.pdf>. (03/10/11).
Zachman, J. A. (2009). Zachman on the Framework. URL:
<http://xpertaml.com/backup/ABS%20Development%20(Martin)/Methodologies/ZIFA/ZIFA0
9.pdf>. (03/10/2011).
XVI
BIJLAGEN
BIJLAGE 1: TOGAF CONTENT FRAMEWORK
XVII
BIJLAGE 2: TOGAF CONTENT METAMODEL
XVIII
BIJLAGE 3: DE BALANCED SCORE CARD VAN KWALICAR
Missie: Wij wensen onze klanten een excellente service te verlenen in de reparatie of
het onderhoud van personenwagens. Om dit te garanderen, nemen wij enkel de meest
gekwalificeerde werknemers in dienst. Verder zijn de onderdelen, nodig voor reparatie,
enkel afkomstig van topleveranciers, waardoor een superieure kwaliteit verzekerd
wordt.
Visie: Bekend staan als de beste garage in de regio Gent wat betreft kwaliteit en service
voor de reparatie en het onderhoud van personenwagens.
Strategie:
S1- Nummer 1 klantvoorkeur zijn
S2- Focus op kwaliteit
S3- Winstgevendheid verhogen
S4- Het verbeteren van de informatie uitwisseling tussen bedienden en arbeiders
S5- Mee zijn met de nieuwste technologieën en technieken
S6- Rekruteer gekwalificeerd personeel
XIX
Doelstellingen: De onderneming dient doelstellingen te formuleren die bijdragen tot
het behalen van de hierboven gedefinieerde strategieën.
Strategie Doelstelling S1 Nummer 1 klantvoorkeur zijn S1 – D1 Verbeteren van de relatie met de
klanten S2 Focus op kwaliteit S2 – D1 Ontwikkelen van toepassingen
die de kwaliteit verbeteren S3 Winstgevendheid verhogen S3 – D1 Verhogen van inkomsten S3 – D2 Vastleggen van de USP (=unique
selling proposition) S4 Het verbeteren van de informatie
uitwisseling tussen arbeiders en bedienden
S4 – D1 Ontwikkeling van informatiesystemen –en infrastructuur voor de interne informatie uitwisseling
S5 Mee zijn met de nieuwste technieken en technologieën
S5 – D1 Oudere technologieën vervangen door nieuwe indien nodig
S6 Rekruteer gekwalificeerd personeel
S6-D1
Verbeteren van de selectie procedure
Maatstaven: Om te kunnen nagaan of je doelstellingen bereikt worden, dienen er
maatstaven gedefinieerd te worden.
Doelstelling Maatstaaf S1 – D1 Verbeteren van de relatie met de
klanten S1-D1-M1 % klanttevredenheid
S1-D1-M2 % klantmoeilijkheden
S2 – D1 Ontwikkeling van toepassingen die de kwaliteit verbeteren
S2-D2-M1 % klanttevredenheid
S3 – D1 Verhogen van inkomsten S3-D1-M1 Rentabiliteitsratio’s
S3 – D2 Vastleggen van de USP S3-D2-M1 #strengths/#weaknesses
S4 – D1 Ontwikkeling van informatiesystemen –en infrastructuur voor de interne informatie uitwisseling
S4-D1-M1 Processing time
S5 – D1 Oudere technologieën vervangen door nieuwe indien nodig
S5-D1-M1 Processing time
S6- D1 Verbeteren van de selectieprocedure
S6-D1-M1 % klanttevredenheid
XX
Doelwaarden: De maatstaven moeten een bepaalde doelwaarde hebben, om te kunnen
nagaan of de doelstellingen al dan niet bereikt worden.
Doelstelling Maatstaaf Doelwaarde S1 – D1 Verbeteren van de
relatie met de klanten
S1-D1-M1-T1 % klanttevredenheid >85%
S1-D1-M2-T1 % klantmoeilijkheden <10%
S2 – D1 Ontwikkeling van toepassingen die de kwaliteit verbeteren
S2-D2-M1-T1 % klanttevredenheid >85%
S3 – D1 Verhogen van inkomsten
S3-D1-M1-T1 Rentabiliteitsratio’s: rentabiliteit van het eigen vermogen
+3%
S3 – D2 Vastleggen van de USP
S3-D2-M1-T1 #strengths/#weaknesses >1
S4 – D1 Ontwikkeling van informatiesystemen –en infrastructuur voor de interne informatie uitwisseling
S4-D1-M1-T1 Processing time Verminderd met 10%
S5 – D1 Oudere technologieën vervangen door nieuwe indien nodig
S5-D1-M1-T1 Processing time Verminderd met 10%
S6-D1 Verbeteren van de selectieprocedure
S6-D1-M1-T1 % klanttevredenheid >85%
Initiatieven: Het laagste niveau van de BSC zijn de initiatieven die genomen kunnen
worden om de hogere niveaus (doelstellingen, strategieën,…) te bereiken.
Strategie Doelstel
ling Initiatief
Nummer 1 klantvoorkeur zijn
S1 – D1 Verbeteren van de relatie met de klanten
S1-D1-M1-T1-I1 S1-D1-M2-T1-I1
Implementeren van CRM technieken
Focus op kwaliteit
S2 – D1 Ontwikkeling van toepassingen die de kwaliteit verbeteren
S2-D1-M1-T1-I1
Het implementeren van six sigma training
Winstgevendheid verhogen
S3 – D1 Verhogen van inkomsten S3-D1-M1-T1-I1
Uitwerken van een marketingstrategie
S3 – D2 Vastleggen van de USP S3-D2-M1-T1-I1
Het toepassen van een SWOT analyse
XXI
Het verbeteren van de informatie uitwisseling tussen arbeiders en bedienden
S4 – D1 Ontwikkeling van informatiesystemen –en infrastructuur voor de interne informatie uitwisseling
S4-D1-M1-T1-I1
Implementeren van een intern computerprogramma dat zowel door arbeiders als bedienden kan gebruikt worden.
Mee zijn met de nieuwste technieken en technologieën
S5 – D1 Oudere technologieën vervangen door nieuwe indien nodig
S5-D1-M1-T1-I1
Halfjaarlijkse controle van de machines door expert
Rekruteer gekwalificeerd personeel
S6-D1
Verbeteren van de selectieprocedure
S6-D1-M1-T1-I1
Beroep doen op een rekruteringsbureau
Conclusie:
De output van de BSC is de input voor de artefacten in de motivatiekolom van het
Zachman raamwerk (Gokhale, 2010).
Door het trapsgewijs opstellen van de visie, missie, strategie, doelstellingen, doelen,
maatstaven en initiatieven, wordt de verticale integratie van de cellen in de motivatiekolom
gegarandeerd. Op basis hiervan kunnen modellen voor elke cel opgesteld worden.
XXII
BIJLAGE 4: BUSINESS MOTIVATION MODEL