Inleiding: de belofte van Enterprise Architectuur

Ongeveer twintig jaar geleden zag Enterprise Architectuur (EA) het levenslicht. Het ontstaan van EA had een duidelijke aanleiding. Organisaties besteedden steeds meer geld aan het bouwen van nieuwe IT-systemen en IT-landschappen werden zo steeds complexer. Men merkte dat het erg moeilijk was om die dure IT-systemen in lijn te houden met de behoeften vanuit de business. Nog meer kosten en nog minder waarde waren het gevolg.

Deze problemen hebben op dit moment, twintig jaar jaar later, een hoogtepunt bereikt. De kosten van IT-systemen zijn enkel maar hoger geworden en de kansen om werkelijke ‘business value’ los te weken zijn dramatisch gedaald, dus nog meer kosten en nog minder waarde. Organisaties, groot en klein, kunnen het zich niet langer meer permitteren om niet op een krachtige manier met deze problematiek om te gaan. De integrale benadering van business en IT met EA was twintig jaar geleden nog ‘Don Quichot’-achtig en is nu een absolute voorwaarde voor een goede afstemming van business en IT-doelstellingen en beweegt organisaties om een EA uit te werken.

Daarbij probeert EA altijd eenzelfde set van problemen te adresseren. Deze problematiek heeft vaak te maken met de moeilijk beheersbare complexiteit van de IT-systemen, die daarnaast te duur en niet flexibel zijn en daarmee de organisatie niet wendbaar genoeg maken om snel in te kunnen spelen op wensen tot verandering. Ook dwingende regelgeving op het vlak van governance, risk en compliance wordt steeds ingewikkelder en vereist een aanpassing van de manier waarop IT-systemen worden gebouwd, gestuurd en gecontroleerd. Daarnaast speelt er binnen veel organisaties een (historisch gegroeide) cultuur van wantrouwen tussen de business- en technologiekant die ‘business agility’ in de weg staat. EA tracht hier een oplossing voor te bieden.

Wat is Enterprise Architectuur?

Personen die ooit hun huis hebben verbouwd weten hoe belangrijk bouwvoorschriften, blauwdrukken en stedelijke of provinciale verordeningen zijn om hun project succesvol te voltooien.

Een bouwkundig architect werkt hierbij binnen een vastgesteld ‘kader’ van bouwvoorschriften, waarbij hij blauwdrukken voorbereidt voor elke fase van het project; van de structurele bouwkundige infrastructuur tot en met de grootte en de indeling van de kamers. Zijn gedetailleerde tekeningen bieden plannen ten behoeve van loodgieterij en elektriciteit en informatie voor de gehele structuur. EA werkt op een vergelijkbare manier.

De rol van de Enterprise Architect kan binnen deze huizenbouw-analogie gevonden worden in de rol van de bouwkundig architect die verantwoordelijk is voor de bepaling van het grotere kader waarbinnen de realisatie van een nieuw bouwkundig object moet plaatsvinden. Gespecialiseerde architecten (bijvoorbeeld interieur- of energiearchitecten) vullen de door de bouwkundig architect gekaderde deelgebieden verder op detailniveau in, zoals beveiligingsarchitecten of softwarearchitecten dat op hun beurt doen binnen een IT-oplossing, waarbij de Enterprise Architect eerst het brede kader van richtlijnen, doelstellingen en oplossingsrichtingen heeft uitgezet. Naast deze analogie is het belangrijk om te proberen om EA als vakgebied te definiëren.

De Open Group definieert EA als volgt:

Je zou EA dus kunnen zien als het model waarbinnen alle business-, informatie- en technologische componenten zijn uitgeschreven en ook de relaties tussen die componenten zijn gespecificeerd. Dat kan worden gedaan voor een current state EA, voor een future state EA of voor beide.

Aan de basis van een future state EA staan idealiter duidelijke strategische ‘business drivers’ die door de toepassing van modellering hun tactische en operationele neerslag krijgen binnen de IT-functies. Naast deze ‘inzichtelijke’ functie biedt EA ook een overzichtsfunctie, doordat de logisch opgebouwde relaties tussen businessprocessen, informatie en techniek via verschillende ‘dwarsdoorsnedes’ kunnen worden bekeken.

Enterprise Architecten willen door de creatie van een integrale weergave van de verbanden tussen business, informatie en techniek de nodige inzichten en overzichten realiseren en begrijpen hoe een organisatie als samenhangend deel functioneert, zodat een organisatie makkelijker, betrouwbaarder en sneller strategische beslissingen kan nemen (met een accent op IT-functies) en daarmee beter, sneller en kwalitatiever kan voldoen aan interne wensen of externe vereisten.[http://eacoe.org/]

Historie

EA is eind jaren tachtig begonnen aan de kant van de informatietechnologie (het ‘technology end’), maar heeft zich door de jaren heen ontwikkeld tot een vakgebied dat zich specifiek richt op de onderlinge afstemming van een groter aantal gezichtspunten binnen een organisatie. Het aandeel informatietechnologie voert nog wel duidelijk de boventoon.

In 1987 publiceerde John Zachman een eerste raamwerk voor EA-beschrijving, het Zachman Framework ([Zach87]). In de negentiger jaren zijn er allerlei EA-projecten gestart bij grote IT-bedrijven en de Amerikaanse overheid. In 1996 kwam het Amerikaanse Congres op dit gebied met de Clinger-Cohen-Act, in eerste instantie de ‘Information Technology Management Reform Act of 1996’ (ITMRA) genoemd.

Deze wet dwong alle organisaties van de Amerikaanse overheid de efficiëntie van IT-investeringen te verhogen en hiertoe een eigen Enterprise Architectuur te ontwikkelen. Dit leidde in 1999 tot de publicatie van de Federal Enterprise Architecture Frameworks (FEAF), die sinds 2002 verder ontwikkeld werden tot de Federal Enterprise Architecture (FEA). De EA-initiatieven die binnen de overheden van de Verenigde Staten zijn ontwikkeld worden globaal als het meest mature beschouwd.

Vanaf midden jaren negentig ontwikkelen verschillende organisaties een eigen visie op EA en experimenteren ermee in de praktijk. Binnen grotere organisaties ontstaan er gespecialiseerde EA-afdelingen. Ook in Nederland werken bedrijven en overheden aan de ontwikkeling van een eigen EA. Voor de overheid is hier de Nederlandse Overheid Referentie Architectuur (NORA) uit voortgekomen. NORA bevat ontwerpprincipes, modellen en afspraken voor het (her)inrichten van de (elektronische) overheid.[http://www.e-overheid.nl/onderwerpen/architectuur-en-nora/nora-30]

Principes

Gelaagdheid

EA wordt in vele gevallen in een aantal verschillende lagen onderverdeeld, die allerlei specifieke zaken bespreken. Deze lagen zijn bijvoorbeeld:

Business- en procesarchitectuur

De business- en procesarchitectuur bestudeert alle aspecten van de bedrijfsorganisatie, met het doel om beter te begrijpen hoe de informatietechnologie en het informatiemanagement passen in de algemene bedrijfsvoering. Zij kan onder andere bestaan uit:

• strategiediagrammen, doelstellingen, bedrijfsregels, operationeel model;
• functionele structuur, capaciteiten van het bedrijf, organisatiemodel;
• bedrijfsprocessen, workflow en de beschrijving van de zeggenschap, verantwoordelijkheden en regels voor de afdelingen;
• overzicht van externe leveranciers en partners, en hoe deze bijdragen tot het functioneren van het bedrijf.

Informatiearchitectuur

De informatiearchitectuur geeft een overzicht van de aanwezige en benodigde gegevens in een organisatie. Zij wordt bepaald door middel van analyse van de informatiebehoeften van een organisatie en wordt weergegeven met behulp van diverse modellen en technieken (onder andere met behulp van de UML-notatietechniek).

Bij het beschrijven van de data-architectuur worden vaak zogenaamde ‘artefacten’ gebruikt. Deze kunnen bestaan uit gestructureerde beschrijvingen die de metadata van het bedrijf weergeven en uit algemene datamodellen. Ook komt hier vaak de beschrijving van de voorzieningen rond datakwaliteit en de structuren voor informatiemanagement aan bod.

Applicatiearchitectuur

De applicatiearchitectuur beschrijft de samenhang van applicaties en informatiesystemen binnen een organisatie. Het is een modelmatige beschrijving van het applicatielandschap, de daadwerkelijk in productie zijnde systemen, met daarbij onder andere:

• applicatiesoftware: lijst van applicaties en diagrammen, vanuit het gezichtspunt van functionaliteit of van systemen;
• interfaces tussen applicaties: webservices, events, berichten, dataflow;
• intranet, extranet, internet, e-commerce, EDI en verbindingen met interne en externe gebruikers.

Technologiearchitectuur

De technologiearchitectuur is een geheel van inrichtingsprincipes en afspraken over de toe te passen technologie:

• hardware, platforms, en hosting: applicatieservers en waar ze geplaatst zijn;
• local en wide area networks, verbindingsdiagrammen;
• operating systems;
• infrastructure software: databaseservers, DBMS;
• programmeringstalen, Code of Conducts, Software / Design Patterns, … etc. voor het gehele bedrijf of per afdeling.

In een EA-raamwerk bepaalt de businessarchitectuur de eisen voor de informatiearchitectuur, die in toenemend detail de eisen voor de applicatiearchitectuur bepaalt, waarna de applicatiearchitectuur de gedetailleerde eisen voor de technologiearchitectuur beschrijft. Soms is er ook sprake van een relatie met en een beschrijving van een nog diepere laag: de infrastructuur.

Richtlijnen en regels

Binnen EA wordt veelvuldig gebruikgemaakt van algemenere architectuurprincipes. Principes zijn richtinggevende afspraken die een overtuiging weergeven over de wijze waarop de gewenste situatie bereikt kan worden. Het is de bedoeling dat de mensen die zich bezighouden met de organisatie-inrichting zich aan deze principes houden.

Voorbeelden van dergelijke principes zijn ([O’Rou03]):

• Elk gegeven heeft een standaarddefinitie.
• Elk gegeven kent een eigenaar en een beheerder.
• Elk gegeven wordt enkelvoudig opgeslagen.
• Gegevens worden zo dicht mogelijk bij de bron vastgelegd.

EA is als IT-architectuurdiscipline uniek doordat zij streeft naar het balanceren van business- en IT-doelstellingen, daarmee een breed curriculum aan functies bevat en een breed spectrum aan competenties en inzichten vereist.

Frameworks

Voor de realisatie van EA kunnen frameworks worden gebruikt. Tijdens de afgelopen twintig jaar hebben steeds meer EA-frameworks het levenslicht gezien. Het is duidelijk dat veel frameworks van recente datum echter nog altijd dezelfde principes hanteren en dat vooral de technologische component verder is geëvolueerd in haar toepassingen binnen Enterprise Architecture. De belangrijkste frameworks op dit moment zijn:

• ‘Zachman Framework for Enterprise Architectures’ – een architectuurframework dat is gebaseerd op het werk van John Zachman;
• ‘The Open Group Architectural Framework (TOGAF)’ – een EA-framework dat ook een methodiek voor EA-ontwikkeling biedt (Architecture Development Method – ADM) en ook standaarden bevat om diverse soorten van EA te beschrijven ([TOGA09]);
• ‘The Federal Enterprise Architecture (FEA)’ – een EA-framework voor VS-overheden ([FEA]).

Welke aanpak is nu het meest geschikt? Dat is een moeilijke vraag die slechts na onderzoek goed te beantwoorden is. Wel is het mogelijk een vergelijking van de gangbare methodieken te maken op basis van het algemeen geldende beeld in de markt, dat kan dienen om een verdere meer gedetailleerde vergelijking uit te voeren. We beperken ons hierbij tot de hierboven genoemde opsomming van EA-frameworks (Zachman, TOGAF en FEA).

Zachman heeft het meeste aandacht voor de compleetheid van de taxonomie. TOGAF is voornamelijk gericht op het brengen van complete procesbeschrijvingen, methodologie en een best-practiceaanpak met haar ADM-methodiek, terwijl Zachman en FEA hier veel minder aandacht aan geven.

Het FEA-raamwerk heeft dan weer veel tools ter beschikking voor de bepaling van de volwassenheid en effectiviteit van EA binnen organisaties. FEA is daarnaast een erg bruikbaar raamwerk wanneer de realisatie van een governancemodel binnen EA van primordiaal belang is. Ook TOGAF leent zich daar goed voor.

FEA scoort verder ook goed als het gaat om het bepalen van de zogenaamde ‘effectieve autonome partities’ binnen de organisatie (ter bepaling van de architectonische bouwblokken) en beschikt over een uitgebreide leidraad met betrekking tot de realisatie van een catalogus van ‘architectural assets’. Op de laatste twee aspecten hebben Zachman en TOGAF minder focus.

TOGAF valt verder op door het feit dat ze een lage ‘lock-in’ heeft en organisaties die TOGAF gebruiken dus niet ‘onlosmakelijk’ met de TOGAF-methodologie verbindt. Ook scoort TOGAF hoog wanneer men kijkt naar de informatie die er gratis en vrij over TOGAF te vinden is.

Ten slotte is de tijd die nodig is voordat organisaties de gekozen methodologie werkelijk kunnen gaan gebruiken voor de realisatie van de beoogde ‘business value’ een interessant criterium. Hierbij scoort TOGAF hoog.

De ideale aanpak

Het is opvallend dat geen enkele aanpak helemaal compleet is en dat elke aanpak specifieke voor- en nadelen biedt. Daarom is een organisatie vaak beter uit met een ‘gecombineerde’ of ‘hybride’ aanpak waarbij ze het goede van de verschillende methodieken probeert te combineren.

Een specifiek samengesteld EA-raamwerk dat bestaat uit de procesmatige elementen van TOGAF (de ADM-methodiek) in combinatie met de Zachman taxonomie en de FEA-benadering van autonome organisatorische partities is een voorbeeld van zo’n samenstelling en kan wellicht beter beantwoorden aan organisatiespecifieke wensen en doelstellingen dan het gebruik van één enkel framework dat kan.

Dit betekent dat het resultaat van zo’n combinatie in werkelijkheid maatwerk wordt; op maat van de organisatie. Maar ook dat gegeven is nog altijd geen recept voor succes. Wat EA-raamwerken namelijk niet of slechts heel beperkt omvatten zijn de instrumenten om draagvlak te realiseren en de ‘mentale verandering’ te begeleiden (People & Change).

Om werkelijk de vruchten te kunnen plukken van EA is er commitment doorheen de hele organisatie nodig, maar wel geïnitieerd vanuit de hoogste niveaus van het bedrijf. Een organisatie moet aandacht geven aan de ‘mentale’ verandering die bij de realisatie van een EA komt kijken, aan het baseren van EA-efforts op duidelijk gedefinieerde en meetbare ‘business benefits’, aan daadkrachtig programmamanagement en het faciliteren van ‘verandering’ en kunnen omgaan met ‘voortschrijdende inzichten’. Een iteratieve aanpak kan hierbij overigens goede handvatten bieden en is daarmee een component die in functie van de behoefte kan worden toegevoegd aan de organisatiespecifieke EA-gereedschapskist.

Een EA-realisatie hoort onderdeel te zijn van een integraal programma voor businesstransformatie en kan nooit een doel op zichzelf zijn (het inzetten van EA-instrumenten ten behoeve van onderzoeks- of optimalisatiedoelstellingen daargelaten). Hierbij hoort allereerst een geïntegreerde aanpak van het organisational change management (OCM) en een strategische, business-driven benadering van de transformatie (bijvoorbeeld op basis van een Target Operating Model) opgezet te worden, waarna de realisatie van (onder andere) EA kan volgen.

Vergeet echter niet dat het ultieme objectief een heel harde is en blijft: het laten dalen van IT-kosten en -complexiteit terwijl de business value en de effectiviteit (‘wendbaarheid’) worden verhoogd: realiseren van een optimale ‘enterprise agility’.