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.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


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.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


IV


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.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 applicatiearchitectuur

beschreven. Ook hier is de output een verzameling bouwblokken en views.

D. Technology architecture – In deze fase worden de data– en applicatiearchitectuur 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.


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.


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)


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.


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.


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)


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.


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


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)


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.


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).


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/motivatiecel 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).

http://www.au.capgemini.com/resources/solution_material/architecture_and_the_integrated_architecture_framework/?d=1%3e

http://www.au.capgemini.com/resources/solution_material/architecture_and_the_integrated_architecture_framework/?d=1%3e

http://www.architecting-the-enterprise.com/enterprise_architecture/articles/using_togaf_to_develop_and_implement_enterprise_architecture_in_government_-_u.s._federal_agencies_as_example.php%3e



http://www.ibm.com/developerworks/rational/library/content/03July/2500/2787/2787_arch_framework.pdf%3e

http://www.ibm.com/developerworks/rational/library/content/03July/2500/2787/2787_arch_framework.pdf%3e

http://www.businessrulesgroup.org/second_paper/BRG-BMM.pdf

http://www.be.atosconsulting.com/NR/rdonlyres/0E873E92-47C0-49EC-882F-4F384B6A6939/0/AtosConsulting_Whitepaper_Enterprise_Architecture_nl.pdf

http://www.be.atosconsulting.com/NR/rdonlyres/0E873E92-47C0-49EC-882F-4F384B6A6939/0/AtosConsulting_Whitepaper_Enterprise_Architecture_nl.pdf

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).

http://www.businessrulesgroup.org/BRWG_RFI/ZachmanBookRFIextract.pdf%3e

http://xpertaml.com/backup/ABS%20Development%20(Martin)/Methodologies/ZIFA/ZIFA09.pdf%3e



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-M1 Processing time


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%



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-M1-T1 Processing time Verminderd met 10%


S5-D1-M1-T1 Processing time Verminderd met 10%

S6-D1 Verbeteren van de selectieprocedure


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-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-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-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

Literatuurstudie naar de bekendste raamwerken voor...

Documents

Transcript of Literatuurstudie naar de bekendste raamwerken voor...