Enterprise Architectuur: Een ontwikkeling in vier decennia
Het vak van Enterprise Architectuur is de afgelopen decennia sterk veranderd, van een specialistisch vakgebied voor de IT-afdeling, naar een samenhangende hoeksteen van digitale transformatie. Peter Hakvoort, die meer dan 30 jaar ervaring heeft in Enterprise Architectuur, neemt ons mee in de evolutie van het vakgebied, en biedt een vooruitblik op de toekomst.
Enterprise Architectuur is een samenvoeging van twee woorden vanuit specifieke context. Een snelle zoekopdracht leidt tot de volgende herkomst. Zowel het woord ‘enterprise’ als ‘architectuur’ zijn te herleiden uit het Latijn en het Frans (rond 1500). Enterprise wordt onder meer gebruikt voor de aanduiding van oorlogsschepen en in de science fiction serie Star Trek voor ruimteschepen.
Vanuit het Latijn is Enterprise te herleiden naar “veroveren” (to occupy). Vanuit het Frans komt enterprise vrij vertaald van het werkwoord “ondernemen”. De term architectuur is vrij vertaald “de kunst van het bouwen”.
In de loop van de jaren is de betekenis van beide woorden verder ontwikkeld. Enterprise heeft zich steeds meer afgebakend naar project of organisatorische eenheid (economische of bedrijfsmatige organisatie eenheid). Het begrip architectuur is verder gedifferentieerd. Zo zijn er verschillende architectuurstijlen, en het begrip architectuur wordt niet alleen in de fysieke bouwwereld gebruikt.
Het begrip enterprise en architectuur hebben zich ontwikkeld onder meer binnen de bedrijfskunde en specifiek de (digitale) informatievoorziening. Uiteindelijk zijn de begrippen enterprise en architectuur aan elkaar gekoppeld tot Enterprise Architectuur.
In de huidige begripsvorming binnen de informatievoorziening wordt Enterprise Architectuur gepositioneerd als het allesomvattende concept waarbinnen allerlei specialisaties van architectuur worden onderkend. De definitie van de term architectuur is zelf genormeerd in de standaard NEN-ISO/IEC/IEEE 42010.
Een aantal definities uit deze norm:
Architecting is het proces van bedenken, definiëren, uitdrukken, documenteren, communiceren, het juist implementeren, onderhouden en verbeteren van een architectuur gedurende de hele levenscyclus van een systeem.
Architecting vindt plaats in de context van een organisatie (persoon of groep mensen en faciliteiten met een verdeling van verantwoordelijkheden, bevoegdheden en relaties) en/of een project (inspanning met gedefinieerde start- en eindcriteria, ondernomen om een product of dienst te creëren in overeenstemming met gespecificeerde middelen en vereisten).
Architecture is het geheel van fundamentele concepten of eigenschappen van een systeem in zijn omgeving, belichaamd in zijn elementen, relaties en in de principes van zijn ontwerp en evolutie.
Architecture Framework betreft conventies, principes en praktijken voor de beschrijving van architecturen, vastgesteld binnen een specifiek toepassingsdomein en/of gemeenschap van belanghebbenden.
Environment is de context die de setting en omstandigheden bepaalt van alle invloeden op een systeem. De omgeving van een systeem omvat ontwikkelings-, technologische, zakelijke, operationele, organisatorische, politieke, economische, juridische, regelgevende, ecologische en sociale invloeden.
Een mooie quote die ik tegenkwam is: Enterprise Architectuur is een werkwoord, niet een zelfstandig naamwoord. Hier kan ik mijzelf in vinden, maar niet iedereen is zich hier bewust van. Door het begrip architecting als eerste in de norm op te nemen wordt gelukkig de nadruk gelegd op het werkwoord. De begrippen omgeving (environment) en systeem (system) genoemd in de norm duiden de afbakening van de term Enterprise.
Een kanttekening die bij de genoemde definities te maken is, is dat ze zo generiek zijn dat een antwoord op de vraag niet zo eenduidig is te geven. Dit is ook precies het dilemma wat binnen het vakgebied Enterprise Architectuur een grote uitdaging is. Hoe is Enterprise Architectuur vanuit de huidige tijdgeest dan te duiden?
Historisch perspectief
Vanuit literatuuronderzoek blijkt de oorsprong van Enterprise Architectuur vooral te leiden naar één organisatie: IBM. In de jaren ‘60 tot eind ‘80 zijn er verscheidene mensen geweest die (on)bewust de basis hebben gelegd voor wat nu Enterprise Architectuur heet. Veel van de mensen die bij IBM werkten zijn hun eigen weg gegaan en hebben het in deze tijd ontstane gedachtengoed verder ontwikkeld.
De ontwikkeling van Enterprise Architectuur bestaat uit drie periodes: Business Systems Planning (1960s – 1980s), Early Enterprise Architecture (1980s – 1990s) en Modern Enterprise Architecture.
Veel architecten duiden het Zachman Framework (1987) als het startpunt van Enterprise Architectuur aan. Echter: Zachman gebruikte in 1987 de term “Information System Architecture”, iets waar hij achteraf spijt van had en erkende dat hij het liever Enterprise Architecture had genoemd.
Het Zachman Framework is later doorontwikkeld en wordt heden ten dage als het Enterprise Architectuur Framework neergezet.
Het National Institute for Standards and Technology (NIST) introduceerde in 1989 het NIST Enterprise Architecture Model. Het NIST model introduceerde vijf architectuurniveaus waaronder business unit, information, information system, data en delivery system. Dit model was een referentie voor modellen en raamwerken die in de jaren ’90 tot ontwikkeling kwamen.
Oplopend met de ontwikkeling van Information Architecture naar Enterprise Architectuur heeft het vakgebied Information Engineering zich parallel ontwikkeld naar Enterprise Engineering. In principe doet een architect wat anders dan een ingenieur.
Maar kijkende naar de methoden en technieken vanuit Enterprise (Information) Architecture in vergelijking met Enterprise (Information) Engineering zijn er meer overeenkomsten dan verschillen. Dit is niet zo gek, omdat het vakgebied Information Engineering ook vanuit dezelfde IBM school is voortgekomen.
Factoren van invloed op de ontwikkeling van Enterprise Architectuur
Factoren die de ontwikkeling van Enterprise Architectuur hebben gevormd zijn te herleiden naar onder meer technologische, economische en politieke factoren waarbij die factoren ook onderling een grote invloed op elkaar hebben.
Technologische factoren beginnen bij de ontwikkeling van databases in de jaren ‘60 tot de personal computer (1981), ontwikkeling van het internet, draadloos/mobiele technologie tot aan alle vormen van cloud computing die zich heden ten dage ontwikkelen.
Informatietechnologie is een key driver geworden voor de ontwikkeling van marktdominante bedrijven zoals Meta, Google, Amazon, TikTok en Netflix die door de inzet van deze informatietechnologie een stempel drukken op economische, politieke én sociaal-maatschappelijke ontwikkelingen.
De technologische ontwikkeling van Enterprise Resource Planning (ERP) systemen, een term begin jaren ‘90 geïntroduceerd door Gartner, naar een Post Modern ERP is ook een factor die de ontwikkeling van Enterprise Architectuur heeft gevormd.
De economische en politieke ontwikkeling van Japan waar methoden en technieken als Lean en Kanban (jaren ‘70 – ‘80) zich ontwikkelden leidde tot grote economische voorsprong van dat land. Als tegenreactie vanuit de USA/UK ontstond het total quality control paradigma. Managementconcepten werden gestimuleerd en breed omarmd vanuit politieke sturing (Clinger-Cohen Act uit 1996).
Ook in Europa ontwikkelden individuele landen en Europa als geheel zich. Thema’s als globalisatie, digitale- en informatierevolutie hebben allemaal invloed op de ontwikkeling van Enterprise Architectuur. Hiernaast is de ontwikkeling van bedrijfskundige modellen en raamwerken door vooral consultancyorganisaties, maar ook vanuit overheden een belangrijke factor die de ontwikkeling van Enterprise Architectuur heeft gevormd.
Interessant om te duiden is dat veel van de methoden groot zijn geworden door slimme marketeers. Zachman was van oorsprong een marketing specialist. Zogenaamd nieuwe frameworks worden gepositioneerd (zoals TOGAF) waarbij het lijkt of alle concepten van de afgelopen 30 jaar zijn samengevat in één allesomvattend raamwerk.
Veel van de concepten die in de afgelopen decennia zijn ontwikkeld worden in deze tijd, vaak in een andere vorm, opnieuw gebruikt, wederom vaak door slimme marketeers, met bijbehorende certificeringsmodellen. Een eerste voorbeeld hiervan zijn de huidige low code/no code platformen die nu als revolutionair worden beschouwd maar die met enige nuance terug te herleiden zijn naar een concept uit de jaren 90 van Computer Aided Software Engineering Tooling (CASE tooling).
Een tweede voorbeeld vanuit de jaren ‘60–‘80 is dat vanuit de ontwikkeling van databasetechnologie er veel aandacht besteed is aan methoden en technieken voor de modellering van gegevens (ERD). In de jaren 90 stonden processen centraal. Business Process Reengineering (BPR) en Business Process Management (BPM) heeft geleid tot methodieken en technieken voor procesmanagement.
In de huidige tijd staan opnieuw de gegevens centraal waarbij de datagedreven organisatie nu een kernthema is voor vele organisaties zowel in het bedrijfsleven als bij de overheid.
Waar staat Enterprise Architectuur anno nu?
Enterprise Architectuur is als begrip verder ontwikkeld. Maar naast Enterprise Architectuur is er een hoeveelheid van architecturen te onderkennen. Business architectuur, applicatiearchitectuur, technische architectuur, informatiearchitectuur, procesarchitectuur, oplossingsarchitectuur, cloudarchitectuur, beveiligingsarchitectuur en ga zo maar door. Achter ieder zelfstandig naamwoord gebruikt binnen de informatietechnologie wordt het woord architectuur geplakt.
Tegenwoordig heeft ook ieder van deze architecturen zijn eigen body of knowledge, één of meerdere certificeringsregelingen en soms zelf meer dan één Association of Netwerk met bijbehorende (inter)nationale chapters. Het is een industrie op zich geworden waarbinnen weer allerlei stromingen zijn te onderkennen.
Hierdoor ontstaan vragen als: is Enterprise Architectuur nu onderdeel van de Business Architectuur of andersom? Om heel eerlijk te zijn vind ik dit persoonlijk een non-discussie. Je kan hier op afstuderen.
Als enterprise architect is het wel van belang om te weten vanuit welke context Enterprise Architectuur wordt gepositioneerd. Soms kan het van belang zijn om deze discussie vooraf te voeren (om bijvoorbeeld het mandaat van de Enterprise architect te verkennen), maar soms is het beste om deze discussie te vermijden en gewoon te beginnen.
Zelf ben ik kritisch op de huidige methoden en technieken (of raamwerken) die in de markt de boventoon voeren. TOGAF heeft als raamwerk bijvoorbeeld te veel vrijheidsgraden en is te breed georiënteerd is. De methoden en technieken binnen TOGAF brengen niet altijd dat wat beloofd wordt in termen van praktische toepasbaarheid en daadwerkelijk bewezen toegevoegde waarde.
Ondanks dat biedt TOGAF wel een aantal methoden en technieken die, mits op de juiste manier gebruikt, wel degelijk toegevoegde waarde leveren. Dit is dan niet iets specifiek vanuit TOGAF maar vanuit de methoden en technieken die in het verleden al eerder waren bedacht en in TOGAF zijn opgenomen.
Generiek versus Specifiek
In de uitvoering van Enterprise Architectuur is één belangrijk concept dat steeds terugkomt. Dat is de balans tussen generiek versus specifiek. Twee illustraties om dit te duiden:
Neem het begrip sport. Als je sport specifieker gaat analyseren kom je tot de ontdekking dat volleybal toch echt iets anders is dan voetbal. Het zijn beide balsporten met specifieke kenmerken. Zwemmen is ook een sport en binnen de zwemsport heb je ook weer een balsport namelijk waterpolo. Zo kan je dus iets specifiek benoemen zoals waterpolo, maar dat generieker maken door daar balsport van te maken of nog generieker door het als sport te beschouwen.
Een andere illustratie is bijvoorbeeld een arts. Zo heb je een arts die gespecialiseerd is in het behandelen van kinderen en een arts die gespecialiseerd is in longproblemen. Een niveau dieper van specialisatie is een kinderarts die ook gespecialiseerd is in longproblemen (of een longarts gespecialiseerd in het behandelen van kinderen).
De ontwikkeling van Enterprise Architectuur heeft zich gevormd vanuit de dynamiek tussen generiek versus specifiek. Vanuit de historie zijn de verschillende architectuurdimensies zoals informatie architectuur, data architectuur, business architectuur generiek gemaakt tot Enterprise Architectuur. In de huidige maatschappij zijn we continu bezig om alles te classificeren en in hokjes te stoppen. Naarmate onze kennis toeneemt worden we steeds specifieker en komen er meer hokjes bij.
Veel van de huidige ‘architectuurmodellen’ maken matrices waarbij per vakje in de matrix een methode of duiding plaats vindt (zo ook het eerder genoemde Zachman Framework). Door op deze manier te classificeren gaan veel enterprise architecten anno 2022 voorbij aan wat daadwerkelijk de toegevoegde waarde van Enterprise Architectuur is. De volgende uitdagingen komen daarbij aan de orde.
Uitdaging 1: creëer overzicht en inzicht door samenhang en balans
De eerste grote uitdaging in Enterprise Architectuur is overzicht en inzicht creëren in de samenhang der dingen.
Enterprise Architectuur gaat namelijk om de samenhang der dingen. Het gaat om inzicht te geven tussen de vakken. Veel van de huidige Enterprise Architectuur werkzaamheden blijven binnen de vakken hangen waardoor het eigenlijk géén Enterprise Architectuur mag heten. Een perfecte procesarchitectuur, een perfecte informatiearchitectuur en een perfecte technische architectuur leiden niet tot een perfecte Enterprise Architectuur.
De beste individuele voetballers bij elkaar zetten leidt niet per definitie tot het beste team. Uiteindelijk gaat het om het vinden van de juiste balans. Conclusie is dat Enterprise Architectuur een interdisciplinaire kunde is en niet alleen multidisciplinair is.
Uitdaging 2: Analyseer de samenhang en afhankelijkheden
De tweede grote uitdaging is om op het snijvlak de analyses daadwerkelijk uit te voeren. In de huidige tijdgeest waarin alles snel en kort moet is er geen geduld en tijd meer om de analyses op de snijvlakken uit te voeren. Via de snijvlak-analyse vindt er ook impliciet kwaliteitsborging plaats op onder meer compleetheid en consistentie.
Een procesarchitectuur onafhankelijk opgesteld van de gegevensarchitectuur leidt bijna per definitie tot een onvolledig en mogelijk zelfs een onjuist beeld.
Het vergt kennis én ervaring om de analyses op samenhang goed uit te kunnen voeren. Als de analyses kwalitatief goed zijn uitgevoerd ontstaat er balans. Om je doelen als organisatie te bereiken dienen de processen, organisatie (mensen), informatie/gegevens, applicaties en techniek perfect in balans te zijn. Aangezien de wereld om ons heen steeds veranderd (en de organisatie zelf ook) wordt de balans continu bijgesteld. In de kern is dat wat Enterprise Architectuur doet.
Uitdaging 3: Juist genoeg, precies op tijd
De derde grote uitdaging is (ondanks de tweede uitdaging) net voldoende uit te werken om tijdig inzicht en overzicht te geven in de mogelijke acties die ingezet kunnen worden om te sturen op de balans. Enterprise Architectuur dient een voorspellend karakter te hebben. Het risico is dat je met de uitvoering van Enterprise Architectuur steeds achter de feiten aanloopt.
De uitdaging zit in een efficiënte- en effectieve manier van analyseren zodat overzicht en inzicht gegeven kan worden aan de juiste mensen om weloverwogen beslissingen te nemen. Uiteindelijk creëert Enterprise Architectuur beweging.
Een vooruitblik
De komende paar jaar voorzie ik in ieder geval nog twee grote ontwikkelingen binnen Enterprise Architectuur.
De eerste ontwikkeling gaat over het gebruik van simulaties. Niet iedereen is overtuigd van nut en noodzaak van Enterprise Architectuur. Argument is dat de complexiteit te groot is om in een model uit te drukken waardoor geen toegevoegde bereikt kan worden.
Een tweede argument is dat Enterprise Architectuur een socio-technisch systeem is waarbij de mens onvoorspelbaarheid creëert in het systeem. De huidige Enterprise Architect maakt vooral gebruik van statische modellen. Mijn argument is dat juist bij een complexe omgeving het maken van een model toegevoegde waarde heeft.
Hiernaast ben ik van mening dat wel degelijk input van de mens in het model gestopt kan worden om via simulaties bij te sturen. Het concept van ‘digital twin’ is mijns inziens een volgende stap binnen de Enterprise Architectuur.
Een voorbeeld ter illustratie is een Formule 1 auto. Van de fysieke auto is een compleet digitaal model beschikbaar. Tijdens de race wordt er allerlei data verzameld (Internet of Things) die via sensoren direct worden uitgelezen én wordt de input van de chauffeur (mensfactor) verwerkt.
Dit tezamen resulteert in een continue bijsturing van de parameters van de auto én het rijgedrag van de chauffeur. Dit principe wordt inmiddels ook op fysieke bouwwerken toegepast, maar kan ook de Enterprise Architectuur tot verdere ontwikkeling brengen.
Tweede ontwikkeling die ik verder nog zie groeien is dat Enterprise Architectuur in de context van ketens wordt uitgewerkt. Veel parallellen zijn te maken met de ontwikkeling van logistiek management wat uiteindelijk tot supply chain management is gegroeid. De scope van ‘enterprise’ zal in de komende jaren ook op ketens worden toegepast. Misschien ontwikkeld Enterprise Architecture zicht wel tot ‘Value Chain Architecture’.
Over de auteur
Peter Hakvoort is Partner bij Vellekoop & Meesters. Dit artikel is afkomstig uit het boek ‘Four Decades of Information Technology and Innovation’ van Clemens Willemsen, waar Hakvoort een bijdrage aan leverde.
