EASE is de architect voor het MKB

EASE is de architect voor het MKB
Midden-en kleinbedrijven nemen vaak niet de tijd om strategisch na te denken over de planning en richting van hun onderneming. EASE is een softwaretool die begeleiding en ondersteuning biedt: zo wijst enterprisearchitectuur ook in het MKB de weg naar succes.
Als u van plan bent een huis te bouwen of te verbouwen, doet u wellicht een beroep 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 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 vergelijkbaar proces kan men onderscheiden bij het opstarten, runnen of uitbouwen van een onderneming. Een onderneming is een complex systeem van mensen, kennis, projecten en processen, samengebracht voor het realiseren van een gedeelde gemeenschappelijke visie. Enterprisearchitectuur 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.
Enterprisearchitectuur werd oorspronkelijk hoofdzakelijk door informatici gebruikt, waardoor de nadruk aanvankelijk op de structurering van informatiesystemen lag en daaropvolgend op het op elkaar afstemmen van business en IT. Het concept is zich echter in de loop der jaren steeds meer gaan richten op het structureren van de business en tegenwoordig bestaan er verscheidene toepassingen over de grenzen van IT heen. Hoewel er veel onderzoek wordt gedaan naar enterprisearchitectuur, is er veel onbekendheid over het gebruik van enterprisearchitectuur in de omgeving van midden- en kleinbedrijven. De implementatie van enterprisearchitectuur blijkt een zeer complex en uitdagend proces te zijn. Het MKB zou door het gebruik van enterprisearchitectuur aanzienlijke voordelen kunnen realiseren. Toch is de adoptie ervan ver beneden peil en maakt zo goed als geen enkele MKB’er er effectief gebruik van.
Enkele onderzoekers leverden pionierswerk: zij ontwikkelden een enterprisearchitectuurmethode die was aangepast aan de specifieke karakteristieken van het MKB, genaamd CHOOSE (Bernaert and Poels 2011; Bernaert, Poels et al. 2013). Uit casestudies met de CHOOSE-methode is gebleken dat softwaretoolsupport aanzienlijk kan bijdragen aan het verbeteren van de adoptie van enterprisearchitectuur in het MKB. In dit artikel beschrijven wij de ontwikkeling van de softwaretool EASE (Enterprise Architecture SME Environment) ter ondersteuning van CHOOSE in de implementatie, het management en het onderhoud van enterprisearchitectuur in het MKB.
CHOOSE
CHOOSE is een enterprisearchitectuurmethode voor het MKB die is afgeleid uit de kernelementen van bestaande enterprisearchitectuurmethodes en gebaseerd op Einsteins principe ‘Everything should be made as simple as possible, but not simpler’ (Bernaert and Poels 2011). CHOOSE is een acroniem voor ‘keep Control, by means of a Holistic Overview, based on Objectives and kept Simple, of your Enterprise’. Elke letter verwijst naar één van de vijf criteria waaraan een enterprisearchitectuurmethode moet voldoen, afgeleid uit Lankhorsts definitie en beschrijving van enterprisearchitectuur (Lankhorst 2009):
1. Controle: enterprisearchitectuur 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 enterprisearchitectuur is dat het een allesomvattend overzicht verschaft van de onderneming. Enterprisearchitectuur is dus gericht op de fundamenten van de onderneming omdat deze stabieler en minder vergankelijk zijn dan tijd- en plaatsafhankelijke oplossingen voor specifieke problemen waarmee het bedrijf geconfronteerd wordt.
3. Objectieven: enterprisearchitectuur helpt bij het vertalen van de ondernemingsstrategie naar de dagelijkse bedrijfsvoering. Het is belangrijk dat de strategie op het hoogste niveau vertaald wordt naar begrijpelijke doelstellingen voor werknemers op het laagste niveau zodat de strategie uitgewerkt kan worden.
4. Aangepast aan de doelgroep: de enterprisearchitectuur moet zo zijn opgebouwd dat iedereen die erbij betrokken is deze begrijpt.
5. Enterprisescope: Deze aanpak helpt de onderneming in zijn geheel te optimaliseren in plaats van lokaal verbeteringen door te voeren. De CHOOSE-aanpak is gericht op het MKB vanwege twee duidelijke redenen. Ten eerste omdat het belang van het MKB in de huidige economie enorm groot is. Ten tweede omdat de enterprisearchitectuurmethodes die momenteel beschikbaar zijn deze doelgroep vaak over het hoofd zien. Het MKB is immers fundamenteel verschillend van een multinational en vraagt dan ook om een eigen unieke aanpak (zie criterium
4). Om hieraan te kunnen voldoen, is er uitgebreid onderzoek gedaan naar de eigenschappen en karakteristieken van het MKB (Devos, Van Landeghem et al. 2012). Dit heeft geleid tot zes criteria voor enterprisearchitectuur in een MKB-context die gezien kunnen worden als subcriteria voor criterium 4 (Bernaert, Poels et al. 2013):
4.1. De ontwikkelde enterprisearchitectuurmethode moet het MKB 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 enterprisearchitectuurmethode.
4.3. Weinig tot geen hulp van externe experts moet vereist zijn voor het werken met de ontwikkelde enterprisearchitectuurmethode.
4.4. De ontwikkelde enterprisearchitectuurmethode 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 enterprisearchitectuur.
4.6. De verwachte opbrengsten moeten de ver-wachte kosten en risico’s overtreffen.
Op basis van de criteria uit figuur 1 werd de CHOOSE-methode ontwikkeld. De kerndimensies zijn: een strategische dimensie (waarom), een actieve dimensie (wie), een operatie dimensie (hoe) en een object dimensie (wat) (figuur 2) . Geïntegreerd voorzien deze dimensies de gebruiker van een holistisch overzicht van hun bedrijf.
Figuur 1. Overzicht evaluatiecriteria enterprisearchitectuurmethode in het MKB
 
Figuur 2. De vier dimensies van CHOOSE
Belang softwaretool
Het is belangrijk om de feitelijke adoptie na te gaan om het succes van de CHOOSE-methode te bepalen. Zelfs al is de ontwikkelde enterprisearchitectuuraanpak technisch superieur of perfect afgestemd op het MKB, zolang deze bedrijven het niet effectief gebruiken, zullen de voordelen nooit gerealiseerd worden. Het is daarom belangrijk om de adoptie door het MKB zo vlot mogelijk te laten verlopen. Hiervoor kan een beroep worden gedaan op verschillende modellen die de adoptie van Informatiesystemen (IS) en IS-methodes verklaren. Het technology acceptance model (TAM) is uitermate bekend en wordt veel gebruikt (Davis 1989). Het method evaluation model (MEM) is een uitbreiding van TAM voor de evaluatie van methodes en kan dus waardevolle inzichten verschaffen bij de analyse van de adoptie van CHOOSE ( figuur 3 ).
Figuur 3. Het Method Evaluation Model
Gebaseerd op het Method Evaluation Model werden de volgende richtlijnen afgeleid voor de optimalisatie van de adoptie van de enterprisearchitectuurmethode CHOOSE door middel van EASE:
• Verhogen actual efficacy: Het gebruik van de softwaretool kan de actual efficacy van CHOOSE verhogen doordat deze de gebruiker voorziet van de noodzakelijke begeleiding en ondersteuning bij de implementatie en toepassing van de enterprisearchitectuurmethode en het metamodel.
• Verhogen perceived efficacy: Bij de verklaring van het menselijk gedrag is de subjectieve realiteit vaak belangrijker dan de objectieve realiteit en dus medieert perceived efficacy de impact van actual efficacy op adoptie in de praktijk (Bernaert, Poels et al. 2013).
• Van intention to use naar actual usage: De werkelijke toepassing in de praktijk door middel van casestudies zal waardevolle inzichten opleveren met betrekking tot de eerste twee richtlijnen. Indien dit niet gebeurt, zal er nooit overgegaan worden 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. Incorporatie van deze richtlijnen in de ontwikkeling van EASE zou moeten bijdragen tot een hogere adoptie en toegevoegde waarde van de enterprisearchitectuurmethode CHOOSE.
De academische literatuur benadrukt ook de behoefte aan softwaretoolsupport ter ondersteuning van enterprisearchitectuur in de praktijk. In het algemeen onderscheidt men drie kritieke probleemgebieden in het enterprisearchitectuurproces: het modelleren, het managen en het onderhouden van enterprisearchitectuur. Een belangrijke oorzaak van problemen binnen deze gebieden is de doorgaans enorme complexiteit van het uitgewerkte enterprisearchitectuurmodel. Het is immers zo dat enorm veel informatie onder de vorm van data en relaties dient opgebouwd en opgeslagen te worden. Deze informatie verspreidt zich bovendien vaak 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 gekoppeld te worden. Deze codering vergt veel energie en is bovendien vaak een broeiplaats van fouten. Uit het bovenstaande is duidelijk dat een softwaretool noodzakelijke ondersteuning kan bieden voor de ontwikkeling, opslag en analyse van een coherente en volledige architectuur om deze moeilijke uitdaging tot een goed einde te brengen. In vele bedrijven dient men bovendien vaak een beroep te doen op methodes ontwikkeld voor een specifiek businessdomein. Deze stellen de architect echter niet in staat om een ‘big picture’ te creëren. Aangezien een belangrijke doelstelling van enterprisearchitectuur erin bestaat om over de functionele grenzen heen een holistisch beeld te verkrijgen van de organisatie, betekent dit dat de beschikbare methodes tekort schieten. Dit ondersteunt opnieuw de visie waarin de behoefte aan geïntegreerde methodes voor de opbouw, analyse en communicatie van de enterprisearchitectuur naar de verschillende stakeholders centraal staat (Jonkers, Lankhorst et al. 2006). Andere voordelen van een softwaretool zijn (Lankhorst, 2009):
• Een tool kan helpen bij het standaardiseren van de semantiek en de syntax die worden gebruikt bij het opstellen van architecturale modellen binnen een onderneming.
• 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.
• Een tool kan de architect ondersteunen in het gebruik van architecturale patronen of het hergebruik van bepaalde delen van de architectuur of oplossingen die al voorhanden zijn binnen de onderneming.
• Een tool faciliteert het vergelijken van alternatieven door middel van ‘impact of change’ en kwantitatieve analyses. Hoewel bovengenoemd onderzoek het belang van een softwaretool bevestigt, kunnen deze bevindingen niet zomaar geëxtrapoleerd worden naar de omgeving van het MKB en het belang van een tool voor de implementatie van de CHOOSE-methode. Toch bevestigt lopend casestudieonderzoek de behoefte aan een softwaretool bij het uitbouwen van enterprisearchitectuur in het MKB. In deze casestudies werd de CHOOSE-methode toegepast in zes verschillende middelgrote en kleine bedrijven door middel van eenvoudige whiteboards met post-its. Tijdens een van deze studies werd deze methode aangevuld met een eerste versie van EASE. Vergelijking van beide bevestigde duidelijk de toegevoegde waarde van het ter beschikking hebben van EASE ter ondersteuning van het enterprisearchitectuurproces.
Belang nieuwe softwaretool
De meeste van de op de markt beschikbare tools zijn gebaseerd op enterprisearchitectuurframeworks, zoals Zachman en TOGAF. Deze
helpen voornamelijk bij de beslissing welke business- en technologische gebieden in de architectuur opgenomen dienen te worden en voorzien ondersteuning op een hoog niveau van abstractie. Daarentegen bieden ze weinig tot geen begeleiding voor de effectieve uitwerking en onderhoud van de enterprisearchitectuur zelf. Er bestaan tools die wel effectief kunnen helpen bij de uitwerking van de architectuur zelf, zoals bijvoorbeeld MS Visio. Deze en gelijkwaardige tools zijn echter niet gericht op het enterprisearchitectuurproces en niet aangepast aan de omgeving van het MKB. Hierdoor bevatten ze vaak overbodige en potentieel verwarrende functionaliteiten terwijl er andere functionaliteiten voor het MKB kunnen ontbreken omdat ze niet gewaardeerd worden door het bredere publiek. Bovendien vertonen de momenteel beschikbare tools enkele algemene zwakten. • De meeste tools ondersteunen geen automatische visualisatie van data. Bovendien wordt er 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. Maar een verscheidenheid aan belangrijke functionaliteiten (zoals het hergebruik van bepaalde delen van de architectuur) wordt niet ondersteund door dergelijke tools. • De meeste beschikbare tools worden aangeboden met een vooraf vastgelegd standaard metamodel. Deze metamodellen zijn vaak ofwel te klein, waardoor ze niet in staat zijn om de enterprisearchitectuur van de onderneming te ondersteunen, ofwel te groot, waardoor het gebruiksgemak en de leesbaarheid van het model afneemt. • De meeste tools voorzien een bepaald metamodel maar bieden geen methode aan op basis waarvan men de enterprisearchitectuur kan opbouwen.
Op basis van deze inzichten spreekt het voor zich dat de ontwikkeling van een softwaretool ter ondersteuning van CHOOSE de toegevoegde waarde van enterprisearchitectuur voor het MKB significant kan verhogen.
Criteria voor EASE
De eerste stap in het ontwikkelingsproces bestaat uit een uitgebreide literatuurstudie met als hoofddoel de vertaling van de criteria van het evaluatiemodel (figuur 1) in algemene richtlijnen voor softwaretoolsupport. Dit proces resulteert in de volgende designobjectieven voor EASE:
1. Simplicity: EASE moet eenvoudig in gebruik zijn en toelaten om met behulp van een gebruiksvriendelijke interface de gewenste functionaliteiten uit te voeren. Door de eenvoud van EASE zou de drempel voor de implementatie van enterprisearchitectuur 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 en 5).
2. Efficiency: De input van de gebruiker moet geminimaliseerd worden. Hiermee wordt bedoeld dat de tijd, moeite en kosten voor het gebruik van EASE zo laag mogelijk dienen gehouden te worden. EASE moet het dus mogelijk maken om zeer tijdsefficiënt te werk te gaan. Bovendien draagt het simplicitycriterium bij aan de ontwikkeling van een tool met een zeer steile leercurve, waardoor de kosten voor opleiding en acclimatisatie aan het programma sterk wordt gereduceerd (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 gebruiker 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 richtlijnen en best practices voor de opbouw van een enterprisearchitectuur 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 enterprisearchitectuur binnen het MKB beperkt is, is het belangrijk voor de adoptie dat EASE de taal van de gebruiker gebruikt. In het geval van het MKB is dat de bedrijfstaal (criteria 4.2, 4.3, 4.5, 5).
5. Completeness: EASE moet in staat zijn om het volledige enterprisearchitectuurproces van het begin tot het einde te ondersteunen. Bovendien dient er rekening gehouden te worden met de algemene zwakten van de huidige beschikbare tools om te voorkomen dat soortgelijke fouten worden gemaakt. Alleen op deze manier kan gegarandeerd worden dat EASE de gebruiker maximaal helpt bij het formuleren van een antwoord op de bestaande tekorten en verlangens (criteria 2, 4.4, 5).
Deze algemene objectieven worden aangevuld met criteria die specifiek gerelateerd zijn aan softwaretoolsupport zoals modulariteit, flexibiliteit en hergebruik. Deze criteria zijn van nature vrij technisch en bespreken we hier niet in detail.
Toolontwikkeling
Door middel van een literatuurstudie over het gebruik van enterprisearchitectuur en door het toepassen van de CHOOSE-methode in zes Belgische MKB-organisaties werden de volgende probleemgebieden geïdentificeerd:
• Input: Dit betreft het omzetten van de beschikbare kennis en informatie naar het effectieve enterprisearchitectuurmodel gebruikmakend van de semantiek en syntax aangeboden door CHOOSE. De enorme hoeveelheid data, het dynamische en gefragmenteerde karakter van dergelijke informatie en de onderlinge afhankelijkheden maken dit proces complex en tijdrovend. Het spreekt voor zich dat begeleiding en ondersteuning een enorme meerwaarde kan leveren op dit vlak. Bovendien kunnen door het gebruik van EASE bepaalde constraints afgedwongen worden waardoor een verhoogde naleving van vooropgestelde richtlijnen, best practices en regels van het metamodel ontstaat in vergelijking met de eerder besproken tekentools waar alles mogelijk is.
• Opslag: Eenmaal gemodelleerd zal de architectuur opgeslagen dienen te worden om deze te kunnen raadplegen, aanpassen of analyseren. Bij gebrek aan toolsupport zal de data fysiek, bijvoorbeeld door middel van post-its op whiteboards of in het beste geval in een zelfgemaakte 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 enterprisearchitectuur, in staat zijn om efficiënt te reageren op deze verhoogde behoefte aan flexibiliteit en reactiesnelheid. EASE maakt het mogelijk om de architecturale artefacten eenvoudig 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 enterprisearchitectuur teruggevonden en opgehaald moeten worden. EASE kan dit proces sterk faciliteren en de inspanning significant reduceren.
• Analyse: Afhankelijk van de stakeholder, zal de informatie vervat in de architectuur op een andere manier bekeken worden. Het is dan ook noodzakelijk dat verschillende ‘viewpoints’ mogelijk zijn. Bovendien kan het nodig zijn om de informatie vervat in de architectuur onder een andere vorm aan de gebruiker voor te stellen en eventueel ook te exporteren, rekening houdende met het kennisniveau, de achtergrond en doelstelling van de stakeholder in kwestie. Bovendien kan men door de analyse van de enterprisearchitectuur bepaalde inconsistenties en onregelmatigheden blootleggen en oplossen.
Input, adjust en output
Gebaseerd op deze inzichten werd EASE opgebouwd rond drie hoofdfunctionaliteiten: input, adjust en output (figuur 4) . De softwaretool is ontwikkeld met Java als programmeertaal en MS Access als databasemanagementsysteem (DBMS). In het vervolg van dit artikel geven we een beknopt overzicht van de belangrijkste kenmerken en features van de tool. Waar mogelijk zullen we deze illustreren met behulp van een basisvoorbeeld: een bedrijf heeft de doelstelling om de verkoop van een bepaald product x te verhogen en zal dit doen door enerzijds te investeren in de huidige afzetmarkt en anderzijds op zoek te gaan naar nieuwe afzetmarkten. We eindigen het artikel met een bespreking van het evaluatieproces.
Figuur 4. Hoofdmenu inclusief drie hoofdfunctionaliteiten
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 aan de gebruiker voorgesteld door middel van een gebruiksvriendelijke en intuïtieve interface. De eerste stap is een keuze maken uit de vier dimensies van de CHOOSE-aanpak en vervolgens worden alle mogelijke relaties die een entiteit van de gekozen dimensie kan aangaan, weergegeven in een overzichtelijk venster.
Figuur 5 illustreert de input van een goal met behulp van EASE.
Figuur 5. Input van een entiteit in de goal dimensie
Vooraleer EASE alles wegschrijft in de onderliggende database, worden er allerlei restricties gecontroleerd met als doel het behoud van eenconsistent en coherent enterprisearchitectuurmodel. Zo zal EASE bijvoorbeeld niet toelaten dat een doelstelling zowel als hoger en als lager liggende doelstelling wordt toegewezen aan de nieuwe entiteit. Mochten dergelijke inconsistenties voorkomen, dan wordt de gebruiker 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 EASE alle informatie opslaan in de onderliggende database en dit gebeurt volledig automatisch. 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 gebruiker hier ook maar iets van hinder van ondervindt.
Adjust
EASE biedt een aantal mogelijkheden waarmee de gebruiker moeiteloos uit het enterprisearchitectuurmodel bepaalde entiteiten, 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 gebruiker, zoals geïllustreerd in figuur 6 .
Figuur 6. Zoekfunctionaliteit (Edit data)
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 relevant zijn. Door deze sterke reductie in complexiteit wordt een holistisch overzicht behouden zonder de gebruiker te overladen met irrelevante en potentieel verwarrende details (figuur 7) . Daarnaast kan de gebruiker door op een bepaalde entiteit te klikken alle hiermee gerelateerde elementen laten weergeven volgens de visuele representatie uit figuur 2. Door consistent deze structuur toe te passen weet de gebruiker altijd waar te zoeken om informatie terug te vinden met betrekking tot één van de vier dimensies van CHOOSE. Dit draagt bij tot het algemene gebruiksgemak en de efficiëntie van EASE.
Figuur 7. Overzicht boomstructuur
Output
In het outputgedeelte helpt EASE de informatie vervat in het enterprisearchitectuurmodel om te vormen in waardevolle kennis en inzichten. De verschillende outputonderdelen bespreken we beknopt. De ‘focused architectural overview’ voorziet de gebruiker van de functionaliteit om in te zoomen op een specifieke entiteit van het enterprisearchitectuurmodel inclusief de onmiddellijke omgeving. Deze automatische visualisatie laat toe om het model te analyseren vanuit verschillende viewpoints en biedt hiermee een oplossing voor één van de algemene zwakten van de huidige toolmarkt. Bovendien kan op deze manier de impact worden ingeschat van een optredende verandering in een bepaalde entiteit door de gevolgen voor de onmiddellijke omgeving van die entiteit te bestuderen. Voor de creatie van duidelijke, begrijpelijke en overzichtelijke visualisaties werden inzichten bekomen door middel van een uitgebreide literatuurstudie naar de visuele perceptie en syntax van modelleertools. Figuur 8 geeft een voorbeeld van deze feature.
Figuur 8. Focused architectural overview
De casestudies hebben aangetoond dat MS Excel een zeer belangrijke tool is en blijft binnen de omgeving van het MKB voor de communicatie, transformatie en analyse van data. 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. De data kan 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 operatiedimensies resulterend in een RACI-tabel (responsible, accountable, consulted, informed) (figuur 9) .
Figuur 9. Export RACI-tabel
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 naar gelang de vier perspectieven aangeboden door de balanced scorecard (figuur 10) .
Figuur 10. Ordenen doelstellingen hoogste niveau
 
Hierdoor wordt het management aangespoord 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 enterprisearchitectuur en de potentiële inconsistenties tussen beide blootleggen. Deze functionaliteit combineert het denkwerk van de gebruiker met de intelligentie inherent vervat in de softwaretool met als resultaat een toegenomen inzicht in en kennis van de onderneming.
Een laatste functionaliteit helpt de gebruiker bij de toepassing en naleving van best practices voor het opstellen van een enterprisearchitectuur. Allerhande restricties worden reeds opgelegd bij de input van de data, maar deze hebben enkel betrekking op ‘hard constraints’. Er zijn echter verscheidene ‘soft constraints’ 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 dus als doel om door middel van voorgeprogrammeerde queries dergelijke restricties automatisch te controleren en de gebruiker hierop te wijzen (figuur 11) . Indien gewenst kunnen deze opmerkingen geïncorporeerd worden, hetgeen resulteert in een volledig, consistent en coherent enterprisearchitectuurmodel.
Figuur 11. Check inconsistenties functionaliteit
Conclusie
De eerste stap in het evaluatieproces bestond eruit om EASE te laten testen door verschillende personen die vertrouwd zijn met het enterprisearchitectuurproces en de onderliggende concepten. Deze testen brachten voordelen, nadelen en potentiële kansen voor verbetering aan het licht, waardoor het gebruiksgemak en de efficiëntie van EASE verder werden gemaximaliseerd. De volgende stap bestaat erin om met behulp van EASE de architectuur van het MKB effectief te modelleren. Op deze manier wordt de softwaretool toegepast in de omgeving waarvoor het ontwikkeld werd en kunnen zeer waardevolle inzichten en feedback worden verkregen. Momenteel is er een samenwerking vastgelegd met zes MKB-organisaties van variërende grootte en sector. EASE is reeds in vier van de zes ondernemingen operationeel. Verzameling van feedback en terugkoppeling met de vooropgestelde criteria vormt de basis van de formele evaluatie, validatie en optimalisatie van EASE. Wilt u op de hoogte blijven van verdere ontwikkelingen of EASE zelf testen? Neem een kijkje op de EASE-blog: eatoolsupport.wordpress.com.
 
Dennis Ingelbeen is juli 2013 afgestudeerd als Handelsingenieur, afstudeerrichting Operationeel Management. E-mail: dennis.ingelbeen@ugent.be
Maxime Bernaert heeft tijdens zijn doctoraat aan de Universiteit Gent CHOOSE ontwikkeld voor het gebruik van Enterprise Architectuur in kleinere bedrijven. Hierbij is de focus van complexiteit van bestaande Enterprise Architectuur technieken naar eenvoud en bruikbaarheid in CHOOSE verschoven. E-mail: maxime.bernaert@ugent.be.
 
Referenties
Bernaert, M. and G. Poels (2011). “De zoektocht naar knowhow, know-why, know-what en know-who: architectuur voor kleinere bedrijven in vier dimensies.” Informatie (Amsterdam) 53(9): 34-41.
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.
Davis, F. D. (1989). “Perceived usefulness, perceived ease of use, and user acceptance of information technology.” MIS quarterly: 319-340.
Devos, J., H. Van Landeghem, et al. (2012). “Rethinking IT governance for SMEs.” Industrial Management & Data Systems 112(2): 206-223.
Jonkers, H., M. Lankhorst, et al. (2006). “Enterprise architecture: Management tool and blueprint for the organisation.” Information Systems Frontiers 8(2): 63-66.
Lankhorst, M. (2009). Enterprise architecture at work: Modelling, communication and analysis, Springer.
 

Tag

Mkb

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag