Kies strategisch!

Het resultaat van enterprise-architectuur is te vaak teleurstellend te noemen. Zelf ben ik dan ook dagelijks bezig als architectuurcoach om de toepassing van enterprise-architectuur bij ondernemingen te verbeteren. In dit artikel draag ik voor verdere discussie aangaande dit onderwerp vier punten aan. Ik doe dat omdat ik deze punten niet voldoende in de discussies van het vakgebied zie terugkomen 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, informatievoorziening of bedrijfsprocessen zelfs niet op de hoogte is dat architecten nieuwe dingen aan het bedenken zijn.

Mijn wapens die ik ‘in de strijd gooi’ om het resultaat van enterprise-architectuur te verbeteren, zijn: (1) het strategisch organiseren van architectuur, (2) architecten moeten meer als ontwerpers bezig gaan, (3) betere architectuurprincipes formuleren en (4) architectuurvisualisaties gaan gebruiken.

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 die in een architectuur zijn gemaakt, 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 (verkeerde) richting opgegaan. Als je dan kijkt naar vele architecten bij ondernemingen en binnen de overheid, dan zie je dat architecten vaak op de ICT-afdeling op tactisch niveau ressorteren onder een manager. Vanuit die positie is het onbegonnen werk om zonder ICT-belang samen met de directie de strategische uitgangspunten van de onderneming te vertalen naar architectuurprincipes voor de vernieuwingsprogramma’s. De afstand tot de directie is voor veel architecten vanwege hun organisatorische positie ook te groot.

Als gevolg hiervan maken architecten vaak strategische keuzes zonder dat de opdrachtgevers (directie en topmanagement) hier voldoende bij 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 onderneming. Informatiearchitectuur 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 identiteit, cultuur, missie, visie 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 gebruikt hierbij 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 ondernemingen, 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 gemeente dezelfde voorrangsregels gaat opstellen in een architectuur voor rotondes. Daar zou iedereen wat aan hebben. Iedereen ziet dit waarschijnlijk wel zitten, maar… niemand gaat het doen, want er was geen ontwerpopdracht voor gegeven, niemand heeft eisen gesteld en er is ook geen goedgekeurd architectuurontwerp dat kan worden gerealiseerd.

Punt 3: Betere architectuurprincipes formuleren
In het architectuurvakgebied is een heuse fout geslopen: de definitie van het begrip ‘principe’. In de bouwkunde is het begrip principe iets om de gehandhaafde werking van systemen, fenomenen en concepten mee te analyseren en te begrijpen. De kwalitatieve resultaten die de werking van een concept produceert worden 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 referentiearchitecturen NORA en GEMMA of gangbare architectuurmethoden erbij, dan zie we dat daarin principes soms worden gedefinieerd of gezien als uitgangspunten of als kenmerken van diensten, of als wetten, regels, richtlijnen, richtinggevende uitspraken die de ontwerpruimte beperken. Principes worden momenteel nog te vaak onvoldoende gezien als de uitleg van de werking van concepten; zeker in de referentiearchitecturen is daar een verbeterslag in te maken.

De principes die men in referentiearchitecturen formuleert (of als zodanig labelt) zijn te vaak 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 waarschijnlijk niet eens dat de architect zelf, vaak onbedoeld overigens, 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 voorbeeld van principe, maar een voorbeeld van een regel of uitgangspunt. ‘De basis op orde’ of ‘Eenmalige uitvraag van gegevens’ zijn regels, eisen of wensen, maar weer geen principes. Principes behoren te gaan over het WAT en over het HOE!

Mijn advies in deze is om ALTIJD naast een architectuurdocument een programma-van-eisendocument te maken en een literatuurlijst. Daarna dient alles wat in het architectuurdocument onder het kopje ‘principes’ staat, beoordeeld te worden: 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? Zo ja, 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 programma van eisen te onderkennen wordt het architectuurdocument beter en wordt er tevens voor gezorgd dat architecten beter gaan luisteren naar wat opdrachtgevers en belanghebbenden vragen. Bovendien krijgen deze partijen meer de kans om hun (tegenstrijdige) wensen en eisen in alle rust in workshops te uiten, waarna de architect 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 onbenut laten. Als men dan toch mensen wil overtuigen van hoe iets zou moeten, waarom dan niet net zoals de bouwkundige broeders het doen?

Een ontwerpschets, een situatieschets, een principedetailtekening, een structuurvisie, een domeinenmodel, een blauwdruk, een persona, een storyboard, een artist impression; stuk voor stuk 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 én dat op zuivere wijze omgaat met de tegenstrijdige eisen. Met een schetsmatige visualisatie kun je een abstracte oplossing met metaforen beter communiceren dan met tekst. De veel gebruikte entiteit-relatie-diagramachtige tekeningen zijn voorbeelden van visualisaties die je vooral niet moet communiceren richting de opdrachtgever en dan te vragen om hiermee keuzes te maken.

Het probleem is: de huidige generatie architecten in de onderneming heeft niet geleerd te ontwerpen en te communiceren door te visualiseren. Oorzaak is onder meer dat 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 zichzelf voorneemt voortaan elk vraagstuk begrijpelijk visueel aan de opdrachtgever voor te leggen (met de keuze uit minimaal twee opties), is de dag dat hij daadwerkelijk architect aan het worden is. Uit mijn promotieonderzoek is bijvoorbeeld gebleken dat iemand die niet deskundig is op het gebied waar een beslissing over 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 de lezer vindt van deze vier gestelde punten! Ben jij ook van mening dat enterprise-architectuur meer strategisch dient te worden georganiseerd? Ik ben benieuwd naar reacties!

Mark Paauwe is directeur van Paauwe Group.