Enterprise-architectuur staat bekend als een stuurinstrument. In de praktijk blijkt dat het opstellen en onderhouden van een enterprise-architectuur zeer complex is en resulteert regelmatig in een teleurstelling. Het potentieel van een enterprise-architectuur is zeer groot. Voor bestuurders is het verkrijgen van inzicht op het gebied van samenhang, witte vlekken en bedrijfsrisico’s een aanleiding om opdracht te verstrekken tot het opstellen van een enterprise-architectuur. De verwachtingen zijn vaak hoog en als bepaalde verwachtingen niet uitkomen, is er een flinke teleurstelling waarneembaar over het geleverde resultaat.
Tijdens het opstellen van een enterprise-architectuur wordt meestal gebruikgemaakt van een standaardraamwerk. Op zich een goed gebruik. De standaardraamwerken waarmee een enterprise-architectuur kan worden opgesteld, hebben echter hun beperkingen. Bestaande raamwerken werken vanuit de gedachte om een enterprise-architectuur te realiseren en te onderhouden. Het hele proces is voor precies die reden ingericht en in de afgelopen jaren geoptimaliseerd. Om het proces in goede banen te leiden worden er randvoorwaarden gesteld om de exercitie om tot een enterprise-architectuur in goede banen te leiden. Op de vraag van de opdrachtgevers 'welke toegevoegde waarde heeft een enterprise architectuur en wat kan ik ermee?' mag vaak geen expliciet en eenduidig antwoord worden verwacht.
Om een goed inzicht te verkrijgen in de samenhang van de informatievoorziening van bedrijven is het noodzakelijk om te beschikken over een instrument dat de samenhang inzichtelijk maakt. Het begrip (enterprise-)architectuur wordt vaak direct in relatie gebracht met deze behoefte. De noodzaak om te beschikken over een goede enterprise-architectuur behoeft in de meeste gevallen geen toelichting. Maar wat is een goede (enterprise-)architectuur?
Het antwoord op de vraag is niet eenvoudig. Dit komt doordat de term architectuur in de ict inmiddels erg beladen is. Daarom wil ik de vraag herformuleren in: 'Wat zijn de uitgangspunten om tot een bruikbare enterprise-architectuur te komen?'
Op de eerste plaats dient architectuur als instrument beter gepositioneerd te worden. Hierbij dient de relatie tussen de volgende onderdelen bij aanvang expliciet te zijn:
– Doel en kwaliteit van de enterprise-architectuur.
– Stakeholders en individuele resultaatbehoefte.
– Scope en randvoorwaarden.
– Afnemers van het resultaat.
– Onderscheid tussen inhoudelijke architectuur en output.
Het aanstellen van een enterprise-architect is nog geen reden om aan te nemen dat er een goede, bruikbare enterprise-architectuur zal ontstaan. Inhoud en besturing gaan vaak niet samen. In de praktijk blijkt dat de enterprise-architect zich met name richt op het realiseren van de enterprise-architectuur en de stakeholders tracht te overtuigen van de resultaten van zijn werkwijze.
Beleidsmakers stellen in beleid doelen, middelen en tijdspaden vast. De onderlinge samenhang van deze elementen is cruciaal. Om doelen meetbaar te krijgen en te houden worden deze vaak opgeknipt naar tussendoelen en een einddoel. Het is hierbij van belang dat alle beleidsinstrumenten de juiste terugkoppeling ten behoeve van het monitoren van realisatie van beleid leveren.
Vanuit beleid gezien kan een enterprise-architectuur een van de instrumenten zijn mits aan de uitgangspunten waaraan een beleidsinstrument dient te voldoen, wordt voldaan. Met het opstellen en onderhouden van een enterprise-architectuur ontstaat er veel kennis over de organisatie en relaties met de randvoorwaarden waarin de enterprise-architectuur zich dient te ontwikkelen. 90 procent van deze kennis is benodigd om het architectuurproces te kunnen beheersen en is niet bruikbaar als terugkoppeling of output.
Door een enterprise-architectuur te positioneren als blackbox, met expliciete sturing op input (randvoorwaarden, scope en dergelijke), terugkoppeling, en output welke is afgestemd op de stakeholders en beleid, ontstaat een enterprise-architectuur die bruikbaar is als beleidsinstrument.
Beste Eric,
Wat je schrijft is heel herkenbaar.
Het punt dat je maakt, dat het resultaat van enterprise architectuur vaak teleurstellend is, is iets wat ik herken. Ik ben zelf ook dagelijks bezig om de toepasssing van enterprise architectuur te verbeteren bij organisaties.
In aanvulling op je duidelijke visie en voor verdere discussie wil ik vier punten aandragen. Ik doe dat omdat ik deze punten niet voldoende in je visie zie terug komen en het in mijn ogen juist deze zaken zijn waarmee architectuur meer toegevoegde waarde kan krijgen.
In mijn praktijk als coach voor enterprise architecten neem ik waar dat architecten soms zelfs zonder opdracht daartoe architecturen gaan opstellen of principes gaan bedenken. Of dat de eigenaar van de architectuur of informatievoorziening of bedrijfsprocessen niet eens op de hoogte is dat er architecten nieuwe dingen aan het bedenken zijn.
Mijn wapens die ik in de strijd gooi om het resultaat van enterprise architectuur te verhogen zijn: (1) het strategisch organiseren van architectuur, (2) architecten moeten meer als ontwerpers bezig gaan, (3) betere architectuurprincipes formuleren en (4) architectuurvisualisaties gaan gebruiken.
Ik hier ook veel over geschreven op mijn pagina: http://research.paauwe.info/enterprise-architectuur.php en op XR magazine.
Punt 1: – strategisch organiseren van enterprise architectuur
Ik positioneer het opstellen van een enterprise architectuur als puur strategische activiteit die input is voor beleid. Alle fundamentele keuzes in een architectuur zijn voor de onderneming al gauw strategische keuzes. Het is een soort treinwissel; heb je die eenmaal genomen dan is het moeilijk de wissel weer terug te zetten, en ook al zet je de wissel terug, je bent toch al een tijdje een bepaalde richting opgegaan. Als je dan kijkt naar vele architecten bij organisaties, dan zie je dat architecten vaak op de IT-afdeling op tactisch niveau resorteren onder een manager. Vanuit die positie is het onbegonnen werk om zonder IT-belang de strategische uitgangspunten van de onderneming te vertalen samen met de directie naar architectuurprincipes voor de vernieuwingsprogramma’s.
Met als gevolg dat architecten vaak strategische keuzes maken zonder dat de opdrachtgevers (directie en topmanagement) hierbij voldoende betrokken worden.
Mijn advies daarin is vaak: herpositioneer de architecten direct onder de directie en geef ze expliciete ontwerpopdrachten met voldoende mandaat en duidelijke definitie van het resultaat en het doel.
Enterprise architectuur is het op conceptueel niveau ontwerpen van ondernemingsbrede systemen en domeinen in de organisatie. Informatie architectuur is daarbinnen weer het conceptueel ontwerp van de ondernemingsbrede informatievoorziening. Het is voor een onderneming van groot belang om deze architecturen op strategisch niveau te laten opstellen, dicht tegen de missie, visie, identiteit, cultuur en strategie van de onderneming aan.
Punt 2: ? Architecten moeten meer als ontwerpers bezig gaan
In de bouwkunde is een architect iemand die ontwerpen maakt. Hij baseert zich daarop op onder andere programma?s van eisen voor een bouwwerk. Het conceptuele deel van het architectuurontwerp staat vaak gelijk aan de architectuur van het bouwwerk. De architect ziet vaak het architectuurgedeelte als onderdeel van het ontwerp, maar stopt niet bij het opstellen van de architectuur.
Kijken we naar de architecten in organisaties, dan zien we veel architectuurdocumenten en zeer weinig programma?s van eisen of ontwerpen. De architecten stoppen in mijn ogen te vroeg met het werk en luisteren te weinig naar de opdrachtgever. Als we dan ook nog eens in de architectuurdocumenten kijken zien we veel uitgangspunten en randvoorwaarden die de architecten zelf hebben bedacht en niet zijn geaccordeerd door de opdrachtgever. Resultaat: een prachtig beschreven architectuur waar je veel aan zou kunnen hebben, maar waar niemand om heeft gevraagd en dus ook door niemand wordt gebruikt! Stel je eens voor dat je zelf voor alle rotondes in jouw gemeenten dezelfde voorrangsregels gaat opstellen. Daar zou iedereen wat aan hebben. Iedereen ziet dit waarschijnlijk wel zitten, maar ? niemand gaat het doen, want er was geen opdracht voor gegeven en niemand heeft eisen gesteld.
Punt 3 ? Betere architectuurprincipes formuleren
In het architectuurvakgebied is een heuse fout geslopen: de definitie voor het begrip principe. In de bouwkunde is het begrip principe iets om de gehandhaafde werking van systemen, fenomenen en concepten mee te analyseren, te begrijpen. De kwalitatieve resultaten die de werking van een concept produceert wordt weer hergebruikt als argument voor de keuze van een concept of oplossingsrichting. Denk aan het zuigerprincipe van een dieselmotor of het principe van de stofzakloze stofzuiger. Maar nu: pakken we de referentie architecturen NORA en GEMMA of gangbare architectuurmethoden erbij, dan zie we dat daarin principes worden gedefinieerd als uitgangspunten of als kenmerken van diensten of als wetten, regels, richtlijnen, richtinggevende uitspraken die de ontwerpruimte beperken. Maar principes worden momenteel nog vaak niet gezien als de uitleg van de werking van concepten, zeker niet in deze referentie architecturen.
De principes die men daarin formuleert (of als zodanig labeled) zijn eisen die worden gesteld aan kenmerken of regels van de te maken oplossingen. Echter deze ?principes? (of beter gezegd eisen of regels ) zijn niet door de opdrachtgever of belanghebbenden bekrachtigd. De opdrachtgever weet namelijk niet eens dat de architect zelfs eisen en regels bedenkt of opstelt.
Voorbeelden: ?Kennis is macht? en ?Door virtualisatie meer kostenbesparing en betere beheersing? zijn voorbeelden van echte principes. ?Kennis wordt altijd maximaal gedeeld onder medewerkers? is geen principe maar een regel of uitgangspunt. ?De basis op orde? of ?Eenmalige uitvraag van gegevens? zijn regels, eisen of wensen maar geen principes. Principes horen te gaan over het WAT en over het HOE!
Mijn advies in deze is om ALTIJD naast een architectuurdocument een programma van eisen document te maken en een literatuurlijst. Daarna alles wat in het architectuurdocument onder het kopje principes staat te beoordelen: willen we dit graag of zou het zo moeten gaan werken? Zo ja, dan is het een eis of uitgangspunt (betreffende een regel of eigenschap) en zetten we het in het programma van eisen. Staat wat als principe wordt onderkend ook zo in een bedrijfskundig of informatiekundig boek als concept? Ja, dan mag het als (basis van een) principe in de architectuur blijven staan met een verwijzing naar de literatuur. Tevens dient de architect te beschrijven/beargumenteren waarom het principe nodig is in het licht van welke eisen, randvoorwaarden, doelen en uitgangspunten in het programma van eisen.
Door een progamma van eisen te onderkennen wordt er tevens voor gezorgd dat architecten ook beter gaan luisteren naar wat opdrachtgevers en belanghebbenden vragen en krijgen deze partijen ook meer de kans om hun (tegenstrijdige) wensen en eisen in alle rust in workshops te uiten, waarna de architecten er een consistent geheel van kan maken. Ook achteraf heeft het altijd zin om een programma van eisen te maken: dan wordt duidelijk tegen welke eisen de opdrachtgever geen ja heeft gezegd! Een mooi leerpunt voor de volgende keer.
Punt 4: – Architectuurvisualisaties gaan gebruiken
Het laatste punt dat ik wil maken is dat architecten vaak de kracht van architectuurvisualisaties niet kennen en laten liggen. Als men dan toch mensen wil overtuigen van hoe iets zou moeten, waarom dan niet net zoals de bouwkundige broeders werken en doen.
Een ontwerpschets, een situatieschets, een principedetailtekening, een structuurvisie, een domeinenmodel, een blauwdruk, een persona, een storyboard, een artist impression; allemaal soorten visualisaties die de architect kan maken om opdrachtgevers en belanghebbenden snel en goed strategische keuzes (strategic trade offs) te laten maken die als ontwerpbeslissingen zijn over te nemen.
In een architectuurvisualisatie kun je heel goed de relatie leggen tussen verschillende tegenstrijdige eisen van de opdrachtgever en een totaalconcept dat invulling geeft aan de behoeften en omgaat met de tegenstijdige eisen. Met een schetsmatige visualisatie kun je een abstracte oplossing met metaforen beter communiceren dan met tekst. De veel gebruikte entiteit-relatie-diagram-achtige tekeningen zijn voorbeelden van visualisaties die je vooral niet moet maken richting de opdrachtgever om keuzes te laten maken.
Het probleem is: de huidige generatie van architecten in de organisatie heeft niet geleerd te ontwerpen en te communiceren door te visualiseren, oa. omdat ze zich niet zien als ontwerpers maar als generalisten die met indelingen en standaarden moeten komen aanzetten in dikke tekstuele documenten. De dag dat een architect zich zelf voorneemt voortaan elk vraagstukken begrijpelijk visueel aan de opdrachtgever voor te leggen (met de keuze uit twee opties), is de dag dat hij architect aan het worden is. Uit mijn promotieonderzoek is bijvoorbeeld gebleken dat iemand die niet deskundig is op het gebied waar een beslissing in moet worden genomen in een minuut tijd een visualisatie beter begrijpt en verbanden en impact meer doorziet dan met een A4-tje tekst.
Ik hoor graag wat je vindt van deze vier punten.
Een aantal concrete vragen uit mijn betoog:
1- Ben je ook van mening dat enterprise architectuur meer strategisch dient te worden georganiseerd?
2- Ben je ook van mening dat informatie architectuur het conceptueel ontwerp is van de ondernemingsbrede informatievoorziening?
3- Ben je ook van mening dat architecten eigenlijk zeer ervaren en creatieve ontwerpers zijn?
4- Ben je ook van mening dat er meer ontwerpopdrachten, programma?s van eisen en literatuurlijsten dienen te komen naast architectuurdocumenten?
5- Ben je ook van mening dat principes in het huidige vakgebied of verkeerde wijze worden gedefinieerd, geformuleerd en gebruikt (i.e. verward worden met eisen, regels en uitgangspunten)?
6- Ben je ook van mening dat architecten meer architectuurvisualisaties moeten gaan maken?
Ik hoor graag van je.
mark@paauwe.info
gsm: 06 284 17 269
http://www.markpaauwe.com