UNIVERSITEIT GENT
FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2012 – 2013
Softwareondersteuning voor een enterprise architectuur in Access en Java Masterproef voorgedragen tot het bekomen van de graad van Master of Science in de Toegepaste Economische Wetenschappen: Handelsingenieur
Dennis Ingelbeen onder leiding van Prof. Dr. Geert Poels en Maxime Bernaert
UNIVERSITEIT GENT
FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2012 – 2013
Softwareondersteuning voor een enterprise architectuur in Access en Java Masterproef voorgedragen tot het bekomen van de graad van Master of Science in de Toegepaste Economische Wetenschappen: Handelsingenieur
Dennis Ingelbeen onder leiding van Prof. Dr. Geert Poels en Maxime Bernaert
I
PERMISSION Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding. Dennis Ingelbeen
II
Woord vooraf Eerst en vooral wil ik graag mijn begeleider en promotor, Maxime Bernaert en prof. dr. Geert Poels bedanken voor de uitstekende begeleiding en ondersteuning tijdens de uitwerking van deze masterproef. Ze hebben mij de kans gegeven om mee te werken aan een vernieuwend en uitdagend onderwerp. Bovendien werden mij verschillende opportuniteiten aangeboden die mij ertoe hebben aangespoord intellectueel uitdagende opdrachten aan te gaan die hebben bijgedragen tot de academische waarde van deze thesis. Daarnaast zou de evaluatie van de masterproef niet mogelijk zijn geweest zonder de medewerking van de ondernemingen Christeyns, Cavalier, Profile Tyrecenter ABS, Sanicomfort en de facultaire studentenadministratie van de Universiteit Gent. Door de toepassing in de praktijk en de waardevolle feedback, werden immers inzichten en kennis bekomen voor de verdere optimalisatie en het verhogen van de meerwaarde van de software tool EASE. Ten laatste wil ik ook mijn vriendin en alle andere mensen bedanken die mij hebben gesteund en geholpen bij de verwezenlijking van deze thesis.
III
Inhoudsopgave Inleiding ............................................................................................................................................ 1 Literatuurstudie ............................................................................................................................. 3 1. Kleine en middelgrote ondernemingen ....................................................................................... 3 1.1. Wat is een KMO? .............................................................................................................................................. 3 1.2. Eigenschappen KMO’s ................................................................................................................................... 4 1.3. Het belang van KMO’s .................................................................................................................................... 5 2. Enterprise architectuur ..................................................................................................................... 6 2.1. Wat is enterprise architectuur? ................................................................................................................. 6 2.2. Voordelen van enterprise architectuur ................................................................................................. 8 2.3. Criteria voor enterprise architectuur technieken ............................................................................. 9 3. Enterprise architectuur voor KMO’s ........................................................................................... 10 3.1. Criteria EA voor KMO’s ............................................................................................................................... 12 3.2. Adoptie modellen .......................................................................................................................................... 13 3.2.1. Technology acceptance model (TAM) ........................................................................................................... 13 3.2.2. Method evaluation model ................................................................................................................................... 15 3.2.3. Richtlijnen voor de adoptie ................................................................................................................................ 17
3.3. Evaluatiemodel EA voor KMO’s ............................................................................................................... 18 3.4. CHOOSE .............................................................................................................................................................. 19 3.4.1. Goal model: Know-‐Why ....................................................................................................................................... 20 3.4.2. Actor model: Know-‐Who ..................................................................................................................................... 21 3.4.3. Operation model: Know-‐How ............................................................................................................................ 22 3.4.1. Object model: Know-‐What .................................................................................................................................. 22 3.4.2. Relaties ........................................................................................................................................................................ 23 3.4.3. Metamodel ................................................................................................................................................................. 25 3.4.4. Reflectie vooropgestelde criteria ..................................................................................................................... 25
4. Belang tool support ........................................................................................................................... 27 4.1. Het belang van tool support ...................................................................................................................... 27 4.2. Het belang van een nieuwe tool .............................................................................................................. 29
Research scope: EASE ................................................................................................................. 31 1. Methodologie ....................................................................................................................................... 33 1.1. Conceptueel framework methodologische correctheid RE papers ......................................... 34 1.2. Design science research methodologie voor information systems research ...................... 37 1.3. Software proces modellen ......................................................................................................................... 40 1.3.1. Specification-‐based modellen ........................................................................................................................... 40 1.3.2. Evolutionary development modellen ............................................................................................................. 41
IV
1.4. EASE methodologie ....................................................................................................................................... 43 2. Criteria voor EASE .............................................................................................................................. 44 3. Software tool ontwikkeling ............................................................................................................ 46 3.1. Database ............................................................................................................................................................ 48 3.1.1. Representatieonderzoek ..................................................................................................................................... 49
3.2. Interface ............................................................................................................................................................. 54 3.2.1. Design principe 1: Begrijp de mens achter het programma ................................................................ 54 3.2.2. Design principe 2: Wees consistent ................................................................................................................ 55 3.2.3. Design principe 3: Een goed schermontwerp is onontbeerlijk ........................................................... 55 3.2.4. Design principe 4: Communiceer eenvoudig, correct en tijdig ........................................................... 57 3.2.5. Design principe 5: Test, test en hertest ......................................................................................................... 58
3.3. Input .................................................................................................................................................................... 58 3.4. Adjust .................................................................................................................................................................. 61 3.5. Output ................................................................................................................................................................. 67 3.5.1. Focused architectural overview ....................................................................................................................... 68 3.5.1.1. Design space ................................................................................................................................................ 70 3.5.1.2. Solution space ............................................................................................................................................. 71 3.5.1.2.1. The physics of notations .................................................................................................................... 71 3.5.1.2.2. Entreprise Architecture at Work ................................................................................................... 75 3.5.1.3. Ontwerp en Functionaliteit .................................................................................................................. 77 3.5.2. Export .......................................................................................................................................................................... 81 3.5.3. Balanced Scorecard Analyse .............................................................................................................................. 82 3.5.4. Check Inconsistenties ........................................................................................................................................... 83
4. Evaluatie ................................................................................................................................................ 84 4.1. Exploratieve evaluatie ................................................................................................................................. 85 4.1.1. Aanpak ......................................................................................................................................................................... 85 4.1.2. Resultaten .................................................................................................................................................................. 87 4.1.3. Kwalitatieve interviews ....................................................................................................................................... 91
Algemeen besluit .......................................................................................................................... 93 1. Conclusie ............................................................................................................................................... 93 2. Beperkingen en richtlijnen voor verder onderzoek .............................................................. 94
Lijst van de geraadpleegde werken ......................................................................................... X Bijlagen .......................................................................................................................................... XIV
V
Gebruikte afkortingen •
CHOOSE: keep Control, by means of a Holistic Overview, based on Objectives and kept Simple, of your Enterprise
•
EA: enterprise architectuur
•
EAM: enterprise architecture management
•
EASE: enterprise architecture SME environment
•
DBMS: databasemanagementsysteem
•
DSR: design science research
•
GUI: graphical user interface
•
IS: informatiesystemen
•
IT: informatietechnologie
•
KMO: kleine en middelgrote onderneming
•
MEM: method evaluation model
•
NPV: net present value
•
PEU: perceived ease of use
•
PU: perceived usefulness
•
RE: requirements engineering
•
TAM: technology acceptance model
•
TOGAF: the open group architecture framework
VI
Lijst van figuren Afbeelding 1: categorisatie KMO's (European Commission 2006) .......................................................................................... 3 Afbeelding 2: economisch belang KMO's (Vervenne 2010) ........................................................................................................ 6 Afbeelding 3: de drie lagen van een traditionele EA techniek ................................................................................................... 7 Afbeelding 4: omgekeerde piramide met focus op de business ................................................................................................. 8 Afbeelding 5: tijdsverloop overlevingsgraad KMO's ................................................................................................................... 10 Afbeelding 6: technology acceptance model (Davis, Bagozzi et al. 1989) ........................................................................ 13 Afbeelding 7: efficiëntie vs. effectiviteit (Moody 2003) ............................................................................................................. 15 Afbeelding 8: method evaluation model (Moody 2003) ............................................................................................................ 16 Afbeelding 9: evaluatiemodel EA techniek voor KMO's ............................................................................................................. 18 Afbeelding 10: de vier geïntegreerde modellen van CHOOSE (Bernaert 2011) .............................................................. 19 Afbeelding 11: voorbeeld goal model ................................................................................................................................................ 20 Afbeelding 12: voorbeeld actor model .............................................................................................................................................. 21 Afbeelding 13: voorbeeld operatie model ........................................................................................................................................ 22 Afbeelding 14: voorbeeld object model ............................................................................................................................................. 22 Afbeelding 15: integratie tot één overkoepelend model ........................................................................................................... 24 Afbeelding 16: metamodel CHOOSE ................................................................................................................................................... 25 Afbeelding 17: fractie EA artefact Belgische KMO ...................................................................................................................... 29 Afbeelding 18: onderzoeksstappen ..................................................................................................................................................... 31 Afbeelding 19: IS research framework (Hevner, March et al. 2004) ................................................................................... 38 Afbeelding 20: watervalmodel op een hoog niveau van abstractie ..................................................................................... 40 Afbeelding 21: spiral model of software development (Boehm 1988) ................................................................................ 42 Afbeelding 22: methodologie op een hoog niveau van abstractie ........................................................................................ 43 Afbeelding 23: hoofdmenu en opbouw tool .................................................................................................................................... 48 Afbeelding 24: ER-‐diagram CHOOSE in UML-‐notatie ................................................................................................................ 49 Afbeelding 25: input venster EASE ..................................................................................................................................................... 58 Afbeelding 26: input van een entiteit in de goal dimensie ....................................................................................................... 59 Afbeelding 27: navigatie EASE ............................................................................................................................................................. 60 Afbeelding 28: edit data .......................................................................................................................................................................... 61 Afbeelding 29: zoekfunctionaliteit ..................................................................................................................................................... 62 Afbeelding 30: overzicht boomstructuur ......................................................................................................................................... 63 Afbeelding 31: adjust goal interface .................................................................................................................................................. 64 Afbeelding 32: adjust goal relaties ..................................................................................................................................................... 65 Afbeelding 33: soft constraints ............................................................................................................................................................. 66 Afbeelding 34: theory of diagrammatic communication (Moody 2009) ........................................................................... 68 Afbeelding 35: visuele variabelen Bertin (Moody 2009) ........................................................................................................... 70 Afbeelding 36: voorbeeld semiotic transparancy (a) ................................................................................................................. 72 Afbeelding 37: voorbeeld semiotic transparancy (b) ................................................................................................................. 72 Afbeelding 38: focused architectural overview interface ......................................................................................................... 77
VII
Afbeelding 39: overzicht opbouw visualisatie ............................................................................................................................... 78 Afbeelding 40: focused architectural overview ............................................................................................................................. 80 Afbeelding 41: export RACI .................................................................................................................................................................... 81 Afbeelding 42: ordenen doelstellingen hoogste niveau ............................................................................................................. 82 Afbeelding 43: check inconsistenties functionaliteit .................................................................................................................. 83 Afbeelding 44: algemene beoordeling EASE .................................................................................................................................. 90
VIII
Lijst van tabellen Tabel 1: overzicht ondernemingen casestudies ............................................................................................................................ 85 Tabel 2: algemene voordelen EASE .................................................................................................................................................... 87 Tabel 3: evaluatie perceived efficacy EASE .................................................................................................................................... 88 Tabel 4: beoordeling CHOOSE criteria .............................................................................................................................................. 89 Tabel 5: beoordeling EASE criteria .................................................................................................................................................... 90
IX
Inleiding Als u van plan bent een huis te bouwen of verbouwen, zult u wellicht een beroep doen op een architect om er zeker van te zijn dat het eindresultaat zowel structureel als functioneel aan uw wensen voldoet. Het is dan aan de architect om deze wensen te gaan vertalen in technische specificaties en plannen waarmee hij de afstemming tussen uw vereisten en de werkelijke uitbouw van de woning beter kan beheersen en communiceren. Een gelijkaardig proces kan men onderscheiden bij het opstarten, runnen of uitbouwen van een onderneming. Een onderneming is een complex systeem van mensen, kennis, projecten, processen en zoveel meer, samengebracht voor het realiseren van een gedeelde gemeenschappelijke visie. Enterprise architectuur (EA) ondersteunt dit proces en wordt omschreven als een samenhangend geheel van beginselen, methodes en modellen met als finale doelstelling de creatie van een consistent en coherent organisatorisch ontwerp van de onderneming. Enterprise architectuur (EA) werd oorspronkelijk hoofdzakelijk door informatici gebruikt waardoor de focus initieel op de structurering van informatiesystemen lag en daarop volgend op het op elkaar afstemmen van business en IT. Het concept is zich echter in de loop der jaren ook meer gaan richten op het structureren van de business en tegenwoordig bestaan er verscheidene toepassingen over de grenzen van IT heen. Niettegenstaande er veel onderzoek wordt gedaan naar EA, is er weinig geweten over het gebruik van EA in de omgeving van kleine en middelgrote ondernemingen (KMO’s) (Bhagwat and Sharma 2007). Enkele onderzoekers leverden pionierswerk op dit vlak door de ontwikkeling van een EA techniek aangepast aan de specifieke karakteristieken van deze doelgroep, genaamd CHOOSE. De implementatie van EA in het algemeen en de CHOOSE methode in het bijzonder, blijkt een zeer complex en uitdagend proces te zijn. Niettegenstaande de aanzienlijke voordelen die KMO’s door het gebruik van EA zouden kunnen realiseren, is de adoptie ervan ver beneden peil en maakt zo goed als geen enkele KMO er effectief gebruik van. Uit casestudies met de CHOOSE methode is gebleken dat software tool support aanzienlijk kan bijdragen tot het oplossen van deze schijnbare paradox en de adoptie van EA in KMO’s significant kan verbeteren. Dit artikel beschrijft de ontwikkeling van de software tool EASE (Enterprise Architecture SME Environment) ter ondersteuning van CHOOSE in de implementatie, het management en onderhoud van EA in KMO’s. Alvorens de ontwikkeling van EASE aan te vatten, is het belangrijk om voldoende inzicht te hebben in de huidige situatie. Het eerste deel bestaat dan ook uit een uitgebreide literatuurstudie. De hoofddoelstelling van deze literatuurstudie is het verzamelen van kennis
1
die kan helpen bij de identificatie, beschrijving en motivatie van het probleem dat aan de basis ligt van het onderzoek. Hierbij is gefundeerde kennis met betrekking tot de twee kernconcepten, KMO’s en EA, onontbeerlijk. Op basis van deze inzichten werd CHOOSE ontwikkeld door Bernaert. Aangezien deze techniek de basis vormt van EASE, zal er vervolgens een uitgebreide beschrijving worden gegeven van de concepten, de relaties en het metamodel van CHOOSE. In het laatste hoofdstuk van de literatuurstudie volgt er een goed gefundeerde uiteenzetting over het belang van een dergelijke software tool. Het tweede deel geeft een overzicht van het ontwikkelingsproces van de software tool zelf (research scope). Dit deel start met de beschrijving van de gevolgde methodologie. Op basis van de kennis verzameld in de literatuurstudie worden vervolgens design criteria afgeleid voor de ontwikkeling van EASE. In het derde hoofdstuk wordt een uitgebreide uiteenzetting gegeven van EASE met aandacht voor de opbouw van de database, de interface ontwerpkeuzes en de functionaliteiten van de software tool. Een gedetailleerde uiteenzetting van het evaluatieproces vormt het einde van dit deel. In het laatste deel zal er een algemeen besluit gegeven worden waarin de belangrijkste bevindingen van het onderzoek worden samengebracht. Bovendien zal er een overzicht worden gegeven van de beperkingen van het onderzoek en worden aanbevelingen voor verder onderzoek voorgesteld.
2
Literatuurstudie 1. Kleine en middelgrote ondernemingen 1.1. Wat is een KMO? In Amerika wordt een KMO omschreven door the Office of Advocacy als een zelfstandig bedrijf met minder dan 500 werknemers (Small Business Administration 2012). In Europa daarentegen gelden andere regels. De Europese Commissie definieert KMO’s als ondernemingen met minder dan 250 personeelsleden en een jaaromzet van maximaal € 50 miljoen of een jaarlijks balanstotaal van niet meer dan € 43 miljoen (European Commission 2006). Het aantal personeelsleden mag in geen geval overschreden worden, maar men laat de keuze aan het bedrijf om hetzij de jaaromzet hetzij het balanstotaal te plafonneren. Ondernemingen uit de handels-‐ en distributiesector hebben immers hogere omzetcijfers dan productieondernemingen. Door de keuze te laten tussen beide criteria verzekert men een eerlijke behandeling voor bedrijven uit verschillende sectoren. KMO’s worden op basis van deze criteria vervolgens onderverdeeld in micro-‐, kleine en middelgrote ondernemingen. Onderstaande figuur geeft een overzicht van deze onderverdeling.
Afbeelding 1: categorisatie KMO's (European Commission 2006)
3
Afhankelijk van waar het bedrijf zijn hoofdzetel heeft, zijn er dus andere criteria ter bepaling van het KMO-‐statuut. Ondanks deze verschillen in kwantitatieve criteria vertonen KMO’s enkele globale karakteristieken, onafhankelijk van de gehanteerde definitie.
1.2. Eigenschappen KMO’s Het is belangrijk om te begrijpen dat een KMO geen groot bedrijf in het klein is. Een KMO is immers fundamenteel verschillend van een multinational en vraagt bijgevolg ook een eigen unieke aanpak (Delmotte, Sels et al. 2001). In het kader van dit thesisonderwerp is het dus zeer belangrijk om deze verschillen te achterhalen en te begrijpen. Bijzondere aandacht zal hierbij geschonken worden aan de verschillen met betrekking tot de implementatie en het gebruik van informatietechnologie (IT). Literatuur onderscheidt zes karakteristieken die de adoptie van IT binnen KMO’s beïnvloeden (Bernaert, Poels et al. 2013):
1. KMO’s zijn gekenmerkt door een pragmatische, hands-‐on en no nonsens stijl van ondernemen. Hierbij worden inspanningen omtrent het strategisch nadenken over bijvoorbeeld process management of kwaliteits-‐ en procesoptimalisatie vaak achterop gesteld ten opzichte van de dagdagelijkse bedrijfsvoering.
2. KMO’s hebben doorgaans beperkte technische kennis en kennis met betrekking tot IT in house (Lybaert 1998). De hoofdreden voor het falen van het gebruik van IT in Europese KMO’s is net dat gebrek aan kennis.
3. KMO’s hebben significant minder middelen ter beschikken omwille van verscheidene redenen. Ze opereren doorgaans in zeer competitieve omgevingen, ze ondervinden regelmatig moeilijkheden in hun zoektocht naar financiering, ze hebben vaak gebrek aan in-‐house kennis en ze zijn sterk gevoelig aan veranderingen van buitenaf. De regel geldt doorgaans, des te kleiner het bedrijf, des te minder middelen men heeft om externe experten (IT experten) in te huren.
4. Gerelateerd aan het feit dat men overrompeld wordt met de dagdagelijkse bedrijfsvoering, heeft het management meestal niet de tijd om een stap terug te zetten en het geheel te bekijken. Vandaar dat er een grote vraag is naar kennis met betrekking tot de productiviteit van taken en hoe de dingen nu worden uitgevoerd.
5. Gezien de beperkte grootte van KMO’s, is de CEO of het management meestal in staat om het bedrijf als een geheel te leiden. De CEO speelt de hoofdrol in het bepalen van de strategische richting die het bedrijf uitgaat en zijn overtuigingen en capaciteiten hebben
4
een enorme invloed op de werking en verandering van de KMO (Devos, Van Landeghem et al. 2012). Het is dus belangrijk om deze centrale rol te begrijpen.
6. Het zesde kenmerk is verbonden met de centraliteit van de CEO. De keuze voor de adoptie van een nieuwe werkwijze wordt in KMO’s meestal genomen door de CEO. Gezien de onzekerheid, zullen de verwachte opbrengsten van een nieuwe werkwijze de verwachte kosten en tijd moeten overstijgen om tot adoptie te kunnen overgaan. Het is belangrijk om met deze eigenschappen rekening te houden bij het uitbouwen van een informatiesysteem voor KMO’s. Door ze expliciet op te nemen bij de ontwikkeling van een enterprise architectuur model, methodiek en tool voor KMO’s, kan de toegevoegde waarde voor deze doelgroep gemaximaliseerd worden.
1.3. Het belang van KMO’s Volgens Günter Verheugen vormen de middelgrote, kleine en micro-‐ondernemingen (KMO’s) de motor van de Europese economie. Ze zijn een essentiële bron van werkgelegenheid, creëren innovatie en ondernemingszin en zijn een cruciale drijfveer voor het concurrentievermogen van de Europese Unie. Circa 23 miljoen KMO’s verschaffen ongeveer 75 miljoen banen en vertegenwoordigen hiermee maar liefst 99 procent van alle ondernemingen in de Europese lidstaten (European Commission 2006). Door in 2008 de Small Business Act door te voeren, plaatst Europa KMO’s bovendien ook centraal in hun politieke en sociaal-‐economische beleid. Dit strategische kader houdt in dat bij het uitstippelen van de Europese beleidslijnen, de commissie het “Think small first” principe toepast met als doelstelling de groei en de competitiviteit van KMO’s te verduurzamen (European Commission 2008). Ook in de Verenigde Staten is het belang en de impact van KMO’s moeilijk te overschatten. Wat betreft jobcreatie, zijn KMO’s verantwoordelijk voor twee op drie nieuw gecreëerde jobs per jaar. Ook hebben ze een significante invloed op het innovatie-‐ en concurrentievermogen van deze economische grootmacht. Zo vertegenwoordigden in 2002 KMO’s maar liefst 40 procent van de zeer innovatieve ondernemingen in de Verenigde Staten (CHI Research Inc. 2004). Als we kijken naar België, zien we opnieuw gelijkaardige resultaten. België wordt vaak bestempeld als een KMO-‐land en volgens een studie van de Tijd is dit zeker niet onterecht (Vervenne 2010). Belgische KMO’s staan in voor 58 procent van de toegevoegde waarde en vertegenwoordigen maar liefst 99,8 procent van alle ondernemingen. Bovendien stijgt hun aandeel in de totale economische activiteit en de werkgelegenheid jaar na jaar. Onderstaande figuur levert bewijs voor de economische dominantie van KMO’s binnen de Belgische economie.
5
Afbeelding 2: economisch belang KMO's (Vervenne 2010)
2. Enterprise architectuur 2.1. Wat is enterprise architectuur? Als u van plan bent een huis te bouwen, zult u hoogstwaarschijnlijk een architect aanspreken en samen met hem uw wensen en verlangens bespreken. Het is aan de architect om dit vervolgens te gaan vertalen in technische specificaties en plannen waarmee hij de afstemming tussen uw vereisten en de werkelijke uitbouw van de woning beter kan beheersen en communiceren. Bij de opbouw van een bedrijf kan een analoog proces onderscheiden worden en dit noemt men enterprise architectuur. Om dit concept verder te verduidelijken, grijpen we terug naar de basis van enterprise architectuur en bestuderen we kort de definitie van een architectuur zoals geformuleerd door Lankhorst (Lankhorst 2009): ‘Architecture is the fundamental organisation of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.’ De definitie benadrukt dat architectuur zowel betrekking heeft op de principes die nodig zijn om de architectuur op te stellen en aan te passen alsook op het uiteindelijke eindresultaat, namelijk een blauwdruk van het systeem en zijn omgeving zelf.
6
In het geval van enterprise architectuur neemt het systeem de vorm aan van een onderneming bestaande uit een verzameling van mensen, activa, kennis, processen, projecten, competenties en veel meer, samengebracht voor het realiseren van gemeenschappelijke doelstellingen. Lankhorst definieert enterprise architecture als (Lankhorst 2009): ‘Enterprise architecture (EA) is a coherent whole of principles, methods, and models that are used in the design and realisation of an enterprise’s organisational structure, business processes, information systems, and infrastructure.’ Uit deze definite blijkt opnieuw duidelijk dat een enterprise architectuur meer is dan een techniek voor organisatorisch ontwerp. Het is een samenhangend geheel van beginselen, methoden en modellen. De meeste bestaande EA technieken bestaan uit drie verschillende lagen van architecturale modellen: een business architectuur laag, een applicatie architectuur laag en een technologie architectuur laag (zie afbeelding 3).
Afbeelding 3: de drie lagen van een traditionele EA techniek
Aangezien enterprise architecturen oorspronkelijk hoofdzakelijk door informatici werden opgesteld, lag de focus initieel voornamelijk op het afstemmen op elkaar van IT en de business. Het concept is echter in de loop der jaren veel breder geworden en men gaat EA tegenwoordig over de grenzen van IT heen gaan toepassen. Zo wordt EA bijvoorbeeld ook gebruikt voor het afstemmen van de operaties met de strategie van de onderneming. Bernaert stelt deze trend plastisch voor door middel van een omgekeerde piramide waarbij de focus voornamelijk op de business laag komt te liggen (zie afbeelding 4).
7
Afbeelding 4: omgekeerde piramide met focus op de business
Een enterprise architectuur techniek bevat doorgaans volgende onderdelen (Lankhorst 2009): •
een proces of methode voor het creëren van de verschillende architecturen inclusief richtlijnen, technieken en best practices.
•
een verzameling viewpoints: de informatie vervat in een architectuur kan bekeken worden vanuit het standpunt van verschillende stakeholders. Voor elk van deze partijen zijn andere data relevant, dus is het belangrijk een inzicht te hebben in deze verschillende belangengroepen.
•
een taal, inclusief notatie om de architectuur te beschrijven, gebaseerd op een metamodel.
•
een opslagplaats waar de ontwikkelde architecturen eenvoudig kunnen opgeslagen en opgehaald worden.
2.2. Voordelen van enterprise architectuur Er zijn veel voordelen verbonden aan het uitbouwen van een enterprise architectuur. Lankhorst geeft in zijn boek ‘Enterprise Architecture at Work’ een opsomming van de belangrijkste voordelen (Lankhorst 2009): •
Door het uitbouwen van een architectuur die de belangen van alle stakeholders in overweging neemt, verkrijgt de onderneming een algemene architectuur die door iedereen aanvaard en gebruikt wordt.
•
Doordat een architectuur modulair is opgebouwd met behulp van viewpoints, worden overbodige details en irrelevante data weg gefilterd voor de eindgebruiker. Dit komt de efficiëntie van de analyse ten goede.
8
•
Bij het implementeren van veranderingen, kunnen de gewenste wijzigingen eerst op de architectuur worden toegepast om de impact ervan te zien op het bedrijf. Op deze manier fungeert de architectuur als een testomgeving en kan men tot waardevolle inzichten komen.
•
De architectuur kan gebruikt worden om de huidige manier van werken te bestuderen. Door het overzicht van alle elementen en hun onderlinge relaties te analyseren kan men de huidige bedrijfsvoering optimaliseren.
•
Door het uitbouwen van een business architectuur, als onderdeel van een enterprise architectuur, krijgt men een goed overzicht van de huidige business processen. Deze inzichten kunnen gebruikt worden voor de selectie van het best passende informatiesysteem voor de onderneming (bv. ERP, CRM, etc.).
Naast deze algemene voordelen zijn er nog andere voordelen afhankelijk van en gerelateerd aan de onderneming waarin ze worden toegepast. Zo zal er in hoofdstuk 3 ingegaan worden op de voordelen die EA kan bieden voor kleine en middelgrote ondernemingen gelinkt aan de specifieke karakteristieken van KMO’s en de uitdagingen waarmee ze geconfronteerd worden.
2.3. Criteria voor enterprise architectuur technieken Bernaert stelt vijf duidelijk afgelijnde criteria voorop waaraan een kwaliteitsvolle enterprise architectuur (EA) techniek moet voldoen, afgeleid van Lankhorsts definitie en beschrijving van EA (Lankhorst 2009; Bernaert, Poels et al. 2013): 1. controle: EA speelt een cruciale rol in het beheersen van de complexiteit van een bedrijf en al haar processen en systemen. 2. holistisch overzicht: De belangrijkste eigenschap van een EA is dat het een holistisch overzicht verschaft van de onderneming. EA focust bijgevolg op de fundamenten van de onderneming omdat deze stabieler en minder vergankelijk zijn dan tijds-‐ en plaats-‐ afhankelijke oplossingen voor specifieke problemen waarmee het bedrijf geconfronteerd wordt. 3. objectieven: EA helpt bij het vertalen van de ondernemingsstrategie naar de dagdagelijkse bedrijfsvoering. Het is belangrijk dat de strategie op het hoogste niveau vertaald wordt naar begrijpbare doelstellingen voor werknemers op het laagste niveau, opdat de strategie uitgewerkt zou kunnen worden.
9
4. aangepast aan de doelgroep: De EA moet zo zijn opgebouwd dat ze door iedereen die er bij betrokken is begrepen wordt. 5. enterprise scope: Deze aanpak laat toe om de onderneming in zijn geheel te optimaliseren in plaats van lokaal verbeteringen door te voeren. Bernaert ontdekte dat er weinig tot geen EA technieken beschikbaar zijn die aangepast zijn aan de karakteristieken en eigenschappen van KMO’s waardoor er aan criterium 4 niet voldaan wordt. Gezien er duidelijke verschillen bestaan tussen KMO’s en grotere ondernemingen (Devos, Van Landeghem et al. 2012), lijkt het opportuun om deze tekortkoming van het huidige aanbod aan EA technieken te onderzoeken. In het volgende hoofdstuk wordt hier verder op in gegaan.
3. Enterprise architectuur voor KMO’s Een gevolg van de zeer competitieve omgeving waarin de meeste KMO’s actief zijn, is dat ze vaak niet de tijd nemen om strategisch na te denken over de toekomstige planning en richting van de onderneming. Ze worden gedwongen om zich te focussen op de dagelijkse activiteiten en verliezen hierdoor frequent het zicht op de strategische ‘big picture’. Dit leidt vaak tot een verlaagd competitief voordeel omwille van slecht gefundeerde beslissingen en een inferieure organisatie en planning binnen het bedrijf (Hudson Smith and Smith 2007). Onderstaande figuur geeft een overzicht van de overlevingsgraad van KMO’s in de Verenigde staten (Bernaert, Poels et al. 2013).
Afbeelding 5: tijdsverloop overlevingsgraad KMO's
Per vier KMO’s die starten, is er slechts één in staat om na vijftien jaar nog operationeel te zijn. Voor het falen van KMO’s bestaan er verschillende redenen, maar in vele gevallen is het gebrek
10
aan structuur en overzicht een doorslaggevende factor (Bernaert, Poels et al. 2013). Centraal in een KMO staat de CEO die vaak alle benodigde kennis bezit voor het uitstippelen van de strategische richting die het bedrijf wenst uit te gaan. Naarmate de KMO in grootte toeneemt, stijgt die hoeveelheid kennis echter en is het niet onvermijdelijk dat het overzicht hierdoor verloren gaat. Het spreekt voor zich dat dit nefaste gevolgen heeft voor de algemene werking van het bedrijf. Bij een dergelijk gebrek aan structuur en overzicht ontstaan er problemen met betrekking tot onder meer communicatie, flexibiliteit, overgang van leiding binnen de KMO en het balanceren van conflicterende doelstellingen. Enterprise architectuur kan helpen om een passend antwoord te formuleren op bovenstaande uitdagingen. Lybaert ontdekte in een onderzoek dat eigenaars (management) van KMO’s met een hoger strategisch bewustzijn doorgaans ook meer informatie gebruiken. Datzelfde onderzoek toonde bovendien aan dat KMO’s die meer informatie gebruiken ook betere resultaten boekten in het verleden en positiever ingesteld waren naar de toekomst toe (Lybaert 1998). Hieruit concludeerde men dat er een duidelijke relatie bestaat tussen het gebruik van informatie en het succes van een KMO. Hannon en Atherton onderscheiden in hun onderzoek vier types CEO’s/managers van KMO’s (Hudson Smith and Smith 2007). Ze gebruiken hiervoor twee criteria namelijk een hoge of lage graad van strategisch bewustzijn enerzijds en planning capaciteiten anderzijds. Hun onderzoek wijst uit dat variatie in beide dimensies een significant effect heeft op het succes van de KMO. In het bijzonder, hoe hoger het strategisch bewustzijn en hoe hoger de planning capaciteiten van het bedrijf, des te groter de kans op succes. Bijgevolg wordt ook hier een verband vastgesteld tussen succes en hogere niveaus van strategisch bewustzijn en planning. Onderzoek wijst ook uit dat bedrijven die naast financiële ook strategische business plannen opstellen, financieel beter presteren dan deze die dat niet doen (Hudson Smith and Smith 2007). EA heeft als finale doelstelling de creatie van een consistent en coherent organisatorisch ontwerp van de onderneming, waarin het behoud van een holistisch overzicht en strategisch bewustzijn onontbeerlijk zijn. We kunnen hieruit besluiten dat bovenstaande studies de stelling dat EA een echte meerwaarde kan betekenen voor KMO’s bevestigen. Een KMO is echter verschillend van een groot bedrijf en vraagt dus een eigen unieke aanpak. De ontwikkeling van een EA techniek aangepast aan de specifieke karakteristieken van KMO’s kan bijgevolg een grote toegevoegde waarde leveren voor deze doelgroep. De volgende paragraaf beschrijft de eerste stap in de richting van de ontwikkeling van een dergelijke techniek.
11
3.1. Criteria EA voor KMO’s Criterium 4 van een kwaliteitsvolle EA techniek (zie hoofdstuk 2.3) stelt dat een EA techniek aangepast moet zijn aan de doelgroep waarvoor het werd ontworpen. Deze thesis bouwt verder op het onderzoek naar de ontwikkeling van zo’n EA techniek voor KMO’s omwille van twee duidelijke redenen. Enerzijds omdat het belang van KMO’s in de huidige economie niet kan worden overschat. Anderzijds omdat deze doelgroep vaak over het hoofd wordt gezien door de EA technieken die momenteel op de markt beschikbaar zijn. Een KMO is immers fundamenteel verschillend van een multinational en vraagt bijgevolg ook een eigen unieke aanpak. Om hieraan te kunnen voldoen, is er uitgebreid onderzoek gedaan naar de eigenschappen en karakteristieken van KMO’s (Devos, Van Landeghem et al. 2012). Dit heeft geleid tot zes criteria voor EA in een KMO context, die gezien kunnen worden als subcriteria voor criterium 4 van een kwaliteitsvolle EA tehniek (Bernaert, Poels et al. 2013): 4.1 De ontwikkelde EA techniek moet KMO’s in staat stellen om tijdsefficiënt te werken aan strategische problemen en uitdagingen. 4.2 Een persoon met beperkte IT-‐vaardigheden moet in staat zijn te werken met de ontwikkelde EA techniek. 4.3 Weinig tot geen hulp van externe experten moet vereist zijn voor het werken met de ontwikkelde EA techniek. 4.4 De ontwikkelde EA techniek moet het bedrijf in staat stellen om een duidelijke omschrijving te maken van hoe de dingen op de huidige manier worden gedaan. 4.5 De CEO, als spilfiguur, moet betrokken worden bij de uitwerking van de EA. 4.6 De verwachte opbrengsten moeten de verwachte kosten en risico’s overtreffen. Deze richtlijnen in combinatie met de richtlijnen voor EA technieken (hoofdstuk 2.3) vormen de basis voor de ontwikkeling van deze nieuwe EA techniek voor KMO’s. Naast deze intrinsieke karakteristieken dient men bij de ontwikkeling van de EA ook rekening te houden met de adoptie van de nieuwe techniek door KMO’s. Hiervoor zal er een beroep worden gedaan op de adoptiemodellen besproken in het volgende hoofdstuk. Op basis van deze modellen, zullen er richtlijnen worden afgeleid ter optimalisatie van de adoptie van de EA techniek. Deze kunnen worden gezien als subcriteria voor criterium 4.6. Het is echter belangrijk om ervan bewust te zijn dat deze richtlijnen breder toepasbaar zijn en niet enkel dienst doen als specificatie van criterium 4.6.
12
3.2. Adoptie modellen Ondanks de ontwikkeling van een EA techniek waarvan de intrinsieke karakteristieken afgelijnd zijn met de eerder besproken eigenschappen van KMO’s, is het belangrijk om de feitelijke adoptie te meten om het uiteindelijke succes van de ontwikkelde EA techniek te bepalen. Zelfs al blijkt de aanpak technisch superieur te zijn of perfect afgestemd op KMO’s, zolang ze het niet effectief gebruiken, zullen de voordelen nooit gerealiseerd worden. Het is bijgevolg belangrijk om de adoptie door KMO’s zo vlot mogelijk te laten verlopen en hiervoor kan er een beroep worden gedaan op verschillende modellen die de adoptie van IS en IS-‐methoden verklaren. Het technology acceptance model (TAM) is uitermate bekend en wordt courant gebruikt (Davis 1989). Het method evaluation model (MEM) is een uitbreiding van TAM voor de evaluatie van methodes en kan bijgevolg waardevolle inzichten verschaffen bij de analyse van de adoptie van CHOOSE (Moody 2003). Beide modellen zullen vervolgens beknopt worden besproken. Op basis van deze bevindingen zullen er richtlijnen worden afgeleid voor de ontwikkelde EA techniek met als doelstelling de adoptie te optimaliseren.
3.2.1. Technology acceptance model (TAM) Het technology acceptance model (TAM) werd geïntroduceerd door Davis als een toepassing van de theory of reasoned action op de aanvaarding en adoptie van informatiesystemen (IS), zoals EA. De doelstelling van TAM is om een model te voorzien op basis waarvan de impact van externe factoren kan worden nagegaan op de overtuigingen, attitudes en gedrag met betrekking tot de adoptie van IS en IS methoden (Davis 1989). Onderstaande figuur geeft een schematische voorstelling van dit model.
Afbeelding 6: technology acceptance model (Davis, Bagozzi et al. 1989)
Centraal in dit model staan perceived usefulness en perceived ease of use. De overtuiging van de eindgebruiker dat het IS hem/haar zal helpen in het beter uitvoeren van zijn/haar job, heeft betrekking op perceived usefulness.
13
Perceived ease of use heeft daarentegen betrekking op de inspanning die de eindgebruiker moet leveren om met het IS te werken. Beide zaken beïnvloeden de attitude van de eindgebruiker ten opzichte van het informatiesysteem wat op zijn beurt een belangrijke determinant is voor de intention to use. Belangrijk hierbij is dat het voor de adoptie van het systeem noodzakelijk is dat de toename in performantie als groter wordt ervaren door de eindgebruiker dan de inspanning die hij/zij dient te leveren om met het systeem te (leren) werken. Desalniettemin is de perceived usefulness de belangrijkste determinant en verklaart het rechtstreeks meer dan de helft van de variatie in de intention to use (Davis, Bagozzi et al. 1989). Praktisch betekent dit dat wanneer de eindgebruiker de waarde inziet van een IS, hij/zij bereid zal zijn om een inspanning te leveren om er mee te leren werken. In tegenstelling hiermee, zal een zeer gebruiksvriendelijk informatiesysteem niet gebruikt worden als het voor de eindgebruiker geen meerwaarde betekent voor de productiviteit van zijn/haar job. Beide concepten hebben betrekking op een louter subjectieve overtuiging van de eindgebruiker en staan bijgevolg volledig los van de werkelijke toegevoegde waarde en vereiste inspanning van een dergelijk IS. Davis heeft beide determinanten verder uitgewerkt en is zo gekomen tot twee schalen bestaande uit zes elementen die deze twee concepten meer in detail beschrijven en verklaren: perceived usefulness: de mate waarin het IS de eingebruiker in staat stelt om... 1. sneller te werken. 2. job performantie te verhogen. 3. productiviteit te verhogen. 4. effectiviteit te verhogen. 5. de taken die deel uitmaken van de job makkelijker te maken. 6. bruikbare/waardevolle zaken te doen. perceived ease of use: de mate waarin het IS door de eindgebruiker ervaren wordt als... 1. makkelijk aan te leren. 2. controleerbaar (het laten doen wat je wil dat het doet). 3. duidelijk en verstaanbaar. 4. flexibel in de omgang. 5. makkelijk om je werkvaardigheid op te krikken. 6. makkelijk in gebruik.
14
3.2.2. Method evaluation model Moody heeft het method evaluation model (MEM) ontwikkeld als reactie op het feit dat de literatuur rond IS zich vooral focuste op de ontwikkeling van nieuwe methodes en niet zozeer op de evaluatie van bestaande methodes (Moody 2003). MEM is een combinatie van enerzijds het eerder besproken TAM en anderzijds methodologisch pragmatisme. Methodologisch pragmatisme werd bedacht door Rescher en gaat ervan uit dat er twee soorten kennis zijn (Rescher 1977): •
propositional knowledge: beweringen en verklaringen over de werkelijkheid.
•
methodological knowledge: beschrijvingen hoe je bepaalde zaken moet doen.
De eerste vorm van kennis vormt al jaren de focus van wetenschappelijk onderzoek en heeft betrekking op het bewijzen of weerleggen van bepaalde stellingen of hypothesen. Bij het onderzoeken van methodologische kennis kan men de methode niet zomaar bestempelen als juist of fout. Methodes hebben bijgevolg geen ‘truth value’ maar wel ‘pragmatic value’ in die zin dat een methode enkel kan bestempeld worden als werkzaam of niet werkzaam (efficacy). De validiteit van een methode kan bijgevolg noch inductief noch deductief worden afgeleid maar dient te worden bewezen door het succesvol toepassen van de methode in de praktijk. Dit wordt het pragmatisch succes van een methode genoemd en gedefinieerd als de efficiëntie en effectiviteit waarmee een methode de vooropgestelde objectieven verwezenlijkt. Een methode heeft bijgevolg een dubbele doelstelling (zie onderstaande figuur): •
efficiëntie verhogen: reductie van de inspanning vereist om de taak te voltooien.
•
effectiviteit verhogen: verhogen van de kwaliteit en de toegevoegde waarde van de output.
Afbeelding 7: efficiëntie vs. effectiviteit (Moody 2003)
15
Onderstaande figuur geeft een schematische weergave van het method evaluation model, een theoretisch model voor de evaluatie van methoden. Het verschil met TAM is de incorporatie van de concepten actual efficiency en actual effectiveness afkomstig van het methodologisch pragmatisme.
Afbeelding 8: method evaluation model (Moody 2003)
Bij het bestuderen van de figuur kan men opmerken dat beide concepten enkel de intention to use op een onrechtstreekse manier beïnvloeden via de perceived ease of use en usefulness. Het verschil is subtiel maar desalniettemin zeer belangrijk. Het impliceert dat bij de verklaring van het menselijk gedrag de subjectieve realiteit vaak belangrijker is dan de objectieve realiteit en perceived efficacy bijgevolg de impact van actual efficacy op adoptie in de praktijk medieert (Bernaert, Poels et al. 2013). Een ander verschilpunt is de mate van belangrijkheid van de variabele ease of use. In TAM is deze variabele van ondergeschikt belang ten opzichte van de usefulness. In dit model benadrukt men het belang van een makkelijk te gebruiken EA techniek voor de adoptie in de praktijk door de rechtstreekse relatie tussen deze variabele en de intention to use. Beide criteria verdienen volgens Moody gelijke aandacht want ze moeten beiden voorkomen om van een succes te kunnen spreken. Zo zal een zeer doeltreffende methode die moeilijk te gebruiken is in de praktijk evenmin bijdragen tot succes als een ondoeltreffende methode die wel makkelijk is in gebruik.
16
3.2.3. Richtlijnen voor de adoptie Gebaseerd op bovenstaande modellen kunnen een aantal richtlijnen worden opgesteld om de adoptie van de ontwikkelde EA te optimaliseren. 1. Actual efficacy verhogen Aan de basis van de percepties van de eindgebruiker ligt de werkelijke performantie van de EA. Het is bijgevolg belangrijk om door middel van onderzoek in de literatuur en door casestudies te achterhalen hoe de efficiëntie en effectiviteit van de ontwikkelde EA te maximaliseren 2. Perceived efficacy verhogen Zoals reeds vermeld is niet de objectieve realiteit maar wel de subjectieve realiteit van doorslaggevend belang bij het verklaren van de graad van adoptie. Het is bijgevolg belangrijk om dit verschil in het achterhoofd te houden. Door implementatie in de praktijk kan aan de hand van de twee schalen van het TAM de perceived usefulness en de perceived ease of use worden berekend (zie hoofdstuk 4 research scope). Mogelijke discrepanties tussen beide, dienen te worden onderzocht en de feedback kan gebruikt worden om de perceived efficacy verder te optimaliseren. In de ontwikkeling zal zowel aan de perveived usefulness als aan de perceived ease of use evenveel aandacht worden besteed omdat ze beiden belangrijk zijn voor het succes van de EA. 3. Van intention to use naar actual usage Het is belangrijk om in te zien dat er een verschil is tussen wat mensen beweren te doen en wat ze ook daadwerkelijk doen. Het kan bijgevolg opportuun zijn om te achterhalen welke factoren deze relatie beïnvloeden om te voorkomen dat eindgebruikers met een positieve intention to use niet overgaan tot werkelijke adoptie van de ontwikkelde EA. Bovendien zal de werkelijke toepassing in de praktijk waardevolle inzichten opleveren met betrekking tot de eerste twee richtlijnen. Indien dit niet gebeurt, zal er nooit worden overgegaan van actual naar perceived efficacy en kan een mogelijke discrepantie tussen beide concepten niet worden achterhaald en weggewerkt door een fundamenteel gebrek aan user feedback.
17
3.3. Evaluatiemodel EA voor KMO’s Op basis van bovenstaande literatuurstudie kunnen alle criteria en richtlijnen samen gegoten worden in één overkoepelend model die ondersteuning en hulp kan bieden bij de ontwikkeling en uitwerking van een enterprise architectuur model en methode voor kleine en middelgrote ondernemingen.
Afbeelding 9: evaluatiemodel EA techniek voor KMO's
Aan de basis van dit model liggen de vijf criteria voor een kwaliteitsvolle EA techniek besproken in hoofdstuk 2.3. Criterium 4 stelt dat de EA techniek aangepast moet worden aan de specifieke eigenschappen en karakteristieken van de doelgroep. In het geval van deze thesis betreft het dus de doelgroep kleine en middelgrote ondernemingen. Hiervoor doen we een beroep op de zes criteria besproken in hoofdstuk 3.1 die als sub criteria kunnen worden beschouwd van criterium 4. Bovendien kunnen voor de realisatie van criterium 4.6 de richtlijnen van de adoptiemodellen gebruikt worden want enkel als de verwachte opbrengsten de verwachte kosten en risico’s overtreffen, zal een KMO de techniek willen toepassen. Bij het respecteren van deze elf duidelijk omschreven criteria, zou de nieuw ontwikkelde EA de actual efficacy voor de doelgroep moeten verhogen. Op basis van bovenstaande criteria werd door Bernaert CHOOSE ontwikkeld. In het volgende hoofdstuk zal er een beknopt overzicht worden gegeven CHOOSE en het onderliggende metamodel.
18
3.4. CHOOSE CHOOSE is een acroniem voor ‘keep Control, by means of a Holistic Overview, based on Objectives and kept Simple, of your Enterprise’. De aandachtige lezer heeft reeds opgemerkt dat elke letter in de naam verwijst naar één van de vijf voorgestelde criteria voor EA technieken (zie afbeelding 9). CHOOSE is een EA aanpak voor KMO’s afgeleid uit de kernelementen van bestaande EA technieken en gebaseerd op Einsteins principe: “Everything should be made as simple as possible, but not simpler” (Bernaert, Poels et al. 2013). Gegeven het profiel van KMO’s, vat dit citaat zeer krachtig samen wat de ontwikkelde techniek zou moeten bewerkstelligen. Het moet zo eenvoudig zijn dat het door KMO’s begrepen en gebruikt kan worden maar het moet toch voldoende detail bevatten opdat de realiteit nog betrouwbaar kan worden weergegeven. Om dit te realiseren werd elk deel van het metamodel uitgebreid besproken met meerdere experten en getest aan de hand van verschillende casestudies. Dit om er voor te zorgen dat enerzijds alle overbodige details geëlimineerd zijn en anderzijds alle relevante aspecten opgenomen zijn. Een strategische dimensie (waarom), een actieve dimensie (wie), een operatie dimensie (hoe) en een object dimensie (wat) vormen de kerndimensies van CHOOSE. Geïntegreerd voorzien de dimensies de eindgebruiker van een holistisch overzicht van de business architectuur laag van het EA-‐model. Onderstaande figuur geeft een schematisch overzicht van deze dimensies en hun symbolische representatie.
Afbeelding 10: de vier geïntegreerde modellen van CHOOSE (Bernaert 2011)
Achtereenvolgens zullen de vier dimensies kort worden besproken. Daarnaast zal er een beknopt overzicht worden gegeven van de verschillende relaties die zorgen voor de integratie tot één overkoepelend model. Voor de bespreking van de vier dimensies en hun onderlinge relaties zal er gebruik worden gemaakt van een eenvoudig voorbeeld. Hierna zal het metamodel kort worden toegelicht. Ten slotte volgt er een korte reflectie over de relatie tussen de gevolgde aanpak en de vooropgestelde criteria.
19
3.4.1. Goal model: Know-‐Why Deze dimensie heeft als doel een volledig beeld te schetsen van de doelstellingen van een onderneming. Een doel is een beschrijving van een gewenste toestand waarin iets of iemand wil terecht komen in de toekomst, uitgedrukt in concreet te bereiken resultaten, die te meten zijn met de bijbehorende indicatoren of maatstaven. Het is belangrijk dat bij het opstellen van een doelenboom, er rekening wordt gehouden met zoveel mogelijk stakeholders. Dit draagt enerzijds bij tot de volledigheid van het model en anderzijds brengt het mogelijks conflicterende doelstellingen aan het licht. Inzicht in deze complexe structuur van doelen brengt kennis teweeg die kan helpen om de juiste balans te vinden tussen de verlangens van de verschillende stakeholders. Een onderneming kan bijvoorbeeld als doel hebben de verkopen van een bepaald product x te verhogen. Dit vormt een onderdeel van de doelstelling op een hoger niveau om de inkomsten op het ondernemingsniveau op te krikken. Voor het realiseren van deze specifieke doelstelling heeft men de keuze uit twee mogelijke strategieën. De eerste strategie bestaat erin om te investeren in de huidige afzetmarkt waarbij de distributie geoptimaliseerd zou worden zodat het product makkelijk beschikbaar is voor de huidige doelgroep. Dit zou gepaard gaan met marketing campagnes om het imago van de onderneming nieuw leven in te blazen. De andere strategie stelt voor om te investeren in nieuwe afzetmarkten. Indien de onderneming kiest voor een nieuwe afzetmarkt, zullen de producten dienen te worden aangepast aan de karakteristieken van de plaatselijke bevolking.
Afbeelding 11: voorbeeld goal model
20
De keuze tussen strategie een en twee noemt men een OR-‐refinement. Dit betekent dat niet alle onderliggende doelstellingen moeten worden gerealiseerd om het doel zelf te realiseren. Het volstaat dat ofwel strategie een of twee succesvol uitgevoerd wordt opdat de verkopen zouden stijgen. Strategie een op zich is een AND-‐refinement aangezien beide onderliggende doelstellingen dienen te worden behaald om van een succesvolle strategie een te kunnen spreken. Bovendien kunnen de doelstellingen om te investeren conflicteren met andere doelstellingen van de onderneming zoals bijvoorbeeld de reductie van het schuldsaldo van de onderneming. Het is uitermate belangrijk om als leidinggevende een inzicht te hebben in dergelijke trade-‐offs om beslissingen te nemen die een juiste balans garanderen tussen conflicterende doelstellingen.
3.4.2. Actor model: Know-‐Who De actor dimensie heeft, zoals de naam doet vermoeden, betrekking op actieve elementen. Actoren kunnen zowel fysieke als niet-‐fysieke instanties zijn. Een voorbeeld van een fysieke instantie is een werknemer of een klant. Een niet-‐fysieke actor is bijvoorbeeld een computersysteem of een robot in een assemblagelijn. In KMO’s wordt IT niet zozeer gezien als fundamenteel verschillend van de business en is er als het ware een samensmelting van IT en business (Bernaert and Poels 2013). Door systemen en applicaties (niet-‐fysieke instanties) in de architectuur te modelleren als actoren wordt er ingespeeld op die trend binnen KMO’s. Fysieke actoren hebben vaak ook een hiërarchische structuur. Zo kan Jan manager van Sales & Marketing baas zijn van Piet, een account manager, maar ondergeschikt aan Maaike, CEO van de onderneming.
Afbeelding 12: voorbeeld actor model
21
3.4.3. Operation model: Know-‐How De volgende dimensie is de operatie dimensie. Operaties kunnen zowel processen als projecten zijn. Een proces is een operatie die veelvuldig herhaald wordt in de dagelijkse bedrijfsvoering. Een project daarentegen is vaak eenmalig en grootschaliger. Een voorbeeld van een proces is bijvoorbeeld kwaliteitscontrole van producten. Een voorbeeld van een project kan het opzetten van een nieuwe productieafdeling zijn. Operaties kunnen ook hiërarchisch worden opgesplitst in onderliggende operaties. Zo kan een kwaliteitscontrole bestaan uit controle van de smaak, van het uitzicht, van de technische eigenschappen,... . Of het uitvoeren van een NPV-‐analyse uit het berekenen van de WACC en het schatten van de toekomstige cash flows.
Afbeelding 13: voorbeeld operatie model
3.4.1. Object model: Know-‐What Naast actieve elementen bevat een architectuur ook meestal passieve elementen en hiervoor doen we een beroep op de object dimensie. Passieve elementen worden in de literatuur ook vaak resources genoemd. Voorbeelden van objecten zijn producten en gereedschap. Objecten kunnen onderling ook met elkaar in verband staan. Zo kan een desktopcomputer die gebruikt wordt voor het berekenen van investeringsparameters in verbinding staan met een volledig ondernemingswijd netwerk waarop kennis onderling gedeeld wordt.
Afbeelding 14: voorbeeld object model
22
3.4.2. Relaties Naast de relaties binnen de dimensies zijn er ook relaties tussen de dimensies. Door de vier dimensies onderling te linken met behulp van dergelijke interdimensionele relaties worden ze geïntegreerd in één overkoepelend model. Mogelijke relaties tussen de dimensies zijn: •
goals en actoren: een relatie hier kan twee betekenissen hebben. Ofwel is de actor verantwoordelijk voor de realisatie van de doelstelling (assignment) ofwel is de actor de oorsprong van het ontstaan van de doelstelling en is het dus zijn wens dat die gerealiseerd wordt (wish). In het voorbeeld is Jan, de manager van Sales & Marketing, verantwoordelijk voor het realiseren van een verhoogde omzet voor product X terwijl Maaike, CEO, aan de oorsprong ligt van de doelstelling om de inkomsten op ondernemingsniveau te verhogen.
•
goals en operaties: een relatie hier betekent in de ene richting dat een operatie bijdraagt tot het realiseren van een bepaalde doelstelling. In de andere richting biedt het een motivatie waarom een bepaalde operatie wordt uitgevoerd (operationalisation). Zo kan een degelijke NPV-‐analyse uitwijzen of het de moeite loont om te investeren, in het achterhoofd houdende dat een conflicterend doel pleit voor een daling van het schuldsaldo van de onderneming.
•
goals en objecten: objecten kunnen nodig zijn voor het realiseren van een doelstelling of kunnen er het resultaat van zijn. Met andere woorden, de concern relatie legt een verband tussen een object en de doelstelling(en) waartoe het behoort. Zo kan een database met klantengegevens gebruikt worden om de impact van de marketing campagne te maximaliseren, gegeven het beschikbare budget, door de juiste doelgroep te targeten (klantensegmentatie).
•
actoren en operaties: in het oorspronkelijke metamodel was er slechts sprake van één soort relatie namelijk een actor die verantwoordelijk is voor het uitvoeren van een operatie (perform). Zowel de literatuur als de praktijk wijzen er op dat een uitbreiding van die relatie naar RACI (responsible, accountable, consulted, informed) een meerwaarde kan betekenen aangezien de zuivere ‘perform’ relatie te eng is en er op deze manier veel waardevolle informatie verloren gaat (lopend onderzoek Bernaert). Zoals reeds eerder gezegd, keep it simple but not too simple en dit laatste was helaas het geval hier. Zo kan Piet, account manager, aangesteld worden voor het uitvoeren van NPV-‐analyses. Desondanks dat Piet de operatie uitvoert, blijft Jan verantwoordelijk voor de berekeningen die Piet maakt. Dit is zeer waardevolle informatie en kan eenvoudig
23
weergegeven worden met behulp van een RACI grafiek (Smith, Erwin et al. 2007). Bijgevolg werd er geopteerd om de RACI relatie in het metamodel te incorporeren. •
actoren en objecten: een relatie hier betekent dat een bepaald object tot een bepaalde actor toebehoort (owns). Zo kan de database gelinkt zijn aan Piet omdat hij aangesteld is als eigenaar van de database en verantwoordelijk is voor het up-‐to-‐date houden van de data.
•
operaties en objecten: objecten kunnen zowel vereist zijn als input voor het uitvoeren van een bepaalde operatie of kunnen het resultaat zijn van die operatie onder de vorm van output. Voor het berekenen van de NPV van beide strategieën zal Piet een beroep doen op methodes op een computer die ervoor zorgen dat de berekeningen op de juiste manier worden uitgevoerd. De output van dergelijke operaties zijn financiële rapporten over de winstgevendheid van beide strategieën.
Afbeelding 15: integratie tot één overkoepelend model
24
3.4.3. Metamodel Op basis van bovenstaande informatie werd het metamodel opgesteld van de CHOOSE techniek (zie afbeelding 16). Op basis van dit metamodel zal er in hoofdstuk 3.1 van het research scope gedeelte een conceptueel datamodel worden opgesteld dat het fundament vormt voor de Access database die aan de basis ligt van de software tool ter ondersteuning van CHOOSE.
Afbeelding 16: metamodel CHOOSE
3.4.4. Reflectie vooropgestelde criteria Elk deel van het metamodel werd uitgebreid besproken met allerlei experten en getest aan de hand van casestudies (Bernaert, Poels et al. 2013). Dit draagt bij tot criteria 4.1 (slechts één symbool wordt gebruikt voor het modelleren van de strategie), 4.3(makkelijk aan te leren aanpak), 4.2 (de aanpak vergt weinig tot geen IT kennis maar business skills zijn onontbeerlijk), 4.6 (de verwachte kosten worden gereduceerd door het sterk stijgende verloop van de leercurve van de aanpak) en 4 (door de incorporatie van de eigenschappen van KMO’s, is de aanpak aangepast aan de doelgroep). Het metamodel bevat bovendien een strategische goal dimensie (criterium 3) die geïntegreerd wordt met de drie andere dimensies om op deze manier een holistisch overzicht (criterium 2) te verkrijgen van de onderneming in haar geheel (criterium 5). De aanpak laat toe om de processen in kaart te brengen maar ondersteunt geen procesbeschrijving om te voorkomen dat deze overbodige details het algemene overzicht (criterium 2, 4.4) in het gedrang brengen. Desalniettemin kan de beschrijving gebeuren met behulp van andere programma’s en gelinkt worden aan de verschillende processen binnen CHOOSE. Door de doelstellingen expliciet te linken aan de operaties, wordt een verhoogde strategic alignment bewerkstelligd (criterium 3). De aanpak laat bovendien toe dat de gebruiker
25
incrementeel de architectuur opstelt. Hierdoor kan de gebruiker het model aanvullen wanneer het voor hem/haar het beste past (criterium 4.1). Bovendien wordt de architectuur hierdoor stapsgewijs vollediger (criterium 2) en bijgevolg ook steeds waardevoller. Deze aanpak kan worden vergeleken met het alledaagse voorbeeld van het bijhouden van een agenda. Het gebeurt vaak dat informatie hieromtrent verspreid is over verschillende media. Zo staan er afspraken op de kalender thuis, verjaardagen staan dan weer op een aparte kalender terwijl meetings en business gerelateerde afspraken bijgehouden worden op een smartphone. Door het centraliseren van al deze gegevens in één agenda, kan er een veel beter overzicht worden verkregen en behouden. Hetzelfde principe is van toepassing op het EA proces en software tool support moet de onderneming hierin begeleiden. Tool support moet er voor zorgen dat de eindgebruiker ondersteund wordt bij het uitvoeren van taken met betrekking tot de implementatie, het managen en onderhouden van de EA (criteria 4.1 & 4.2). Daarnaast verhoogt de incorporatie van allerhande functionaliteiten (zoals change analysis en queries) de toegevoegde waarde van een dergelijke aanpak (criteria 1, 4.6 en 5). Het is net die tool support die de focus uitmaakt van deze thesis. In het volgende hoofdstuk zal beknopt het belang van tool support voor EA worden toegelicht vooraleer over te gaan tot de feitelijke uitwerking van de ontwikkelde software tool EASE.
26
4. Belang tool support Een fundament waarop dit thesisonderwerp wordt gebaseerd, is het belang van tool support ter ondersteuning van EA bij KMO’s. Hierbij kunnen twee duidelijke probleemstellingen worden onderscheiden. 1. Het belang van tool support voor de implementatie, het management en de analyse van EA in KMO’s. 2. Het belang van een nieuwe tool aangepast aan de specifieke karakteristieken van een KMO. Dit hoofdstuk zullen we bijgevolg aanvatten met een uiteenzetting over de probleemstelling of er al dan niet noodzaak is aan tool support bij het uitwerken en onderhouden van een EA binnen de omgeving van KMO’s. Hierbij zal er een beroep worden gedaan op zowel praktische kennis onder de vorm van casestudies als op academische bronnen. Eenmaal het belang van tool support is gerechtvaardigd, dient er dieper te worden ingegaan op het belang van de ontwikkeling van een nieuwe tool. Hierbij zullen we teruggrijpen naar de specifieke eigenschappen van een KMO en deze projecteren op de vereisten van een dergelijke nieuw ontwikkelde tool. Vergelijking van deze vereisten met de functionaliteiten en werking van de beschikbare tools, zal een antwoord verschaffen op de tweede probleemstelling.
4.1. Het belang van tool support In de literatuur onderscheidt men drie kritieke probleemgebieden in het enterprise architectuur proces: het modelleren, het managen en het onderhouden van enterprise architecturen (Kaisler, Armour et al. 2005). Een belangrijke oorzaak van problemen binnen deze gebieden is te wijten aan de doorgaans enorme complexiteit van een uitgewerkte EA (Ernst, Lankes et al. 2006). Het is immers zo dat enorm veel informatie onder de vorm van data en relaties dient te worden opgebouwd en opgeslagen. Deze informatie is bovendien vaak verspreid over meerdere personen. Daarnaast dient men bij de vertaling van deze kennis naar de architectuur gebruik te maken van de syntax en de semantiek van de gekozen modelleertaal. Hierbij dient aan elk kennisobject het juiste symbool te worden gekoppeld. Deze codering vergt veel energie en is bovendien vaak een broeiplaats van fouten. Uit het bovenstaande is bijgevolg duidelijk dat voor de ontwikkeling, opslag en analyse van een coherente en volledige architectuur een tool noodzakelijke ondersteuning kan bieden om deze moeilijke uitdaging tot een goed einde te brengen (Ernst, Lankes et al. 2006). In vele bedrijven dient men bovendien vaak een beroep te doen op methodes en technieken ontwikkeld voor een specifiek business domein, maar deze stellen de architect niet in staat om een ‘big picture’ te creëren. Aangezien
27
een belangrijke doelstelling van EA het verkrijgen van een holistisch beeld over de functionele grenzen van de organisatie heen is, betekent dit dat de beschikbare methoden te kort schieten. Dit ondersteunt opnieuw de visie van de nood aan geïntegreerde methodes en technieken voor de opbouw, analyse en communicatie van de EA naar de verschillende stakeholders (Jonkers, Lankhorst et al. 2006). Ook Lankhorst benadrukt in zijn boek ‘Enterprise Architecture at Work’ de voordelen van tool support voor EA (Lankhorst 2009): •
Een tool kan helpen bij het standaardiseren van de semantiek en de notatie gebruikt bij het opstellen van architecturale modellen binnen een onderneming. Indien het gebruik van de tool ondersteund wordt door degelijke training en opleiding, kan een ondernemingswijde implementatie van de tool een enorme bijdrage leveren voor het standaardiseren van de architecturale talen en praktijken die in de onderneming gebruikt worden.
•
Het gebruik van een tool draagt bij tot de constructie van correcte en consistente architecturen door middel van mistake proofing en ondersteuning bij het maken van de architectuur. De tool kan allerhande beperkingen opleggen die ervoor zorgen dat de gewenste praktijken en richtlijnen gerespecteerd worden. Dit draagt bij tot de algemene kwaliteit van het eindresultaat.
•
Tools kunnen de architect ondersteunen in het gebruik van architecturale patronen of het hergebruik van bepaalde delen van de architectuur of oplossingen die reeds voorhanden zijn binnen de onderneming.
•
Tools kunnen ook helpen bij het vergelijken van alternatieven. Zo kunnen twee architecturen naast elkaar worden opgebouwd, één van de huidige situatie en één van de gewenste situatie. Hierbij kan men voor de tweede architectuur vertrekken van de eerste en de veranderingen toepassen op de reeds bestaande architectuur. Tools helpen bovendien bij het uitvoeren van impact-‐of-‐change en kwantitatieve analyses.
Ondanks het feit dat bovengenoemd onderzoek het belang van tool support bevestigt, kunnen deze bevindingen niet zomaar geëxtrapoleerd worden naar de omgeving van KMO’s en het belang van tool support voor de implementatie van de CHOOSE techniek. Desalniettemin bevestigt het lopende casestudieonderzoek van Bernaert en Callaert de nood aan een software tool bij het uitbouwen van EA’s in KMO’s. In deze casestudies werd de CHOOSE methode toegepast in zes verschillende KMO’s door middel van eenvoudige whiteboards met post-‐its zoals in afbeelding 17. Tijdens één van deze gevalstudies werd deze methode aangevuld met
28
een eerste versie van EASE. Vergelijking van beide bevestigde duidelijk de toegevoegde waarde van het ter beschikking hebben van EASE ter ondersteuning van het EA proces.
Afbeelding 17: fractie EA artefact Belgische KMO
4.2. Het belang van een nieuwe tool De meeste van de op de markt beschikbare tools zijn gebaseerd op EA frameworks. Het Zachman framework is één van de bekendste en wordt vaak gebruikt als beschrijvend framework voor de categorisatie van EA artefacten (Zachman 1996; Zachman International 2011). Een ander bekend framework en tevens ook een methode, is het Open Group Architecture Framework (TOGAF). TOGAF kent een bredere toepassing dan Zachman en voorziet een uitgebreidere begeleiding voor de ontwikkeling van de EA . Beide bieden begeleiding op een hoog niveau van abstractie en helpen voornamelijk bij de beslissing welke business-‐ en technologische gebieden in de architectuur dienen te worden opgenomen. Ze bieden daarentegen weinig tot geen begeleiding voor de effectieve uitwerking en onderhoud van de EA zelf (Jonkers, Lankhorst et al. 2006). Daarnaast bestaan er tools die wel effectief helpen bij de uitwerking van de architectuur zelf. Een voorbeeld hiervan is Objectiver (Respect-‐ IT 2010; Objectiver 2013). Deze requirements engineering (RE) tool stelt de gebruiker ertoe in staat om zijn architectuur te tekenen op een canvas aan de hand van vooraf beschikbare symbolen die bepaalde constructen vertegenwoordigen. Deze software tool was echter niet ontwikkeld voor het modelleren van EA’s en is gebaseerd op het metamodel van KAOS, een goal-‐oriented RE approach. Om toepasbaar te zijn voor de CHOOSE methode zouden bijgevolg aanzienlijke aanpassingen moeten worden doorgevoerd. Daarnaast ligt de focus van deze en gelijkaardige tools niet op KMO’s waardoor er overbodige en potentieel verwarrende functionaliteiten zijn ingebouwd, terwijl er andere functionaliteiten die voor deze specifieke doelgroep waardevol kunnen zijn ontbreken omdat ze niet gewaardeerd worden door het bredere publiek.
29
Bovendien vertonen de beschikbare tools enkele algemene zwakten (Ernst, Lankes et al. 2006). •
Zo ondersteunen de meeste tools geen automatische visualisatie van data en wordt er bovendien weinig aandacht besteed aan de semantiek van de visualisatie. Beide zwakten zijn gelinkt aan het feit dat vele van de beschikbare tools eigenlijk tekentools zijn (vb. MS Visio), waarbij de gebruiker zelf de architectuur moet gaan tekenen op een canvas en de informatie onder deze vorm opgeslagen wordt. Echter, een verscheidenheid aan belangrijke functionaliteiten zoals het hergebruik van bepaalde delen van de architectuur wordt niet ondersteund door dergelijke tools (Braun and Winter 2005). De nieuwe tool zou zo ontwikkeld kunnen worden dat een antwoord wordt geboden aan dit gebrek aan visualisatievermogen van de beschikbare tools.
•
Een tweede zwakte heeft te maken met de onderliggende metamodellen van de tools. De meeste beschikbare tools worden aangeboden met een vooraf vastgelegd standaard metamodel. Aangezien ondernemingen sterk van elkaar verschillen, is het vaak nodig om dit standaard metamodel te gaan aanpassen aan de specifieke eisen en karakteristieken van de onderneming vooraleer de EA werkelijk kan worden uitgebouwd. Deze standaard metamodellen zijn ofwel te klein waardoor ze niet in staat zijn om de EA van de onderneming te ondersteunen ofwel zijn ze te groot waardoor het gebruiksgemak en de leesbaarheid van het model afneemt. De ontwikkeling van een nieuwe tool op basis van een metamodel aangepast aan de specifieke eisen en verlangens van KMO’s (CHOOSE) biedt bijgevolg een antwoord op dit probleem.
•
De meeste tools voorzien een bepaald metamodel, maar bieden geen methode aan op basis waarvan men de EA kan opbouwen. Door een gebrek aan methode loopt het bij bepaalde bedrijven mis, waardoor het metamodel verkeerdelijk gebruikt of geïnterpreteerd wordt. Door de tool op een bepaalde manier op te bouwen kan men de gebruiker een zekere volgorde van stappen opleggen, waardoor er naast een metamodel ook richtlijnen voor het gebruik en de toepassing ervan worden opgelegd.
Nu het belang van de ontwikkeling van een nieuwe software tool is aangetoond, kan er in het volgende deel overgegaan worden tot de feitelijke ontwikkeling van EASE.
30
Research scope: EASE
Dit deel van de thesis vormt de basistekst van het werkstuk en beschrijft de ontwikkeling van een software tool genaamd EASE ter ondersteuning en begeleiding van de implementatie, het management en de analyse van EA (CHOOSE) in KMO’s. EASE is een acroniem voor “Enterprise Architecture SME Environment”. In zijn meest abstracte vorm kan EASE worden gezien als een platform dat begeleiding biedt doorheen het volledige EA proces. EASE is ontwikkeld gebruik makende van MS Access als databasemanagementsysteem (DBMS) en Java als programmeertaal. In de rest van het thesisverslag zal er dieper worden ingegaan op de ontwikkeling en evaluatie van EASE. Om dit onderzoek te schetsen binnen het grotere geheel, kan het worden gepositioneerd in het Design Science Research (DSR) proces (Hevner, March et al. 2004; Peffers, Tuunanen et al. 2007), toegepast op de ontwikkeling van de CHOOSE techniek. Afbeelding 18 geeft een schematisch overzicht van dit proces.
Afbeelding 18: onderzoeksstappen
Op basis van criteria voor KMO’s en EA (stap 1: literatuurstudie) en de kennis opgebouwd doorheen de onderzoeksstappen een tot vier (Bernaert 2011; Bernaert, Poels et al. 2013), zullen er algemene design concepten afgeleid worden voor de ontwikkeling van EASE ter ondersteuning van de CHOOSE techniek (hoofdstuk 2). Deze vormen in de volgende stap de basis van het ontwikkelingsproces zelf (stap 5: hoofdstuk 3). In dit hoofdstuk zal er een uitgebreide uiteenzetting worden gegeven van EASE met aandacht voor de opbouw van de database, interface-‐ontwerpkeuzes en de functionaliteiten van EASE. Evaluatie van EASE door middel van casestudies zal vervolgens waardevolle inzichten verschaffen met betrekking tot de meerwaarde van EASE, de mate waarin EASE voldoet aan de vooropgestelde criteria en de
31
aanpassingen die dienen doorgevoerd te worden voor de verdere optimalisatie van de software tool (stap 6: hoofdstuk 4). De stappen aangeduid in het groen zijn reeds uitgevoerd in voorgaand onderzoek en vormen bijgevolg het vertrekpunt van deze thesis (research scope aangeduid in het blauw). Het ontwikkelingsproces start immers met het opstellen van een gefundeerde methodologie. Deze methodologie fungeert als een rode draad voor de uitwerking van het ontwikkelingsproces van EASE en wordt besproken in het volgende hoofdstuk.
32
1. Methodologie Het is belangrijk dat er bij de uitwerking van EASE een methodologie wordt gebruikt die een structuur afdwingt die de volledigheid en correctheid van het werkstuk bevordert. Duidelijke doelstellingen en een gefundeerde opbouw kunnen immers bijdragen tot de academische en praktische waarde van deze thesis. Hiervoor werd er een beroep gedaan op drie bestaande methodologische frameworks: •
Conceptual Framework for the Methodological Soundness of Requirements Engineering (RE) Papers (Wieringa and Heerkens 2006): Dit framework stelt een lijst van criteria voor op basis waarvan de methodologische opbouw van RE papers kan worden geëvalueerd. Het RE vakgebied vertoont affiniteit met het tool ontwikkelingsgedeelte van deze thesis. Bijgevolg kunnen hiervan waardevolle inzichten worden afgeleid.
•
Design Science Research Methodology for Information Systems Research (Hevner, March et al. 2004; Peffers, Tuunanen et al. 2007): Dit framework stelt een methodologie voor op basis waarvan design science onderzoek binnen het informatietechnologie vakgebied kan worden gedaan. Design science (DS) heeft betrekking op de wetenschappelijke studie van het ontwerp van een artefact en heeft als doel het ontwerpen van artefacten (bv. concepten, modellen, methodes of instanties hiervan) die wetenschappelijke kennis bevatten over problemen en hun oplossingen. EASE kan gezien worden als een instantie van een methode, die in het geval van een modelleermethode gebaseerd is op een onderliggend metamodel en concepten, door middel waarvan men een methode kan evalueren (March and Smith 1995). Bijgevolg kan er bij de uitbouw van dit onderzoek rekening worden gehouden met de richtlijnen voorgesteld door dit framework.
•
Software Proces Modellen (Boehm 1988; Sommerville 1996): Het zwaartepunt van deze thesis betreft de ontwikkeling van een nieuwe tool als softwareondersteuning voor EA in KMO’s. Om deze programmeeruitdaging op een gefundeerde manier te lijf te gaan, zal er een beroep worden gedaan op een vergelijking van de belangrijkste software proces modellen door Sommerville.
Achtereenvolgens zullen bovenstaande theorieën meer in detail worden besproken. Consolidatie van de waardevolle elementen zal leiden tot de ontwikkeling van een eigen gefundeerde methodologie voor de uitwerking van deze thesis.
33
1.1. Conceptueel framework methodologische correctheid RE papers Wieringa (Wieringa and Heerkens 2006) heeft een conceptueel framework ontwikkeld dat een onderscheid maakt tussen design papers en research papers. Voor elk van beide categorieën werd een structuur en een lijst van criteria ontwikkeld op basis waarvan de methodologische onderbouw van een paper kan opgesteld of geanalyseerd worden. Dit framework kwam er nadat Wieringa ontdekte dat veel requirements engineering papers methodologisch slecht gefundeerd waren en dat er systematisch belangrijke elementen ontbraken. Tevens was er veel verwarring met betrekking tot de grondslag van de papers en dit heeft geleid tot de definitie van de volgende twee categorieën die belangrijk zijn bij het uitstippelen van de te volgen werkwijze: •
knowledge problems: Dit soort problemen vindt zijn oorsprong in een gebrek aan kennis over de wereld en om hiervoor een oplossing te vinden, moeten we onze kennis uitbreiden. Zo zal men bij een studie van het menselijke gedrag in een onderneming louter observeren en niet interageren met de omgeving. Het enige criterium op basis waarvan de oplossing van een kennis probleem wordt geëvalueerd, is de validiteit van de oplossing. Alle knowledge problemen zijn research problemen (research papers).
•
world problems: Dit soort problemen vindt zijn oorsprong in het verschil tussen hoe de wereld werkelijk is en hoe wij denken dat de wereld zou moeten zijn. Dit soort problemen zal men doorgaans oplossen door te proberen de wereld om ons heen te veranderen. Zo zullen er bij een gebrek aan communicatie in een bedrijf, bepaalde richtlijnen of communicatiemiddelen worden opgesteld om dit probleem op te lossen. De evaluatie van de oplossing is afhankelijk van de karakteristieken van het specifieke probleem. Alle world problemen zijn engineering problemen (design papers).
Er is vrij veel overlap tussen beide concepten. Toch is het belangrijk om een duidelijk onderscheid te behouden en dit kan worden gedaan door te kijken naar de fundamentele doelstelling die aan de basis ligt van de paper (hoofdcirkel). Wanneer het de doelstelling is om een kennis probleem op te lossen dan zullen we actief op zoek gaan naar de ontbrekende kennis en managen we de optredende verandering op een dergelijke manier, dat de verkregen kennis valide blijf. Anderzijds wanneer het doel het oplossen van een world probleem betreft, zullen we de wereld om ons heen actief trachten te veranderen en alle kennis die we hierdoor opdoen, is mooi meegenomen maar geen doel op zich.
34
Dit onderscheid is belangrijk, omdat de rationele methoden om beide problemen op te lossen van elkaar verschillen. Het is wel zo dat beide soorten niet los staan van elkaar en dat er vaak sprake is van een mutueel recursieve relatie. Zo kunnen er bij het oplossen van wereld problemen kennis problemen opduiken die opgelost dienen te worden om tot inzichten te komen om de eerstgenoemde problemen op een gefundeerde manier aan te pakken (nested cycles). Op basis van bovenstaande definities valt deze thesis duidelijk te klasseren onder de design paper categorie. Vervolgens zal er dus enkel ingegaan worden op de zes richtlijnen aangeboden door de engineering cyclus voor het rationeel oplossen van wereldproblemen. Deze structuur is toepasbaar op een zeer brede waaier van disciplines, gaande van architectuur tot product engineering en ziet er als volgt uit: 1) Problem investigation: De engineering cyclus start met een kennis probleem. Alvorens de wereld om ons heen te kunnen veranderen, is het noodzakelijk om voldoende kennis te hebben over het probleem. Mogelijke voorbeelden met betrekking tot deze thesis zijn: a. Het belang van tool support voor de implementatie, management en analyse van EA in KMO’s. b. Het belang van een nieuwe tool aangepast aan de specifieke karakteristieken van een KMO. Door een antwoord te formuleren op bovenstaande vragen, neemt de kennis met betrekking tot het probleem toe en kan deze geïncorporeerd worden bij de uitwerking van de oplossing. Dit draagt bij tot de kwaliteit en de volledigheid van het eindresultaat (zie literatuurstudie). 2) Solution design: Deze stap betreft het creatief uitwerken van een design dat anders is dan bestaande oplossingen, waardoor de voorkomende problemen opgelost worden. Deze oplossing kan een combinatie of aanpassing van bestaande methodes zijn of een volledig nieuw, nooit eerder gezien design. In beide gevallen dient de auteur de techniek zo duidelijk en volledig mogelijk te specifiëren opdat verschillende entiteiten het zouden kunnen testen. Daarnaast dient er ook te worden geargumenteerd waarom deze specifieke oplossing in staat is een antwoord te formuleren op de optredende uitdagingen en problemen (zie hoofdstuk 3 research scope).
35
3) Design validation: Volgens Wieringa dient de validatie de volgende vorm te hebben: als oplossing S wordt geïmplementeerd, dan zullen de voorkomende fenomenen P veranderen in P’, en P’ is beter dan P. Deze validatie bevat twee onderliggende stellingen, namelijk een causale claim en een value claim. De causale claim heeft betrekking op de stelling dat S P’ veroorzaakt. De value claim stelt dan weer dat P’ beter is dan het oorspronkelijke P. Een manier om deze stellingen te verifiëren is door de oplossing toe te passen in de praktijk en waar te nemen wat er gebeurt. Meestal is dit echter niet mogelijk omdat de stakeholders bewijs willen hebben alvorens de oplossing werkelijk te gaan toepassen. Validatie is het proces waarbij een dergelijk bewijs wordt voortgebracht. We spreken hier bijgevolg opnieuw van een kennis probleem (zie hoofdstuk 4 research scope). 4) Choose a solution: In een rationele engineering cyclus dienen meerdere oplossing gespecifieerd en gevalideerd te worden (stap 2 en 3) alvorens de beste oplossing te selecteren voor de daadwerkelijke implementatie. De keuze wordt meestal niet gemaakt door de maker van de oplossing, maar wel door de stakeholder waarvoor de oplossingen initieel opgesteld werden (buiten de scope van deze thesis). 5) Implement the solution: Het toepassen van de gekozen oplossing in de praktijk (buiten de scope van deze thesis). 6) Implementation evaluation: De implementatie gebeurt met als doel het oplossen van het initiële probleem. De oplossing kan echter de gewenste effecten maar gedeeltelijk of zelfs helemaal niet teweegbrengen. Dit kan het gevolg zijn van onverwachte en onvoorziene gebeurtenissen of omdat de omgeving veranderd is tijdens de ontwikkeling van de oplossing, etc. Bijgevolg zal de ontwerper de oplossing in de praktijk opvolgen en alle effecten ,hetzij gewenst, hetzij onverwacht, analyseren en evalueren (buiten de scope van deze thesis). Wieringa stelt dat bij het ontwikkelen van een oplossing voor een wereldprobleem de rationele structuur van de engineering cyclus gevolgd dient te worden, opdat geïnteresseerde partijen beter in staat zouden zijn om te begrijpen wat er gedaan werd en waarom. Bijgevolg verhoogt bovenstaande methodologie de waarde van het onderzoek en is het opportuun om er rekening mee te houden bij de verdere uitwerking van deze thesis. Merk echter op dat Wieringa niet pleit dat alle papers over wereldproblemen voldoen aan alle bovenstaande criteria. Om alle stappen te doorlopen zou het aanzienlijk veel tijd vragen, bijgevolg zal er in deze thesis gefocust worden op de eerste drie stappen van de engineering cyclus.
36
1.2. Design science research methodologie voor information systems research Design science research (DSR) in IS wordt door Peffers gedefinieerd als het creëren en evalueren van IT-‐artefacten die als doel hebben geïdentificeerde organisatorische problemen op te lossen. Het ontwikkelen van een software tool voor EA (EASE) voldoet aan deze definitie aangezien het een oplossing biedt voor verscheidene problemen die eerder in deze thesis meer in detail besproken werden (zie literatuurstudie). De ontwikkelde methodologie is een geheel van principes, praktijken en procedures die IS-‐onderzoekers in staat moeten stellen om DSR in hun vakgebied met hoge kwaliteit te produceren en presenteren. Eerst en vooral voorziet Hevner (Hevner, March et al. 2004) zeven richtlijnen voor het uitvoeren van DSR in het IS vakgebied. Deze richtlijnen beschrijven karakteristieken van goed uitgevoerd onderzoek: •
De hoofddoelstelling is de creatie van een artefact toegespitst op een specifiek probleem.
•
Het artefact moet relevant zijn voor het oplossen van tot nog toe onopgeloste en belangrijke business problemen.
•
Het nut, de kwaliteit en de doeltreffendheid dienen grondig te worden geëvalueerd.
•
Het onderzoek dient een waarneembare en relevante bijdrage te leveren
•
De ontwikkeling en evaluatie van het artefact dient rigoureus te worden uitgevoerd.
•
Bij de ontwikkeling van het artefact dient gebruik gemaakt te worden van bestaande theorieën en kennis om een gepaste oplossing te kunnen formuleren voor het onderliggende probleem (rigor).
•
Het onderzoek dient effectief te worden gecommuniceerd naar het doelpubliek.
Afbeelding 19 geeft een schematisch overzicht van bovenstaande richtlijnen met een reflectie naar het onderzoek in deze thesis. Deze richtlijnen bieden echter enkel criteria om het eindresultaat te beoordelen maar geen methodologie hoe de ontwikkeling van EASE (het artefact) op te bouwen. Peffers ontwikkelde een normatief DSR-‐methodologieproces bestaande uit zes stappen die voldoen aan de volgende drie objectieven: •
Voorziet een nominaal proces voor het uitvoeren van DSR. 37
•
Gebaseerd op een uitgebreide literatuurstudie betreffende DS in IS en gelijkaardige disciplines.
•
Voorzien onderzoekers van een mentaal model of sjabloon voor het structureren van de output van het onderzoek
Afbeelding 19: IS research framework (Hevner, March et al. 2004)
Vervolgens zullen de zes verschillende stappen kort worden toegelicht: 1) Problem identification and motivation: De hoofddoelstelling van deze stap is het verzamelen van kennis die kan helpen bij de identificatie, beschrijving en motivatie van het probleem dat aan de basis ligt van het onderzoek. Het kan hierbij opportuun zijn om het probleem te atomiseren in subproblemen, opdat de volledige complexiteit goed begrepen en geïncorporeerd kan worden in het artefact. Daarnaast is een goed gefundeerde uiteenzetting over het belang van de oplossing onontbeerlijk om alle belanghebbende partijen te overtuigen van de waarde van het artefact, alsook om hen te motiveren om de oplossing te implementeren (zie literatuurstudie). 2) Define the objectives for a solution: Op basis van de verworven kennis met betrekking tot het probleem en inzichten in wat mogelijk en praktisch haalbaar is, dienen objectieven voor de te ontwikkelen oplossing afgeleid te worden. Deze objectieven kunnen zowel kwantitatief, onder de vorm van specifieke doelstellingen, als
38
kwalitatief, onder de vorm van beschrijvingen van functionaliteiten, zijn. Deze objectieven worden ook vaak metarequirements of requirements genoemd. Er dient echter wel te worden opgemerkt dat niet enkel hier objectieven worden geïdentificeerd. Door toepassing van het artefact in de praktijk in latere stappen, kunnen nieuwe objectieven ontdekt worden of kunnen de bestaande worden bijgeschaafd. De methodologie is dus niet louter sequentieel maar eerder iteratief (zie hoofdstuk 2 research scope). 3) Design and development: Deze stap vormt het zwaartepunt van deze methodologie en betreft de creatie van het artefact zelf. Een artefact wordt conceptueel omschreven door Peffers als eender welk object waarvan het design een bijdrage bevat van het uitgebreide onderzoek dat er aan voorafging. Specifiek houdt dit in dat de architectuur van EASE bepaald dient te worden, de objectieven vertaald dienen te worden in functionaliteiten alsook de creatie van EASE zelf (zie hoofdstuk 3 research scope). 4) Demonstration: Demonstratie van de toegevoegde waarde van het ontwikkelde artefact bij toepassing ervan in relevante omgevingen. Hiervoor kan men een beroep doen op casestudies, simulaties, experimenten, etc. Om dit te realiseren, moet de ontwerper echter een duidelijk inzicht hebben in de werking van de tool en de meerwaarde van het gebruik ervan met het oog op de verschillende probleemgebieden (zie hoofdstuk 4 research scope). 5) Evaluation: Observatie en meting van de effectiviteit en efficiëntie van het artefact als oplossing voor het probleem. Hierbij zullen de vooropgestelde objectieven vergeleken worden met de werkelijke prestatie gedurende de demonstratie. Ook hier zijn er opnieuw verschillende mogelijkheden. Afhankelijk van de aard van het artefact en het probleem, kan de evaluatie verscheidene vormen aannemen. Mogelijke voorbeelden zijn tevredenheidsenquêtes, user feedback, vergelijking van de functionaliteiten met de vooropgestelde objectieven, allerhande kwantitatieve meetschalen, etc. Op het einde van de evaluatie kunnen de onderzoekers teruggaan naar stap 2 of stap 3, indien hetzij de objectieven, hetzij het artefact, aangepast dienen te worden gebaseerd op de bevindingen van stap 5 (zie hoofdstuk 4 research scope). 6) Communication: De laatste stap betreft de communicatie van de verworven kennis en het ontwikkelde artefact naar alle mogelijke relevante en belanghebbende partijen. Voor een efficiënte communicatie kan bovenstaande structuur worden gebruikt om het resulterende werkstuk te ordenen (papers AMCIS en tijdschrift Informatie, blog eatoolsupport.wordpress.com, thesis).
39
1.3. Software proces modellen Een software proces is een verzameling van activiteiten en informatie die vereist zijn bij de ontwikkeling van een bepaald softwaresysteem. Zowat elke organisatie heeft een eigen software proces, maar doorgaans volgen deze individuele benaderingen wel een abstract generiek model. Deze generieke modellen worden software proces modellen genoemd en geven een inzicht in de verschillende stappen van concept tot afgewerkt product. In het algemeen zijn er twee groepen modellen te onderscheiden, de specification-‐based en de evolutionary development modellen.
1.3.1. Specification-‐based modellen Het bekendste en meteen ook oudste is het watervalmodel bestaande uit verschillende fasen waarbij elk van hen doorlopen wordt door middel van een cascadesysteem. Zoals de naam doet vermoeden, start men bij dit soort modellen van de specificaties. Daarna volgt de design-‐ en implementatiefase, gevolgd door de integratie-‐ en testfase. Finaliter is er ook nog de operationele en maintenancefase waarbij het eindproduct aan de gebruiker wordt geleverd, gepersonaliseerd en onderhouden. Onderstaande figuur geeft een schematisch weergave van dit model.
Afbeelding 20: watervalmodel op een hoog niveau van abstractie
Het probleem met dit model is het gebrek aan feedback. Eenmaal een specificatie is vastgelegd en het in een latere fase blijkt dat die niet voldoet aan de wensen en verlangens van de eindgebruiker, dan kan het vaak moeilijk of tijdrovend zijn om de aanpassing nog door te voeren. Dit in combinatie met het fenomeen dat de gebruikers en stakeholders van een systeem het vaak moeilijk vinden om op voorhand de benodigde specificaties van een systeem te bepalen, heeft geleid tot de ontwikkeling van incrementele modellen, de cleanroom aanpak genoemd.
40
Deze modellen zijn zo opgebouwd dat er een juiste balans wordt gevonden tussen stabiliteit voor de ontwerpers en flexibiliteit om de vereisten en specificaties tijdens de ontwikkeling aan te passen voor de eindgebruikers. Dit wordt gerealiseerd door het programma functioneel op te splitsen in meerdere delen. Voor elk van deze delen worden de specificaties bevroren tijdens de ontwikkeling, maar er kunnen wel veranderingen van specificaties worden doorgevoerd bij de volgende versie. Bovendien krijgt men hierdoor eerder prototypes waardoor, door middel van vroege feedback, waardevolle informatie kan worden bekomen.
1.3.2. Evolutionary development modellen Het fundamentele probleem met specification-‐based modellen is de nood aan het vooraf vastleggen van de specificaties van de eindgebruiker. De omgeving kan zo dynamisch zijn dat er voortdurend veranderingen optreden en dan is zelfs de cleanroom aanpak onvoldoende flexibel en efficiënt om hierop in te spelen. In de evolutionary development models worden de specificatie, ontwerp en implementatiefase geïntegreerd. Deze aanpak bestaat uit de volgende fasen: 1) Het maken van een schets van de algemene specificaties van het systeem. Deze schets dient noch compleet noch consistent te zijn. De enige doelstelling is om de ontwerpers een idee te geven van wat het systeem zou moeten doen. 2) Zo snel mogelijk ontwerpen van een eerste systeem op basis van deze schets. 3) Het ontwikkelde systeem evalueren samen met de eindgebruikers en aanpassen aan hun opmerkingen tot de functionaliteiten van het systeem voldoen aan de vereisten van de gebruikers. Hoewel dit systeem een grotere kans heeft om beter aan te sluiten bij de wensen en verlangens van de eindgebruikers, heeft het ook enkele uitdrukkelijke nadelen: •
Door te focussen op de eindgebruiker kunnen bepaalde functionaliteiten, zoals bijvoorbeeld interoperabiliteit, onvoldoende aandacht krijgen aangezien deze de scope van de gebruiker overstijgen.
•
De constante verandering van het software systeem heeft een nefaste invloed op de structuur van het systeem, waardoor het vaak moeilijk te onderhouden en te hergebruiken is.
•
Het ontwikkelingsproces is minder transparant, waardoor opvolging en monitoring van de vooruitgang en de productiviteit bemoeilijkt wordt.
41
De evolutionary development aanpak is het meest geschikt voor interactieve systemen waarbij de userinterface van cruciaal belang is, of voor zeer innovatieve systemen waarbij de specificaties zeer moeilijk op voorhand vast te leggen zijn. Daarnaast wordt deze aanpak ook het meest gebruikt voor kleine en middelgrote business systemen. Om de voordelen van dit systeem met de managementvereisten die bovenstaande uitdagingen teweegbrengen te combineren, werd het spiral model of development ontwikkeld door Boehm (Boehm 1988). Onderstaande figuur geeft een schematisch overzicht van dit model.
Afbeelding 21: spiral model of software development (Boehm 1988)
Deze aanpak laat toe om verschillende delen van het softwaresysteem met een verschillende aanpak te ontwikkelen afhankelijk van de eigenschappen van die delen. Op basis van een risicoanalyse in het tweede kwadrant, wordt bepaald welke van de eerder besproken modellen het best in staat is om de volgende iteratie van het te ontwikkelen systeem zo efficiënt en doeltreffend mogelijk uit te voeren. Naarmate het systeem meer vorm krijgt en de onzekerheid met betrekking tot de specificaties bijgevolg sterk is gereduceerd, wordt er overgegaan naar de watervalaanpak. Deze is in de figuur weergegeven in de laatste iteratie in het derde kwadrant. Voor de ontwikkeling van het input en adjust luik is er een beroep gedaan op de watervalaanpak. Gezien de hoge mate van stabiliteit in de vereisten en functionaliteiten van dit deel van EASE, was er een beperkte nood aan flexibiliteit en kan er bijgevolg genoten worden
42
van de hoge graad van stabiliteit van deze aanpak voor de ontwerpers. Het output gedeelte daarentegen vertoonde vrij veel onzekerheid en bijgevolg werd dit luik ontwikkeld door gebruik te maken van de de evolutionary development modellen. Hierbij werd zo rap mogelijk een eerste operationele versie gemaakt en door toepassing in de praktijk werd dit luik verder geoptimaliseerd en aangevuld.
1.4. EASE methodologie Legt men de hierboven beschreven modellen en frameworks naast elkaar, dan kan men ze combineren in een methodologie voor de verdere uitwerking van deze thesis. Consolidatie van alle relevante en waardevolle elementen heeft geleid tot onderstaande methodologie voor de ontwikkeling van EASE (zie afbeelding 22). In het blauw worden alle relevante elementen weergegeven van de onderliggende aanpakken en in het rood de resulterende methodologie. Doorheen het ontwikkelingsproces kan er een beroep worden gedaan op de inzichten en kennis van de onderliggende benaderingen wat bijdraagt tot de academische en praktische waarde van dit onderzoek.
Afbeelding 22: methodologie op een hoog niveau van abstractie
43
2. Criteria voor EASE Stap één bestaat uit een uitgebreide literatuurstudie met als hoofddoel de vertaling van de criteria voor EA, de criteria voor KMO’s (afbeelding 9) en de kennis met betrekking tot het CHOOSE metamodel en methode in algemene richtlijnen voor tool support. In afbeelding 18 wordt dit weergegeven door stap 5. Deze richtlijnen voor software tool support zijn voornamelijk afgeleid van kennis verzameld door middel van literatuurstudies in de volgende gebieden: •
Adoptiemodellen voor IS en IS modellen.
•
Probleemgebieden van EA implementatie, management en onderhoud.
•
De zwakten van de huidige tools.
•
CHOOSE methode en metamodel.
Dit resulteert uiteindelijk in de volgende design objectieven voor EASE, representatief voor research steps 1 tot 4 (zie afbeelding 18): 1. Simplicity: EASE moet eenvoudig zijn in gebruik en toelaten om met behulp van een gebruiksvriendelijke interface de gewenste operaties door te voeren. Door de eenvoud van EASE, zou de drempel voor de implementatie van EA in de volledige onderneming verlaagd kunnen worden. Bovendien is het een hulpmiddel om de gefragmenteerde informatie te verzamelen door middel van interactie met de standaard interface. Dit zorgt voor een verhoogde flexibiliteit en inzetbaarheid wat bijdraagt tot de toegevoegde waarde van EASE (criteria 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 5). 2. Efficiency: De input van de eindgebruiker moet worden geminimaliseerd. Hiermee wordt bedoeld dat de tijd, moeite en kost voor het gebruik van EASE zo laag mogelijk dient te worden gehouden. EASE moet bijgevolg toelaten om zeer tijdsefficiënt te werk te gaan. Bovendien draagt het simplicity criterium bij tot de ontwikkeling van een tool met een zeer steile leercurve waardoor de kost voor opleiding en acclimatisatie aan het programma zeer beperkt is (criteria 4.1, 4.6). 3. Effectiveness: Gegeven de minimale input, dient EASE de toegevoegde waarde van de output te maximaliseren. Dit betekent dat EASE zeer flexibel en zonder hulp van de eindgebruiker de data dient te transformeren zodat die voor meerdere stakeholders bruikbare en waardevolle informatie oplevert. Door het wegfilteren van irrelevante data, wordt het holistisch overzicht behouden en de complexiteit van de realiteit gereduceerd tot een controleerbaar niveau. Bovendien ziet EASE erop toe dat algemeen aanvaarde
44
richtlijnen en best practices voor de opbouw van een EA gerespecteerd worden door achter de schermen automatisch allerhande constraints te controleren en af te dwingen (criteria 1, 2, 3, 4.4, 4.6). 4. Business oriented: Aangezien de kennis van IT en EA binnen KMO’s eerder beperkt is, is het belangrijk voor de adoptie dat EASE de taal van de eindgebruiker spreekt. In het geval van KMO’s is dat de bedrijfstaal. Het is dus belangrijk om bij de opbouw van EASE hier rekening mee te houden (criteria 4.2, 4.3, 4.5, 5). 5. Completeness: EASE moet in staat zijn om het volledige EA proces van begin tot einde te ondersteunen. Bovendien dient er rekening te worden gehouden met de algemene zwakten van de huidig beschikbare tools om te voorkomen dat gelijkaardige fouten worden gemaakt. Enkel op deze manier kan er worden gegarandeerd dat EASE de eindgebruiker maximaal helpt bij het formuleren van een antwoord op de bestaande tekorten en verlangens (criteria 2, 4.4, 5). Door de toepassing van deze design objectieven bij de ontwikkeling van EASE, kan het gebruik van EASE ter ondersteuning van CHOOSE bijdragen tot de adoptie en de toegevoegde waarde van de techniek. Elk van bovenstaande objectieven vertaalt immers meerdere CHOOSE criteria (zie hoofdstuk 3.3 literatuurstudie) naar de software tool omgeving. Indien uit de evaluatie van EASE blijkt dat deze design objectieven positief beoordeeld worden door de gebruiker, dan draagt het gebruik van EASE bij tot de realisatie van de CHOOSE criteria wat een verhoogde actual efficacy van de EA techniek zou moeten bewerkstelligen. Deze algemene objectieven worden verder aangevuld met criteria specifiek gerelateerd aan software tool support en de ontwikkeling ervan. In hoofdstuk 3.2 worden richtlijnen afgeleid voor de opbouw en het ontwerp van een gebruiksvriendelijke EASE user interface. Daarnaast worden voor de opbouw van de visualisatiefunctionaliteit (zie hoofdstuk 3.5.1) criteria toegepast gerelateerd aan menselijke perceptie en visuele syntax. Bovendien bestaan er allerhande criteria met betrekking tot de manier van programmeren en het structureren van de onderliggende code. Voorbeelden hiervan zijn modulariteit, flexibiliteit en hergebruik. Voor de ontwikkeling van EASE is er echter gebruik gemaakt van een taakgerichte aanpak en werden de richtlijnen gevolgd van de software proces modellen (zie hoofdstuk 1.3), zonder hierbij expliciet dergelijke criteria in rekening te brengen. Bijgevolg zullen deze niet besproken worden.
45
3. Software tool ontwikkeling Door middel van een literatuurstudie van EA in de praktijk (Kaisler, Armour et al. 2005; Ernst, Lankes et al. 2006; Lankhorst 2009) en door het toepassen van de CHOOSE aanpak in meerdere casestudies, werden de volgende probleemgebieden geïdentificeerd: •
input: Dit betreft het omzetten van de beschikbare kennis en informatie naar de effectieve EA gebruik makende van de semantiek en syntax aangeboden door CHOOSE. Deze codering vergt veel energie en tijd. De enorme hoeveelheid data, het dynamische en gefragmenteerde karakter van dergelijke informatie en de onderlinge afhankelijkheden maken dit proces zeer complex en tijdrovend. Bovendien spreekt het voor zich dat begeleiding en ondersteuning een enorme meerwaarde kan leveren op dit vlak. Daarnaast kunnen door het gebruik van een software tool bepaalde constraints worden afgedwongen waardoor een verhoogde naleving van vooropgestelde richtlijnen, best practices en regels van het metamodel bekomen wordt in vergelijking met de eerder besproken methodes waar alles mogelijk is.
•
opslag: Eenmaal gemodelleerd zal de architectuur opgeslagen dienen te worden om het in de nabije toekomst te kunnen raadplegen, aanpassen of analyseren. Bij gebrek aan tool support zal de data fysiek, bijvoorbeeld door middel van post-‐its op whiteboards, of in het beste geval in een zelf gemaakte database opgeslagen worden. Het is duidelijk dat dit een suboptimale oplossing is die de gebruiksvriendelijkheid en toegevoegde waarde zeker niet ten goede komt.
•
aanpassen data: Bedrijven zijn dynamische instellingen die vaak in zeer competitieve markten actief zijn waarbij er dagelijks van hen verwacht wordt dat ze zeer snel en gepast reageren op optredende veranderingen. Bijgevolg eisen deze ondernemingen dat hun systemen, inclusief hun EA, in staat zijn om efficiënt te reageren op deze verhoogde nood aan flexibiliteit en reactiesnelheid. Software tool support maakt het mogelijk om de architecturale artefacten moeiteloos en snel aan te passen en draagt op deze manier bij aan deze opkomende trend.
•
ophalen data: Hetzij om een verandering door te voeren, hetzij om een analyse uit te voeren zullen specifieke elementen binnen de EA teruggevonden en opgehaald dienen te worden. Software tool support kan dit proces sterk faciliteren en de inspanning significant reduceren. Dit draagt opnieuw bij aan de toegevoegde waarde van tool support.
46
•
analyse: Afhankelijk van de stakeholder, zal de informatie vervat in de architectuur op een andere manier bekeken worden. Het is bijgevolg noodzakelijk dat de EA deze verschillende viewpoints mogelijk maakt. Bovendien kan het nodig zijn om de informatie vervat in de architectuur onder een andere vorm, rekening houdende met het kennisniveau, de achtergrond en doelstelling van de persoon in kwestie, aan de gebruiker voor te stellen en eventueel ook te publiceren. Bovendien kan men door de analyse van de EA bepaalde inconsistenties en onregelmatigheden blootleggen en oplossen.
Zonder tool zal de inspanning in elk van bovenstaande gebieden zowel op het vlak van tijd, kost en energie exponentieel toenemen naarmate de hoeveelheid data vervat in de EA toeneemt. Lankhorst onderscheid drie categorieën van tools voor de ondersteuning van EA (Lankhorst 2009). Elk van deze categorieën kan gelinkt worden aan één of meerdere van de bovenstaande probleemgebieden: 1. modeling and design: Deze categorie ondersteunt het probleemgebied met betrekking tot de input. 2. reporting and publication: Deze categorie biedt een antwoord op de probleemgebieden met betrekking tot de analyse en het ophalen van data. 3. storage and retrieval: Deze categorie heeft betrekking tot de opslag, het aanpassen en het ophalen van data. Een complete en waardevolle software tool moet in staat zijn om de gebruiker te begeleiden in en een antwoord te bieden op elk van bovenstaande probleemgebieden. Bijgevolg dient de software tool EASE de drie categorieën te integreren in één overkoepelende tool ter ondersteuning van het volledige end-‐to-‐end EA proces (criterium 5). Gebaseerd op deze inzichten werd EASE opgebouwd rond drie hoofdfunctionaliteiten: input, adjust en output (afbeelding 23). EASE is ontwikkeld gebruik makende van Java als programmeertaal en MS Access als databasemanagementsysteem (DBMS). In het vervolg van dit artikel zal er eerst beknopt worden besproken hoe de onderliggende database is opgebouwd. Vervolgens zal er een uiteenzetting worden gegeven over het ontwerp van de interface met een reflectie naar de vooropgestelde criteria voor EASE. Finaliter zal er een uitgebreid overzicht worden gegeven van de belangrijkste kenmerken en features van de tool. Waar mogelijk zullen deze worden geïllustreerd met behulp van het eenvoudig voorbeeld besproken in hoofdstuk 3.4 van de literatuurstudie.
47
Afbeelding 23: hoofdmenu en opbouw tool
3.1. Database Zoals reeds vermeld maakt EASE gebruik van MS Access als DBMS. De eerste stap in de constructie van de database is het uitvoeren van een objectonderzoek met als doel het opstellen van een gegevensmodel dat qua opbouw nauw aansluit bij de werkelijkheid. Voor deze thesis is er gebruik gemaakt van het conceptueel gegevensmodel ontwikkeld door Bernaert gebaseerd op de CHOOSE techniek (zie afbeelding 24). De volgende stap bestaat uit het databaseontwerp met behulp van een representatieonderzoek. Dit proces resulteert in een representatiedatabasemodel op basis waarvan de initiële database kan worden geconstrueerd. Vervolgens is er de implementatiefase van het databaseontwikkelingsproces. Aangezien deze stap eerder technisch is van aard zal dit proces in deze thesis niet beschreven worden. Op het einde van deze drie stappen wordt de initiële versie van de database bekomen. Het kan echter zijn dat bij het modelleren van de werkelijkheid in het conceptueel gegevensmodel er zaken vergeten werden, waardoor er in de database bepaalde gegevens ontbreken die waardevol kunnen zijn. De laatste stap bestaat bijgevolg uit de validatie en evaluatie van de database. Op basis van deze inzichten kunnen er aanpassingen worden doorgevoerd die de volledigheid en correctheid van de database ten goede komen.
48
Aangezien dit een proces van lange adem is geweest waarbij er in de loop van de thesis geregeld aanpassingen zijn gebeurd en het niet mogelijk of opportuun is om elke aanpassing apart te bespreken, zal er bij het representatieonderzoek vertrokken worden van het meest recente conceptueel gegevensmodel. Het finale resultaat is het representatiedatabasemodel waarmee de Access database werd opgebouwd die momenteel aan de basis ligt van EASE.
3.1.1. Representatieonderzoek Het ER-‐model in afbeelding 24 is een conceptueel gegevensmodel dat een logische weergave is van het CHOOSE probleemdomein. In dit model wordt echter nog geen rekening gehouden met enerzijds de beperkingen en anderzijds de mogelijkheden inherent verbonden aan Microsoft Access als DBMS. Een representatieonderzoek heeft als doel de gegevens die opgenomen zijn in dit conceptueel datamodel zo te structureren, opdat ze opgeslagen kunnen worden onder het gekozen type van DBMS. Dit proces vormt het startpunt van de systeemontwerpfase en resulteert uiteindelijk in een representatiedatabasemodel aangepast aan de specifieke karakteristieken van MS Access.
Afbeelding 24: ER-‐diagram CHOOSE in UML-‐notatie
Het grote verschil tussen het datamodel en het databasemodel is de manier waarop de gegevens zijn gestructureerd. In Access wordt gewerkt met een relationele gegevensstructuur die verschilt van de conceptuele gegevensstructuur van het (E)ER-‐diagram. Een relationeel metamodel is gebaseerd op principes afkomstig uit de wiskundige Relationele Theorie. Op basis van die principes kan immers databasetechnologie worden ontwikkeld. Daarnaast is de relationele databasetechnologie in het bedrijfsleven de populairste en meest gebruikte vorm van informatietechnologie voor het beheren van grote hoeveelheden data. De omzetting van het
49
conceptuele ER-‐gegevensmodel in een relationeel representatiedatabasemodel kan eenvoudig gebeuren door de gegevens in het gegevensmodel te herstructureren volgens de principes van het relationele databasemodel. Hiervoor kan er een beroep gedaan worden op tien mappingregels die elk één welbepaald ER-‐modelleerconcept vertalen naar het equivalente relationele modelleerconcept. Tijdens deze omzetting kan er echter waardevolle informatie verloren gaan. Het is dan ook belangrijk om een goed inzicht te hebben in de beperkingen van een dergelijk relationeel model en een gepaste oplossing te bedenken om het verlies aan data te elimineren of op te vangen. Aangezien er geen specifieke en veelgebruikte modelleertalen voorhanden zijn voor het beschrijven van een relationeel gegevensmodel, zal er gebruik worden gemaakt van notaties aangeleerd in het vak beleidsinformatica van prof. dr. G. Poels. Achtereenvolgens zullen de 10 mappingregels worden toegepast op het ER diagram weergegeven in afbeelding 24. Regel 1: Sterk entiteittype -‐-‐> relatie Voor elk sterk entiteitstype uit het ER model wordt er een relatie gecreëerd met alle enkelvoudige attribuuttypen van dit entiteittype. De primaire sleutel wordt hierbij onderstreept. Goal(GoalId, GoalNaam, GoalBeschrijving) Actor(ActordId, ActorNaam, ActorBeschrijving, Employee) Object(ObjectId, ObjectNaam, ObjectBeschrijving) Operation(OperationId, OperationNaam, OperationBeschrijving) Merk op dat Actor een extra attribuuttype employee heeft. Employee is van het type boolean en neemt de waarde ‘yes’ aan indien de actor een werknemer is van het bedrijf. Deze informatie zal later in het programma handig gebruikt kunnen worden om een onderscheid te maken tussen enerzijds werknemers en anderzijds bijvoorbeeld klanten of leveranciers. Regel 2: Zwak entiteittype -‐-‐> relatie Komt niet voor. Regel 3: Binair 1:1 relationshiptype => vreemde sleutel Komt niet voor Regel 4: Binair 1:* relationshiptype => vreemde sleutel Komt niet voor
50
Regel 5: Binair *:* relationshiptype => relatie Voor elk binair *:* relationshiptype in het ER diagram maak je in het relationele model een relatie aan waarvan de primaire sleutel de combinatie is van twee vreemde sleutels die elk verwijzen naar de primaire sleutel van één van de relaties voor de entiteittypen die verbonden worden door het *:* relationshiptype. Tekstueel worden vreemde sleutels aangeduid door ze cursief te maken. Concerns(GoalId, ObjectId) Operationalization(GoalId, OperationId) Input(ObjectId, OperationId) Output(ObjectId, OperationId) Assignment(GoalId, ActorId) Wish(GoalId, ActorId) Performance(ActorId, OperationId, Type) BelongsTo(ActorId, ObjectId) Merk op: Het is belangrijk om de nadruk te leggen op een subtiel nuanceverschil met betrekking tot de omzetting van de binaire relaties in het representatiedatabasemodel. Voor de omzetting van de RACI-‐relatie wordt er gebruik gemaakt van een extra attribuut (Type) die verduidelijkt om welk type relatie (RACI) het gaat. Bij de relaties tussen object en operatie en tussen goal en actor wordt er voor elk type relatie een aparte tabel gemaakt. RACI is immers door Bernaert naar voor geschoven als waardevol voor het modelleren van de relatie tussen actoren en operaties. In de praktijk zijn er echter verscheidene variaties hierop (vb. RASCI). Door deze manier van modelleren kan hier handig op worden ingespeeld, aangezien het attribuuttype kan worden aangevuld met dergelijke variaties. Dit maakt de database een stuk flexibeler en verlaagt de inspanning aanzienlijk in geval er aanpassingen dienen te worden doorgevoerd. De relaties tussen goals en actoren enerzijds en objecten en operaties anderzijds worden door Bernaert ingeschat als stabieler en bijgevolg werd hier de keuze gemaakt om niet met een attribuut te werken. Als uit de casestudies blijkt dat er andere relaties mogelijk en wenselijk zijn kan hetzelfde principe hier ook worden toegepast.
51
Regel 6: Recursief 1:* relationshiptype => vreemde sleutel Komt niet voor Regel 7: Recursief *:* relationshiptype => relatie Net zoals bij het binair *:* relationshiptype wordt er een nieuwe relatie gemaakt voor elk recursief *:* relationshiptype maar hier bestaat de primaire sleutel uit twee vreemde sleutels verwijzend naar hetzelfde attribuuttype. Aangezien er in een relatie geen twee attribuuttypen met dezelfde naam mogen voorkomen zal men gebruik moeten maken van rolnamen. OrRefinement(GoalId, GoalId2) AndRefinement(GoalId, GoalId2, AndRefinementGroep) Conflict(GoalId, GoalId2) Association(ObjectId, ObjectId2, Type) Includes(OperationId, OperationId2) Supervision(ActorId, ActorId2) Merk op dat AndRefinement een extra attribuuttype AndRefinementGroep bevat die deel uitmaakt van de primaire sleutel. Een eenvoudig voorbeeld verduidelijkt de nood aan dit extra attribuuttype. Stel dat een doelstelling A twee mogelijke uitkomsten heeft. Hetzij zullen doelstellingen B én C moeten worden gerealiseerd hetzij doelstellingen B én D. Bij gebrek aan een AndRefinementGroep attribuuttype zal B slecht éénmaal gelinkt kunnen worden aan A, aangezien de primaire sleutel in elke tabel uniek dient te zijn. Bovendien gaat informatie verloren over welke doelstellingen samen dienen gerealiseerd te worden. Zo zou men enkel weten dat voor doelstelling A, doelstellingen B, C en D noodzakelijk zijn maar gaan de gewenste combinaties van deze drie doelstellingen verloren. Regel 8: Meerwaardig attribuuttype => relatie Komt bij Actor niet voor Regel 9: Complexe relationshiptypen => relatie Komt bij Actor niet voor
52
Het uiteindelijke resultaat van het generatieproces: Goal(GoalId, GoalNaam, GoalBeschrijving) Actor(ActordId, ActorNaam, ActorBeschrijving, Employee) Object(ObjectId, ObjectNaam, ObjectBeschrijving) Operation(OperationId, OperationNaam, OperationBeschrijving) OrRefinement(GoalId, GoalId2) AndRefinement(GoalId, GoalId2, AndRefinementGroep) Conflict(GoalId, GoalId2) Wish(GoalId, ActorId) Assignment(GoalId, ActorId) Operationalization(GoalId, OperationId) Concerns(GoalId, ObjectId) Supervision(ActorId, ActorId2) Performs(ActorId, OperationId, Type) BelongsTo(ActorId, ObjectId) Includes(OperationId, OperationId2) Input(ObjectId, OperationId) Output(ObjectId, OperationId) Association(ObjectId, ObjectId2) Merk op dat er bij de overgang van het datamodel naar het databasemodel geen informatie verloren gaat.
53
3.2. Interface EASE communiceert met de gebruiker door middel van graphical user interfaces (GUI’s). Het succes van dergelijke grafische interfaces ten opzichte van de oorspronkelijk op tekst gebaseerde tegenhanger is te verklaren door enkele algemene eigenschappen van GUI’s (Galitz 2007). Enerzijds zijn ze sterk intuïtief waardoor de gebruiker vaak zeer snel de applicatie onder de knie krijgt en er bovendien zeer efficiënt mee kan werken. Anderzijds is snelheid en meer specifiek responsiviteit een belangrijke determinant van het overdonderende succes van dit type interface. Afhankelijk van de specifieke toepassing, kan de snelheid van doorslaggevend belang zijn en beïnvloedt die in sterke mate of de applicatie al dan niet effectief gebruikt zal worden. In tegenstelling tot wat sommige mensen denken is de snelheid niet alleen afhankelijk van de onderliggende hardware, maar ook van de manier waarop de interface is opgebouwd (Hobart 1995). Onderzoek wijst uit dat het niet verbazend is om productiviteitsstijgingen van 25 à 40 procent te realiseren door eenvoudigweg een interface op de juiste manier te herontwerpen (Galitz 2007). In de literatuur onderscheidt men een verscheidenheid aan richtlijnen voor de optimalisatie van het ontwerp van GUI’s. Het is niet opportuun en evenmin mogelijk om ze allemaal te bespreken. Daarom werden de relevantste en belangrijkste elementen onderscheiden en vervolgens samengebracht in 5 design richtlijnen voor het ontwerp van de EASE GUI’s (Hobart 1995; Galitz 2007).
3.2.1. Design principe 1: Begrijp de mens achter het programma Het is belangrijk om bij de opbouw van de interface de gebruiker in het achterhoofd te houden. Hiermee wordt niet enkel specifieke kennis met betrekking tot het profiel van de gebruiker bedoeld (vb. zijn/haar kennisniveau), maar ook in het algemeen kennis over de mens achter de gebruiker. Mensen delen bepaalde universele kenmerken en door hier gepast op in te spelen, wordt de gebruiksvriendelijkheid van het programma verhoogd ongeacht wie de applicatie finaliter zal gebruiken. Onderzoek naar menselijke perceptie, geheugencapaciteit, mentale modellen en de fysieke en psychologische karakteristieken van de gebruiker voorzien in dit opzicht waardevolle kennis. Incorporatie van die kennis in het ontwerp van de GUI’s verhoogt bijgevolg de toegevoegde waarde van de applicatie. Mensen leren bijvoorbeeld veel makkelijker door middel van herkenning dan door herinnering. Een persoon kan gemiddeld 2000 a 3000 woorden onthouden maar herkent er daarentegen meer dan 50000. Bijgevolg is het altijd opportuun, indien mogelijk, de gebruiker uit een lijst van waarden te laten kiezen dan van hem/haar te verwachten dat hij/zij een bepaalde waarde zelf gaat intypen.
54
3.2.2. Design principe 2: Wees consistent Goed ontworpen GUI’s zijn consistent doorheen de volledige applicatie en bouwen hierdoor verder op de kennis die de gebruiker reeds heeft opgedaan door te werken met de applicatie. Consistentie heeft zowel betrekking op de manier waarop het scherm is opgebouwd, de manier waarop de interactie met de gebruiker verloopt als de naamgeving doorheen de applicatie. De interface dient consistent te zijn in die zin dat op basis van zijn/haar ervaring met een voorgaand scherm, de gebruiker reeds een idee heeft hoe te interageren met het volgende scherm. Een vaak voorkomende fout in dit opzicht is dat bepaalde termen door elkaar worden gebruikt. Zo kan in de ene interface gesproken worden over een doelstelling terwijl een andere spreekt over een goal en nog een andere over een objectief terwijl in elk van de schermen hetzelfde concept wordt bedoeld. Dit kan voor verwarring zorgen bij de gebruiker en moet bijgevolg te allen tijde vermeden worden. Daarnaast is er ook sprake van de consistentie van de applicatie buiten het systeem. Hierbij dienen allerlei factoren in rekening te worden gebracht, zoals cultuur, taal en ervaring met andere applicaties. Het gebruiksgemak van de applicatie kan worden gemaximaliseerd door hier gepast op in te spelen. Zo werken programma’s doorgaans met lijsten bestaande uit gestandaardiseerde en universele labels en iconen. Door deze lijsten te raadplegen bij het opstellen van de eigen GUI’s kunnen vaak voorkomende fouten vermeden worden en kan er handig en op een snelle manier geprofiteerd worden van de gecumuleerde kennis vervat in deze lijsten.
3.2.3. Design principe 3: Een goed schermontwerp is onontbeerlijk Hoe een GUI is opgebouwd, is van doorslaggevend belang om de efficiëntie en effectiviteit te bepalen waarmee de interface enerzijds informatie uitwisselt en anderzijds de gebruiker navigeert doorheen de applicatie. Of een interface al dan niet goed is opgebouwd, wordt beïnvloed door een enorme hoeveelheid verschillende factoren. Een beknopt overzicht van enkele belangrijke factoren: •
kleuren: Indien correct toegepast, kunnen kleuren de logische opbouw van een scherm versterken, helpen om visuele componenten van elkaar te onderscheiden, bepaalde aspecten van de interface benadrukken en nog veel meer. In geval van slecht gebruik, kunnen kleuren storend werken en een omgekeerd effect hebben op de perceptie van de gebruiker. Literatuur kan hiervoor de broodnodige begeleiding voorzien. Zo werden er bijvoorbeeld lijsten gebruik om de optimale achtergrond/tekst kleurencombinaties te bepalen.
55
•
hoeveelheid informatie: Voorzie enkel die informatie die nodig is om een welbepaalde taak uit te voeren. Zowel te weinig als te veel informatie zorgt voor verwarring en inefficiënt gebruik van de applicatie. Zo kan bijvoorbeeld van de gebruiker niet verwacht worden dat hij/zij informatie uit een vorige interface onthoudt om in de huidige interface een beslissing te kunnen nemen. Als algemene richtlijn geldt bovendien dat de densiteit van een scherm beperkt dient te worden tot hoogstens 30 procent.
•
organisatie: Zorg ervoor dat de compositie van het scherm een logische en sequentiële volgorde vertoont. Hierbij dient rekening te worden gehouden met de natuurlijke beweging van de gebruiker (bv. in Europa van links naar rechts, van boven naar onder) en moet men streven om de afstand te minimaliseren die de gebruiker met de muis en visueel moet afleggen om het scherm volledig te doorlopen. Daarnaast bestaan er ook regels met betrekking tot de positionering van de verschillende besturingselementen in het scherm. Zo moet je er bijvoorbeeld steeds voor zorgen dat indien een bepaald element x een ander element y mogelijk maakt of beïnvloedt, dan moet element x voor element y gepositioneerd worden in de logische volgorde van het scherm.
•
navigatie: De schermen dienen zo te worden opgebouwd dat de navigatie door de schermen natuurlijk aanvoelt en de inspanning van de gebruiker hiervoor wordt geminimaliseerd (bv. aantal maal klikken, beweging met de muis vereist). Vaak gebruikte technieken in dit opzicht zijn groepering, uitlijning en positionering van de navigatie-‐elementen.
•
esthetiek: Eye tracking studies hebben aangetoond dat gedurende de initiële screening van een scherm, mensen beïnvloed worden door de esthetiek bij de beoordeling ervan (Galitz 2007). De notie van wat al dan niet esthetisch is, is in de loop der jaren sterk geëvolueerd. Perceptueel onderzoek heeft enkele principes onderscheiden ter verduidelijking van het concept zoals onder meer symmetrie, groepering, uitlijning, gebruik van witregels, eenvoud en voorspelbaarheid. Toepassing van deze principes beïnvloedt de onderbewuste beoordeling van de gebruiker van het gebruiksgemak en de toegevoegde waarde van de applicatie.
Deze lijst is zeker niet exhaustief maar heeft louter als doel een beeld te geven van welke factoren in rekening werden gebracht bij het ontwerp van de GUI’s voor EASE.
56
3.2.4. Design principe 4: Communiceer eenvoudig, correct en tijdig Communicatie met de gebruiker van de applicatie is zeer belangrijk. De verklaring hiervoor is opnieuw terug te vinden bij de aard van het beestje. Mensen zijn van nature ongeduldig. Zoals eerder vermeld, is het daarom belangrijk dat de applicatie de gebruiker in staat stelt om sneller te werken. Sommige operaties vergen echter tijd. Door correct en tijdig met de gebruiker te communiceren kan zijn/haar perceptie van de wachttijd beïnvloed worden. Een schoolvoorbeeld van een toepassing van dit principe in de praktijk zijn pretparkattracties en de manier waarop de wachtrijen zijn opgebouwd. Gebruikers waarderen het wanneer ze op de hoogte gehouden worden van hoe lang een bepaalde operatie nog zal duren vooraleer ze er de vruchten van kunnen plukken. In dit opzicht is het gebruik van een progress bar dan ook zeer waardevol. Daarnaast is communicatie onder de vorm van feedback ook zeer belangrijk. Feedback kan allerlei vormen aannemen. De feedback kan onder meer betrekking hebben tot de status van het systeem, de toepassing van mistake-‐proofing technieken, de begeleiding en ondersteuning van de gebruiker en hulpfunctionaliteiten. De gebruiker kan bijvoorbeeld op de hoogte gebracht worden indien bepaalde velden die hij/zij wenst op te slaan niet geldig zijn. Op deze manier kunnen aanpassingen worden doorgevoerd en voorkomt het systeem dat de gebruiker fouten maakt. Anderzijds kan de gebruiker een confirmatie ontvangen dat de handeling die men wou uitvoeren is voltooid en wordt men gerustgesteld dat alles succesvol is verlopen. Een vaak voorkomende fout in dit opzicht is dat ontwikkelaars tekstuele feedback overladen met overbodige en potentieel verwarrende woorden. Een gouden regel is om de feedback zo kort mogelijk te houden en de boodschap tot de essentie te beperken. Dit is een zeer moeilijke en uitdagende taak waarvoor voldoende tijd moet worden voorzien. Een laatste toepassing is communicatie met betrekking tot de navigatie doorheen de applicatie. Het is belangrijk om de gebruiker steeds te voorzien van een traceerbaar pad dat hem/haar er toe in staat stelt te zien waar hij/zij zich precies bevindt in de applicatie en hoe hij daartoe gekomen is. Indien dit niet duidelijk gecommuniceerd wordt, kan de gebruiker verloren lopen in de applicatie en kostbare tijd verliezen, wat de gebruiksvriendelijkheid zeker niet ten goede komt. In elk van de drie toepassingen dienen de juiste communicatiekanalen en middelen te worden ingezet. De keuzes hieromtrent beïnvloeden in sterke mate de adoptie en het succes van de applicatie.
57
3.2.5. Design principe 5: Test, test en hertest Het laatste design principe wijst erop dat het ontwerpen van GUI’s geen louter sequentieel proces is. Enorm veel verschillende factoren moeten in rekening worden gebracht en men zal hierbij ongetwijfeld trade-‐offs dienen te maken. Bovendien is er geen absoluut beste design. Alles hangt af van de situatie waarin de applicatie gebruikt wordt. De implicaties van bepaalde design beslissingen kunnen immers vaak niet worden voorspeld en dienen geobserveerd te worden in de praktijk. Op basis van die observaties moet men dan beslissen of het huidige ontwerp behouden blijft of er aanpassingen dienen doorgevoerd te worden. Er is dus veeleer sprake van een iteratief proces. De GUI’s die bijgevolg in de volgende hoofdstukken zullen worden getoond, zijn het resultaat van een lange weg van ontwerpen en herontwerpen. De toepassing van dit principe wordt uitgebreider besproken in hoofdstuk 4 van deze thesis.
3.3. Input De verschillende elementen en hun onderlinge relaties dienen gemodelleerd en opgeslagen te worden met behulp van de concepten en relaties aangeboden door de CHOOSE aanpak. Deze worden via het input luik aan de eindgebruiker voorgesteld door middel van een uiterst gebruiksvriendelijke en sterk intuïtieve interface. De eerste stap bestaat erin een keuze te maken uit de vier dimensies van de CHOOSE aanpak (zie afbeelding 25).
Afbeelding 25: input venster EASE
58
Vervolgens worden alle mogelijke relaties die een entiteit van de gekozen dimensie kan aangaan, weergegeven in een overzichtelijk venster (zie afbeelding 26).
Afbeelding 26: input van een entiteit in de goal dimensie
Centraal bovenaan de interface bevinden zich de primaire gegevens van de entiteit van de gekozen dimensie, nl. de naam en de beschrijving. Vervolgens is er gebruik gemaakt van tabs om alle relaties weer te geven die een entiteit van de gekozen dimensie kan hebben met entiteiten van de andere dimensies (groepering). Op deze manier wordt de eindgebruiker niet overladen met informatie maar kan hij/zij toch alles terugvinden in deze enkele interface (design principe 3). Bovendien is de opbouw van de input interface identiek voor elk van de vier dimensies. Enkel de inhoud, dus de soorten relaties die voorkomen, verschillen. Om deze consistentie nog
59
verder door te trekken, is er gekozen om de tabs en actieknoppen steeds op dezelfde plaats en in dezelfde volgorde weer te geven. Al deze factoren komen de voorspelbaarheid en gebruiksvriendelijkheid van de opbouw ten goede (design principe 2). De kleuren zijn bewust neutraal gehouden om de gebruiker visueel niet te overladen en om potentiële verwarring te voorkomen. Daarnaast wordt er gebruik gemaakt van een witte/grijze achtergrond met zwarte letters voor de communicatie met de eindgebruiker. Het contrast tussen deze kleuren zorgt voor een optimale leesbaarheid van de interface (design principe 3). Voor de input van de data is er waar mogelijk gebruik gemaakt van lijsten aangezien de gebruiker veel makkelijker en sneller waarden kan herkennen dan herinneren (design principe 1). Deze lijsten zijn bovendien alfabetisch gerangschikt zodat de gebruiker snel de entiteit kan terugvinden die hij/zij zoekt. Daarnaast kan de gebruiker door met de muis over bepaalde speciale actieknoppen te gaan, een pop-‐up venster laten verschijnt met extra uitleg ter verduidelijking van de functionaliteit ervan (design principe 4). Bovendien is elke interface voorzien van een navigatiemenu in de werkbalk. Op deze manier kan de gebruiker eenvoudig en snel doorheen de applicatie navigeren. Voor de hoofdmenu’s is er tevens een sneltoets geprogrammeerd. Opdat de gebruiker steeds zou weten waar hij/zij zich in het programma bevindt, wordt een traceerbaar pad continue bovenaan het scherm weergegeven (design principe 4). Dit wordt geïllustreerd in onderstaande afbeelding.
Afbeelding 27: navigatie EASE
De hierboven beschreven ontwerpkeuzes worden eveneens toegepast voor de schermen in de andere twee luiken en zullen bijgevolg niet meer opnieuw herhaald worden bij de bespreking van de functionaliteiten in de andere luiken.
60
Vooraleer de tool bij het saven alles wegschrijft in de onderliggende database, worden er allerlei restricties en constraints gecontroleerd met als doel het behoud van een consistente en coherente EA. In het geval er bepaalde inconsistenties voorkomen, wordt de eindgebruiker hierop gewezen en verzocht om de aanpassingen door te voeren om de kwaliteit van het eindresultaat te garanderen. In het geval alles correct is, zal de tool alle informatie opslaan in de onderliggende database en dit gebeurt volledig automatisch en vergt verder geen interactie met de gebruiker (design principe 4). Deze ‘separation of concerns’ zorgt ervoor dat in het geval het DBMS niet langer voldoet aan de evoluerende vereisten van het systeem, de interface kan overstappen naar een beter alternatief zonder dat de eindgebruiker hiervan ook maar iets van hinder ondervindt.
3.4. Adjust De tool biedt via het adjust luik een aantal mogelijkheden waarmee de gebruiker moeiteloos bepaalde entiteiten vervat in de EA, hun attributen en hun relaties kan ophalen en indien nodig aanpassen. De eerste en meest vanzelfsprekende manier is door middel van een ingebouwde zoekfunctie waarbij de database gefilterd wordt op basis van de input voorzien door de eindgebruiker.
Afbeelding 28: edit data
De zoekfunctie is zo opgebouwd dat de database tijdens het typen continue gefilterd wordt. Dit zorgt ervoor dat een oplossing wordt geboden voor het probleem waarbij de gebruiker de entiteit verkeerd intypt door hem/haar onmiddellijk van feedback te voorzien (design principe 4). Daarnaast filtert de zoekfunctionaliteit vergissingen in hoofdlettergebruik weg en wordt er globaal een overeenkomstige entiteit gezocht in de database. Specifiek betekent dit, dat er geen rekening dient te worden gehouden met de volgorde waarin de woorden voorkomen.
61
Stel dat we uit het voorbeeld besproken in hoofdstuk 3.4 van de literatuurstudie de entiteit ‘Verkoop product X verhogen’ willen opzoeken en aanpassen. Zo zullen bij het intypen van het woord ‘product’ alle entiteiten worden weergegeven waarin ‘product’ is opgenomen. In dit specifieke voorbeeld zullen dus zowel de entiteit ‘Verkoop product X verhogen’ als de entiteit ‘Producten aanpassen aan plaatselijke gewoontes’ worden weergegeven.
Afbeelding 29: zoekfunctionaliteit
Eenmaal de gewenste entiteit is gevonden kan de gebruiker de entiteit hetzij aanpassen door middel van de ‘continue’-‐knop, hetzij verwijderen met behulp van de ‘remove’-‐knop. In het geval de gebruiker de entiteit wenst te verwijderen, verschijnt er een pop-‐up venster ter bevestiging van de keuze. Dit om te voorkomen dat entiteiten per vergissing worden gewist, omdat de gebruiker bijvoorbeeld door onoplettendheid op de verkeerde knop duwt. Enkel als
62
de gebruiker bevestigt, wordt de entiteit effectief uit de database verwijderd, inclusief alle relaties die de gekozen entiteit had met andere entiteiten in het EA-‐model (referentiële integriteit). Vooraleer over te gaan tot de bespreking van de werkelijke adjust-‐functionaliteit, zal er een tweede manier besproken worden waarlangs entiteiten kunnen worden teruggevonden. EASE voorziet de gebruiker ook van de functionaliteit om de entiteiten die deel uitmaken van een bepaalde hiërarchie per dimensie van CHOOSE weer te geven in een boomstructuur. Deze optie heeft als voordeel dat de hiërarchische structuur hierdoor duidelijk weergegeven wordt en de gebruiker enkel die takken dient te bekijken die voor hem/haar relevant zijn. Door deze sterke reductie in complexiteit wordt een holistisch overzicht behouden zonder de gebruiker te overladen met irrelevante en potentieel verwarrende details (afbeelding 30). Daarnaast kan de gebruiker door op een bepaalde entiteit te klikken alle hiermee gerelateerde elementen laten weergeven volgens de visuele representatie uit afbeelding 10.
Afbeelding 30: overzicht boomstructuur
63
Indien de boomstructuur onvoldoende visuele ondersteuning biedt om de hiërarchie optimaal te vatten, kan de gebruiker een beroep doen op een automatische visualisatie functionaliteit door op de ‘draw’-‐knop te duwen. Deze functionaliteit zal hier echter niet besproken worden, aangezien dit reeds aan bod komt in hoofdstuk 3.5.1 van het output luik. Indien er aanpassingen dienen doorgevoerd te worden, moet de gebruiker eenvoudigweg de gewenste entiteit selecteren en op de ‘adjust’-‐knop drukken. Ongeacht op welke manier de entiteit is opgezocht, komt de gebruiker op onderstaand scherm dat hem/ haar ertoe in staat stelt om gericht aanpassingen door te voeren.
Afbeelding 31: adjust goal interface
Er is bewust gekozen om de opbouw van het scherm in afbeelding 31 anders aan te pakken dan het eerder besproken input scherm waarin alle informatie in één venster wordt weergegeven. Design principe 3 pleit ervoor dat een goed schermontwerp enkel die informatie weergeeft die voor de eindgebruiker van belang is. Aangezien bij het aanpassen van een entiteit de gebruiker doorgaans slechts een bepaald aspect van de gekozen entiteit wil aanpassen, is het bijgevolg niet gewenst om alle mogelijke relaties direct weer te geven. Door op de gepaste knop te duwen, leidt de applicatie de gebruiker naar een apart venster waar gericht aanpassingen kunnen worden doorgevoerd. Afbeelding 32 illustreert het aanpassen van de goal relaties van de entiteit ‘Verkoop product X verhogen’.
64
Ook hier worden opnieuw restricties gecontroleerd en best practices toegepast op de aanpassingen die de gebruiker wenst door te voeren. Een dergelijk controlemechanisme helpt de gebruiker om de vooropgestelde richtlijnen te respecteren, wat resulteert in een verhoogde kwaliteit van het resulterende EA-‐model. Zo zal bijvoorbeeld bij het aanpassen van een entiteit die deel uitmaakt van een hiërarchie, het maken van een loop vermeden worden door te verhinderen dat hogere liggende entiteiten ook worden toegewezen als ondergeschikte entiteiten (zie afbeelding 32).
Afbeelding 32: adjust goal relaties
65
Er dient echter een onderscheid te worden gemaakt tussen hard en soft contraints. Soft constraints kunnen niet zonder meer afgedwongen worden, in tegenstelling tot het voorbeeld in afbeelding 32, omdat ze de vrijheid van de gebruiker zouden beperken. Indien de gebruiker aanpassingen doorvoert die niet in lijn zijn met de vooropgestelde soft constraints, dan wordt hij/zij hiervan op de hoogte gebracht en communiceert EASE duidelijk de implicaties van een dergelijke actie. Zo kan een actor die geen employee is niet deelnemen aan de employee-‐hiërarchie. Wenst de gebruiker dit toch te doen dan verschijnt er een pop-‐up venster dat de gebruiker erop wijst dat bij het doorvoeren van een dergelijke aanpassing, de actor automatisch tot de employee categorie wordt omgevormd. Het is dan aan de gebruiker om te beslissen of hij de aanpassing al dan niet wil laten uitvoeren (zie afbeelding 33). Deze aanpak zorgt voor de juiste balans tussen freedom-‐to-‐operate voor de gebruiker en het respecteren van de best practices voor de kwaliteit van het EA-‐model.
Afbeelding 33: soft constraints
66
3.5. Output Het output luik heeft als doel waardevolle informatie te extraheren uit de grote hoeveelheid gefragmenteerde data die door de gebruikers werden ingevoerd in de vorige twee luiken. Waarde wordt gecreëerd door de integratie van deze losse feiten in een consistent en coherent model gebaseerd op de concepten die beschikbaar worden gesteld door de CHOOSE methode. Aangezien duidelijk gekozen werd om de informatie schriftelijk te verzamelen, in tegenstelling tot de meeste bestaande tools, is er noodzaak om een automatische visualisatie van de EA te voorzien. Dit onderdeel van het programma wordt aangeduid als de focused architectural overview functionaliteit. Moody benadrukt immers dat naast de syntax van het model ook de semantiek van de visuele weergave van doorslaggevend belang is voor de communicatie van kennis en informatie (Moody 2009). Alle informatie over de opgebouwde EA zit vervat in de onderliggende Access database. Gebruikers krijgen toegang tot deze informatie door middel van EASE. Toepassing van EASE in de praktijk heeft echter aangetoond dat het opportuun is een functionaliteit aan te bieden die de gebruiker in staat stelt om data uit de EASE omgeving te exporteren. Bijgevolg voorziet EASE de gebruiker van een export functionaliteit naar MS Excel. Een derde functionaliteit voorziet de eindgebruiker van een gebruiksvriendelijk framework voor het uitvoeren van een balanced scorecard analyse. Een dergelijke analyse zet de gebruiker aan het denken en kan inconsistenties of fouten aan het licht brengen. De laatste functionaliteit van het output luik assisteert de eindgebruiker in het toepassen van allerhande best practices en richtlijnen voor het opbouwen van een consistent en coherent EA-‐ model (check inconsistencies). Achtereenvolgens zullen de verschillende functionaliteiten van het output luik meer in detail worden besproken.
67
3.5.1. Focused architectural overview De keuze om de communicatie met de eindgebruiker visueel te laten verlopen vindt zijn oorsprong in het feit dat visuele notaties informatie en kennis op een meer efficiënte manier kunnen overbrengen naar niet technisch geschoolde mensen. Het menselijke brein houdt er immers van om informatie op een visuele manier te ontvangen en is zeer efficiënt in de verwerking ervan, aangezien ongeveer een kwart van ons brein gewijd is aan het zicht. Dat is meer dan alle andere zintuigen gecombineerd. Daarnaast is de kans ook groter dat de informatie op deze manier door de gebruiker effectief wordt onthouden (Moody 2009). Het doel van deze functionaliteit bestaat erin om in te zoomen op het EA-‐model, vertrekkende van het standpunt van een specifieke entiteit binnen de architectuur. De focus ligt op de gekozen entiteit en alle entiteiten waarmee het een relatie heeft. De keuze werd bijgevolg gemaakt om de relaties die weergegeven worden in de visualisatie te beperken tot één niveau. Naast de semantiek van het CHOOSE model ontwikkeld door Bernaert, speelt de visuele syntax een heel belangrijke rol bij de ontwikkeling van een grafische weergave van het model. Het is immers heel belangrijk om een goed inzicht te hebben in de manier waarop visuele notaties kennis communiceren naar de eindgebruiker. Alleen door dergelijke inzichten kan men het communicatieve vermogen van een grafische optekening verhogen. Of zoals Moody het zo mooi zegt: “Description provides the foundation for prescription.”(Moody 2009). Bijgevolg gaan we eerst terug naar de basis alvorens dieper in te gaan op de gebruikte syntax voor de visualisatie van het EA-‐model. Hiervoor doen we een beroep op de ‘theory of diagrammatic communication’ van Moody weergegeven in de onderstaande figuur (Moody 2009).
Afbeelding 34: theory of diagrammatic communication (Moody 2009)
68
Deze theorie is een toepassing van de oorspronkelijke communicatietheorie, ontwikkeld door Shannon en Weaver, op het domein van de visuele notaties. Aan de ene kant bevindt zich de bron, de zender die de gewenste informatie codeert onder de vorm van een visuele weergave. Aan de andere kant bevindt zich de ontvanger die de informatie ontvangt in de visuele vorm en probeert de informatie uit de grafische weergave te decoderen. Voor het coderen en decoderen zullen beide partijen een beroep doen op vooraf vastgelegde regels en overeenkomsten over de visuele notatie. Dit heeft zowel betrekking op de semantiek (CHOOSE) als op de syntax (voorzien door EASE). Het medium is het kanaal waarlangs de visualisatie wordt verspreid. In dit geval de tool EASE. Bij de communicatie van de visualisatie kan er echter storing optreden. Storing is een verzamelnaam voor alle mogelijke soorten willekeurige variaties die kunnen optreden tijdens de communicatie. De effectiviteit van de communicatie wordt uiteindelijk bepaald door de mate van conformiteit tussen de bedoelde en de ontvangen informatie/boodschap. De communicatie kan worden opgesplitst in twee duidelijke processen: coderen (visualiseren) en decoderen (interpreteren). Om communicatie te optimaliseren moeten we rekening houden met beide aspecten: •
coderen: Wat zijn de mogelijkheden waaruit we kunnen kiezen bij het omzetten van informatie naar een visuele vorm. De verzameling van alle mogelijkheden hiervoor wordt door Moody omschreven als de design space.
•
decoderen: Hoe worden visuele notaties door het menselijke brein verwerkt? Dit wordt door Moody aangeduid als de solution space.
De principes die verklaren hoe mensen informatie verwerken, vormen de basis voor het bepalen van de manier waarop de informatie het beste wordt gecodeerd. Beide concepten worden achtereenvolgens meer in detail besproken.
69
3.5.1.1. Design space Bertin identificeert in zijn boek ‘Semiology of Graphics: Diagrams, Networks, Maps’ acht visuele variabelen die de basis vormen voor de ontwikkeling van visuele notaties (Bertin 1983). Deze variabelen vormen een soort van alfabet waarmee de zender visuele notaties kan ontwikkelen voor de visualisatie van een bepaalde boodschap. De verzameling van alle mogelijke combinaties vormt de zogenaamde design space. Onderstaande figuur geeft een overzicht van de acht verschillende visuele variabelen.
Afbeelding 35: visuele variabelen Bertin (Moody 2009)
Variatie in deze visuele variabelen wekken bepaalde responsen op bij de persoon die de visualisatie decodeert. Zo zal een figuur die centraal staat, groter is dan de rest of een opvallende kleur heeft in het oog springen. Dergelijke variaties spelen een gelijkaardige rol als non-‐verbale communicatie tijdens een gesprek en kunnen de gewenste boodschap hetzij verduidelijken hetzij verstoren. Hiervoor gebruikt men de termen primary notation en secondary notation. De primary notation gaat over de formele definitie van een visuele notatie. De secondary notation heeft betrekking op het gebruik van de visuele variabelen die niet formeel gedefinieerd zijn maar die gebruikt worden om de visualisatie kracht bij te zetten of te verduidelijken. Zo kan de primaire notatie van een doelstelling gedefinieerd zijn als een wolk. Om verschillende groepen doelstelling te groeperen, kan men als secondaire notatie werken met verschillende kleuren voor elke groep doestellingen. Men spreekt van visual noise wanneer er ongewenste secondary notations voorkomen die conflicteren met de gewenste boodschap. Het is dus heel belangrijk om voor elke primary notation de secondary notation te bekijken en na te gaan of deze in lijn is met de gewenste boodschap.
70
3.5.1.2. Solution space Mensen kunnen gezien worden als informatieverwerkende systemen. Dagelijks worden we geconfronteerd met gigantische hoeveelheden informatie die ons onder verschillende vormen worden voorgeschoteld. Om een efficiënte visualisatie te ontwikkelen is het daarom nodig om een goed inzicht te hebben in de manier waarop wij informatie verwerken. Hiervoor doen we een beroep op een model van Moody (Moody 2009) die verklaart hoe mensen grafische informatie verwerken. De verwerking gebeurt in twee stappen: •
perceptuele verwerking: Deze stap gebeurt automatisch, zeer snel en in parallel in het menselijke brein.
•
cognitieve verwerking: Deze stap is relatief traag, vergt vrij veel energie en gebeurt sequentieel in het menselijk brein.
Aan de basis van het voordeel van grafische weergaves ligt het feit dat visualisaties een deel van de verwerking verplaatsen van het cognitieve systeem naar het perceptuele systeem dat in staat is om de informatie veel sneller te verwerken. Bovendien komt hierdoor cognitief vermogen vrij dat voordien nodig was voor de verwerking van dezelfde hoeveelheid informatie. Dit vermogen kan nu voor andere taken worden gebruikt. Bijgevolg is het voordeel van visualisaties groter naarmate de grafische weergave in staat is een groter deel van de verwerking van de informatie te laten gebeuren in het perceptuele deel van het brein. Op basis van deze bevindingen is een design theorie (‘The physics of notations’) ontwikkeld door Moody. Deze theorie stelt een set van principes voor die dienen te worden gevolgd voor de ontwikkeling van visuele notaties. Ook Lankhorst stelt in zijn boek ‘Enterprise Architecture at Work’(Lankhorst 2009) enkele richtlijnen voor om de leesbaarheid en het gebruiksgemak van modellen te verhogen. Achtereenvolgens bespreken we beknopt beide theorieën met het oog op de optimalisatie van de visualisering van de EA. Vervolgens gaan we kort in op de beslissingen genomen bij het ontwerp van deze functionaliteit in het programma.
3.5.1.2.1. The physics of notations Moody legt in zijn theorie de nadruk hoofdzakelijk op de fysieke, perceptuele eigenschappen van notaties dan op de logische, semantische eigenschappen. De principes die in deze theorie naar voor worden geschoven, hebben als doel de cognitieve effectiviteit van de grafische weergave te maximaliseren. Cognitieve effectiviteit wordt gedefinieerd als de snelheid, het gemak en de accuraatheid waarmee een visuele representatie kan worden verwerkt door het menselijke brein. Zeven principes zullen kort worden toegelicht en het belang van elk van hen voor de effectiviteit van de communicatie zal worden onderstreept.
71
1. Principle of semiotic clarity Dit principe stelt dat er een 1:1 relatie moet bestaan tussen alle semantische constructen en de grafische symbolen. Het is beter dat er geen homoniemen en synoniemen voorkomen in een grafische taal, zoals dat in gewone taal wel het geval is. 2. Principle of perceptual discriminability Dit principe stelt dat de verschillende symbolen duidelijk van elkaar moeten verschillen. Perceptuele discriminatie heeft betrekking op het gemak en de accuraatheid waarmee de symbolen van elkaar kunnen worden onderscheiden. Om dit in de hand te werken stelt Moody enkele richtlijnen voor zoals bijvoorbeeld visuele afstand, tekstuele differentiatie en perceptuele pop-‐out. 3. Principle of semantic Transparency Gebruik symbolen waarvan visueel reeds het construct kan worden afgeleid. Dit zorgt ervoor dat de eindgebruiker veel sneller en makkelijker de boodschap kan decoderen en bovendien ook de symbolen kan aanleren. Hiervoor kun je gebruik maken van kleur (rood voor gevaar), symbolen die een vertegenwoordiging zijn van het construct (een mannetje voor een werknemer), metaforen (gekruiste pijlen voor een tegenstelling) en veel meer. Een voorbeeld verduidelijkt het belang van dit principe. Onderstaande symbolen worden gebruikt voor procesmodelering (BPMN):
Afbeelding 36: voorbeeld semiotic transparancy (a)
Door de volgende kleine aanpassingen toe te voegen, zal een niet technisch geschoolde gebruiker veel vlugger de mening van de symbolen begijpen en bovendien ook onthouden.
Afbeelding 37: voorbeeld semiotic transparancy (b)
Het voorzien van de kleuren groen, oranje en rood zou de semantische transparantie nog verhogen.
72
4. Principle of complexity management Complexity management heeft betrekking op het vermogen van een visualisatie om informatie te communiceren zonder daarbij de eindgebruiker te overladen met enorme hoeveelheden symbolen. Complexiteit heeft in deze context dus te maken met het aantal elementen die tijdens de visualisatie worden getoond aan de eindgebruiker. Men spreekt in dit opzicht ook wel van diagrammatic complexity. Complexiteit heeft een enorme impact op de effectiviteit waarmee grafische weergaves informatie kunnen communiceren naar de eindgebruiker. De hoeveelheid informatie die door middel van één visualisatie kan worden overgebracht, is afhankelijk van twee factoren: •
perceptual limits: Het vermogen om een onderscheid te maken tussen de elementen van de visualisatie neemt af met het aantal elementen dat de visualisatie weergeeft.
•
cognitive limits: Het aantal elementen die op één grafische weergave kunnen worden begrepen door de eindgebruiker is gelimiteerd door het werkgeheugen van het menselijke brein. Indien dit aantal overschreden wordt, spreekt men van een cognitieve overload en dit gaat gepaard met een exponentiële afname van de begrijpbaarheid van de visualisatie.
Bijgevolg is het duidelijk dat bij de ontwikkeling van een visualisatietool er voorzichtig moet worden omgesprongen met de hoeveelheid informatie die grafisch wordt weergegeven. Complexiteit kan gereduceerd worden door de volgende toepassingen: •
modules: opsplitsen van het geheel in subsystemen.
•
hiërarchieën: opsplitsen van een systeem in verschillende niveaus van detail.
5. Principle of visual expressiveness Dit principe meet hoeveel verschillende visuele variabelen er gebruikt worden bij het opstellen van een grafisch schema en hoe effectief de gebruikte visuele variabelen zijn. Visual expressiveness vertoont vrij veel affiniteit met perceptuele discriminatie (principe 2), desalniettemin is er toch een nuanceverschil. Perceptuele discriminatie zal de symbolen paarsgewijs gaan vergelijken om te zien of er voldoende visuele discriminatie is tussen beide, terwijl visual expressiveness de variatie van visuele variabelen in het volledige grafische schema gaat bekijken. Belangrijk om te weten is dat vorm de meest gebruikte visuele variabele is en tegelijk ook de minst efficiënte. Kleur daarentegen wordt vaak vergeten en is de meest doeltreffende visuele variabele. Verschillen in kleur worden door het menselijke brein immers drie keer zo snel
73
gedetecteerd in vergelijking met verschillen in vorm, en bovendien ook beter onthouden. Toch mag kleur niet de enige visuele variabele zijn die gebruikt wordt om symbolen te onderscheiden van elkaar, aangezien kleur onderhevig is aan een aantal risico’s zoals bijvoorbeeld kleurenblindheid en scherm-‐ en printerkarakteristieken. Een belangrijke richtlijn voor dit principe stelt dat de keuze van de visuele variabelen afhankelijk moet zijn van wat je er wenst mee te bereiken. Zo zal men met kleur, vorm, textuur en oriëntatie enkel nominale constructen kunnen representeren. Een hiërarchie in de constructen zal bijgevolg een beroep moeten doen op visuele variabelen die interval geschaald zijn zoals bijvoorbeeld positionering en grootte. Bijgevolg moet er bij de keuze van de visuele variabelen steeds vertrokken worden van de informatie die men wenst over te brengen naar de eindgebruiker. 6. Principle of dual coding Dit principe pleit voor het gezamenlijke gebruik van tekst en visuele variabelen. Volgens de dual coding theorie van Paivio is het gezamenlijke gebruik van tekst en beeld efficiënter dan elk van beide afzonderlijk (Clark and Paivio 1991). Bovendien verschillen mensen aanzienlijk in hun vermogen om verbale en grafische objecten te interpreteren. Door ze te combineren verhoog je de efficiëntie van de communicatie onafhankelijk van de capaciteiten van de persoon die de visualisatie ontvangt. 7. Principle of graphic economy Dit principe stel dat het aantal verschillende grafische symbolen niet dermate groot mag zijn dat het cognitief niet meer beheersbaar is. Het gaat hier dus om de reductie van grafische complexiteit, nl. het aantal verschillende grafische symbolen dat wordt gebruikt in een visualisatie. Merk op dat dit concept niet gelijk is aan de diagrammatic complexity besproken bij principe vier. Hier gaat het louter over het aantal verschillende grafische concepten en niet over het aantal elementen van die concepten. Door de combinatie van de verschillende visuele variabelen is de ontwerper in staat om oneindig veel verschillende symbolen te creëren voor de visualisatie van de semantische constructen. Het menselijke brein is echter slechts in staat om een eindig aantal van die symbolen ook effectief te onthouden. Naarmate men die grens overschrijdt, daalt de cognitieve effectiviteit van de visualisatie. Moody stelt dat een cognitief efficiënte visualisatie optimaal niet meer dan zes verschillende symboolcategorieën bevat.
74
3.5.1.2.2. Entreprise Architecture at Work De belangrijkste ontwerpdoelstellingen volgens Lankhorst zijn de leesbaarheid en het gebruiksgemak van de modellen en bijgevolg ook van de visualisatie van die modellen. Ook hier wordt de complexiteit van het model als een doorslaggevende factor erkend voor het behalen van die doelstellingen (zie principe 4). Om deze complexiteit te reduceren kan er bij het ontwerpen van het model rekening worden gehouden met de reductie van: •
het aantal elementen in het model
•
het aantal verschillende elementen in het model
•
het aantal relaties die weergegeven worden in het model
Aangezien het echter niet altijd mogelijk is om bovenstaande zaken te reduceren als men de werkelijkheid accuraat wenst te modelleren, stelt men voor om gebruik te maken van viewpoints. Een viewpoint focust op specifieke aspecten van de architectuur en zal die bekijken vanuit het standpunt van een bepaalde stakeholder. Bijgevolg is het voor die persoon niet nodig om alle mogelijke elementen en relaties daadwerkelijk te gebruiken. Door enkel die elementen en relaties weer te geven die voor die specifieke stakeholder van belang zijn, kan aan bovenstaande eisen worden voldaan zonder verlies aan accuraatheid. Naast de complexiteit van de semantiek dient ook rekening te worden gehouden met de complexiteit van de syntax. Deze vorm noemt Lankhorst de visuele complexiteit (zie principe 7). Hier wordt de ontwerper geconfronteerd met een paradox. Enerzijds vraagt de eindgebruiker om een rijke visualisatie die in staat is om grote hoeveelheden informatie te communiceren volgens de viewpoint van de eindgebruiker. Anderzijds kan de eindgebruiker slechts een beperkte mate van complexiteit verwerken. Wordt die grens overschreden, dan neemt de effectiviteit van de visualisatie exponentieel af. Bijgevolg dient bij het ontwerp van dergelijke modellen een juiste balans te worden gevonden tussen beide. Ook hier is opnieuw het concept van de viewpoints belangrijk. Rekening houdende met de doelstelling van de visualisatie en de kenmerken van de stakeholder in kwestie, zal de visualisatie enkel die elementen en relaties bevatten die relevant zijn voor de specifieke situatie. Miller kwantificeert deze doelstelling en stelt dat het menselijke brein in staat is om vijf à negen elementen cognitief te verwerken bij elke visualisatie. Indien het aantal elementen wordt overschreden, kan er gebruik worden gemaakt van abstractie. In plaats van alle elementen weer te geven zullen sommige groepen elementen gegroepeerd worden onder één overkoepelend element. De gebruiker kan dan zelf kiezen om op bepaalde elementen al dan niet dieper in te gaan. Aan deze vereiste is reeds voldaan bij het adjust luik van EASE. Door de gebruiker de mogelijkheid te geven de data van de goal, actor en operatie dimensie automatisch in een boomstructuur te ordenen, wordt er
75
vertrokken van het hoogste niveau van abstractie. De gebruiker kan vervolgens enkel die specifieke takken van de boom bekijken die voor hem/haar relevant zijn. Bovendien worden de relaties met de andere elementen enkel getoond indien de gebruiker er voor kiest om op een bepaald element te klikken. Op deze manier wordt de complexiteit van het EA-‐model sterk gereduceerd en krijgt de gebruiker de autonomie om zelf te beslissen welke informatie wordt weergegeven. Deze boomstructuren zijn echter beperkt in hun vermogen om informatie visueel over te brengen en daarom werd de ‘focused architectural overview’ ontwikkeld om specifiek op bepaalde elementen in te zoomen. Naast het aantal elementen stelt Lankhorst nog vijf andere principes voor die kunnen worden gevolgd voor verdere reductie van de visuele complexiteit. Deze principes zijn gebaseerd op de Gestalttheorie omtrent menselijke perceptie. Door een beter inzicht te verwerven in de menselijke perceptie van visuele modellen, kan bij het ontwerp ervan handig ingespeeld worden op deze kennis. •
Proximity: elementen die dicht bij elkaar staan worden door het menselijk brein onder dezelfde groep gecategoriseerd. Bijgevolg is het opportuun om elementen die hetzelfde semantische concept vertegenwoordigen, te groeperen. Dit principe is eveneens van toepassing op kleur.
•
Continuity: het menselijke brein heeft de neiging om onderbroken lijnen te gaan doortrekken in de richting die de pijl oorspronkelijk aannam. Wanneer pijlen elkaar in de visualisatie kruisen, dient de ontwerper hier rekening mee te houden en te voorkomen dat de richting van de pijl onder invloed van dit principe verkeerd wordt ingeschat.
•
Closure: het menselijk brein heeft de neiging om asymmetrie en onvolledigheid te corrigeren. Bijgevolg zorgt symmetrie en regelmaat voor een verhoogde leesbaarheid van het model en vermindert het de complexiteit en de benodigde cognitieve inspanning.
•
Similarity: mensen hebben de neiging om elementen die er gelijkaardig uitzien te beschouwen als gelijkaardige elementen. Meer nog, elementen die even groot zijn, worden als even belangrijk beoordeeld. Bijgevolg spelen vorm en grootte een belangrijke rol bij de interpretatie van een visualisatie.
•
Common fate: het menselijk brein zal elementen met eenzelfde richting, positie of beweging zien als een eenheid en de verschillende elementen onderbrengen in een groep. Bijgevolg zal in een groep van vier identieke symbolen waarvan er twee licht geroteerd zijn niet één, maar wel twee groepen worden onderscheiden.
76
3.5.1.3. Ontwerp en Functionaliteit De focused architectural overview voorziet de eindgebruiker van de functionaliteit om in te zoomen op een specifieke entiteit van de EA inclusief haar onmiddellijke omgeving. Er werd geopteerd om het aantal elementen te beperken tot die entiteiten die rechtstreeks in verbinding staan met de gekozen entiteit. Op deze manier wordt het aantal elementen die tijdens de visualisatie weergegeven worden, beperkt tot een cognitief verwerkbaar aantal (principe 4). Afbeelding 38 toont het beginscherm van deze functionaliteit. Hier dient de gebruiker de dimensie en vervolgens de entiteit te selecteren die hij/zij wenst te visualiseren. Bovendien wordt opnieuw een beroep gedaan op de zoekfunctionaliteit beschreven in hoofdstuk 3.4 om de gebruiker te assisteren in het zoeken van de entiteit die hij/zij grafisch wenst te bekijken.
Afbeelding 38: focused architectural overview interface
Voor de creatie van duidelijke, begrijpelijke en overzichtelijke visualisaties werd er een beroep gedaan op de principes en richtlijnen afgeleid van de hierboven beschreven theorieën. Afbeelding 39 geeft een samenvattend overzicht van het ontwerp van de visualisatie. Aan elke dimensie van de CHOOSE methode wordt precies één uniek symbool gelinkt (principe 1). De symbolen worden van elkaar onderscheiden door middel van enerzijds kleur en anderzijds positionering op het scherm (principe 2 en 5). Zo kan men goals steeds terugvinden links boven in het scherm in een gele kleur. Op deze manier wordt een deel van de cognitieve verwerking
77
overgenomen door een automatische visuele reflex. Alle goals worden daar immers ook samen gegroepeerd waardoor de gebruiker perceptueel wordt ondersteund in de interpretatie dat alle entiteiten in dat gebied van het scherm en in het geel behoren tot eenzelfde dimensie, namelijk de goal dimensie (proximity, similarity). Daarnaast bevinden alle entiteiten van een dimensie zich in een oppervlak dat dezelfde kleur draagt als de kleur van de dimensie die het bevat. In de focused architectural overview is ervoor gekozen om in tegenstelling tot afbeelding 39 enkel met een gekleurde omtrek te werken om de visualisatie niet te druk te maken en de focus op de entiteiten te houden. Al deze factoren zorgen voor een verhoogde consistentie en voorspelbaarheid wat bijdraagt tot de gebruiksvriendelijkheid en leesbaarheid van de visualisatie.
Afbeelding 39: overzicht opbouw visualisatie
Er dient echter te worden opgemerkt dat er bij de visualisatie geen gebruik is gemaakt van de visuele variabele vorm. Alle dimensies hebben immers een rechthoekige vorm. Dit is een bewuste keuze omwille van twee duidelijke redenen. Enerzijds is vorm de minst efficiënte visuele variabele. Anderzijds pleit principe 3 voor het gebruik van symbolen waarvan visueel reeds het construct kan worden afgeleid. Om dit te doen dient er bijkomend onderzoek gedaan te worden naar dergelijke symbolen voor de vier dimensies van CHOOSE. Omwille van deze redenen is er gekozen om initieel te werken met dezelfde vorm met als aanbeveling om in de toekomst, na bijkomend onderzoek, principe 3 toe te passen. De visuele variabelen worden vervolgens aangevuld met een tekstueel label in de overeenkomstige kleur. Dit label is steeds terug te vinden in de linkerbovenhoek en communiceert via een tekstueel kanaal wat de visuele variabelen reeds wensen over te brengen.
78
De dual coding theorie van Paivio stelt immers dat het gezamenlijke gebruik van tekst en beeld efficiënter is dan elk van beide afzonderlijk (principe 6). Moody stelt dat een cognitief efficiënte visualisatie optimaal niet meer dan zes verschillende symboolcategorieën bevat. Door de sterke reductie van het aantal constructen van de CHOOSE methode, waarop EASE is gebaseerd, wordt er aan deze richtijn voldaan (principe 7). In het algemeen verlaagt de esthetische en symmetrische opbouw van de visualisatie de perceptuele inspanning om de visualisatie te interpreteren (closure). De relaties tussen de verschillende entiteiten worden weergegeven door middel van lijnen. Door de opbouw van het scherm worden kruisende lijnen vermeden en op deze manier potentiële verwarring of onduidelijkheden bij de gebruiker geminimaliseerd (continuity). Daarnaast krijgen de lijnen ook de kleur van de dimensie waarmee de gekozen entiteit een relatie aangaat om eventueel resterende onduidelijkheden volledig weg te werken. Indien er meer dan één relatie mogelijk is tussen entiteiten van een welbepaalde dimensie, dan wordt er gebruik gemaakt van een tekstueel label om te verduidelijken om welk type relatie het specifiek gaat. De hiërarchie tussen entiteiten van eenzelfde dimensie wordt visueel weergegeven door met drie hiërarchische niveaus te werken. Zo zullen de entiteiten die hiërarchisch ondergeschikt zijn aan de gekozen entiteit, zich bijgevolg ook steeds visueel op een lager hiërarchisch niveau bevinden (common fate). Hetzelfde geldt natuurlijk voor de entiteiten die hiërarchisch boven de gekozen entiteit staan. Afbeelding 40 illustreert de focused architectural overview functionaliteit waarbij er ingezoomd wordt op de entiteit ‘ Uitvoeren NPV analyse’ uit het eerder besproken voorbeeld (zie hoofdstuk 3.4 literatuurstudie). Deze automatische visualisatie stelt de gebruiker er toe in staat om de EA te analyseren vanuit verschillende viewpoints en biedt hiermee een oplossing voor één van de algemene zwakten van de huidige toolmarkt (zie literatuurstudie). EASE laat tevens toe dat meerdere visualisatie gegenereerd worden op hetzelfde moment en in hetzelfde scherm. Hoewel de relaties beperkt worden tot één niveau, kan op deze manier enorm veel informatie visueel uit het EA-‐model geëxtraheerd worden door vergelijking en analyse van de verschillende grafische weergaves. Bovendien kan de impact van een optredende verandering in een bepaalde entiteit snel en accuraat worden ingeschat door de gevolgen voor de onmiddellijke omgeving van die entiteit te bestuderen.
79
Afbeelding 40: focused architectural overview
80
3.5.2. Export De casestudies hebben aangetoond dat MS Excel een zeer belangrijke tool is en blijft binnen de omgeving van KMO’s voor de communicatie, transformatie en analyse van data (Osadnik and Landryova 2011). Incorporatie van een functionaliteit die toelaat om data te exporteren van de EASE-‐ naar de Excel-‐omgeving bleek dan ook een sterke toegevoegde waarde te hebben. Eerst dient de gebruiker de dimensie te selecteren waaruit men data wenst te exporteren. Elk van deze dimensies biedt de gebruiker vervolgens een lijst van mogelijkheden. De data kunnen hetzij in de vorm van lijsten geëxporteerd worden, hetzij getransformeerd worden in een meer betekenisvolle representatie. Een voorbeeld hiervan is de combinatie van informatie vervat in de actor en operatie dimensies resulterend in een RACI-‐tabel (responsible, accountable, consulted, informed) (zie afbeelding 41) (Smith, Erwin et al. 2007; ISACA 2012).
Afbeelding 41: export RACI
81
3.5.3. Balanced Scorecard Analyse Een volgende functionaliteit is de balanced scorecard analyse. Hierbij wordt de gebruiker gevraagd om de doelstellingen op zowel het hoogste als het laagste niveau van abstractie te ordenen volgens de vier perspectieven aangeboden door de balanced scorecard (zie afbeelding 40). Hierdoor wordt het management aangespoord om een stap terug te zetten en na te denken of de doelstellingen van de onderneming enerzijds gebalanceerd zijn en anderzijds in lijn zijn met de visie die men heeft over de gewenste toekomstige marktpositie. Bovendien kan EASE de positionering op beide niveaus analyseren en vergelijken met de relaties vervat in de reeds gemodelleerde EA en potentiële inconsistenties tussen beide blootleggen. Deze functionaliteit combineert het denkwerk van de gebruiker met de intelligentie, inherent vervat in de software tool met als resultaat een toegenomen inzicht in en kennis van de onderneming.
Afbeelding 42: ordenen doelstellingen hoogste niveau
82
3.5.4. Check Inconsistenties Een laatste functionaliteit helpt de gebruiker bij de toepassing en naleving van best practices voor het opstellen van een EA. Allerhande restricties worden reeds opgelegd bij de input van de data, maar deze hebben enkel betrekking op hard constraints. Er zijn echter verscheidene soft contraints die niet zonder meer afgedwongen kunnen worden omdat ze de modelleervrijheid zouden beperken. Bij naleving komen ze de algemene kwaliteit van de architectuur echter wel ten goede. Deze functionaliteit heeft bijgevolg als doel om door middel van voorgeprogrammeerde queries dergelijke restricties automatisch te controleren en de gebruiker hierop te wijzen (zie afbeelding 43).
Afbeelding 43: check inconsistenties functionaliteit
Eerst dient de gebruiker een welbepaalde query te selecteren die hij/zij wenst uitgevoerd te zien. Daaropvolgend verschijnt er een uitleg ter verduidelijking waarom de naleving van de gekozen best practice belangrijk is met daarnaast alle entiteiten die ermee conflicteren. Indien gewenst kan de gebruiker vervolgens de entiteiten aanpassen door ze te selecteren en op de ‘adjust’-‐knop te drukken. Hierdoor komt de gebruiker in het adjust venster besproken in hoofdstuk 3.4 van het research scope gedeelte. De gebruiker kan hier de nodige aanpassingen doorvoeren opdat de best practice nageleefd zou worden, hetgeen resulteert in een volledig, consistent en coherent EA-‐model. Afbeelding 43 illustreert opnieuw het voorbeeld besproken in hoofdstuk 3.4 van de literatuurstudie. Hierin zijn zowel de operatie ‘Berekenen WACC’ als de operatie ‘Berekenen cash flows’ niet toegewezen aan een actor via minstens één van de RACI relationshiptypes.
83
4. Evaluatie De evaluatie van EASE is geen duidelijk afgelijnd proces. Er dienen immers verschillende facetten in rekening gebracht te worden om van een complete evaluatie te kunnen spreken. Voor de evaluatie van EASE werden verschillende fasen doorlopen. Elk van deze fasen heeft specifieke karakteristieken en verschilt van de andere met betrekking tot de gebruikte technieken, de partijen die erbij betrokken waren en de uiteindelijke doelstelling(en) ervan. In de eerste fase, tijdens de ontwikkeling van EASE, werden op geregelde tijdstippen voorbeelden uitgewerkt om te controleren of alles correct werkte en om eventuele fouten en bugs uit de software tool te verwijderen. Tijdens deze fase werd er voornamelijk een beroep gedaan op de kennis van de programmeur en theoretische beginselen beschreven in de literatuur. Voor de uitwerking van deze fase werd er gebruik gemaakt van de methodologie van de software proces modellen beschreven in hoofdstuk 1.3 van het research scope gedeelte (Boehm 1988; Sommerville 1996). Bovendien werd hier ook vaak een beroep gedaan op de kennis en de inzichten van Bernaert en Callaert. Bernaert ligt aan de oorsprong van dit onderzoek als uitvinder van CHOOSE. Bijgevolg was er nauwe communicatie vereist om de nieuwste ontwikkelingen met betrekking tot de concepten en relaties van CHOOSE te incorporeren in EASE. Callaert daarentegen voert onderzoek naar de ontwikkeling van een methode voor de implementatie van CHOOSE in de praktijk. Bijgevolg had Callaert waardevolle inzichten over potentiële toepassingen van en mogelijkheden voor een software tool ter ondersteuning van de implementatie, het onderhoud en de analyse van CHOOSE. Tijdens deze fase werd bovendien een eerste versie van EASE voorgesteld aan een Belgische KMO. De ontwikkeling van EASE was echter een proces van lange adem waarbij er een continue opeenvolging van testen, aanpassen en hertesten plaatsvond. Deze fase kan gezien worden als de fase waarin de software tool EASE op punt werd gezet op basis van voorbeelden en korte casestudies. Deze casestudies brachten voordelen, nadelen en potentiële opportuniteiten voor verbetering aan het licht waardoor het gebruiksgemak en de efficiëntie van de tool verder konden worden gemaximaliseerd. Het einde van deze fase wordt gekenmerkt door de eerste volledig operationele versie van EASE. De volgende fase in het evaluatieproces maakt de overgang van de theorie naar de praktijk. Hiervoor werd er een samenwerking vastgelegd met vijf KMO’s van variërende grootte en sector. Voor elk van de deelnemende bedrijven werd het volledige EA-‐model in de software tool EASE ingegeven. Bovendien kregen de verantwoordelijken binnen de verschillende bedrijven een uiteenzetting over de werking en de functionaliteiten van de software tool. Daarnaast diende een beknopte handleiding de nodige ondersteuning te bieden om EASE operationeel te
84
gebruiken in de dagelijkse bedrijfsvoering voor het up-‐to-‐date houden van de EA en voor de analyse van de data erin vervat. Nadat EASE enkele weken operationeel was in de verschillende KMO’s, werd hen een enquête toegestuurd ter bevraging van hun algemene beoordeling van de werking van EASE. Verzameling van dergelijke feedback en terugkoppeling met de vooropgestelde criteria, vormt de basis van een formele evaluatie van de software tool EASE. Het aantal respondenten is echter dermate klein dat het onmogelijk is om statistisch significante uitspraken te doen. Deze bevraging heeft dan ook veeleer de bedoeling een exploratief beeld te schetsen van de meerwaarde van het ter beschikking stellen van EASE ter ondersteuning van de implementatie, het management en de analyse van CHOOSE in de context van KMO’s. In het volgende hoofdstuk gaan we dieper in op de gevolgde werkwijze en worden de belangrijkste bevindingen en beperkingen kort besproken.
4.1. Exploratieve evaluatie 4.1.1. Aanpak Ondanks het feit dat de software tool EASE slechts geïmplementeerd is in een populatie van vijf ondernemingen, zullen er door de doelbewuste diversificatie in enkele kernparameters toch waardevolle uitspraken kunnen worden gedaan over de meerwaarde van EASE ter ondersteuning van CHOOSE in de context van KMO’s. Onderstaande tabel geeft een samenvattend overzicht van enkele belangrijke karakteristieken voor elk van de vijf casestudies.
Tabel 1: overzicht ondernemingen casestudies
Omwille van welbepaalde omstandigheden in het bedrijf van casestudie vijf, is het gebruik van EASE uitgesteld en werd de enquête bijgevolg ingevuld zonder de benodigde operationele kennis die noodzakelijk is om uniform de resultaten te kunnen vergelijken. Bijgevolg zal er bij de bespreking van de resultaten met deze casestudie verder geen rekening gehouden worden.
85
Vooraleer in te gaan op de resultaten van de exploratieve enquête is het belangrijk om een beknopte duiding te geven van het proces voorafgaand aan de enquête. Tot op het moment dat CHOOSE werd voorgesteld, maakte geen enkele van de deelnemende ondernemingen gebruik van EA. Bovendien werd het EA-‐model volledig opgesteld met behulp van de CHOOSE methode in afwezigheid van een software tool ter ondersteuning van dit proces. De ondernemingen werden echter tijdens dit proces wel persoonlijk begeleid bij de toepassing van het metamodel en de methode van CHOOSE. Eenmaal dit proces was afgelopen, kregen de ondernemingen het EA-‐model zowel op papier als in de EASE software tool. Bijgevolg is het belangrijk om in het achterhoofd te houden dat dit proces van persoonlijke begeleiding en EA op papier als referentiepunt zal gebruikt worden door de ondernemingen voor het beoordelen van de stellingen opgenomen in de enquête met betrekking tot EASE. De evaluatie van EASE in deze fase heeft echter een groot nadeel, de bedrijven hebben EASE zelf niet gebruikt om de EA van hun onderneming vanuit het niets op te bouwen. Ze vertrekken van een bestaand EA-‐model en gebruiken de tool om nieuwe data in te geven, aanpassingen door te voeren en om het bestaande EA-‐model te analyseren. Bijgevolg werd EASE in deze ondernemingen vooral gebruikt voor het managen en analyseren van de EA (EAM). Uitspraken over de meerwaarde van EASE voor de implementatie van CHOOSE zullen dus niet voorkomen in deze exploratieve evaluatie. Daarnaast kan een enquête bepaalde nuances niet vatten aangezien het een samenvattende beoordeling vertegenwoordigt van de respondent over een bepaalde periode. Zo kan een respondent bijvoorbeeld in het begin bepaalde moeilijkheden ondervinden. Naarmate hij/zij langer met EASE werkt, verdwijnen deze problemen en worden ze bijgevolg ook niet vermeld bij de beoordeling in de enquête. Desalniettemin kan het waardevol zijn om hiervan op de hoogte te zijn en feedback hieromtrent kan helpen voor de verdere optimalisatie van EASE. Bovendien kunnen dergelijke problemen enkel worden ondervraagd met behulp van open vragen. Vragen van het open type hebben als nadeel dat ze weinig gestructureerd zijn waardoor de respondent enkel de belangrijkste en meest recente zaken vermeldt. Om aan deze tekortkoming tegemoet te komen, werd er bij twee van de vijf ondernemingen nog een aanvullend interview afgenomen met als doelstelling precies dergelijke nuances te achterhalen. In het volgende hoofdstuk worden eerst de belangrijkste resultaten van het exploratieve onderzoek toegelicht. Om het evaluatiehoofdstuk af te sluiten, zal er een beknopt overzicht worden gegeven van de bijkomende bevindingen verkregen door middel van de kwalitatieve interviews.
86
4.1.2. Resultaten Om een algemeen overzicht te krijgen van de voordelen van het ter beschikking hebben van een software tool in de praktijk, werden de respondenten gevraagd enkele stellingen met betrekking tot de voordelen van EASE te beoordelen op een 5-‐punt Likertschaal (van ‘helemaal akkoord’ tot ‘helemaal niet akkoord’). Elke stelling vertaalt een vaak in de literatuur voorkomend voordeel van software tool support voor EA naar de respondent zijn/haar ervaring met EASE (zie tabel 2).
Tabel 2: algemene voordelen EASE
Over het algemeen worden dezelfde voordelen, zoals beschreven in de literatuur, ook teruggevonden in het gebruik van EASE. Een beter overzicht van de onderneming, een reductie van de complexiteit en toegenomen inzicht in de toepassingen van EA komen naar voor als de meest doorslaggevende voordelen van EASE in elk van de vier casestudies. Daarentegen bestaat er meer verdeeldheid over de bijdrage van EASE aan de kwaliteit van de EA en de mogelijkheid om sneller te kunnen werken. Deze verdeeldheid valt mogelijks te verklaren door het proces voorafgaand aan de exploratieve enquête. Het is immers zo dat bij de implementatie van CHOOSE de bedrijven persoonlijk werden begeleid en ondersteund. In het geval er geen dergelijke begeleiding wordt voorzien, kan de software tool EASE dit gebrek in zekere mate opvangen en het maken van bepaalde fouten voorkomen. Aangezien de bedrijven zelf het EA-‐ model van hun onderneming niet hebben ingegeven in EASE, hebben ze mogelijks een vertekend beeld van de voordelen van tool support in deze fase van het EA proces. Daarnaast is het voordeel ‘sneller werken’ voor een fractie te verklaren door een versnelde implementatie van de EA met behulp van EASE. Aangezien de bedrijven in de casestudies de EA reeds gemodelleerd voorgeschoteld kregen, konden ze met dit aspect geen rekening houden bij hun beoordeling ervan.
87
Aan de basis van de meerwaarde van een software tool ter ondersteuning van de adoptie van CHOOSE liggen de concepten perceived usefulness en perceived ease of use van het method evaluation model (MEM) (zie hoofdstuk 3.2.1 research scope). MEM stelt immers dat methodes geen ‘truth value’ maar wel ‘pragmatic value’ hebben in die zin dat een methode enkel kan bestempeld worden als werkzaam of niet werkzaam (efficacy). De validiteit van een methode dient bijgevolg bewezen te worden door het succesvol toepassen van de methode in de praktijk, hier door middel van casestudies. Dit wordt het pragmatisch succes van een methode genoemd en gedefinieerd als de efficiëntie en effectiviteit waarmee een methode de vooropgestelde objectieven verwezenlijkt (Rescher 1977; Moody 2003). EASE is immers zo opgesteld dat door het gebruik ervan de actual usefulness en actual ease of use van CHOOSE verhoogd zouden worden. Om de perceptie van beide concepten te meten, werden de vier ondernemingen gevraagd om beide determinanten te scoren aan de hand van de schalen ontwikkeld door Davis toegepast op EASE (Davis 1989). Aangezien hier gebruik wordt gemaakt van 7-‐punt Likertschalen (van ‘hoogst waarschijnlijk’ tot ‘hoogst onwaarschijnlijk’), kunnen de antwoordmogelijkheden geïnterpreteerd worden als zijnde interval geschaald, met andere woorden er mogen numerieke waarden aan worden toegekend (De Pelsmacker and Van Kenhove 2006). Op deze manier kan er op basis van de zes stellingen een gemiddelde score worden berekend voor de perceived usefulness (PU) en de perceived ease of use (PEU) van EASE.
Tabel 3: evaluatie perceived efficacy EASE
88
Op basis van deze schalen kan er geconcludeerd worden dat EASE in elk van de gevalstudies positief geëvalueerd wordt op zowel PU als PEU. De variatie in de beoordeling is beperkt en gemiddeld gezien is het meer dan waarschijnlijk dat EASE een hoge graad van PU en PEU bewerkstelligt. Wanneer beide met elkaar vergeleken worden, kan men zien dat in drie van de vier casestudies PEU hoger of gelijkwaardig beoordeeld wordt als PU. Dit is mogelijks te verklaren door het feit dat het output luik, een belangrijke determinant van de PU, een beeld schetst van wat mogelijk is, zonder hierbij de indruk te willen scheppen dat de tool compleet en volledig is. Onderzoek naar andere relevante en waardvolle outputfunctionaliteiten kan bijgevolg bijdragen tot een verdere verhoging van de PU (zie hoofdstuk 2 algemeen besluit). PU en PEU worden in het evaluatiemodel van EA voor KMO’s (zie hoofdstuk 3.3 literatuurstudie) gebruikt ter verklaring van criterium 4.6. Om een zicht te krijgen op de mate waarin EASE bijdraagt tot de realisatie van de andere criteria die aan de basis liggen van CHOOSE, werden de respondenten gevraagd om enkele stellingen te beoordelen op een 5-‐punt Likertschaal (van ‘ helemaal akkoord’ tot ‘helemaal niet akkoord’). Deze stellingen vertalen de criteria van het EA evaluatiemodel naar de EASE omgeving en meten de toegevoegde waarde van EASE ter ondersteuning van CHOOSE voor de realisatie ervan. Criterium 4.5 wordt hier niet opgenomen aangezien in elke casestudie de CEO telkens betrokken was bij de implementatie van CHOOSE en EASE.
Tabel 4: beoordeling CHOOSE criteria
Uit de enquête kan er geconcludeerd worden dat EASE in het algemeen bijdraagt tot de realisatie van de criteria vooropgesteld door CHOOSE. Criterium 1 (controle) en 2 (holistisch overzicht) komen hierbij sterk naar voor. Dit is conform de resultaten in tabel 2. De bijdrage van EASE aan criterium 5 (enterprise scope) daarentegen is eerder beperkt. Een mogelijke verklaring hiervoor is dat EASE slechts een beperkte impact heeft op de scope waarop CHOOSE wordt toegepast. Bovendien focust CHOOSE zich voornamelijk op het strategische aspect en is
89
er bijgevolg nood aan integratie en interactie met andere applicaties om alle aspecten van de onderneming in detail in kaart te brengen. Zo zal men voor een gedetailleerde procesbeschrijving een beroep moeten doen op andere methodes en modelleertalen zoals bijvoorbeeld BPMN. De CHOOSE criteria werden bij de ontwikkeling van de software tool reeds in rekening gebracht bij het definiëren en toepassen van de vijf EASE criteria (zie hoofdstuk 2 research scope). Bijgevolg werden de respondenten ook gevraagd om de vooropgestelde design criteria te evalueren op een 5-‐punt Likertschaal (van ‘zeer positief’ tot ‘zeer negatief’) (zie tabel 5).
Tabel 5: beoordeling EASE criteria
Hier worden alle design objectieven als positief of zelfs zeer positief beoordeeld wat bevestigt dat EASE in staat is om de vooropgestelde objectieven te verwezenlijken. Finaliter wordt in afbeelding 44 een overzicht gegeven van de verdeling van de algemene beoordeling van EASE binnen de vier deelnemende ondernemingen. Neutraal
0% Eerder slecht Zeer slecht 0%
Eerder goed 25%
Goed 75%
Zeer goed
Goed
Eerder goed
Neutraal
Eerder slecht
Slecht
Zeer slecht
Afbeelding 44: algemene beoordeling EASE
90
4.1.3. Kwalitatieve interviews Zoals reeds vermeld, geven de resultaten beschreven in hoofdstuk 4.1.2 een algemeen beeld van de evaluatie van EASE. Om echter een inzicht te krijgen in de specifieke uitdagingen en problemen waarmee de deelnemende ondernemingen geconfronteerd werden bij het gebruik van EASE, werd er een aanvullend interview afgenomen bij twee van de vijf respondenten (CS 1 en CS2, waarvan CS1 een KMO is volgens de definitie van de Europese Commissie). Over het algemeen bevestigde het kwalitatieve interview de bevindingen bekomen door middel van de enquête. Desalniettemin kwamen er bij de twee ondervraagde ondernemingen gelijkaardige problemen aan bod die niet naar voor waren gekomen in de exploratieve enquête. Eerst en vooral kwam de eerder abstracte en ingewikkelde terminologie van de concepten en relaties van CHOOSE ter sprake. Bij een gebrek aan kennis van het CHOOSE metamodel, kan de onderneming niet beginnen modelleren omdat de naamgeving van de concepten en relaties onvoldoende eenduidig en vanzelfsprekend is. In het bijzonder wanneer de EA gebruikt zou worden door lager geschoolde werknemers van de onderneming, waren de ondervraagden ervan overtuigd dat deze zeer moeilijk met de tool zouden kunnen werken omdat men eerst voldoende kennis moet hebben over de betekenis van de verschillende concepten van het CHOOSE metamodel. Beide ondernemingen stelden bijgevolg voor om een terminologie te gebruiken aangepast aan het kennisniveau en de doelstelling van de onderneming waarin het gebruikt wordt. Aangezien hierdoor de consistentie verloren gaat tussen de naamgeving in het CHOOSE metamodel en de implementatie in de software tool EASE, is dit geen aanvaardbare oplossing voor het gestelde probleem. Een tegenvoorstel waarbij in elk venster via een helpfunctionaliteit een korte tutorial wordt gegeven van de concepten en relaties gebruikt in dat venster, leek de ondervraagden een waardevol alternatief te zijn. Op deze manier wordt de gebruikte terminologie geïllustreerd met een eenvoudig en verstaanbaar voorbeeld maar blijft de consistentie wat betreft de naamgeving behouden. Bij de implementatie van EASE in de ondernemingen werden dergelijke voorbeelden reeds voorzien in een handleiding. Desalniettemin zal de gebruiker er zelden tot niet naar teruggrijpen en is het noodzakelijk om voorbeelden in EASE zelf te incorporeren. Ten tweede vergen bepaalde functionaliteiten van EASE tijd om geladen te worden en deze tijd neemt toe naarmate de data vervat in de reeds gemodelleerde EA toeneemt. Zoals eerder vermeld, is de mens van nature ongeduldig en kan een te lange wachttijd zijn/haar perceptie van de toegevoegde waarde sterk beïnvloeden. Voor dit probleem zijn er twee mogelijke oplossingen. De eerste oplossing stelt voor om op een gepaste manier met de gebruiker te communiceren waarbij er feedback wordt gegeven over de wachttijd om op deze manier
91
zijn/haar perceptie ervan te beïnvloeden. Deze oplossing heeft echter een beperkt vermogen om effectief een antwoord te formuleren op het wachtprobleem. De tweede oplossing gaat effectief op zoek naar mogelijkheden om de wachttijd werkelijk te reduceren. Toepassing van allerhande heuristieken en algoritmen op de uitgevoerde queries kunnen de efficiëntie van het zoekproces in de database bevorderen. Anderzijds is de wachttijd voor een deel te wijten aan de eerder stroeve interactie tussen de Java interface en MS Access als DBMS. Onderzoek naar een alternatief DBMS met een efficiëntere interactie, kan in dit opzicht dan ook waardevol zijn. Casestudie 1 wees ook op de opportuniteit om de kleuren die gebruikt worden bij de visualisatie van de EA-‐modellen door te trekken doorheen de volledige EASE software tool. Kleuren kunnen immers ondersteunend werken en de efficiëntie van het programma verder verhogen. Desalniettemin kan overmatig of verkeerd gebruik van kleur ook voor verwarring zorgen en storend werken. Bijkomende casestudies dienen het potentieel van een dergelijke ingreep te onderzoeken vooraleer het effectief toe te passen als standaard in EASE. Anderzijds was er een duidelijk verschil waar te nemen in de evaluatie van de meerwaarde van CHOOSE en EASE in de verschillende ondernemingen. Casestudie 2 wordt gekenmerkt door een zeer stabiele omgeving, duidelijk afgelijnde doelstellingen, processen en verantwoordelijkheden en finaal ook een beperkte mate van complexiteit. De respondent in casestudie 2 vond het gebruik van CHOOSE en EASE dan ook waardevol als denkoefening maar was minder geïnteresseerd in de toepassingen en het gebruik van het resulterende EA-‐model. In casestudie 1 was er opvallend meer interesse in het gebruik en de analyse van de EA-‐modellen . Ook de overige ondernemingen waren gretig om op de hoogte te blijven van de nieuwste ontwikkelingen van EASE. Het kan bijgevolg interessant zijn om na te gaan onder welke specifieke omstandigheden CHOOSE en software tool support met behulp van EASE het meest waardevol zijn.
92
Algemeen besluit 1. Conclusie De groeiende belangstelling in het bedrijfsleven voor EA in combinatie met de ontdekking van de kloof tussen de vereisten van KMO’s en de functionaliteiten van de beschikbare EA technieken, heeft geleid tot de ontwikkeling van CHOOSE. Toepassing van CHOOSE in de praktijk door middel van casestudies benadrukte de potentiële meerwaarde van software tool support. Dit was dan ook de aanzet voor het onderzoek naar de ontwikkeling van een software tool ter ondersteuning van het EA proces in de context van KMO’s. De hoofddoelstelling van de literatuurstudie was het verzamelen van kennis voor de identificatie, beschrijving en motivatie van het probleem dat aan de basis ligt van het onderzoek. Uit de literatuurstudie kan er geconcludeerd worden dat CHOOSE op een gepaste manier inspeelt op de huidige tekorten van de markt en KMO’s voorziet van een EA techniek die voldoet aan duidelijk vooropgestelde criteria met als doel de reductie van complexiteit zonder verlies aan relevante informatie. Bovendien blijkt zowel uit de literatuur als in de praktijk dat voor de ontwikkeling, opslag en analyse van een coherente en volledige architectuur een tool noodzakelijke ondersteuning kan bieden om deze moeilijke uitdaging tot een goed einde te brengen. Analyse van het huidige aanbod aan tools benadrukt de nood aan en het belang van een nieuwe software tool, specifiek ontwikkeld ter ondersteuning van het EA proces in de context van KMO’s rekening houdende met de tekortkomingen en zwakten op de huidige toolmarkt. In het research scope gedeelte van deze thesis wordt een uitgebreide uiteenzetting gegeven over het volledige ontwikkelingsproces inclusief evaluatie van de software tool EASE (Enterprise Architecture SME Environment). Voor een planmatige en gestructureerde uitwerking van dit proces, wordt er enerzijds een beroep gedaan op een eigen ontwikkelde methodologie en anderzijds worden allerhande criteria, principes en richtlijnen afgeleid die bij naleving de toegevoegde waarde van de software tool voor de doelgroep verhogen. Evaluatie van EASE door middel van casestudies in vier Belgische ondernemingen bracht aan het licht dat zowel de CHOOSE criteria als de EASE criteria goed tot zeer goed worden gerealiseerd. Bovendien blijkt uit de enquête dat door het gebruik van EASE de perceived usefulness en de perceived ease of use verhoogd worden, wat zou moeten bijdragen tot een verhoogde adoptie van CHOOSE. In het algemeen wordt EASE door alle respondenten positief geëvalueerd en kan er geconcludeerd worden dat het onderzoek in de opzet ter ontwikkeling van een waardevolle
93
software tool ter ondersteuning van CHOOSE is geslaagd. Desalniettemin zijn er beperkingen verbonden aan deze thesis die verder dienen te worden onderzocht. Het volgende hoofdstuk gaat hier dieper op in en stelt mogelijks waardevolle aanvullingen voor toekomstig onderzoek voor.
2. Beperkingen en richtlijnen voor verder onderzoek Net als in elk ander onderzoek zijn er beperkingen verbonden aan de ontwikkeling van EASE die men in het achterhoofd dient te houden. Eerst en vooral kan er niet gesproken worden van een volledig afgewerkte software tool. De ontwikkeling van EASE is immers een iteratief proces van evaluatie en ontwikkeling waarbij op basis van de verkregen feedback aanpassingen worden doorgevoerd voor de verdere optimalisatie ervan. Bijgevolg geeft de huidige versie van EASE een beeld van wat mogelijk is zonder hierbij de indruk te willen scheppen dat de tool volledig is. In het bijzonder het output luik valt hieronder te klasseren. Naast de functionaliteiten beschreven binnen deze thesis zijn er allerlei andere potentieel waardevolle toepassingen die niet in de huidige versie van EASE geïncorporeerd zijn omwille van de beperkte tijd. Het kan dus interessant zijn om door middel van bijkomstige casestudies en literatuuronderzoek dergelijke functionaliteiten te identificeren en vervolgens te ontwikkelen. Reeds aangehaald bij de beschrijving van de evaluatie, wordt EASE momenteel operationeel gebruikt in vier ondernemingen. Bij de implementatie van EASE werd er echter reeds vertrokken van een model dat opgebouwd was in afwezigheid van ondersteuning door EASE. Uitspraken met betrekking tot de meerwaarde van EASE in de eerste fase van EA implementatie kunnen dus niet gemaakt worden. Het kan bijgevolg interessant zijn om een gelijkaardig proces te doorlopen waarbij van het prille begin reeds gestart wordt met EASE voor het opbouwen van de EA. Bovendien kunnen er waardevolle inzichten en kennis worden bekomen door observatie van de gebruiker in zijn/haar interactie met EASE. Uit de evaluatie zijn er reeds potentiële verbeteringen van de software tool door de gebruiker aangehaald. Een belangrijkste beperking van de huidige versie van EASE is de eerder trage interactie tussen de EASE interface en de Access database waarin alle data is opgeslagen. Om de efficiëntie van de tool te maximaliseren dient de cycle time van dergelijke interacties zo kort mogelijk gehouden te worden. Een studie naar en de toepassing van (meta-‐)heuristieken en algoritmen voor de optimalisatie van queries zou in dit opzicht kunnen bijdragen tot de vraag naar verhoogde efficiëntie.
94
Momenteel is EASE ontwikkeld voor het gebruik in single-‐user omgevingen. Door de database eenvoudigweg te verplaatsen in de cloud (vb. op een lokaal netwerk), kunnen er meerdere gebruikers werken aan een en dezelfde EA. Een dergelijke aanpak houdt echter allerhande risico’s in met betrekking tot veiligheid (vertrouwelijke data, autorisatie, toegankelijkheid, etc.) en synchronisatie van data. Onderzoek naar een multi-‐user omgeving en de ontwikkeling van een ondersteunend systeem kunnen in dit opzicht zeer waardevol zijn. Ten laatste is er een algemeen pijnpunt gerelateerd aan de implementatie van EA binnen de context van KMO’s, namelijk de algemene ingesteldheid en de beschikbare tijd. Zoals reeds vermeld in de literatuurstudie, nemen KMO’s meestal niet de tijd om strategisch na te denken over hun onderneming omdat de dagdagelijkse bedrijfsvoering in de ogen van de bedrijfsleiders vaak primeert. De brandjes-‐blus-‐mentaliteit is een vaak voorkomend fenomeen waarbij de dringende (vaak minder belangrijke) zaken voorrang krijgen op minder dringende maar vaak veel belangrijkere zaken in de toekomst. Bij de verklaring van de lage adoptie van EA binnen de context van KMO’s dient men bijgevolg zeker ook rekening te houden met een dergelijke ingesteldheid. Naast de ontwikkeling van EASE dienen de KMO’s bijgevolg ook opgevoed te worden om hen te laten inzien dat wanneer men de tijd neemt om een stap terug te zetten en de onderneming te analyseren met een duidelijke visie naar de toekomst, men meer dan evenredig tijd zal uitsparen door simpelweg dergelijke problemen te vermijden.
95
Lijst van de geraadpleegde werken Bernaert, M. (2011). "De zoektocht naar know-‐how, know-‐why, know-‐what en know-‐ who: architectuur voor kleinere bedrijven in vier dimensies." INFORMATIE (AMSTERDAM) 53(9): 34-‐41. Bernaert, M. and G. Poels (2013). "Enterprise architecture management for small and medium sized enterprises: a case study and tool support." INFORMATION SYSTEMS AND E-‐BUSINESS MANAGEMENT. Bernaert, M., G. Poels, et al. (2013). Enterprise architecture for small and medium-‐sized enterprises: a starting point for bringing EA to SMEs, based on adoption models. Information systems and small and medium-‐sized enterprises (SMEs) : state of art of IS research in SMEs. J. Devos, H. Van Landeghem and D. Deschoolmeester. Berlin, Germany, Springer. Bertin, J. (1983). "Semiology of graphics: Diagrams, networks, maps." Madison, WI: The University of Wisconsin Press, Ltd. Bhagwat, R. and M. Sharma (2007). "Information system architecture: a framework for a cluster of small-‐and medium-‐sized enterprises (SMEs)." Prod Plan Control 18(4): 283-‐296. Boehm, B. W. (1988). "A spiral model of software development and enhancement." Computer 21(5): 61-‐72. Braun, C. and R. Winter (2005). "A comprehensive enterprise architecture metamodel and its implementation using a metamodeling platform." EMISA: 24-‐25. CHI Research Inc. (2004). "Small Firms and Technology: Acquisitions, Inventor Movement, and Technology Transfer." Retrieved January 23, 2013, from http://www.smallbusinessnotes.com/small-‐business-‐resources/small-‐firms-‐and-‐ technology-‐acquisitions-‐inventor-‐movement-‐and-‐technology-‐transfer.html.
Clark, J. M. and A. Paivio (1991). "Dual coding theory and education." Educational psychology review 3(3): 149-‐210. Davis, F. D. (1989). "Perceived usefulness, perceived ease of use, and user acceptance of information technology." MIS Q: 319-‐340.
X
Davis, F. D., R. P. Bagozzi, et al. (1989). "User acceptance of computer technology: a comparison of two theoretical models." Management science 35(8): 982-‐1003. De Pelsmacker, P. and P. Van Kenhove (2006). Marktonderzoek: methoden en toepassingen, 2/e, Pearson Education. Delmotte, J., L. Sels, et al. (2001). "Personeelsbeleid in KMO’s: een onderzoek naar de kenmerken van een effectief KMO-‐personeelsbeleid." Over.Werk. Tijdschrift van het Steunpunt WAV 11(4): p. 98-‐105. Devos, J., H. Van Landeghem, et al. (2012). "Rethinking IT governance for SMEs." Industrial Management & Data Systems 112(2): 206-‐223. Ernst, A. M., J. Lankes, et al. (2006). Tool support for enterprise architecture management-‐strengths and weaknesses. EDOC, IEEE. European Commission. (2006). "De nieuwe definitie van KMO’s: informatiebrochure en modelverklaring. ." Retrieved January 25, 2013, from http://ec.europa.eu/enterprise/policies/sme/index_en.htm.
European Commission. (2008). "Minimizing regulatory burden for SMEs: Adapting EU regulation to the needs of micro-‐enterprises." Retrieved April 15, 2013, from http://ec.europa.eu/enterprise/policies/sme/small-‐business-‐act/.
Galitz, W. O. (2007). The essential guide to user interface design: an introduction to GUI design principles and techniques, Wiley. Hevner, A. R., S. T. March, et al. (2004). "Design science in information systems research." MIS Q 28(1): 75-‐105. Hobart, J. (1995). "Principals of Good GUI Design." Retrieved November 9(2004): 10-‐95. Hudson Smith, M. and D. Smith (2007). "Implementing strategically aligned performance measurement in small firms." International Journal of Production Economics 106(2): 393-‐408. ISACA. (2012). "COBIT 5." from http://www.isaca.org/COBIT/Pages/COBIT-‐5-‐Framework-‐ product-‐page.aspx.
Jonkers, H., M. Lankhorst, et al. (2006). "Enterprise architecture: Management tool and blueprint for the organisation." Inf Sys Front 8(2): 63-‐66.
XI
Kaisler, S. H., F. Armour, et al. (2005). Enterprise architecting: Critical problems. HICSS, IEEE. Lankhorst, M. (2009). Enterprise architecture at work: Modelling, communication and analysis, Springer. Lybaert, N. (1998). "The information use in a SME: its importance and some elements of influence." Small Business Economics 10(2): 171-‐191. March, S. T. and G. F. Smith (1995). "Design and natural science research on information technology." Decis Support Syst 15(4): 251-‐266. Moody, D. (2009). "The 'Physics' of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering." IEEE Trans Softw Eng 35(6): 756-‐779. Moody, D. L. (2003). The method evaluation model: a theoretical model for validating information systems design methods. ECIS, Naples, Italy, June. Objectiver. (2013). "Objectiver: general overview." Retrieved February 15, 2013, from http://www.objectiver.com/index.php?id=6.
Osadnik, P. and L. Landryova (2011). Principles of key performance indicators for small and medium enterprise in European union. Carpathian Control Conference (ICCC), 2011 12th International, IEEE. Peffers, K., T. Tuunanen, et al. (2007). "A design science research methodology for information systems research." J Manage Inform Syst 24(3): 45-‐77. Rescher, N. (1977). Methodological pragmatism: A systems-‐theoretic approach to the theory of knowledge, New York University Press New York. Respect-‐IT. (2010). "Objectiver." from http://www.objectiver.com/. Small Business Administration, U. S. (2012). "What is a Small Business?" Retrieved March, 2012, from http://www.sba.gov/size. Smith, M. L., J. Erwin, et al. (2007). "Role & responsibility charting (RACI)." Online: http://www.pmforum. org/library/tips/pdf_files/RACI_R_Web3_1. pdf, abgerufen
am 17: 2007. Sommerville, I. (1996). "Software process models." ACM Comput Surv 28(1): 269-‐271.
XII
Vervenne, W. (2010). Kmo's sterkste motor Belgische economie: Kleine en middelgrote ondernemingen leveren ruim de helft van onze welvaart. De Tijd. Brussel: 1. Wieringa, R. and J. M. G. Heerkens (2006). "The methodological soundness of requirements engineering papers: a conceptual framework and two case studies." Requir Eng 11(4): 295-‐307. Zachman International. (2011). "Zachman Version 3.0." from http://www.zachman.com. Zachman, J. A. (1996). "The framework for enterprise architecture: background, description and utility." Zachman International.
XIII
Bijlagen Bijlage 1: Vragenlijst exploratieve evaluatie EASE
XIV
XV
Bijlage 2: Resultaat casestudie 1 -‐ Profile Tyrecenter ABS
XVI
XVII
XVIII
Bijlage 3: Resultaat casestudie 2 -‐ FSA Universiteit Gent
XIX
XX
XXI
Bijlage 4: Resultaat casestudie 3 -‐ Sanicomfort
XXII
XXIII
XXIV
Bijlage 5: Resultaat casestudie 4 -‐ Cavalier
XXV
XXVI
XXVII
Bijlage 6: EASE programma en database Zie bijgevoegde cd-‐rom Programma starten Ga naar de map CHOOSE 1 > dist en voer de executable jar file CHOOSE.jar uit. Op de cd-‐rom staan tevens de volgende databases: •
Case.mdb: de database waarin het voorbeeld van hoofdstuk 3.4 van de literatuurstudie is opgenomen.
•
Leeg.mdb: een lege database waarvan men kan starten om een nieuw EA-‐model op te bouwen
•
FSA.mdb: de database die het EA-‐model van casestudie 1 bevat.
•
ABS.mdb: de database die het EA-‐model van casestudie 2 bevat.
•
Sanicomfort.mdb: de database die het EA-‐model van casestudie 3 bevat.
•
Cavalier.mdb: de database die het EA-‐model van casestudie 4 bevat.
•
Christeyns.mdb: de database die het EA-‐model van casestudie 5 bevat.
XXVIII
