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
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.
I
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 II
3.3.2. Voordelen en nadelen .............................................................................................................................. 24 3.4. Federal Enteprise Architecture Framework (FEAF) .......................................................................... 24 3.4.1. Opbouw ......................................................................................................................................................... 24 3.4.1.1. Algemene methode .......................................................................................................................... 24 3.4.1.2. FEAF matrix......................................................................................................................................... 26 3.4.1.3. Referentiemodellen ......................................................................................................................... 26 3.4.2. Voordelen en nadelen .............................................................................................................................. 27 Hoofdstuk 4: EA raamwerken vergeleken ............................................................................................................ 28 4.1. Zachman ................................................................................................................................................................ 28 4.1.1. Type informatie.......................................................................................................................................... 28 4.1.2. Bereik ............................................................................................................................................................. 28 4.1.3. Detailniveau ................................................................................................................................................. 28 4.1.4. Aard ................................................................................................................................................................. 29 4.1.5. Belanghebbenden...................................................................................................................................... 29 4.1.6. Taxonomie- en procesvolledigheid .................................................................................................... 29 4.2. The Open Group Architecture Framework (TOGAF) .......................................................................... 29 4.2.1. Type informatie.......................................................................................................................................... 29 4.2.2. Bereik ............................................................................................................................................................. 30 4.2.3. Detailniveau ................................................................................................................................................. 30 4.2.4. Aard ................................................................................................................................................................. 30 4.2.5. Belanghebbenden...................................................................................................................................... 30 4.2.6. Taxonomie- en procesvolledigheid .................................................................................................... 30 4.3. Integrated Architecture Framework (IAF).............................................................................................. 30 4.3.1. Type informatie.......................................................................................................................................... 30 4.3.2. Bereik ............................................................................................................................................................. 31 4.3.3. Detailniveau ................................................................................................................................................. 31 4.3.4. Aard ................................................................................................................................................................. 31 4.3.5. Belanghebbenden...................................................................................................................................... 31 III
4.3.6. Taxonomie- en procesvolledigheid .................................................................................................... 32 4.4. Federal Enterprise Architecture Framework (FEAF) ......................................................................... 32 4.4.1. Type informatie.......................................................................................................................................... 32 4.4.2. Bereik ............................................................................................................................................................. 32 4.4.3. Detailniveau ................................................................................................................................................. 32 4.4.4. Aard ................................................................................................................................................................. 33 4.4.5. Belanghebbenden...................................................................................................................................... 33 4.4.6. Taxonomie- en procesvolledigheid .................................................................................................... 33 4.5. Vergelijking .......................................................................................................................................................... 33 4.6. Besluit van de vergelijking ............................................................................................................................. 35 Hoofdstuk 5: Besluit literatuurstudie ..................................................................................................................... 37
DEEL II: Gevallenstudie ................................................................................................................................... 38 Hoofdstuk 6: Inleiding Gevallenstudie ................................................................................................................... 39 6.1. KwaliCar ................................................................................................................................................................ 40 6.2. Assumpties ........................................................................................................................................................... 40 Hoofdstuk 7: Het Zachman Raamwerk uitgewerkt........................................................................................... 41 7.1. Assumptie ............................................................................................................................................................. 41 7.2. Integratie gap ...................................................................................................................................................... 42 7.3. Methode van Pereira & Sousa ....................................................................................................................... 43 7.3.1. Stap 1: Het bereik ...................................................................................................................................... 45 7.3.2. Stap 2: Conceptuele gegevensmodellering ..................................................................................... 48 7.3.3. Stap 3: Business proces modellering en logische data modellering .................................... 51 7.3.4. Stap 4: Business locaties, functies van het informatiesysteem, tijdsequentie van de business activiteiten en business motivatie ............................................................................................... 55 7.3.5. Stap 5: Organogram, systeemcontext, systeemtriggers en business rules ....................... 67 7.3.6. Stap 6: Systeemgebruikers .................................................................................................................... 70 7.4. Overzicht gebruikte artefacten .................................................................................................................... 71 7.5. Alternatieve artefacten .................................................................................................................................... 71 IV
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 V
Bijlage 3: De balanced score card van Kwalicar ....................................................................................... XVIII Bijlage 4: Business motivation model ............................................................................................................. XXII
VI
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 VII
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
VIII
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
IX
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. 1
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.
2
DEEL I: LITERATUURSTUDIE
3
|Hoofdstuk 1
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).
4
|Hoofdstuk 1
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. 5
|Hoofdstuk 1 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. 6
|Hoofdstuk 1 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: projecten 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 architectuurdomeinen
(business,
IT,
organisatie) geïntegreerd te ontwerpen.
de vier
technologie
en
Dit maakt snelle
verandering in een organisatie mogelijk (Dietz et al., 2007). Hierdoor bekomt men een competitief voordeel, wat cruciaal
Figuur 1.3: Architectuurdomeinen
is gezien de toegenomen business dynamiek (Hoogervorst, 2004).
7
|Hoofdstuk 2
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.
8
|Hoofdstuk 2 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).
9
|Hoofdstuk 2 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.
10
|Hoofdstuk 2
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). 11
|Hoofdstuk 3
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 12
|Hoofdstuk 3 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. 13
|Hoofdstuk 3 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.
14
|Hoofdstuk 3 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)
15
|Hoofdstuk 3
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), gebeurteniscyclus- 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 16
|Hoofdstuk 3 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.
17
|Hoofdstuk 3
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 18
|Hoofdstuk 3 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. 19
|Hoofdstuk 3 B. Business architecture – In deze fase worden de bedrijfsaspecten beschreven. Dit resulteert in een set van bouwblokken en views die de architectuur beschrijven. C. Information systems architectures – In deze fase worden de data– en applicatie- architectuur beschreven. Ook hier is de output een verzameling bouwblokken en views. D. Technology architecture – In deze fase worden de data– en applicatie- architectuur vertaald naar een technologiearchitectuur, rekening houdend met de business architectuur. E. Opportunities and solutions – Hier wordt de architectuur vertaald naar een verzameling projecten. Uit deze verzameling worden de beste projecten geselecteerd, die zullen bijdragen tot het bereiken van de doelstaat van de onderneming. F. Migration planning – In deze fase worden de projecten die geselecteerd werden voor implementatie, geprioriteerd en gepland in de tijd. G. Implementation governance – In deze fase wordt de architectuur vertaald naar richtlijnen voor projecten. Al de informatie die nodig is voor het succesvol managen van de verschillende implementatieprojecten wordt verzameld. H. Architecture change management – In deze fase worden de omstandigheden bepaald waaronder de enterprise architectuur, of een deel ervan, dient veranderd te worden na implementatie. Requirements management – Dit is geen fase, maar wel een centrale link tussen de verschillende fasen van de methode. Het is de plaats waar alle eisen worden beheerd die aan de architectuur worden gesteld.
3.2.1.2. Enterprise continuüm De ADM is sterk gelinkt aan het enterprise continuüm, hetgeen een tweede kerncomponent is van het raamwerk. TOGAF vertrekt immers vanuit het principe dat er niet zoiets bestaat als één enkele universele architectuur die geschikt is voor alle doeleinden op elk moment. Daarentegen is het wel een continuüm van architecturen, een proces waarin men van een zeer generieke architectuur naar een specifieke architectuur gaat afgestemd op de bedrijfsspecifieke business, data, applicaties en technologie. Dit wordt het enterprise continuüm genoemd. Het meest generieke niveau van het enterprise continuüm, waarop meer specifieke architecturen gebaseerd kunnen worden, is de foundation architectuur. Die is opgebouwd uit algemeen beschikbare architecturale bouwblokken waarop de ADM beroep doet om een organisatiespecifieke architectuur te ontwikkelen.
20
|Hoofdstuk 3
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.
21
|Hoofdstuk 3
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 22
|Hoofdstuk 3 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 23
|Hoofdstuk 3 abstractieniveau is het logisch niveau, gekenmerkt door de how- vraag. Deze heeft als doel een aantal oplossingsalternatieven te ontwikkelen, waaruit uiteindelijk een optimale oplossing gekozen kan worden. Een vierde en laatste abstractieniveau is het fysiek niveau. Dit abstractieniveau wordt gekenmerkt door de with what- vraag, die in tegenstelling tot de rest van de vragen uit het IAF niet terug te vinden is in het Zachman raamwerk. Deze laag beschrijft met welke fysieke componenten de ideale oplossing geïmplementeerd kan worden. Zoals zichtbaar in figuur 3.6 worden enkel de abstractieniveaus what, how en with what onderverdeeld voor de verschillende architectuurdomeinen. Het contextuele niveau (why) heeft geen verdere onderverdeling en geldt dus voor de gehele architectuur. Het nut van deze onderverdeling in vier abstractieniveaus kan verduidelijkt worden aan de hand van een eenvoudig praktisch voorbeeld uitgewerkt door Van ’t Wout et al. (2010). Veronderstel een stad die door het toenemend aantal verkeer nood heeft aan het bouwen van een extra brug. Het doel van de brug is dus om meer verkeer toe te laten in de stad (why). De brug moet modern zijn, ze moet passen binnen het imago van de stad (what). Een aantal mogelijke plannen van bruggen worden getoond, maar natuurlijk zullen er maar enkele van deze voldoen aan de vereisten van het jong en modern imago (how). Ten slotte worden de materialen gekozen voor elk deel van de brug (with what). Na deze stappen is de architectuur voor de brug opgebouwd en kan die overhandigd worden aan de ingenieurs die de brug zullen ontwikkelen. Het Capgemini raamwerk wordt aangevuld met tools, technieken en roadmaps voor het gebruik ervan. Veel gebruikte tools binnen het IAF zijn Microsoft Word en Powerpoint. Focusinterviews en workshops zijn voorbeelden van technieken om informatie te verzamelen voor het raamwerk. Ten slotte definiëren engagement roadmaps de delivrables van het werk.
3.3.2. VOORDELEN EN NADELEN Aangezien het IAF volledig is afgeleid van het Zachman raamwerk, zijn dezelfde voor– en nadelen hier van toepassing (cfr. supra 3.1.2., p.16).
3.4. FEDERAL ENTEPRISE ARCHITECTURE FRAMEWORK (FEAF)
3.4.1. OPBOUW 3.4.1.1. Algemene methode De Clinger Cohen act (cfr. supra) lag aan de basis voor de ontwikkeling van het Federal Enterprise Architecture Framework (FEAF). Elke overheidsinstelling in Amerika was immers 24
|Hoofdstuk 3 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
25
|Hoofdstuk 3 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 26
|Hoofdstuk 3 weer van de federale overheid vanuit een businessstandpunt. Het technical reference model (TRM) definieert verschillende technologieën en standaarden die gebruikt kunnen worden in het opbouwen van IT- systemen. Het data reference model (DRM) definieert standaarden voor het beschrijven van data. Het vijfde en laatste referentiemodel is
het service component
reference model (SRM). Dit model identificeert en classificeert servicecomponenten die de federale agentschappen helpen hun IT- investeringen en activa te ondersteunen. Samen omvatten de referentiemodellen een raamwerk dat de belangrijkste elementen beschrijft van de FEA op een algemene en consistente manier.
3.4.2. VOORDELEN EN NADELEN Een groot voordeel van het FEAF is dat het een zeer compleet EA raamwerk is. Meer nog, het is het meest complete EA raamwerk van de vier besproken EA raamwerken. Het bestaat immers zowel uit een taxonomie, zoals Zachman (weergegeven door de FEAF matrix), als een architecturaal proces, zoals TOGAF (Sessions, 2007). Een nadeel is echter wel dat het domein waarin dit raamwerk wordt toegepast, overheidsinstellingen zijn. Ondernemingen kunnen dit EA raamwerk maar moeilijk toepassen.
27
|Hoofdstuk 4
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). 28
|Hoofdstuk 4 Over het algemeen is het raamwerk zelf ook zeer gedetailleerd: het biedt immers gedetailleerde beschrijvingen voor de gehele enterprise. Eerst en vooral wordt er vanuit zes perspectieven naar de onderneming gekeken. Verdere detaillering wordt verkregen door elk perspectief nog eens te bekijken vanuit zes verschillende abstractieniveaus.
4.1.4. AARD De inhoud van de cellen bestaat voornamelijk uit modellen en tekstuele beschrijvingen.
4.1.5. BELANGHEBBENDEN In het Zachman raamwerk worden de architectuurbeschrijvingen opgedeeld naar de verschillende belanghebbenden. Elke rij geeft namelijk een heldere weergave van de organisatie weer, vanuit het perspectief van een belanghebbende van de onderneming. De belanghebbenden die in het Zachman raamwerk zijn opgenomen zijn: de planner, de eigenaar (owner), de ontwerper (designer), de ontwikkelaar (builder) en de onderaannemer (subcontractor).
4.1.6. TAXONOMIE- EN PROCESVOLLEDIGHEID Het Zachman raamwerk scoort heel erg hoog op de eigenschap taxonomievolledigheid. Zoals reeds eerder vermeld, is het Zachman raamwerk louter een structuur voor het classificeren van verschillende artefacten. Het is een descriptief raamwerk. Het definieert architectuur, maar beschrijft niet hoe iemand architectuur kan doen. Het Zachman raamwerk mist een procesomschrijving voor het creëren van een enterprise architectuur en scoort dus zeer laag op de eigenschap procesvolledigheid.
4.2. THE OPEN GROUP ARCHITECTURE FRAMEWORK (TOGAF) 4.2.1. TYPE INFORMATIE TOGAF deelt een enterprise architectuur op in vier categorieën: de business architectuur, applicatie architectuur, data architectuur en technische architectuur. Elk van deze wordt uiteengezet in een fase van de ADM. De business architectuur wordt gespecificeerd in de businessarchitectuurfase, de data– en applicatiearchitectuur worden gespecificeerd in de informatie systeem architectuur fase en de technische architectuur ten slotte wordt gespecificeerd in de technologie architectuur fase.
29
|Hoofdstuk 4
4.2.2. BEREIK TOGAF kan toegepast worden op eender welke organisatie die producten en services levert in een business– of industriedomein (Van Sante et al., 2008).
4.2.3. DETAILNIVEAU Om een consistent detailniveau te bekomen over de verschillende architectuurdomeinen, wordt het detailniveau bepaald per iteratie van de ADM. Het is onmogelijk om reeds na de eerste iteratie een gedetailleerde architectuurbeschrijving te voltooien. Echter, hoe meer iteraties reeds doorlopen zijn, hoe groter het detailniveau van de architectuurbeschrijving. Bij elke iteratie neemt het detailniveau immers toe.
4.2.4. AARD De manier waarop informatie in The Open Group Architecture Framework wordt weergegeven is aan de hand van modellen, principes, richtlijnen en standaarden. In alle fases van de ADM wordt de output overwegend weergegeven aan de hand van modellen en principes. De resource base op haar beurt bestaat uit een set van richtlijnen, modellen, principes, standaarden en achtergrondinformatie.
4.2.5. BELANGHEBBENDEN In TOGAF worden de architectuurbeschrijvingen niet opgedeeld naar de verschillende belanghebbenden van de onderneming. Voor elke fase van de ADM kunnen de belanghebbenden echter wel impliciet bepaald worden. Bender (2009) definieert voor elk van deze belanghebbenden die artefacten (diagrammen, lijsten en matrices) die tot hun interessegebied behoren.
4.2.6. TAXONOMIE- EN PROCESVOLLEDIGHEID Op deze eigenschappen scoort TOGAF net andersom dan Zachman. TOGAF scoort immers heel hoog op de eigenschap procesvolledigheid, maar mist een structuur voor het ordenen van de artefacten van de ADM. In die zin zou het Zachman raamwerk een perfecte aanvulling kunnen zijn op TOGAF (Sessions, 2007).
4.3. INTEGRATED ARCHITECTURE FRAMEWORK (IAF) 4.3.1. TYPE INFORMATIE Vier architectuurdomeinen voegen informatie toe aan de globale architectuur in het IAF: business, informatie, informatiesystemen en technologie infrastructuur. Eerst en vooral is er 30
|Hoofdstuk 4 informatie nodig over de structuur van de business, zodanig dat men zicht kan krijgen over welke technologie nodig is om de business te ondersteunen of mogelijk te maken. De informatievoorziening heeft betrekking op de manier waarop de businessinformatie wenst verwerkt te worden: wie heeft welke informatie nodig en wanneer, welke relaties bestaan tussen informatiestromen,… In een derde architectuurdomein wordt er informatie verschaft over de structuur van de informatiesystemen die de business ondersteunen. Er wordt gekeken welke informatiesystemen gebouwd en welke gekocht moeten worden (build vs. buy decision). Ten slotte zorgt de technologie- infrastructuur dan voor de ondersteuning in het gebruik van de informatiesystemen en applicaties (Van ’t Wout et al., 2010).
4.3.2. BEREIK Het raamwerk moet gebruikt kunnen worden op alle niveaus in een organisatie. Het IAF moet met andere woorden van toepassing kunnen zijn op eender welk systeem, gaande van een organisatie, een business unit tot specifieke projecten. Voor elk systeem kan er een architectuur ontworpen worden. Het bereik van het IAF is dus sterk vergelijkbaar met dat van het Zachman raamwerk en gaat eveneens uit van een holistische benadering, waarbij een organisatie gezien wordt als een vervlochten geheel van facetten.
4.3.3. DETAILNIVEAU Net zoals dit in het Zachman raamwerk het geval is, wordt ook in het IAF een hoog detailniveau verkregen. Elk systeem wordt beschreven vanuit vier architectuurdimensies, die op hun beurt nog verder gedetailleerd worden over verschillende abstractieniveaus. Het raamwerk heeft in totaal twintig cellen waardoor een architectuurbeschrijving zeer gedetailleerd kan worden opgesteld.
4.3.4. AARD Het raamwerk levert voornamelijk principes, standaarden, richtlijnen en modellen op.
4.3.5. BELANGHEBBENDEN In het IAF wordt de architectuurbeschrijving niet opgedeeld naar belanghebbenden. Om de architectuur over te brengen naar de verschillende belanghebbenden van de onderneming definieert het raamwerk echter wel enkele views. Zo een view is een verzameling architectuurartefacten die in overeenstemming zijn met bepaalde criteria; voorbeelden zijn governance view, performance view, …
31
|Hoofdstuk 4
4.3.6. TAXONOMIE- EN PROCESVOLLEDIGHEID Hoewel het IAF en het Zachman raamwerk sterk op elkaar lijken, is er toch een klein verschil in opvatting van architectuur tussen de twee. Zachman ziet architectuur eerder als een ‘one-shot’ proces. Het IAF benadrukt meer het feit dat architectuur een nooit stoppend proces is en is daarom zodanig ontworpen dat het raamwerk makkelijk haar inhoud aan andere raamwerken kan uitlenen die eerder procesgericht zijn, zoals TOGAF. Dit raamwerk (of meer specifiek de ADM van TOGAF) geeft dan het proces voor IAF’s inhoud. Het IAF is dus een heel flexibel raamwerk: het kan zowel op zichzelf gebruikt worden, als samen met andere methoden. Dit is tevens het geval voor Zachman, alleen wordt bij deze laatste de samenspraak met andere raamwerken minder benadrukt.
4.4. FEDERAL ENTERPRISE ARCHITECTURE FRAMEWORK (FEAF) 4.4.1. TYPE INFORMATIE Het FEAF maakt onderscheid tussen vier architectuurgebieden: business architectuur, data architectuur, applicatie architectuur en technologie architectuur.
4.4.2. BEREIK Het bereik van het FEAF betreft alle organisaties die deel uitmaken van de federale overheid van een land en al haar partners, waaronder (Schekkerman, 2004): -
Grote federale departementale systemen
-
Departementale subagentschappen -en kantoorsystemen
-
Andere federale agentschapsystemen
-
Systemen waar substantiële federale investeringen betrokken zijn bij internationale, staatsof 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.
32
|Hoofdstuk 4
4.4.4. AARD Informatie in het FEAF wordt voornamelijk weergegeven aan de hand van modellen, standaarden en richtlijnen.
4.4.5. BELANGHEBBENDEN Aangezien de FEAF-matrix volledig gebaseerd is op de eerste drie kolommen van het Zachman raamwerk, wordt ook de architectuurbeschrijving op dezelfde manier opgedeeld naar belanghebbenden als bij Zachman. Volgende belanghebbenden worden onderscheiden: de planner, de eigenaar (owner), de ontwerper (designer), de ontwikkelaar (builder) en de onderaannemer (subcontractor).
4.4.6. TAXONOMIE- EN PROCESVOLLEDIGHEID Het FEAF is een zeer complete methodologie. Het bestaat immers zowel uit een taxonomie, zoals Zachman (weergegeven door de FEAF matrix), als een architecturaal proces, zoals TOGAF (Sessions, 2007).
4.5. VERGELIJKING Zoals eerder vermeld is geen enkel EA raamwerk compleet. Elk raamwerk heeft zijn sterktes en zwaktes. In dit hoofdstuk werden enkele belangrijke EA raamwerken (het Zachman raamwerk, TOGAF, het IAF en het FEAF) vergeleken op basis van de volgende zes eigenschappen: type informatie, bereik, detailniveau, aard, belanghebbenden, taxonomie- en procesvolledigheid. Uit deze analyse kunnen voor elk van de zes eigenschappen een aantal conclusies getrokken worden. Eerst en vooral is het opvallend dat de informatie die aanwezig is in elk van de besproken EA raamwerken evenwichtig verdeeld is over alle vier de architectuurdomeinen: business, informatie, organisatie en techniek. Dit verklaart waarschijnlijk waarom de besproken EA raamwerken zoveel toegepast worden in de praktijk. Immers, een raamwerk dat bijvoorbeeld vooral focust op het informatie- architectuurdomein in vergelijking met de andere architectuurdomeinen is veel minder compleet en zal bijgevolg veel minder populariteit en dus praktische toepasbaarheid genieten. Een tweede conclusie die getrokken kan worden is dat de architectuurinformatie van de besproken EA raamwerken zowel betrekking kan hebben op de volledige onderneming, als op een bedrijfstak of businessunit van de onderneming. De raamwerken gaan uit van een 33
|Hoofdstuk 4 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 34
|Hoofdstuk 4 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.
35
|Hoofdstuk 4 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.
36
|Hoofdstuk 5
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.
37
DEEL II: GEVALLENSTUDIE
38
|Hoofdstuk 6
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.
39
|Hoofdstuk 6
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.
40
|Hoofdstuk 7
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.
41
|Hoofdstuk 7 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 businessIT 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) 42
|Hoofdstuk 7 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
43
|Hoofdstuk 7
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.
44
|Hoofdstuk 7
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.
45
|Hoofdstuk 7
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 46
|Hoofdstuk 7 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 47
|Hoofdstuk 7 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 48
|Hoofdstuk 7 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.
49
|Hoofdstuk 7
Figuur 7.3: EER diagram
50
|Hoofdstuk 7
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.
51
|Hoofdstuk 7
Figuur 7.4: BPMN diagram
52
|Hoofdstuk 7
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 53
|Hoofdstuk 7 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)
54
|Hoofdstuk 7
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. 55
|Hoofdstuk 7 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 56
|Hoofdstuk 7 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.
57
|Hoofdstuk 7 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). 58
|Hoofdstuk 7 -
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 59
|Hoofdstuk 7 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
Voeg gegevens toe aan werkfile
Pas bestaande klantfile aan
Bediende
Creëer een nieuwe werkfile
Arbeider
Pas bestaande werkfile aan
Stel factuur op
Figuur 7.9: Use case diagram
60
|Hoofdstuk 7 -
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.
61
|Hoofdstuk 7
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 62
|Hoofdstuk 7 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
63
|Hoofdstuk 7 Zoals zichtbaar in figuur 7.11 bestaat de hoofdstrategie van KwaliCar erin om de winstgevendheid te verhogen. Dit kan enkel indien de onderneming veel klanten kan aantrekken en behouden. Het is met andere woorden belangrijk om nummer één in de klantvoorkeur te zijn. Om dit te bereiken focust KwaliCar in haar bedrijfsvoering enerzijds op het bereiken van kwaliteit en anderzijds op het verbeteren van de informatie uitwisseling. KwaliCar tracht kwaliteit te garanderen door gekwalificeerd personeel te rekruteren en door continu mee te zijn met de nieuwste technieken en technologieën. Een ander model aan de hand waarvan de business model/motivatie- cel kan voorgesteld worden, is het Business Motivation Model (BMM) (S. Ostadzadeh, Aliee & A. Ostadzadeh, 2007). Het gebruik van het BMM voor deze motivatiecel wordt bevestigd in een paper uitgebracht door de Business Rules Group (BRG, 2010). Zij definiëren het BMM als volgt: “Het is een schema voor het ontwikkelen, communiceren en managen van business plannen op een georganiseerde manier”. Het basisidee is om een business model van het business plan van de onderneming te ontwikkelen, vooraleer de systeemontwikkeling gestart wordt. De belangrijkste elementen van het model zijn onder te brengen in twee grote areas. Een eerste definieert de ends en means van de business plannen. Dingen die de onderneming wil bereiken zijn ends. De manier waarop een onderneming deze ends tracht te bereiken, worden means genoemd. Een tweede area bestaat uit de interne en externe factoren die de onderneming beïnvloeden, evenals een assessment van de impact die deze influencers hebben op de ends en means van de onderneming. Een assessment is niets anders dan een SWOT analyse die gemaakt wordt van deze influencers. Al de elementen waaruit het BMM bestaat (ends, means, influencers, assessment of influencers) zijn onderling gerelateerd aan elkaar. In bijlage 4 wordt een algemeen BMM weergegeven. Hierin zijn duidelijk de verschillende elementen te zien waaruit een BMM bestaat, evenals de onderlinge relaties tussen deze elementen. Een vereenvoudigd BMM voor het fictief bedrijf KwaliCar is hieronder weergegeven in figuur 7.12.
64
|Hoofdstuk 7 Figuur 7.12: BMM van KwaliCar
Means 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
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%
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. 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 /
65
|Hoofdstuk 7 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. 66
|Hoofdstuk 7
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 67
|Hoofdstuk 7 (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.
68
|Hoofdstuk 7 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.
Systeem
User (bediende)
File server
Login
Get klantgegevens Klantgegevens
Check klantgegevens Confirm
Store klantfile Confirm
Figuur 7.15: UML sequence diagram voor de use case ‘Creëer nieuwe klantfile’
69
|Hoofdstuk 7 -
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
Voeg gegevens toe aan werkfile
Pas bestaande klantfile aan
Bediende
Creëer een nieuwe werkfile
Arbeider
Pas bestaande werkfile aan
Stel factuur op
Figuur 7.16: Use case diagram
70
|Hoofdstuk 7
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. 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
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 71
|Hoofdstuk 7 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
Function
Network
People
Time
Motivation
(what)
(how)
(where)
(who)
(when)
(why)
/
-Activity
/
/
P.E.R.T
/
Scope
Business Model
diagram
schema
-Petri nets 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 72
|Hoofdstuk 7 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.
73
|Hoofdstuk 8
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. 74
|Hoofdstuk 8 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 75
|Hoofdstuk 8 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.
76
|Hoofdstuk 9
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. 77
|Hoofdstuk 9
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).
78
|Hoofdstuk 9
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. 79
|Hoofdstuk 9
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.
80
|Hoofdstuk 9
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.
81
|Hoofdstuk 9
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?
82
|Hoofdstuk 10
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
83
|Hoofdstuk 10 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 84
|Hoofdstuk 10 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.
85
|Hoofdstuk 10 -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.
86
|Hoofdstuk 10
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.
87
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 88
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.
89
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.
90
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: 19.
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. X
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: 375380.
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.
XI
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.
XII
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.technicalcommunicators.com/articles/zachman_framework.pdf>. (10/11/2011)
Mulholland, A. and A. L. Macaulay (2006) Architecture and the Integrated Architecture Framework.
URL: XIII
. (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-theenterprise.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:
.
(10/04/2012).
Van Dullemen et al. (2008). Enterprise Architectuur: Een managementinstrument voor business transformatie. URL: . (11/10/2011). Zachman, J. A. (2003). The Framework for Enterprise Architecture Cell Definitions. URL: . (08/11/2011).
XIV
Zachman, J. A. (2003). The Zachman Framework: A Primer For Enterprise Architecture: Primer for
Enterprise
Engineering
and
Manufacturing.
URL:
. (03/10/11).
Zachman,
J.
A.
(2009).
Zachman
on
the
Framework.
URL:
. (03/10/2011).
XV
BIJLAGEN BIJLAGE 1: TOGAF CONTENT FRAMEWORK
XVI
BIJLAGE 2: TOGAF CONTENT METAMODEL
XVII
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
XVIII
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
S2
Focus op kwaliteit
S2 – D1
S3
Winstgevendheid verhogen
S3 – D1 S3 – D2
S4
Het verbeteren van de informatie uitwisseling tussen arbeiders en bedienden
S4 – D1
S5
Mee zijn met de nieuwste technieken en technologieën
S5 – D1
S6
Rekruteer gekwalificeerd personeel
S6-D1
Verbeteren van de relatie met de klanten Ontwikkelen van toepassingen die de kwaliteit verbeteren Verhogen van inkomsten Vastleggen van de USP (=unique selling proposition) Ontwikkeling van informatiesystemen –en infrastructuur voor de interne informatie uitwisseling Oudere technologieën vervangen door nieuwe indien nodig 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
S2 – D1
Ontwikkeling 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 selectieprocedure
S3 – D1 S3 – D2 S4 – D1
S5 – D1 S6- D1
S1-D1-M1
% klanttevredenheid
S1-D1-M2 S2-D2-M1
% klantmoeilijkheden % klanttevredenheid
S3-D1-M1 S3-D2-M1 S4-D1-M1
Rentabiliteitsratio’s #strengths/#weaknesses Processing time
S5-D1-M1
Processing time
S6-D1-M1
% klanttevredenheid
XIX
Doelwaarden: De maatstaven moeten een bepaalde doelwaarde hebben, om te kunnen nagaan of de doelstellingen al dan niet bereikt worden. Doelstelling S1 – D1
S2 – D1
S3 – D1
S3 – D2 S4 – D1
S5 – D1
S6-D1
Maatstaaf Verbeteren van de relatie met de klanten Ontwikkeling van toepassingen die de kwaliteit verbeteren Verhogen van inkomsten
Doelwaarde
S1-D1-M1-T1
% klanttevredenheid
>85%
S1-D1-M2-T1 S2-D2-M1-T1
% klantmoeilijkheden % klanttevredenheid
<10% >85%
S3-D1-M1-T1
Rentabiliteitsratio’s: +3% rentabiliteit van het eigen vermogen #strengths/#weaknesses >1
Vastleggen van de S3-D2-M1-T1 USP Ontwikkeling van S4-D1-M1-T1 informatiesystemen –en infrastructuur voor de interne informatie uitwisseling Oudere S5-D1-M1-T1 technologieën vervangen door nieuwe indien nodig Verbeteren van de S6-D1-M1-T1 selectieprocedure
Processing time
Verminderd met 10%
Processing time
Verminderd met 10%
% klanttevredenheid
>85%
Initiatieven: Het laagste niveau van de BSC zijn de initiatieven die genomen kunnen worden om de hogere niveaus (doelstellingen, strategieën,…) te bereiken. Initiatief
Strategie
Doelstel ling
Nummer 1 klantvoorkeur zijn
S1 – D1
Verbeteren van de relatie met de klanten
Focus op kwaliteit
S2 – D1
Winstgevendhei d verhogen
S3 – D1
Ontwikkeling van toepassingen die de kwaliteit verbeteren Verhogen van inkomsten
S3 – D2
Vastleggen van de USP
S1-D1-M1-T1I1 S1-D1-M2-T1I1 S2-D1-M1-T1I1
Implementeren van CRM technieken
S3-D1-M1-T1I1 S3-D2-M1-T1I1
Uitwerken van een marketingstrategie Het toepassen van een SWOT analyse
Het implementeren van six sigma training
XX
Het verbeteren van de informatie uitwisseling tussen arbeiders en bedienden Mee zijn met de nieuwste technieken en technologieën Rekruteer gekwalificeerd personeel
S4 – D1
Ontwikkeling van informatiesystemen –en infrastructuur voor de interne informatie uitwisseling
S4-D1-M1-T1I1
Implementeren van een intern computerprogramma dat zowel door arbeiders als bedienden kan gebruikt worden. Halfjaarlijkse controle van de machines door expert
S5 – D1
Oudere technologieën vervangen door nieuwe indien nodig
S5-D1-M1-T1I1
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. XXI
BIJLAGE 4: BUSINESS MOTIVATION MODEL
XXII
