Architecten vinden het vaak niet eenvoudig om helder te maken wat hun toegevoegde waarde is. Dat heeft veel te maken met het feit dat het vakgebied ook erg groot is en architecten allerlei verschillende rollen kunnen aannemen. Door architectuur in het algemeen te zien als een vorm van kennisdeling en vervolgens als een manier van afspraken maken wordt deze waarde ineens veel duidelijker.
Architecten kunnen een strategische rol vervullen waarbij de nadruk ligt op het concretiseren van de bedrijfsstrategie in principes en actielijnen, maar ook relatief operationele rollen vervullen waarbij de nadruk ligt op het komen tot oplossingen. Er lijkt echter een belangrijke analogie in deze rollen te zitten als je er op een wat meer abstracte manier naar kijkt. Kernactiviteiten van architecten lijken te liggen in het delen van kennis en het maken van afspraken, waarbij de eerste randvoorwaardelijk is voor de tweede. Dit maakt het leven van de architect potentieel veel eenvoudiger. Laten we eens naar deze twee perspectieven kijken.
De algemene doelstelling van architectuur is het sturen van veranderingen in de inrichting van organisatie, processen en systemen. Voor het initiëren van veranderingen zijn keuzes en daarmee samenhangende besluiten van management noodzakelijk. Voor het uitvoeren van verandering moeten keuzes worden gemaakt over de nieuwe inrichting. Richting geven aan verandering betekent dus vooral het beïnvloeden van keuzes. Besluiten en keuzes worden vooral genomen op basis van de kennis die mensen hebben. De architect kan keuzes daarom vooral beïnvloeden door ervoor te zorgen dat mensen over de juiste kennis beschikken. Voordeel hiervan is ook dat dit niet direct een bedreiging oplevert omdat je mensen nergens toe dwingt, maar alleen maar laat zien dat je meedenkt en meehelpt.
Sommige keuzes worden toch niet gemaakt in het belang van de organisatie, ondanks dat de juiste kennis wel aanwezig is. De oorzaak ligt daarbij vooral in belangen van mensen, afdelingen en organisaties. Architectuur probeert te sturen op wat goed is voor de organisatie als geheel en op de langere termijn, en dat is niet altijd voor iedereen en op de korte termijn gunstig. In dat geval zijn afspraken noodzakelijk. Architecten kunnen hier een rol in spelen door essentiële afspraken vast te leggen in de vorm van principes en richtlijnen. Daarmee moet worden bewaakt dat er voldoende ruimte blijft voor autonomie, vakmanschap en ondernemerschap.
Wat betekent dit inzicht nu in de praktijk? Het begint met zicht krijgen in lacunes in kennis bij medewerkers die een belangrijke rol spelen in de verandering die moet plaats vinden. Begin met het verzamelen en verspreiden van kennis waarom een verandering noodzakelijk is. Na besluitvorming verschuift de rol naar het verzamelen en verspreiden van kennis die noodzakelijk is om te komen tot een goed ontwerp van de verandering. Leg in het algemeen de nadruk op kennis die inherent niet geborgd is in de organisatie. Denk bijvoorbeeld aan kennis over nieuwe ontwikkelingen en kennis over de de huidige inrichting van de organisatie, processen en systemen en de samenhang daarin. Een deel van deze kennis is generiek van aard en kan vastgelegd worden in de vorm van een referentie-architectuur. Door deze op een laagdrempelige manier te ontsluiten, bijvoorbeeld in de vorm van een wiki, is de kennis optimaal toegankelijk voor een ieder.
Nadat alle relevante kennis expliciet is gemaakt en in samenhang beschikbaar is in de organisatie verschuift de rol van de architect naar het maken van essentiële afspraken. Om een optimale balans te vinden tussen sturing en flexibiliteit is het belangrijk deze afspraken expliciet af te leiden van strategie, beleid en doelstellingen van de organisatie. In het algemeen willen professionals professionele vrijheid en geen betuttelende regels. Principes bieden een goed instrument om snel afspraken te inventariseren en op een compacte manier vast te leggen. Eén workshopsessie kan al voldoende zijn om de zaken die echt belangrijk zijn boven tafel te krijgen. Het resultaat kan in verhalende vorm in een paar pagina’s worden worden vastgelegd, waardoor deze eenvoudig naar een brede groep kan worden gecommuniceerd. De resulterende principes horen bij specifieke architecturen; enterprise-architecturen, domeinarchitecturen en solution-architecturen. Deze specifieke architecturen en principes kunnen overigens wel prima gebruik maken van kennis die is vastgelegd in referentie-architecturen.
Kennis delen en afspraken maken vormen dus de essentie van het werk van de architect. Door niet direct met afspraken te beginnen, maar met het delen van kennis zorgt een architect er voor dat iedereen hetzelfde kennisniveau heeft waardoor veel van de keuzes al in de juiste banen worden geleid. Daarnaast ontstaat een veel positiever beeld over de rol van de architect, die geen blokkades opwerpt maar juist blokkades wegneemt.
In de praktijk zullen we vaak eerst afspraken moeten maken over het delen van kennis. Nog steeds zijn veel “experts” niet happig op het weggeven van informatie, uit angst dat dit ten koste gaat van hun status of positie en mogelijk zelfs van hun baan. Hierbij zijn hoog-over twee situaties te onderscheiden: de interne expert en de externe dienstverlener die (delen van) het IT-beheer doet.
De interne expert is “onmisbaar”. Hij ontleent zijn status en positie aan die onmisbaarheid en is om die reden niet geneigd zijn kennis te delen. Hij is dan ook erg druk, heeft nergens tijd voor, bekritiseert de organisatie op slecht management (waardoor hij het zo druk heeft…) en wuift tegelijkertijd alle verantwoordelijkheid voor het initiëren van – of bijdragen aan verbetering weg.
De externe dienstverlener doet er alles aan zo min mogelijk transparant te zijn, al prediken ze vaak het tegenovergestelde. Kleine lettertjes bij uitgeklede basisovereenkomsten zorgen voor onduidelijke kostenplaatjes, gammele callafhandelingsroutines en vaak uit de hand lopende projecten. De externe partij wijst graag naar de opdrachtgever als er iets fout is gegaan (wat wil je nu eigenlijk?) en ze hebben vaak nog gelijk ook: IT is niet in control, wordt onvoldoende aangestuurd door functioneel Beheer en die doen weer te weinig om de klantvraag goed in beeld te brengen.
ik chargeer wellicht, maar het maakt het wat duidelijker.
Dus dat moet anders. En dat een architect hierin een belangrijke rol kan spelen ben ik met je eens. Maar voordat hij gebruik kan maken van “gedeelde kennis” om een betere architectuur te ontwikkelen, moet je dus eerst organiseren (en managen) dat die kennisdeling op gang komt. Pas als je organisatie staat en afspraken (beter) kunnen worden nagekomen, kun je blijvend werken aan verbetering, op alle fronten en op basis van gedeelde kennis.
Beste Hans,
Ik ben het helemaal met je eens. Dit soort aspecten zijn randvoorwaardelijk om kennisdeling te laten werken. Hier heeft management een duidelijke verantwoordelijkheid in het maken van afspraken omdat dit vooral over belangen gaat.
Mvgr,
Danny
@ Danny
Mooi dat je nu ook de kennislijn volgt. Maakt e.e.a. inderdaad veel makkelijker, en duidelijker.
Waar ik wel vraagtekens bij zet is je idee dat het vakgebied van architect zo groot zou zijn. Als je naar de huidige raamwerken kijkt zie je dat er veel teveel onder de titel architectuur wordt gevat. Dat zorgt er ook voor dat er misschien wel 100 verschillende titels gebruikt worden, waarbij de meeste andere namen zijn voor beroepen die we al kennen.
Als je van de originele idee uitgaat dat een architect iemand is met inzicht en overzicht blijven maar een paar soorten over. Daarvan zijn maar een paar IT architect, die vrijwel allemaal aan vooral tactische zaken werken. Zoals de inzet en de exploitatie van IT als manier van oplossen van informatie problemen.
Je geeft aan dat de algemene doelstelling van architectuur “het sturen van veranderingen in de inrichting van organisatie, processen en systemen is” zou zijn. In deze definitie zitten een aantal stevige problemen die ook steeds weer in de praktijk van architectuur voorkomen.
Ten eerste dat blijven veranderen. Dit is een denkfout die, zover ik kan zien, ontstaan is uit de (commerciële) IT-wereld waar geld verdiend wordt aan dat veranderen. We zijn al jaren zover dat we (vele) informatievoorzieningen hebben. Die zullen beheerd moeten worden. En, indien nodig, kunnen ze veranderd worden. Maar vanuit de behoefte en het gebruik van informatie. Daar ligt de behoefte om te veranderen. Verandering is daarom niet de kern, maar een afgeleide. Dit is trouwens ook een van de hoofdredenen waarom zoveel IT-projecten fout gaan.
IT-Architectuur, Enterprise Architectuur of alle namen die er nog meer voor zijn hebben in de kern IT. Met die basis kan je bijvoorbeeld zien dat organisaties moeten worden veranderd, bijvoorbeeld door bedrijfsprocessen aan te passen. Dit veranderen kan echter niet de verantwoording zijn voor deze soort architecten. Ik zie in de praktijk natuurlijk ook dat de mensen die hier wel verantwoordelijk zouden moeten zijn om welke reden dan ook hun taak niet pakken. Maar dat kan niet betekenen dat IT-ers die taak dan maar voor deze mensen invullen. Hoe belangrijk de inbreng van een IT-specialist in bepaalde situaties ook kan zijn, de verantwoording ligt bij de mensen die er echt verantwoordelijk voor zijn.
Natuurlijk kan het beïnvloeden van keuzes door specialisten van belang zijn. Maar IT is maar een soort specialisme, en er zijn een hele lijst andere specialisten die ook invloed zullen (moeten) hebben. Daarom heeft IT ook vooral op tactisch en operationeel niveau invloed, en wordt de invloed daarboven, terecht, minimaal gefilterd. De productiefactor is immers informatie, niet IT. Degene die dan ook de informatiepositie van een organisatie beheert, en veel CIO´s doen dat echt niet, hoort de koppeling strategisch/tactisch te leggen. En dus strategische invloed te hebben. Dit past ook bij de situatie dat organisatie informatie nodig hebben, en dat de vraag naar IT daarvan afhankelijk is. Vraag naar informatie, en aanbod van IT-oplossingen. Die oplossingen worden gecreëerd door de veranderingen in IT die jij in de kern van je doelstelling van (IT/Enterprise) architectuur zet.
De meeste van de huidige architecten in en rond de IT zijn bezig met de inzet en het beheer van IT. Het zijn dan ook architecten die voor IT-organisaties werken. Deze IT-organisaties zijn in feite de aannemers in de IT-wereld. Als je naar architecten kijkt die de vraag naar informatie in de kern van zijn of haar functioneren heeft kijkt, en daar zijn er ook een paar van, zie je dat die juist niet voor IT-organisaties werken, maar juist vanuit de kennis van de informatie van de organisatie. En die maken inderdaad op die basis afspraken. Of zij voeren gestandaardiseerde afspraken in, inclusief normen en standaarden. Je kunt dat een referentie architectuur noemen, la past die term niet goed. Zo´n referentie architectuur is dan geen werk van de (IT/Enterprise) architect, maar van die informatie specialisten.
Natuurlijk kunnen IT-specialisten informatie specialist worden. Alleen betekent dat, dat zij een ander beroep moeten aanleren en dat is niet zo makkelijk.
Steven van ´t Veld
Hoi Danny,
Leuk artikel, maar zit niet zover af van wat ik ook wel eens zeg: ik maak plaatjes, schrijf, lees, presenteer. Allemaal dingen die ik na de lagere school al kon, maar wat heb ik dan bijgeleerd..?
Het lijkt alsof de architect opschrijft wat er is, nou zo ervaar ik niet. In de eerste fase is het dan misschien vooral scherp krijgen wat de stakeholders willen of wat goed voor ze zou zijn, in een tweede fase is het ook op basis daarvan vorm geven aan een inrichting en kijken waar de tegenstrijdige wensen zitten. Daar moet je dan weer op doorvragen: waar gaat het nu echt om? En de partijen bij elkaar brengen om te onderhandelen over een aspect/onderdeel. Dat levert in mijn beleving nieuwe kennis: een nieuw gezamenlijk beeld van een stukje toekomst. Als je dat opschrijft dan is dat gestolde kennis, ja. Maar als architect heb je daar wel en sturende, creatieve, slimme en empathische rol. In die tweede fase kan trouwens ook steeds scherper worden wat de stakeholders willen. Soms is dat alleen maar meer inzicht bij jou, soms is dat ook een inzicht dat jij als architect mee helpt creëren. Dus je creëert ook kennis.