Enterprise Architectuur: een ontwikkeling in vier decennia

Introductie

Vanuit mijn huidige opdracht kwam ik in contact met Clemens Willemsen. Op zijn LinkedIn profiel deed hij vervolgens de volgende oproep:

I will write a book on the technology in the last 4 decades related to information systems, hardware and software. contact me if you want to write a chapter! You do not have to be an academic researcher but it helps. So far we have experts on information security and other fields.

Clemens Willemsen

De laatste jaren ben ik voorzichtig gestart met schrijven over het onderwerp “Enterprise Architectuur” en in overleg met Clemens heb ik besloten een hoofdstuk te schrijven. Dit hoofdstuk heeft geen directe wetenschappelijke basis, maar is geschreven vanuit persoonlijk perspectief.

Via mijn werk ontmoet ik veel mensen die zich als Enterpise Architect presenteren. In verschillende leeftijdscategorieën, met verschillende achtergronden en met verschillende drijfveren. Zelf ben ik sinds eind jaren ’80 werkzaam op het snijvlak van organisatie, informatie en informatietechnologie. Sinds 2001 werk ik met veel plezier bij een klein adviesbureau in Nederland waar ik inmiddels de rol van partner vervul.

Mijn drie dochters (leeftijd 16, 18 en 21) stellen mij regelmatig de vraag “Wat doe je nu eigenlijk voor werk?”. Ik ben erachter gekomen dat het antwoord op deze vraag niet zo éénduidig is te geven. Als ik zeg dat ik Enterprise Architect ben vragen ze daarna “maar wat doe je nu echt?”. In dit hoofdstuk doe ik een poging om daar antwoord op te geven. Om het werk van een Enterprise Architect vanuit mijn perspectief te beschrijven heb ik de volgende vragen gesteld:

1. Wat is het historisch perspectief van Enterprise Architectuur?
2. Welke factoren hebben de ontwikkeling van Enterprise Architectuur beïnvloed?
3. Waar staat Enterprise Architectuur anno 2021?

De woorden verklaard

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 (én 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 én 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:

Begrip	Omschrijving	Referentie
Architecting	process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle. NOTE: Architecting takes place in the context of an organization (“person or a group of people and facilities with an arrangement of responsibilities, authorities and relationships”) and/or a project (“endeavour with defined start and finish criteria undertaken to create a product or service in accordance with specified resources and requirements”) [ISO/IEC 12207, ISO/IEC 15288]	Artikel 3.1
Architecture	fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution	Artikel 3.2
Architecture Framework	conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders	Artikel 3.4
Environment	context determining the setting and circumstances of all influences upon a system NOTE The environment of a system includes developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social influences.	Artikel 3.8

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.

Kanttekening die bij de genoemde definities zijn te maken, is dat ze zo generiek zijn dat een antwoord op de vraag van mijn dochters 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? In de volgende paragrafen wordt dit verder verkend.

Historisch Perspectief

“The further backward you look, the further forward you can see.”

Winston Churchill

Vanuit literatuuronderzoek blijkt de oorsprong van Enterprise Architectuur vooral te leiden naar één organisatie genaamd: International Business Machines Corporation (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.

Uitgebreide historische analyse in de ontwikkeling van Enterprise Architectuur is uitgevoerd door Kotusev. In zijn artikel “the history of Enterprise Architecture: An Evidence-Based Review” (2016) worden drie periodes geduid:

1. Business Systems Planning (1960s – 1980s)
2. Early Enterprise Architecture (1980s – 1990s)
3. Modern Enterprise Architecture

Veel architecten duiden het Zachman Framework (1987) als het startpunt van Enterprise Architectuur aan. Zoals in het artikel wordt beargumenteerd ligt de oorsprong eerder (onder meer het PRISM framework) en heeft Enterprise Architectuur zich al doende in de jaren ontwikkeld. Zachman gebruikte in 1987 de term “Information System Architecture” waar hij achteraf spijt van had en erkende dat hij het liever Enterprise Architecture had genoemd. Het Framework is later doorontwikkeld en wordt heden ten dage als Enterprise architectuur Framework neergezet.

Het National Institute for Standards and Technology (NIST) introduceerde in 1989 het NIST Enterprise Architecture Model met “Need for integration; the condition of being formed into a whole by the addition or combination of parts or elements.” Het NIST model introduceerde vijf architectuur niveaus 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 (Finkelstein, Martin) 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.

Een compleet beeld geven van de ontwikkeling van Enterprise Architectuur is binnen dit hoofdstuk niet te doen. Daarvoor verwijs ik naar het eerder genoemde artikel.

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 (Meta, Google, Amazon, TikTok, Netflix etc.) 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. Management concepten werden gestimuleerd en breed omarmd vanuit politieke sturing (Clinger- Cohen act 1996 USA). 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, raamwerken door vooral consultancy organisaties, 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 jaren 60/70/80/90 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 database technologie 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 (1990) en Business Process Management heeft geleid tot methodieken en technieken voor procesmanagement. In de huidige tijd staan opnieuw de gegevens centraal waarbij de data gedreven 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, applicatie architectuur, technische architectuur, informatiearchitectuur, procesarchitectuur, oplossingsarchitectuur, cloud architectuur, 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 Group 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.

Een klassieker in de afbakening tussen Enterprise Architectuur en Business Architectuur is geïllustreerd in de volgende figuur.

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.

Kotusev is uitermate kritisch op de huidige methoden, technieken (of raamwerken) die in de markt de boventoon voeren. Ik ben het met hem eens dat bijvoorbeeld TOGAF als raamwerk te veel vrijheidsgraden heeft en 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.

In de uitvoering van Enterprise Architectuur is één belangrijk concept dat steeds terugkomt. Dat is de balans tussen generiek versus specifiek. Twee illustraties voor mijn dochters om dit te duiden:

1. 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.
2. 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).

Waarom nu deze illustraties?

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 (zie bijlage). Door op deze manier te classificeren gaan veel Enterprise architecten anno 2021 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. En dan bedoel ik ook echt daadwerkelijk de samenhang der dingen. Veel van de huidige Enterprise architecten gaan hier aan voorbij. Een theoretische exercitie ter illustratie:

Op niveau 1 wordt een willekeurige context weergegeven in een matrix van negen vakken (naar analogie met de 30 vakken vanuit het Zachman Raamwerk). Op ieder vak ontstaan specialismes met bijbehorende methoden en technieken om binnen het vak een zo goed mogelijke beschrijving te maken. Enterprise architectuur gaat 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.

In 1993 werd al onderkend dat inzicht in de samenhang belangrijk is. Het concept van Alignment is door Henderson en Venkatraman bekend geworden. Bij niveau 2 wordt op de snijvlakken van de vakken de samenhang zichtbaar. Het tussen de regels of lijnen door lezen is een cruciale vaardigheid binnen Enterprise architectuur. Dit leidt tot (nieuwe) methoden en technieken die zich vooral richten op de samenhang. Een concept wat al een aantal jaren veel aandacht krijgt is Business-IT alignment. Vraagstuk hierbij blijft wat we nu precies verstaan onder “business” of “IT”. De positionering van Business-IT alignment is nagenoeg synoniem aan de positionering van Enterprise architectuur.

Uiteraard hangt het ook samen met de keuzes in de initiële indeling van de vakken op welke lijnen de samenhang wordt onderkend. Waar op niveau 2 alleen de aanliggende vakken worden gecombineerd biedt niveau 3 het inzicht om alle vakken met elkaar in verband te brengen. Uiteraard moet gezonde verstand wel gebruikt worden waarbij alleen die verbanden gemaakt moeten worden die ook als relevant worden geacht.

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”.

Terug naar de vraag van mijn dochters: Wat doet een Enterprise architect nu eigenlijk? Het volgende antwoord geef ik daar nu op:
Een Enterprise Architect doet onderzoek naar een organisatie (bedrijf, overheid, non-profit of keten) waardoor inzicht en overzicht wordt gegeven van de samenhang (hoe) tussen processen en gegevens (wat), organisatie (mensen – wie), informatiesystemen en techniek (waarmee). Het onderzoek resulteert in modellen (simulaties) met voorstellen om verbeteringen door te voeren. Op basis van de voorstellen wordt besluitvorming ondersteund om veranderingen door te voeren om balans in de totale oplossing te creëren. Een Enterprise Architect creëert verandering en beweging tot verbetering.

Bronnenlijst

• Fang, Irving. A History of Mass Communication Six Information Revolutions, 1997.
• Finkelstein, Clive. Enterprise architecture for integration: rapid delivery methods and technologies, 2006.
• Fong, Elizabeth N., Alan H. Goldfine. “Information Management Directions: The Integration Challenge”. In NIST Special Publication 500-167, September 1989.
• Hammer, Michael. “Reengineering Work: Don’t Automate, Obliterate. In Harvard Business Review Magazine July-Augustus 1990.
• Kotusev, Svyatoslav. “The History of Enterprise Architecture: An Evidence-Based Review”, 2016.
• Zachman, J.A.” A Framework for Information Systems Architecture”. In IBM Systems Journal vol 26. Nr. 3 (1987): 276–292.