Enterprise Architecture at Bedrijf X

Bedrijf X

Hessel M. Hoekstra

Januari 2007

Auteur:

Hessel M. Hoekstra

Studentnummer:

1141406

Organisatie:

Bedrijf X

Opdrachtgever Bedrijf X:

Anton Bakkum

Inhoudelijke begeleider Bedrijf X:

Bert Aaltsz

Mentor Bedrijf X:

Michiel van Wijk

Datum:

26 januari 2007

Begeleiders van de Rijksuniversiteit Groningen

Faculteit bedrijfskunde:

Eerste begeleider:

Dr. H. Balsters

Tweede begeleider:

Dr. A. Boonstra

Voorwoord

De scriptie die voor u ligt, is geschreven ter afronding van mijn studie Technische Bedrijfswetenschappen (IT) en vormt het resultaat van mijn afstudeeronderzoek bij Bedrijf X. Voor deze organisatie heb ik gedurende mijn onderzoek met plezier op de IT-afdeling in Utrecht gezeten.

Ik wil iedereen bedanken waarmee ik heb gesproken binnen Bedrijf X. Ik heb veel geleerd van de gesprekken die de ene keer wat makkelijker gingen dan de andere. Toch heb ik altijd genoeg tijd gehad om voldoende vragen te stellen hoe onsamenhangend ze ook waren.

Naast een bedankje aan alle medewerkers van de IT-afdeling, wil ik in het bijzonder mijn begeleider Bert Aaltsz bedanken. Als een waar docent kon hij mij theorie€n duidelijk maken waar ik anders nog heel hard voor had moeten studeren en dat allemaal tussen zijn drukke werkzaamheden door.

Daarnaast wil ik mijn opdrachtgever bedanken voor het bieden van deze kans in Utrecht en mijn mentor voor de voortgangsbewaking en zijn terugkoppelmomenten.

Tenslotte wil ik mijn eerste begeleider van de universiteit Groningen de heer Balsters bedanken voor zijn luisterend oor, de feedback en zijn oneindige geduld. Mijn tweede begeleider de heer Boonstra wil ik bedanken voor zijn snelle en duidelijke commentaar en natuurlijk zijn coulantheid.

Als allerlaatste wil ik iedereen bedanken, die op welke manier dan ook een bijdrage hebben geleverd aan mijn scriptie.

Hessel Hoekstra Groningen, april 2006

N.B.: Dit is de publieke versie van mijn scriptie en daardoor zijn er delen van mijn verslag gecensureerd of veranderd.

Samenvatting

Dit onderzoeksverslag rapporteert over de resultaten van een afstudeeronderzoek uitgevoerd bij de IT-afdeling van Bedrijf X.

Bedrijf X ondervindt problemen op het gebied van risicomanagement en

klantmanagement. Het is tijdrovend en duur om een overzicht te verkrijgen over de aard van de verrichte en de te verrichten werkzaamheden bij klanten. Daarnaast is het niet eenvoudig een compleet overzicht te verkrijgen van benaderde potentiele klanten door de afzonderlijke business units.

Om tot een gezamenlijke (IT) visie te komen vanwege de uiteenlopende bedrijfstakken. Er zal naar overeenkomsten tussen de verschillende Business Units moeten worden gezocht

en knelpunten behoren uit de weg te worden geruimd om een optimale

informatievoorziening te garanderen. Voor een hechtere samenwerking is afstemming nodig tussen de business en IT. De business-IT alignment is dan ook het hoofdprobleem van Bedrijf X NL

.

De aanpak dient zich te richten op de afstemming van de geautomatiseerde en niet geautomatiseerde informatiestromen op de huidige en toekomstige behoeften zoals die binnen de ‘business’ spelen. Om dit te doen, is het noodzakelijk een referentiekader te defini€ren welke gebruikt gaat worden door de verschillende Business Units. Een referentiekader (‘framework’) waarbinnen alle toekomstige en in principe ook lopende projecten dienen te worden afgestemd. Een ‘framework’ waarmee de architectuur van de

business, de informatiestromen, de informatiesystemen alsmede alle hiermee

samenhangende functionele en technische aspecten, worden vastgelegd.

Het is van belang dat de huidige stand van zaken met betrekking tot architectuur en business-IT alignment inzichtelijk wordt gemaakt. Belangrijke knelpunten kunnen op deze manier worden geƒdentificeerd. Een manier om dit inzicht te bieden, is gebruik te maken van een model dat de volwassenheid van architectuur en business-IT alignment meet. De hoofdvraag voor het onderzoek is dan ook:

‘Wat is het niveau van volwassenheid van de Enterprise Architecture van Bedrijf X NL Nederland en hoe kan Bedrijf X in de toekomst groeien op het gebied van de Enterprise Architecture om de business-IT alignment te bevorderen?’

Het beantwoorden van deze vraag wordt in dit verslag vooraf gegaan met een theoretisch kader met betrekking tot de business-IT alignment en Enterprise Architecture. Voor de beschrijving van business-IT alignment binnen Bedrijf X is gebruik gemaakt van de theorie van Luftman en de theorie van Henderson en Venkatraman.

Raamwerk

Vervolgens is er een literatuuronderzoek uitgevoerd voor het selecteren van een geschikt meetraamwerk van de volwassenheid van architectuur binnen Bedrijf X. Gekozen is voor het Architecture Capability Maturity Model, welk ontwikkeld is door de US Department of Commerce, vanwege het feit dat de binnen dit model gehanteerde dimensies toereikend en toepasbaar zijn binnen Bedrijf X. Deze dimensies vormen de leidraad voor het beschrijven van het architectuurdenken binnen Bedrijf X en zijn onderstaand weergegeven:

 Business linkage  Governance

 IT-investeringsstrategie  Communicatie

 Senior management betrokkenheid  Werkvloer participatie

 Architectuurproces

 Ontwikkeling onder architectuur  Programma management

Per dimensie kan een score worden behaald varierend van 0 als laagste waarde tot 5 als hoogste waarde. Volgens het gehanteerde model wordt eindwaardering bepaald door de laagste score in de reeks van dimensies.

Beoordeling van het architectuur-volwassenheidsniveau

Aan de hand van interviews met personen uit verschillende lagen van de organisatie en interne documentatie kan de hoofdvraag worden beantwoord. Deze hoofdvraag is gesplitst in twee delen. Het eerste deel is:

‘Wat is het niveau van volwassenheid van Enterprise Architecture van Bedrijf X?’

Het niveau van volwassenheid van architectuur binnen Bedrijf X is volgens de Architecture Capability Maturity Model van de Department of Commerce gewaardeerd op 1 (zie paragraaf 7.4.2). Architectuur speelt momenteel binnen Bedrijf X op territoriaal niveau een kleine rol. De doelstellingen met betrekking tot architectuur zijn vaag en er zijn weinig procedures gedefinieerd ter ondersteuning van het werken ‘onder architectuur’. Door wet-en regelgeving wordt er nu hard gewerkt aan het opzettwet-en van ISO gecertificeerde afdelingen. Het documenteren van processen en procedures komt hier aan bod, maar er is geen relatie met een architectuurraamwerk. Dit heeft te maken het ontbreken van een architectuurraamwerk. Het werken met standaarden vindt hoofdzakelijk zijn weerslag op technisch niveau en zijn voornamelijk gebaseerd op de standaarden die zijn gedefinieerd door Bedrijf X Global.

Uit het onderzoek blijkt dat de dimensies over het algemeen hetzelfde scoren (niveau 2) met als uitzonderingen de drie dimensies: business linkage, ontwikkelen onder architectuur en governance.

Voor business linkage en het ontwikkelen onder architectuur geldt een niveau van 1, doordat de doelstellingen van architectuur vaag zijn gedefinieerd en het management weinig betrokkenheid toont. Het ontbreekt aan een formele link tussen de business en EA. Het ontbreken van heldere doelstellingen, het missen van een architectuurraamwerk en het federatieve karakter van Bedrijf X leidt tot een lage score voor business linkage en het ontwikkelen onder architectuur.

Governance valt op vanwege zijn relatief hoge score van 3. De belangrijke overlegorganen benodigd voor het werken ‘onder architectuur’ zijn aanwezig en gedocumenteerd. Het ontbreekt echter aan daadkracht. Dit heeft te maken met de afwezigheid van beslissingsbevoegdheid van de overlegorganen.

Enterprise Architecture kent een nauwe relatie met business-IT alignment. De business-IT alignment van Bedrijf X is onderontwikkeld. De federatieve inslag van Bedrijf X, de

partnerstructuur en de onduidelijke belegging van verantwoordelijkheden en

bevoegdheden die hieruit voortkomt, staan een heldere en formele IT-alignment in de weg. Er wordt geconstateerd dat de CIO een senior Business Unit board member niet kan overrulen als er een beslissing is gemaakt die niet strookt met de vastgestelde IT-strategie. De in de IT-strategie uitgezette prioriteiten moeten immers leidend zijn. Er is te weinig daadkracht en verantwoordelijkheid in de CIO office belegd.

Ook het ontbreken van een formeel architectuur raamwerk waarmee keuzes voor applicaties en informatiesystemen moeten worden gestuurd, werkt de ongewenste diversiteit en versnippering van platformen in de hand.

Verbetervoorstellen

De geformuleerde verbetervoorstellen komen voort uit het tweede deel van de hoofdvraag:

‘Hoe kan Bedrijf X in de toekomst groeien op het gebied van de Enterprise Architecture om de business-IT alignment te bevorderen?’

Naar aanleiding van de eerste deelvraag zijn er knelpunten geƒdentificeerd. De knelpunten bevinden zich in de volgende gebieden:

 EA raamwerk

 Werken ‘onder architectuur’

 Communicatie

Voor elk gebied is er een verbetervoorstel geschreven. In de samenvatting worden deze in het kort beschreven voor een uitgebreidere versie verwijs ik naar hoofdstuk 9 van dit verslag.

Managementstructuur

Delegeer beslissingsbevoegdheid en budgetten naar beslissingsorganen. Dit zijn voormalige overlegorganen en verander de samenstelling van deze organen. Delegeer bevoegdheden en verantwoordelijkheden naar de Informatie Managers ten aanzien van IT-zaken.

EA raamwerk

Definieer het EA raamwerk voor Bedrijf X NL in de vorm van referentiemodellen en standaarden. Belangrijk hierbij is de actieve houding en steun van het senior management. Betrek daarnaast de Informatieb Managers bij het opstellen en inrichten van een EA raamwerk.

Werken ‘onder architectuur’

Toets IT-investeringen, projecten, oplossingsrichtingen en applicaties vooraf aan een EA raamwerk. Laat (DTAG) architecten in een vroeg stadium participeren in de oplossingsdefinitie en –keuze. Het in een later stadium laten reviewen van documenten is niet voldoende.

Communicatie

Communiceer doelstellingen, strategie, oplossingrichtingen, keuzes, afspraken,

standaarden en referentiemodellen tot op alle lagen van de organisatie. Publiceer deze via een centraal medium.

Samenvattend kan worden gesteld dat architectuur binnen Bedrijf X een kleine rol speelt. Er is geen EA raamwerk, de business-IT alignment is niet volwassen door het ontbreken van voldoende gedelegeerde bevoegdheden en verantwoordelijkheden. De benodigde verbeteringen richten zich dan ook op de navolgende aandachtsgebieden: opstellen van een EA raamwerk, het aanscherpen van de governance structuur met een belangrijke rol voor de Informatie Managers.

Inhoudsopgave

-1.3 CENTRALE DIENSTVERLENING &DE IT-AFDELING... 10

-HOOFDSTUK 2: METHODOLOGISCHE VERANTWOORDING ... 11

-2.1 INLEIDING... 11

-2.2 INITIEEL PROBLEEM... 11

-2.3 PROBLEEMSTELLING... 12

-2.4 DE RANDVOORWAARDEN: ... 12

-2.5 CONCEPTUEEL MODEL EN DEELVRAGEN... 13

-2.6 ONDERZOEKSOPZET... 14

-HOOFDSTUK 3: BUSINESSIT ALIGNMENT ... 16

-3.1 INLEIDING... 16

-3.2 ALIGNMENT... 16

-3.3 ALIGNMENT VOLGENS VERSCHILLENDE THEORIEËN... 17

-3.3.1 Luftman... 17

-3.3.2 Henderson en Vekantraman... 18

-3.4 RELATIE MET ARCHITECTUUR... 20

-3.5 SAMENVATTING... 21

-HOOFDSTUK 4: DE ENTERPRISE ARCHITECTURE... 22

-4.1 INLEIDING... 22

-4.2 ARCHITECTUUR... 22

-4.3 DOEL/NUT VAN ARCHITECTUUR... 23

-4.4 ENTERPRISE... 23

-4.5 ENTERPRISE ARCHITECTURE... 24

-4.6 ENTERPRISE ARCHITECTUUR RAAMWERK... 25

-4.7 INVENTARISATIE EA-RAAMWERKEN... 26

-4.7.1 Business architectuur... 28 -4.7.2 Informatie architectuur... 28 -4.7.3 Technologie architectuur... 28 -4.7.4 Applicatie architectuur ... 29 -4.7.5 Data Architectuur ... 29 -4.8 VIEWPOINT EN VIEWS... 30 -4.9 STAKEHOLDERS... 31 -4.10 PRINCIPES... 31 -4.11 TIJDSASPECT... 32 -4.12 ZACHMAN FRAMEWORK... 32 -4.13 DYA ... 33 -4.14 SAMENVATTING... 35

-HOOFDSTUK 5: HET ARCHITECTURE MATURITY MODEL ... 37

-5.1 INLEIDING... 37

-5.2 ARCHITECTUUR VOLWASSENHEID VOLGENS VERSCHILLENDE THEORIEËN... 38

-5.2.1 Capability Maturity Model ... 38

-5.2.3 OMB Architecture Maturity Assessment Framework ... 40

-5.2.4 Nascio EA Maturity Model ... 43

-5.2.5 De Architecture scorecard... 45

-5.2.6 Enterprise Architecture Management Maturity Framework ... 46

-5.3 CONCLUSIE... 47

-5.3.1 Onderbouwing ... 47

-5.3.2 Slotsom ... 49

-HOOFDSTUK 6: BUSINESSIT ALIGNMENT BIJ BEDRIJF X ... 50

-6.1 INLEIDING... 50

-6.2 GOVERNANCE... 50

-6.2.1 Organisatiestructuur... 50

-6.2.2 Commissies en organen ... 51

-6.2.3 Bedrijf X als federatieve instelling... 52

-6.2.4 IT Governance historie binnen Bedrijf X... 53

-6.2.5 de ITafdeling ... 53 -6.2.6 Project governance... 54 -6.3 STRATEGIE... 54 -6.3.1 De strategie opbouw ... 54 -6.3.2 Henderson en Venkatraman... 55 -6.3.3 Business leidend ... 56 -6.4 COMMUNICATIE... 56 -6.4.1 Overlegorganen ... 56 -6.4.2 Managementstijl ... 57 -6.4.3 Associatie (partnership)... 57 -6.4.4 Vaardigheden... 58 -6.5 PRESTATIEMETING... 58

-6.5.1 Kostenstructuur van de ITafdeling ... 59

-6.5.2 De ITafdeling als cost center... 60

-6.5.3 SLA’s... 60 -6.5.4 Project management ... 61 -6.6 ARCHITECTUUR... 61 -6.7 CONCLUSIE... 62 -6.7.1 Onderbouwing ... 62 -6.7.2 Slotsom ... 62

-HOOFDSTUK 7: ARCHITECTUUR BINNEN BEDRIJF X ... 63

-7.1 INLEIDING... 63

-7.2 ARCHITECTUUR VOLGENS BEDRIJF X... 63

-7.3 HET METEN VAN VOLWASSENHEID VAN ARCHITECTUUR... 64

-7.3.1 Business linkage ... 65

-7.3.2 Governance... 67

-7.3.3 IT investeringsstrategie ... 69

-7.3.4 Communicatie van architectuur... 71

-7.3.5 Senior management betrokkenheid ... 73

-7.3.6 Werkvloerparticipatie ... 75

-7.3.7 Architectuurproces gedefinieerd... 76

-7.3.8 Ontwikkeling onder architectuur ... 81

-7.3.9 Programma management... 83

-7.3.10 Holistische Enterprise Architecture... 86

-7.3.11 Security ... 88 -7.4 CONCLUSIE... 90 -7.4.1 Onderbouwing ... 90 -7.4.2 Slotsom ... 91 -HOOFDSTUK 8: EINDCONCLUSIE ... 92 -8.1 INLEIDING... 92

-8.2 BUSINESS-ITALIGNMENT CONCLUSIE... 92

-HOOFDSTUK 9: VERBETERVOORSTEL ... 95

-9.1 INLEIDING... 95

-9.2 AANBEVELINGEN:MANAGEMENTSTRUCTUUR... 95

-9.3 AANBEVELINGEN: EARAAMWERK... 96

-9.4 AANBEVELINGEN: WERKEN ‘ONDER ARCHITECTUUR’ ... 97

-9.5 AANBEVELINGEN: COMMUNICATIE... 97

-9.6 SAMENVATTING AANBEVELINGEN... 98

LITERATUURLIJST ... 99

LIJST VAN FIGUREN ... 101

LIJST VAN TABELLEN... 102

AFKORTINGENLIJST ... 104

-Hoofdstuk 1: Bedrijf X

1.1 Inleiding

Dit hoofdstuk zal een introductie geven van het bedrijf Bedrijf X. 1.2 De organisatie

Binnen Bedrijf X worden de verschillende takken ‘Business Units’ (Business Unit) genoemd. Om de beste service aan de klant te kunnen bieden, dienen de Business Units optimaal te functioneren. Om dit te garanderen zijn er verschillende afdelingen binnen de organisatie die de Business Units ondersteunen. Samen vormen deze ondersteunende afdelingen Centrale Dienstverlening (FS).

1.3 Centrale Dienstverlening & de IT -afdeling

De IT-afdeling (de IT-afdeling) is de interne automatiseringsafdeling van Bedrijf X Nederland. Deze afdeling is verantwoordelijk voor het onderhoud en beheer van applicaties en biedt diverse diensten aan op het gebied van consultancy, projectmanagement, netwerk-, applicatie- en werkplekbeheer, gebruikersondersteuning en aanleg, beheer, onderhoud van ICT infrastructuur.

de IT-afdeling Nederland is opgebouwd uit de volgende teams:

 CIO Office;

 Service Management & Projects;

 Customer Services;

 Technology Infrastructure;

Hoofdstuk 2: Methodologische verantwoording

2.1 Inleiding

In dit hoofdstuk wordt de onderzoeksopzet nader toegelicht. Allereerst wordt de aanleiding van het onderzoek besproken en daarna de probleemstelling met bijbehorende doel- en vraagstelling. Vervolgens worden aan de hand van het conceptuele model de deelvragen geformuleerd. Als laatste zal de aanpak van het onderzoek worden weergegeven.

2.2 Initieel probleem

Vanwege grote boekhoudschandalen zoals Enron, Worldcom en Parmalat is de overheidsbemoeienis ten aanzien van boekhouden en financi€le verslaggeving vergroot. Dit resulteerde in meer regulatie vanuit de overheid. De overheid bereikt dit door het aanpassen van de wet- en regelgeving. Wetten zoals Sarbanes Oxley zijn opgezet om beursgenoteerde bedrijven ‘in control’ te laten zijn.

Binnen Bedrijf X speelt risicomanagement een grote rol, omdat op grond van wet- en regelgeving hoge eisen worden gesteld aan de dienstverlening naar clienten. Dit impliceert dat de benodigde klantinformatie volledig, juist en betrouwbaar dient te zijn. Momenteel

ondervindt Bedrijf X problemen op het gebied van risicomanagement en

klantmanagement. Het is tijdrovend en duur om een overzicht te verkrijgen over de aard van de verrichte en de te verrichten werkzaamheden bij klanten. Daarnaast is het niet eenvoudig een compleet overzicht te verkrijgen van benaderde potenti€le klanten door de afzonderlijke business units.

Er is een rapportagebehoefte geformuleerd door de business en deze informatiebehoefte moet worden afgestemd met de IT. Deze afstemming is onderdeel van de business-IT alignment van Bedrijf X. Voor een goede afstemming moet er een kader zijn waarbinnen deze plaatsvindt: het raamwerk. Dit raamwerk omvat procedures, richtlijnen en afspraken ten aanzien van de business-, informatie- en technologie architectuur. Om het raamwerk te kunnen toepassen moet er een duidelijke belegging zijn van verantwoordelijkheden in een heldere beslissingsstructuur. De afstemming zal leiden tot wijzigingen of vernieuwingen binnen de informatievoorziening. Om deze wijzigingen of vernieuwingen daadwerkelijk te kunnen doorvoeren is capaciteit in de vorm van mensen en/of middelen noodzakelijk. Dit zal leiden tot het definieren van specifieke programma’s en projecten. Het is voor Bedrijf X moeilijk om tot een gezamenlijke (IT) visie te komen vanwege de uiteenlopende bedrijfstakken. Er zal naar overeenkomsten tussen de verschillende Business Units gezocht moeten worden en knelpunten behoren uit de weg te moeten geruimd om een optimale informatievoorziening te garanderen. Voor een hechtere samenwerking is afstemming nodig tussen de business en IT. De Business-IT alignment is

dan ook het hoofdprobleem van Bedrijf X NL

.

Het afstemmen van de business met de IT begint met het gezamenlijk formuleren en onderbouwen van een probleemstelling en het stellen van doelen. De oplossing van de gestelde problemen moet passen binnen het geformuleerde raamwerk. Dit raamwerk is momenteel nauwelijks ingevuld. Door Bedrijf X is de strategische doelstelling geformuleerd om het architectuurraamwerk vorm te geven. Hierbij speelt de dienstverlening van de IT en de mate waarop zij aansluit op de businessbehoefte (IT governance) een belangrijke rol. Vanuit het architectuurdenken wordt gesteld dat IT governance bestaat uit de navolgende elementen: businessbehoefte, applicatiestructuur, technische infrastructuur en de overlegstructuur. Om tot een juiste afstemming te komen, zijn diverse overlegorganen nodig. Deze overlegorganen zijn ook onderdeel van de organisatiestructuur.

Het is van belang dat de huidige stand van zaken met betrekking tot architectuur en business-IT alignment inzichtelijk wordt gemaakt. Belangrijke knelpunten kunnen op deze manier worden geƒdentificeerd. Een manier om dit inzicht te bieden, is gebruik te maken van een model dat de volwassenheid van architectuur en business-IT alignment meet. Uitgaande van de verkregen inzichten kunnen probleemgebieden worden benoemd en oplossingsrichtingen worden voorgesteld.

2.3 Probleemstelling

Het onderzoek richt zich op het gebied van business-IT alignment en Enterprise Architecture binnen Bedrijf X NL Nederland. In de aanleiding van het onderzoek is ingegaan op de verschillende problemen die er spelen. De volgende doelstelling en vraagstelling worden geformuleerd.

De doelstelling:

De doelstelling legt vast voor wie het onderzoek wordt gedaan, wat er voor hen uitkomt en waarom dat van belang is (De Leeuw 2001). De algemene doelstelling voor dit onderzoek luidt:

‘Het vaststellen van het volwassenheidsniveau van het architectuurdenken (Enterprise Architecture) door Bedrijf X NL Nederland en het identificeren van verbeterpunten ten aanzien van business-IT alignment.’

Uitleg begrippen

Business-IT alignment is het op het geschikte tijdstip aanwenden van informatie

technologie op de doelen en behoeften, welke in harmonie zijn met de organisatiestrategie (Luftman, 2000).

Enterprise Architecture is het begrijpen van alle verschillende elementen waaruit een enterprise bestaat en hoe deze elementen met elkaar relateren (Schekkerman, 2005) Een enterprise is een collectie van organisaties die dezelfde doelen/principes nastreven. Een enterprise kan dan een gehele organisatie zijn, maar ook een divisie of een alleenstaand departement (Schekkerman, 2005).

De vraagstelling:

In de vraagstelling wordt, in voor onderzoek toegankelijke woorden, de hoofdvraag vastgelegd die aansluit bij de doelstelling van het onderzoek. De vraagstelling is een belangrijk uitgangspunt voor de uitwerking in deelvragen. De vraagstelling van dit onderzoek luidt:

‘Wat is het niveau van volwassenheid van de Enterprise Architecture van Bedrijf X NL Nederland en hoe kan Bedrijf X in de toekomst groeien op het gebied van de Enterprise Architecture om de business-IT alignment te bevorderen?’

2.4 De randvoorwaarden:

Randvoorwaarden hebben een relatie met de beperking ten aanzien van de methode die zal worden gevolgd en op inperkingen om het onderzoek haalbaar te maken. Er wordt onderscheid gemaakt tussen product en proces randvoorwaarden (De Leeuw, 2001). Voor

De procesrandvoorwaarden zijn:

De totale duur van het onderzoek bedraagt acht maanden.

Voor het schrijven van dit onderzoek zal rekening gehouden worden met de vormvereisten van de Rijksuniversiteit Groningen.

2.5 Conceptueel model en deelvragen

Een conceptueel model is volgens Jonker en Pennink (2000) een abstractie van de werkelijkheid waarin aandacht wordt besteed aan die zaken die voor het functioneren daarvan cruciaal zijn. Het conceptueel model bevat een aantal denkbeelden over het te onderzoeken probleem. Hierbij wordt vastgesteld wat er wel en wat er niet bij het onderzoek hoort; de afbakening.

Figuur 2.2: Het conceptueel model

Uitleg model

In figuur 2.1 staat het conceptueel model voor dit onderzoek. Het figuur beschrijft de relatie tussen de verschillende onderdelen in dit verslag. Het model moet van binnen naar buiten worden gelezen. Het eerste fragment behandelt de business-IT alignment. Deze is gesplitst in twee delen. Eerst zal er gekeken worden naar de theorie van alignment en aan de hand van deze theorie zal de business-IT alignment van Bedrijf X worden beschreven. Het tweede fragment behandelt de theoretische beschrijving van Enterprise Architecture. Eerst zullen de belangrijkste begrippen worden besproken en daarna is er een literatuuronderzoek naar de verschillende raamwerken met betrekking tot het meten van de volwassenheid van architectuur. Aan de hand van een gekozen raamwerk zal een beschrijving en beoordeling worden gegeven van de huidige situatie binnen Bedrijf X op het gebied van architectuur. Tenslotte zullen de beschrijvingen van de business-IT alignment en Enterprise Architecture binnen Bedrijf X resulteren in een eindconclusie en aanbevelingen.

Deelvragen:

Aan de hand van het conceptuele model kunnen vervolgens de deelvragen geformuleerd worden. De deelvragen dienen aan te sluiten bij de elementen van het conceptuele model.

1.

Wat is business en IT alignment volgens verschillende theoretische perspectieven?

2.

Wat is Enterprise Architecture?

3.

Hoe is de volwassenheid van architectuur van een organisatie te meten volgens

verschillende theoretische perspectieven en welke is toepasbaar binnen Bedrijf X NL?

Wat doet Bedrijf X NL momenteel aan business en IT alignment?

5.

Wat doet Bedrijf X NL momenteel aan architectuur?

6.

Op welk niveau van volwassenheid van architectuur zit Bedrijf X?

7.

Wat kan er worden geconcludeerd en aanbevolen met betrekking tot de rol van de

Enterprise Architecture in relatie tot de business-IT alignment?

In het onderzoeksverslag zijn eerst de deelvragen 1 t/m 3 behandeld. Deze deelvragen kunnen gezien worden als het theoretisch kader. De vragen 4 t/m 7 zijn ter toetsing van de praktijk.

2.6 Onderzoeksopzet

Om een antwoord te geven op de hoofdvraag van dit onderzoek zal gebruik worden gemaakt van de BIO-5 methode (zie figuur 2.3). De BIO-5 methode onderkent drie onderdelen: het systeem, de diagnose en het herontwerp. De methode begint met een zoekproces met het systeem als afkadering. Uit het systeem komen een set van problemen. Het instrumentele probleem is het bedrijfskundige probleem voor de organisatie. Het instrumentele probleem leidt tot verscheidene functionele problemen. Aan de hand van deze verzameling van problemen wordt de probleemstelling opgezet. De probleemstelling valt vervolgens uiteen in een doelstelling en een vraagstelling. Daarna komen in een conceptueel model de zaken naar voren die worden betrokken in het onderzoek. De relaties van de verschillende onderdelen van het onderzoek worden hierin beschreven.

Het onderzoek richt zich op variabelen of dimensies die het systeem, volgens de theorie, zou moeten kunnen beƒnvloeden. Niet alle variabelen zijn gemakkelijk te beƒnvloeden, maar door te ‘draaien’ aan de juiste variabelen kunnen geidentificeerde knelpunten uit het systeem worden geruimd. De mogelijkheden met betrekking tot de variabelen zullen tot uiting komen in enkele verbetervoorstellen die eventueel kunnen leiden tot een herontwerp.

Binnen dit onderzoek vertaalt dit zich in twee delen. Er zal eerst worden gekeken naar de verschillende theorie€n over Enterprise Architecture en business-IT alignment. Het tweede gedeelte zal een beschrijving geven van de huidige situatie binnen Bedrijf X aan de hand van de gevonden theoretische inzichten in het eerste deel. Hieruit zullen vervolgens de conclusies en aanbevelingen worden afgeleid.

Figuur 2.3: Rijksuniversiteit Groningen BIO-5 methodiek

De deelvragen worden behandeld in de verschillende hoofdstukken. Hoofdstuk twee biedt een introductie en een onderzoeksopzet. Het derde hoofdstuk geeft een algemene beschrijving van het begrip Business-IT alignment. Er wordt voornamelijk gekeken naar methoden om de volwassenheid van alignment van een organisatie te meten. In hoofdstuk vier komen de verschillende theorie€n ten aanzien van het Enterprise Architecture denken aan bod. In het vijfde hoofdstuk zullen de theorie€n die verband houden met het werken onder architectuur aan bod komen. Hier zal de nadruk worden gelegd op een methode die de volwassenheid van architectuur van een organisatie kan meten. De theorie€n worden getoetst op toepasbaarheid op de organisatie Bedrijf X. Vervolgens zal in het zesde hoofdstuk de situatie van Bedrijf X worden beschreven met betrekking tot de business-IT alignment. Het zevende hoofdstuk zal zich focussen op het werken onder architectuur binnen Bedrijf X. De resultaten gevonden over de theorie€n besproken in hoofdstuk vijf zullen worden geanalyseerd en deze wordt getoetst op de situatie in Bedrijf X in hoofdstuk zeven. Tenslotte zullen er conclusies worden getrokken en aanbevelingen worden gedaan over het volwassenheidsniveau van architectuur van de organisatie in hoofdstuk acht en negen.

De beschrijving van de situatie in de organisatie (hoofdstuk 6&7) is afhankelijk van de theoretische inzichten over business-IT alignment en architectuur. Dit betekent dat de theoretische kennis over architectuur en alignment is meegenomen in het beschrijven van de situatie binnen Bedrijf X.

Hoofdstuk 3: Business-IT Alignment

3.1 Inleiding

Het is duidelijk dat de informatie technologie (IT) niet alleen meer wordt gebruikt voor administratieve ondersteuning, maar steeds meer een strategische rol krijgt. Hierbij is het belangrijk dat de IT doelen overeenkomen met die van de business. Enkele theorieen zullen worden beschreven in dit hoofdstuk.

In dit hoofdstuk wordt deelvraag 1 behandeld:

‘Wat is business-IT alignment volgens verschillende theoretische perspectieven?’

Additioneel aan de deelvraag zal de relatie tussen business-IT alignment en architectuur worden behandeld. Tenslotte wordt er een samenvatting gegeven van de behandelde theorie in dit hoofdstuk.

3.2 Alignment

Vanwege de toenemende impact en afhankelijkheid van IT op organisaties, zullen hedendaagse organisaties veranderen. Door die toename van impact krijgt de IT meer invloed. Tegenwoordig bestaat er dan ook de discussie of het onvermogen om waarde te realiseren vanuit IT investeringen te wijten is aan het gebrek van ‘alignment’ tussen de organisatie- en de IT strategie (Henderson en Venkatraman, 1999). Alignment is het op het geschikte tijdstip aanwenden van informatie technologie op de doelen en behoeften, welke in harmonie zijn met de organisatiestrategie (Luftman, 2000). De definitie legt de nadruk op twee zaken:

 hoe de IT op ……n lijn ligt met de organisatie;

 hoe de organisatie op een lijn ligt met de IT.

Volwassenheid van alignment betekent dat er een relatie is ontstaan tussen de IT en de organisatie, zodanig dat de strategie€n elkaar beƒnvloeden en zich op elkaar aanpassen. Het maakt dus niet uit of je gebruik maakt van de term business-IT alignment of IT-business alignment. Het doel is het verzekeren van een harmonieuze aanpassing van de strategie€n. Er zijn een aantal zaken die het doel willen hinderen of juist willen bevorderen. Een opsomming hiervan is te zien in tabel 3.1.

Bevorderen Hinderen

Management steunt IT IT/business hebben geen hechte relatie

IT doet mee aan het formuleren van de strategie

IT kan niet goed prioriteiten stellen

IT begrijpt de organisatie IT schiet tekort in het nakomen van

afspraken

Business-IT associatie IT begrijpt de organisatie niet

Goed geprioritiseerde IT projecten Management steunt de IT niet

IT uit leidschap IT management is ontoereikend in

leiderschap Tabel 3.1: Factoren die alignment hinderen of bevorderen.

De hoofden van de IT en de organisatie moeten dus dezelfde kant op kijken om winst te draaien of kosten te minimaliseren in een organisatie. In het achterhoofd moet worden gehouden dat geen enkele IT applicatie hoe complex en geavanceerd deze ook mag zijn -een langdurig concurrentie voordeel kan opleveren. Het voordeel kan all-een worden behaald door het vermogen van de organisatie om de functionaliteiten van de IT volledig te benutten op continue basis (Henderson en Venkatraman, 1999).

Het doel van alignment volgens Papp (1995) is de juiste dingen doen (effectiviteit) en de dingen juist doen (effici€ntie). Het bereiken van dit doel is evolutionair en dynamisch (Luftman, 2000). De IT heeft hiervoor veel ondersteuning nodig van het management en

3.3 Alignment volgens verschillende theorie€n

In de afgelopen jaren is er veel onderzoek gedaan op het gebied van de koppeling tussen organisatie en IT (Luftman & Brier, 1999), de rol van relaties tussen IT en organisatie management (Keen, 1996) en het begrijpen van de noodzaak om strategie€n te transformeren die resultaat zijn van concurrerend gebruik van IT (Boynton, Victor & Pine, 1996). Veel van dit onderzoek was desondanks conceptueel. Empirische studies van alignment (Baets, 1996) gingen voornamelijk over een enkele industrie of organisatie. Conclusies van zulke empirische studies zijn mogelijk bevooroordeeld en zijn niet toepasbaar op andere organisaties (Luftman, 2000).

3.3.1 Luftman

Jerry Luftman doet al vele jaren onderzoek naar de alignment tussen business en IT. Er zijn twee assessment theorie€n die eruit springen. Enerzijds is dat een raamwerk opzet door Papp en anderzijds is dat de theorie ontwikkeld door Luftman. In veel aspecten zijn de raamwerken hetzelfde. Beiden zoeken naar (algemene) variabelen die de alignment meten ongeacht wat voor organisatie het is. Ook hoort er geen dubbelzinnigheid in te zitten, zodat verschillende mensen binnen een organisatie de variabelen hetzelfde interpreteren.

Er zijn verschillende niveaus van volwassenheid van alignment. Luftman (2000) identificeert vijf niveaus (zie figuur 3.1):

 Initieel/ad hoc proces;

 Verbindingsproces;

 Gevestigd/gefocused proces;

 Verbeterd proces;

 Geoptimaliseerd proces.

Elk van de vijf niveaus van alignment volwassenheid richt zich op een set van zes criteria gebaseerd op een empirisch onderzoek. Een beschrijving in detail van de opbouw van de niveaus en de invulling van de zes criteria kan gevonden worden in bijlage A van het verslag.

De zes business-IT alignment factoren zijn te zien in figuur 3.2. De zes criteria zijn:

 Communicatie volwassenheid

 Competentie/Waarde meting volwassenheid

 Governance volwassenheid

 Partnership volwassenheid (relatie volwassenheid)

 Bereik & architectuur volwassenheid

 Vaardigheid volwassenheid

De zes Business-IT alignment volwassenheids criteria COMMUNICATIE

Begrip van de organisatie door IT

Begrip van IT door organisatie Delen van kennis

PRESTATIEMETING

IT indicatoren Business indicatoren Service level argreements Benchmarking GOVERNANCE Organisatiestructuur IT investering management Commissies Prioriteiten proces ASSOCIATIE

Business perceptie van de waarde van IT Gedeelde doelen IT programma management Relatie / vertrouwen ARCHITECTUUR Standaarden Architectuur transparantie Flexibiliteit nieuwe technologie VAARDIGHEDEN Innovatie, ondernemerschap Management stijl Educatie, training Politiek

Figuur 3.2: De zes alignment criteria

3.3.2 Henderson en Vekantraman

De strategische alignment bestaat uit twee componenten volgens Henderson en Venkatraman: een intern en een extern domein. Het externe domein gaat over strategiebepaling en keuzes met betrekking tot concurrenten en allianties. Het interne domein betreft de keuzes die gaan over de logische en administratieve structuur (processen) van de organisatie als ook over het ontwikkelen van menselijke vaardigheden die nodig zijn voor het verwerven van organisatie competenties. Doordat strategie als een management concept voornamelijk werd gebruikt in de output markt, de plaats waar producten worden verkocht, is de nadruk komen te liggen op het externe domein. De IT strategie wordt dan gezien als een functionele, interne respons op de organisatie strategie. Hierdoor wordt de business dus leidend.

Strategic alignment model

Voor het bereiken van een strategische fit hebben Henderson en Venkatraman in 1999 een model ontwikkeld die daarbij kan helpen. Het model ziet er als volgt uit.

Figuur 3.3: Het Strategic alignment model van Henderson en Venkatraman De positie op de externe domein bestaat uit:

 Reikwijdte

De technologie reikwijdte bestaan uit de specifieke technologie€n die de huidige business strategie ondersteunen of de nieuwe technologie€n die nieuwe organisatie strategie€n kunnen voortbrengen. Zij moeten analoog zijn aan de business reikwijdte, welke op haar beurt voortkomt uit de keuzes ten aanzien van de producten die door de organisatie op de output markt worden gebracht.

 Competenties

Dit zijn de onderscheidende factoren (prijs, kwaliteit) die voortkomen uit de organisatie strategie, maar die sterk beƒnvloed worden door de kwaliteit van de IT competenties (systeem betrouwbaarheid, cost-performance ratio, de mate waarin toegepaste IT systemen in staat zijn om handwerk te beperken).

 Governance

De selectie en het gebruik van mechanismen (joint research, allianties, comit…s) voor het verkrijgen van competenties. Het gaat hier om het nemen van en het ten uitvoer brengen van de tactische en strategische beslissingen die gebaseerd zijn op de organisatiestrategie.

Ook het interne domein bestaat uit enkele componenten, namelijk:  Infrastructuur

De keuzes die zijn gemaakt betreffende de portfolio van applicaties, de configuratie van hardware, software, communicatie en de data architectuur. Deze vormen

samen de technologie architectuur. Voor de organisatie kant is dit de

administratieve structuur. Hierin worden de processen, rollen en

verantwoordelijkheden bepaald.  Processen

Dit zijn de processen die het functioneren van de (administratieve) infrastructuur mogelijk maken, zoals logistiek, financi€n, IT-beheer en monitoring en control.  Vaardigheden

De vaardigheden die nodig zijn om de infrastructuur te laten functioneren en effectief te managen.

Strategie€n van Henderson en Venkatraman

Voor het op een lijn krijgen van de organisatie en de IT zijn nu twee strategie€n mogelijk. Bij de eerste is de organisatie leidend en bepalend. Dit is een top-down benadering. Vanuit de organisatiedoelen wordt er gedaald naar de organisatiestructuur en vervolgens vertaald dit zich naar de technische infrastructuur. Hiervoor dragen Henderson en Venkatraman enkele methoden voor zoals, business systems planning en enterprise modeling.

De tweede manier is waarbij de ICT als de bepaler wordt gezien. Het management verkent hoe de IT de organisatie in staat stelt om nieuwe organisatie strategie€n te ontwikkelen. Dit gebeurt vaak als de onderneming te maken heeft met een dynamische markt, waarin de behoeften van de klant snel verandert.

Dit betekent voor de organisatie dat er gekozen moet worden voor een bepaalde strategie. De organisatie moet een inschatting maken van de belangrijkheid van de IT voor de organisatie en hoe deze het beste ingezet kan worden, zodat de doelen het beste bereikt kunnen worden. Dit houdt in dat de invloed van het management en het IT management kan veranderen.

3.4 Relatie met architectuur

Veel grote organisaties lijden onder de complexiteit van hun organisatie en IT structuur. Deze complexiteit maakt het moeilijk voor organisaties om een overzicht te krijgen van de organisatiestructuur, terwijl juist dit overzicht belangrijk is voor het maken van strategische beslissingen. Maar ook zou dit overzicht de knelpunten en inconsistenties tussen de organisatie en de IT kunnen identificeren. Dus een centraal punt voor naslag zou communicatie tussen de organisatie en de IT verbeteren. Dit probleem brengt organisaties steeds meer tot het gebruik van architectuur. Er wordt verwacht dat architectuur de communicatie kan verbeteren, maar ook toepasbaar is als management instrument om grip te krijgen op de vaak onbegrijpelijke business en IT situaties en de ‘fit’ tussen deze twee (Van Der Raadt e.a., 2004). De ‘fit’ is de aansluiting van de organisatiedoelen met de IT doelen.

IT is h…t middel voor strategische vernieuwing en innovatie. De IT-strategie is voor bedrijven van levensbelang geworden. In steeds meer bedrijfstakken is IT inmiddels de strategie van de onderneming. Echter, de IT is niet alleen de ‘enabler’, maar helaas ook een ‘disabler’ voor vernieuwing. Dit houdt in dat IT de organisatie kan verrijken, maar dat een IT strategie de organisatie ook kan beperken. De huidige topmanagers kunnen het zich dan ook niet meer permitteren om IT slechts als louter ondersteunende technologie te beschouwen. Juist IT is de factor die de regels van het spel kan doen wijzigen en daarmee het bedrijf snel op achterstand kan zetten ofwel juist een voorsprong kan geven in de markt.

Het in lijn brengen en houden van business en IT heeft dan ook prioriteit. Architectuur is hierbij een hulpmiddel om de steeds sneller in elkaar grijpende veranderingen te sturen op samenhang. Doelgerichte, duurzame investeringen maken het daarbij mogelijk om in de toekomst beter, sneller en goedkoper in te kunnen spelen op veranderingen. Maar niet iedere organisatie is goed in staat om te veranderen onder architectuur, waardoor veelbelovende kansen worden gemist.

Het invoeren van het architectuurdenken is niet gemakkelijk. Het gaat gepaard met het cre€ren van nieuwe problemen. Het is nodig voor een organisatie om te weten waar deze staat op het gebied van architectuurdenken. Daarom zijn er een aantal modellen ontwikkeld om de volwassenheid van architectuur te bepalen. Hier wordt op ingegaan verderop in het onderzoek. Het verband tussen alignment en volwassenheid komt wel naar voren in deze modellen. Factoren die gebruikt worden voor het meten van volwassenheid en alignment komen gedeeltelijk overeen. Dit zijn factoren zoals governance, proces, communicatie, scope en betrokkenheid. Er kan dus gezegd worden dat als er beter wordt gescoord op het werken onder architectuur in veel gevallen de organisatie en de IT meer op een lijn zitten.

3.5 Samenvatting

De kern van business-IT alignment is de afstemming van doelstellingen zowel aan de business kant als aan de IT zijde op basis van een gemeenschappelijke business strategie. Luftman heeft als insteek het meten van Business-IT alignment. Dit doet hij door het toewijzen van niveaus aan de hand van zes criteria. Henderson en Venkatraman legt de nadruk meer op het afstemmen van de strategie.

De overeenkomsten tussen de theorie€n van Luftman en Henderson en Venkatraman zijn te vinden in de benodigde competenties en de uitvoering van governance.

Architectuur is een hulpmiddel / raamwerk voor het afstemmen en toetsen van de strategie, tactische beslissingen en de operationele uitvoering (verwezenlijken business doelen). Door de veranderende markt kan door middel van architectuur de samenhang tussen de business en IT worden behouden.

Hoofdstuk 4: De Enterprise Architecture

4.1 Inleiding

Dit hoofdstuk gaat over het begrip Enterprise Architecture. Hier wordt beschreven wat architectuur, enterprise en Enterprise Architectuur zijn. Vervolgens worden de dimensies, het doel en stakeholders behandeld. Tenslotte wordt er beschreven wat een architectuurraamwerk inhoudt.

In dit hoofdstuk wordt deelvraag 2 behandeld: ‘Wat is Enterprise Architecture?’

Een praktische toepassing van Enterprise Architecture komt naar voren in het werkmodel van DYA. Dit raamwerk vertaalt de theorie naar een in de praktijk in te zetten model. Daarnaast zal een beschrijving worden gegeven van het raamwerk van de grondlegger van Enterprise Architecture: het Zachman Framework.

4.2 Architectuur

Er zijn enorm veel verschillende definities van architectuur. Dit varieert van modern tot klassiek en van abstract tot concreet. Een overzicht van definities is te vinden op de website van Carnegie Mellon1. Chorafas (2002) zegt dat veel bedrijven en ook experts enterprise architectuur en systeem (of software) architectuur door elkaar halen. Hierbij vertelt hij dat ‘de enterprise architectuur het resultaat is van toevallige groei van computers en communicatienetwerken, terwijl systeem architectuur vaak een inflexibele en rottende structuur is, gekocht in de jaren ’70 en ’80 van een favoriete leverancier.’ Voor de duidelijkheid maak ik in dit onderzoek een opdeling in software architectuur en enterprise architectuur terwijl het onderzoek zich voornamelijk richt op de enterprise architectuur.

Traditionele architecturen worden gedreven door lineair oorzaak-gevolg denken welke werkt in een simpele en statische wereld. Tegenwoordig doorbreekt het Internet (Chorafas 2002) deze lineaire relaties in complexe en flexibele systemen. Hier zit dan ook volgens hem de kern van het verschil tussen systeem architectuur en enterprise architectuur. De enterprise architectuur (Chorafas, 2002) richt zich op een flexibele en dynamische omgeving, terwijl systeem architectuur een idee opwekt van het concept van IBM in de jaren zeventig (mainframe-based).

De definities van architectuur die ik wil behandelen zijn gebaseerd op personen en bedrijven die veel met architectuur te maken hebben. De definitie die het meest wordt gehanteerd is die van de Institute of Electrical and Electronics Engineers, namelijk de IEEE 1471-2000:

‘The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.’ Deze definitie geeft een omschrijving van wat een software architectuur is. De relaties tussen de onderlinge elementen in een systeem worden door middel van architectuur zichtbaar. Dit richt zich niet op de informatie- en businessaspecten. Ook wordt hier gesproken over principes (zie paragraaf 4.10). Deze principes zijn nodig om het ontwerpproces in te perken. In de architectuurwereld is het belangrijk dat er niet wordt afgeweken van deze principes, omdat deze als fundament voor het raamwerk gelden. Van de verschillende frameworks die worden behandeld in dit onderzoek, komen de principes dan ook aan bod.

Een definitie van architectuur die principes toepast op de gehele architectuur is die van Rijsenbrij (2004).

‘Architectuur is een coherente, consistente verzameling principes, verbijzonderd naar ‘concerns’, regels, richtlijnen en standaarden die beschrijft hoe een onderneming, de informatievoorziening, de applicaties en de infrastructuur zijn vormgegeven en zich voordoen in het gebruik.’

Een coherente verzameling van principes wordt opgesteld om de ordelijke samenhang te ondersteunen en de consistentie zorgt ervoor dat de principes elkaar niet tegenspreken. Een andere visie welke meer gerelateerd is aan het enterprise denken is die van Zachman (1987). Die luidt als volgt:

‘Architecture is that set of design artifacts, or descriptive representations, that are relevant for describing an object such that it can be produced to requirements as well as maintained over the period of its useful life.’

Hier komen de componenten kwaliteit (requirements) en tijdspanne (period) naar voren en dit allemaal voor het opzetten van een generieke logische structuur voor het organiseren en classificeren van een beschrijvende representatie van een object. Hierbij is het object dan de enterprise. De requirements kunnen worden gezien als kwalitatieve eisen die aan de architectuur worden gekoppeld. ‘Period’ geeft een bepaalde levensduur aan. Architectuur zal zich dus moeten aanpassen in de loop der tijd aan de omgeving.

4.3 Doel/nut van architectuur

Het nut van architectuur is moeilijk objectief te beoordelen. Toch is het nodig om het management te overtuigen van het werken ‘onder architectuur’. Architectuur vergt op korte termijn investeringen en levert pas op lange termijn een kostenbesparing op. Volgens Rijsenbrij (2002) levert het werken onder architectuur het volgende op:

 Meer inzicht en overzicht met betrekking tot de mogelijkheden en beperkingen van

business-transformaties. Voorts kan met architectuur op soepele wijze het continue transformatieproces in het gareel worden gehouden;

 Meer adaptiviteit (o.a. ruimte voor nieuwe relatievormen);

 Soepeler informatieverkeer ter vergroting van de bestuurbaarheid;

 Rationalisatie van de geautomatiseerde informatiesystemen, databases, de

outsourcing (uitbesteding) en hun onderling verband;

 Effici€ntere systeemontwikkeling (programma’s en projecten);

 Uniformering van de (technische) infrastructuur;

 Meer ruimte om nieuwe technologische mogelijkheden te kunnen incorporeren.

Wat Zachman (1987) wil benadrukken is dat architectuur de mogelijkheid geeft tot het juist beschrijven van een complex product met de mogelijkheid dieper te duiken in probleemgebieden zonder het geheel uit het oog te verliezen. TOGAF (2003) vindt dat de architectuur de organisatie in staat stelt om de juiste balans tussen business- en ICT-strategie te vinden. Als laatste zegt Chorafas (2002) dat het belangrijkste reden voor Enterprise Architecture Business Intelligence is. Business Intelligence is het proces van het

systematisch verwerven en verwerken van informatie ten behoeve van de

strategievorming van organisaties (Vriens en Philips, 1999).

In algemene termen is architectuur besproken. In de navolgende paragrafen wordt het begrip Enterprise en Enterprise Architecture uitgewerkt.

4.4 Enterprise

De enterprise wordt volgens het Federal Enterprise Architecture Framework (FEAF, 1999) gedefinieerd als:

‘an organization supporting a defined business scope and mission. An enterprise includes interdependent resources (people, organisatie en technologie) who must coordinate their functions and share information in support of a common mission’.

The Open Group Architecture Framework (TOGAF, 2003) ziet het als:

‘any collection of organizations that has a common set of goals and/or a single bottom line’.

Een enterprise kan in dit geval dus een overheidsinstantie, een gehele corporatie, een divisie van die corporatie, een department of een wereldwijde onderneming zijn die verbonden is door een gemeenschappelijk eigenaarschap.

Een enterprise hoeft dus niet de gehele organisatie te zijn, maar het kan ook een onderdeel hiervan betreffen. In principe zou het voor enterprise architectuur niet moeten uitmaken. Voor het in- en uitzoomen op een raamwerk moet er consistentie en geen dubbelzinnigheid zijn tussen de verschillende niveaus. Voor een enterprise geldt de piramide zoals die te zien is in Figuur 4.1: Planning piramide. Er is een top-down benadering voor de enterprise. De missie beschrijft de bestaanredenen. Vervolgens wordt in de visie het beeld gevormd dat een bedrijf of organisatie heeft richting de toekomst, haar omgeving en de keuzes die men daarbij maakt. Op basis hiervan kunnen een of meer strategie€n worden ontwikkeld die de richting naar de toekomst aangeven. Uiteindelijk visualiseert en ondersteunt de architectuur deze strategie€n met behulp van concepten en modellen. Daarbij wordt een integrale benadering gehanteerd vanuit zowel de organisatie als de IT.

Figuur 4.1: Planning piramide

4.5 Enterprise Architecture

Een enterprise architectuur bestaat uit verschillende architecturen. In figuur 4.2: Brug tussen business strategie en implementatie staat een grafische weergave van de opdeling die de Meta Group (2003) heeft gemaakt en hoe deze de brug vormt tussen strategie en implementatie. Business Strategie - Business doelstellingen - Trend analyse - Business beleid Implementatie - Business processen - Applicaties en systemen - Technische infrastructuur - Business architectuur - Informatie architectuur - Service architectuur - Technische architectuur

De brug tussen strategie en implementatie

Enterprise Architecture

Hier is te zien dat de Meta Group de enterprise architectuur verdeelt in vier gebieden welke bij de meeste definities worden gebruikt. Dit is de opdeling in de business architectuur, de information architectuur, de solution architectuur en de technology architectuur. Bedrijf X verdeelt het in business architectuur, informatie architectuur, service architectuur, data architectuur en technologie architectuur (zie bijlage B).

Er geldt vaak dat bij de bovenste en de onderste laag, business en technologie architectuur, bij de verschillende definities hetzelfde wordt bedoeld. Het interessante zit in het midden. Dit is bij de Meta Group de informatie architectuur en bij Bedrijf X is deze uiteengerafeld in informatie, service en data architectuur. Wat daar mee bedoelt wordt behandel ik verder in dit document.

Rijsenbrij komt ook dichterbij de visie van Bedrijf X. Hij ziet het als volgt:

figuur 4.3: Architectuurgebieden van Rijsenbrij

Bedrijfsgebeuren

Dit gebied houdt zich bezig met de wereld van zaken doen. Er wordt hier gesproken over: de missie, de visie, de strategie€n, de producten en diensten die de onderneming levert, concerns, de processen die nodig zijn om die producten en diensten te produceren, de organisatie en besturing van mensen en bedrijfsmiddelen die daarbij nodig zijn.

Informatieverkeer

In deze informatielaag zitten de volgende zaken: informatiestromen, informatiebehoeftes, informatiebronnen en informatie-uitwisseling met de omgeving.

Applicatielandschap

Applicaties zijn (geautomatiseerde) informatiesystemen en gegevensverzamelingen. Deze systemen kunnen, alleen vooraf ingestelde bewerkingen uitvoeren en zijn dus geen volledige afspiegeling van de werkelijkheid.

Technologie infrastructuur

Deze infrastructuur is het fundament waarop de informatievoorziening wordt gebouwd. Het vormt ook het bindende element tussen de applicaties. De fysieke laag, zoals bekabeling routers e.d, zorgt voor deze verbinding.

4.6 Enterprise architectuur raamwerk

Een architecture framework is volgens The Open Group (2003) een hulpmiddel welke gebruikt kan worden voor het ontwikkelen van breed scala aan architecturen. Het moet een methodiek beschrijven voor het ondersteunen van het ontwerpen van een informatiesysteem in termen van bouwblokken en de relaties hiertussen. Verder moet het een set van standaarden bevatten met gemeenschappelijk woordgebruik welke gebruikt kunnen worden voor het implementeren van het framework. Dit framework moet ervoor zorgen dat het gebruik van een architectuur sneller en gemakkelijker verloopt. Het garandeert een completere dekking van de ontwerpoplossing.

Rijsenbrij (2002) ziet een raamwerk als een hulpmiddel en communicatiemiddel of een

model om informatiearchitecten te ondersteunen bij het maken van een

architectuurbeschrijving voor een onderneming. Maar een raamwerk is er ook voor het ondersteunen van het proces waar de business op de ICT wordt afgestemd. Een raamwerk reikt dus een methodiek aan die de huidige business in kaart brengt en hoe de toekomst

bedrijfsgebeuren informatieverkeer applicatielandschap technologie infrastructuur voor schrijvend In staat stellend

van de business er behoort uit te zien, zodat er een migratiepad kan worden opgesteld voor het transitieproces. The Open Group ziet het raamwerk als een hulpmiddel op hoofdzakelijk het technische gebied, terwijl Rijsenbrij het raamwerk inzet om juist de relatie te leggen tussen de IT en business, zodat afstemming mogelijk wordt gemaakt. Het idee achter het opzetten van een framework is het beschrijven van een complex product. Dit gebeurt aan de hand van het focussen op verschillende dimensies zonder de samenhang met het geheel te verliezen (Zachman, 1987). Belangrijk hierbij is de informatie actueel te houden. Anders ontstaat er een grote lijst met systemen welke niet geƒntegreerd en niet ondersteunend zijn en geen toegevoegde waarde biedt aan de enterprise. Dit soort systemen staan bekend onder de naam ‘legacy’ systemen. Dat willen we juist voorkomen door het gebruik van een raamwerk.

Het concept van het onderzoeken van systemen in verschillende dimensies begon door Boeke (1957). Later maakten Charles en Ray Eames (1968) een film van dit concept en uiteindelijk kwamen Philip en Phylis Morrison (1977) met het boek Power of Ten. Rouse et al. (1992) voegde de aspecten What, How en Why toe om er een matrix van te maken. Hierdoor werd al snel het geheel uit het oog verloren en Zachman introduceerde verschillende perspectieven en de aspecten Who, When en Where.

Een framework levert een organisatie een schema op voor het ontwikkelen van enterprises. Dit alleen is niet genoeg. Een compleet pakket bestaat uit een raamwerk, een proces (Bahill en Gissing, 1998), een methode (Martin, 1997), een notatie (b.v. UML) en een tool (b.v. MS Visio).

Verschillende mensen gebruiken raamwerken voor verschillende redenen. Een high-level planner gebruikt deze om interoperabiliteit van systemen te garanderen en om kosten te monitoren van het ontwikkelen van systemen. Managers gebruiken het om de return on investment te schatten en om een ICT-strategie aan te sluiten op de business. Op operationeel niveau is het voor het begrijpen van de organisatie en te focussen op probleemgebieden.

4.7 Inventarisatie EA -raamwerken

Er zijn momenteel vele verschillende EA-raamwerken. Om hiervan een overzicht te geven heb ik er enkele op een rij gezet.

Raamwerk Naam

IAF Intergrated Architecture Framework

Zachman Zachman Framework for Enterprise Architecture

TOGAF The Open Group Architecture Framework

IFW Information Framework

MAD Methodology for Architecture Description

DYA DYnamische architectuur

xAF Extensible Architecture Framework

TEAF Treasury Enterpirse Architecture Framework

DoDAF Department of Defense Architecture Framework

FEAF Federal Enterprise Architecture Framework

E2AF Extended Enterprise Architecture Framework

C4ISR Command, Control, Communications, Computers, Intelligence,

Surveillance, and Reconnaissance Architecture Framework

Bedrijf X EAF Bedrijf X Enterprise Architecture Framework

Tabel 4.1: Overzicht Frameworks

Bedrijf X Global maakt gebruik van het Bedrijf X EAF (zie bijlage B). Deze is afgeleid van het raamwerk van Zachman.

Aan de hand van een literatuurstudie kan geconcludeerd worden dat niet alle voornoemde raamwerken praktisch toepasbaar zijn. Door het ontbreken van concrete aanwijzingen bij een aantal raamwerken zijn deze niet relevant voor dit onderzoek. Hierdoor is gekozen voor een viertal raamwerken die overeenkomsten vertonen met het Bedrijf X EAF. De geselecteerde raamwerken zijn:

 DYA, legt een link tussen de theorie en de praktijk en geeft concrete en praktische

aanwijzingen;

 Zachman, is de grondlegger van het architectuur raamwerk;

 FEAF & TOGAF, dit zijn concreet uitgewerkte Amerikaanse raamwerken, maar

speciaal gericht op overheidsinstellingen;

 Bedrijf X EAF, is het Global raamwerk wereldwijd gebruikt door Bedrijf X. Deze is afgeleid van het raamwerk van Zachman.

De verschillende raamwerken onderkennen verschillende dimensies en hierbinnen worden vervolgens weer meerdere aspecten onderscheiden. Een inventarisatie van de raamwerken en de bijbehorende dimensies is hieronder opgenomen.

Raamwerk Dimensies

Zachman Data, Functie, Netwerk, Mensen, Tijd, Motivatie

TOGAF Business, Applicatie, Data, Technologie

DYA Business, Informatie, Technologie

FEAF Business, Applicatie, Data, Technologie

Bedrijf X EAF Business, Informatie, Service, Data, Technologie

Tabel 4.2: De verschillende dimensies per raamwerk.

Het raamwerk van Zachman is een vreemde eend in de bijt. Deze dimensies stroken niet met de anderen.

Zoals in de tabel kan worden afgelezen zijn de hoofddimensies:

 Business;

 Informatie;

 Applicatie;

 Data;

Pruijt heeft in zijn artikel alleen Business-, Informatie- en Technologie architectuur beschreven. De Data- en Applicatie architectuur zijn onderdeel van de Informatie architectuur (Wagter 2001).

4.7.1 Business architectuur

Volgens Pruijt (2003) geeft business architectuur een beeld van de eisen die de business op korte en lange termijn stelt aan de organisatie en de informatievoorziening. En van de keuzes die zijn gemaakt met betrekking tot de organisatie-inrichting en de informatievoorziening om aan deze eisen te kunnen voldoen. Centraal staat hier de visie van het management op de veranderende markt en op de noodzakelijke veranderingen in de bedrijfsvoering. Volgens Wagter (2001) vormt de business architectuur het kader voor de wijze waarop de organisatie is opgebouwd om de businessdoelen te bereiken: de producten en diensten waarmee de organisatie de bedrijfsdoelen wil bereiken, de processen die hiervoor nodig zijn, de manier waarop de uitvoering van die processen plaatsvindt en de manier waarop de uitvoering van die processen is georganiseerd. Pruijt en Wagter gaan beide in op de eisen/doelen en hoe dit in de loop der tijd bereikt moet worden. Ik zie hierin dan ook een huidige en toekomstige toestand van de business en een beschrijving van het transitieproces om tot deze toekomstige situatie te komen.

4.7.2 Informatie architectuur

De informatie-architectuur moet een beeld geven van de eisen die aan de totale informatie voorziening wordt gesteld (Pruijt, 2003). Er is een indeling in deelsystemen, zodat aan deze eisen kan worden voldaan. Deelsystemen kunnen gezien worden als conceptuele componenten. Bij een componentgebaseerde architectuur worden deelsystemen zo gekozen dat redundantie in gegevens en processen wordt voorkomen. En er wordt geprobeerd om kennis over een bepaald onderwerp zoveel mogelijk binnen ……n deelsysteem te concentreren. Zo kunnen componenten gecre€erd worden die eenvoudig te hergebruiken, te wijzigen of te vervangen zijn.

Voor Wagter (2001) vormt de informatie-architectuur het kader voor de wijze waarop de informatievoorziening ten behoeve van de organisatie wordt vormgegeven: de gegevens die voor de organisatie van belang zijn en de applicaties waarmee de informatie-uitwisseling ten behoeve van de organisatie ondersteund wordt. Uit de definitie van Pruijt en Wagter blijkt dat het ordenen van de juiste gegevens belangrijk is. Het gaat om de structuur van gegevens en applicaties waar de organisatie belang bij heeft en de wijze waarop gegevens worden aangeboden qua vorm en tijdstip.

Opvallend is dat Pruijt uitgaat van de logische informatiestructuur, terwijl Wagter zich meer concentreert op de achterliggende technische componenten, zoals de gegevens en de applicaties. In tabel 4.2 is weergegeven dat de diverse raamwerken onderscheid maken naar informatie, data en applicaties (informatiesystemen). Om deze reden worden de begrippen applicatie architectuur en data architectuur in respectievelijk de paragrafen 4.7.4 en 4.7.5 nader toegelicht.

4.7.3 Technologie architectuur

Pruijt (2003) vindt dat de technologie architectuur een beeld geeft van de eisen die aan de software worden gesteld en beschrijft de technische oplossingen die zijn gekozen om aan die eisen te voldoen. Concrete richtlijnen beschrijven hoe de software tijdens de bouw moet worden gestructureerd. Zo wordt vastgelegd hoe conceptuele componenten verder opgesplitst moeten worden tot softwarecomponenten, hoe deze softwarecomponenten onderling communiceren en hoe ze over de technische infrastructuur moeten worden verdeeld.

Wagter (2001) zegt dat de technische architectuur het kader vormt voor de technische infrastructuur van de organisatie: de hardware waarop de informatievoorziening draait, veelal opgenomen in een netwerk en de software waardoor applicaties met elkaar kunnen samenwerken (de zogenaamde middleware). Wagter onderkent een verdere opsplitsing van de business-, informatie en technische architectuur. Dit is te zien in figuur 4.4.

figuur 4.4: Verschillende objecten van architectuur

4.7.4 Applicatie architectuur

De applicatie architectuur (Veld, 2001) is de structuur van de diverse informatie systemen en specifieke informatie verwerkende toepassingen zoals die binnen de organisatie worden toegepast voor de verwerking, bewerking en opslag van gegevens waarmee de bedrijfsprocessen in de meest brede zin van het woord worden ondersteund, bestuurd en gecontroleerd.

Applicaties moeten de functionaliteit bieden die ‘gebruikers’ nodig hebben om hun taken (beter) uit te kunnen voeren. Ze maken IT bruikbaar. De applicatie architectuur, gevormd door de gegevens-, systeemsoftware-, hardware- en netwerk-componenten, is de kern van de IT architectuur.

Op zich is een applicatie architectuur een uitstekend hulpmiddel om in kaart te krijgen welke applicaties er zijn en hoe deze aan elkaar ‘gerelateerd’ zijn. Applicaties kunnen zich tot systemen combineren. Alle applicaties en systemen samen vormen de applicatie infrastructuur binnen de informatie infrastructuur. Het beeld daarvan noemen we hier dus de applicatie architectuur.

4.7.5 Data Architectuur

Het begrip data architectuur is een wat lastig te omschrijven begrip. In hoofdzaak gaat het hier om de beschrijving van de structuur van de logische en fysieke2 _{gegevens (data).}

Echter, de exacte omschrijving van dit begrip kan verschillen al naar gelang van het aandachtsgebied. Als de architect kijkt naar de logische structuur van de gegevens zoals die binnen een organisatie worden gebruikt, spreekt men vaak van de ‘logische data architectuur’. Hierbij worden de voornaamste business objecten beschreven in termen van (logische) attributen en relaties. Een typisch voorbeeld zijn de Entity Relationship Diagrams (ERD). Deze modellen worden gebruikt om de business objecten te onderkennen en de hiermee gerelateerde kenmerken (attributen) vast te leggen. Hierbij wordt geen rekening gehouden met technische aspecten.

Zodra gegevens worden verwerkt, bewerkt en vastgelegd door middel van geautomatiseerde informatiesystemen, zal de data architectuur snel een technisch karakter aannemen en zeer specifiek worden gestructureerd al naar gelang de toepassing en het gebruikte opslagmedium. Typische voorbeelden hiervan zijn de logische- en technische datamodellen die de gegevens van een logisch business object terugbrengen tot een set van genormaliseerde tabellen en attributen waarbij de nadruk ligt op de technische opslagstructuur en de effici€ntie van die technische opslag. Te denken valt daarbij aan

relationele database modellen, veld- en/of kolombeschrijvingen in termen van

gegevenstype, lengte en andere kenmerken. Maar ook de specifieke gegevensmodellen voor Data Warehouse toepassingen (Kimball, 1996) vallen binnen deze categorie.

Het begrip ‘data architectuur’ denkt feitelijk zowel de logische als de technische representatie van de bedrijfsgegevens, het gebruik van die gegevens en de opslag en presentatie van die gegevens.