Ik heb behoorlijk moeten lachen, dat dan weer wel. Er blijken op de Europese markt voor freelance ict-architecten namelijk soms wel heel bijzondere types actief te zijn. Ze zullen ongetwijfeld allemaal hun kwaliteiten hebben, maar wat ik tijdens mijn zoektocht zoal voorbij heb zien komen, viel te karakteriseren als persiflages op Austin Powers, de Nutty Professor of zelfs kapitein Haddock. Als ik niet beter wist, dan zou ik zomaar spreken met de legendarische woorden van Obelix: 'Rare jongens, die ict-architecten…'.
Waarom was het nou zo lastig om het juiste kaliber mensen te vinden? Voor de duidelijkheid: ik was op zoek naar ict-architecten voor een omvangrijk mondiaal veranderprogramma. Met 'ict' doel ik op de digitale wereld in z'n volle omvang. Wat het in mijn beleving lastig maakte, is dat het in de markt niet helder is aan welke behoefte een ict-architect moet voldoen. Nu is een mooi moment om daar even bij stil te staan.
Laat ik beginnen met het zo praktisch en simpel mogelijk omschrijven van de twee soorten behoefte aan ict-architecten binnen grotere organisaties. Om een organisatie in staat te stellen haar doelen te bereiken is de juiste en doeltreffende inzet van ict veelal onontbeerlijk. Om dat te bereiken is een gedegen langere termijn visie op ict-vlak noodzakelijk. De categorie van architecten die in dit proces een rol speelt zijn de enterprise (ict-)architecten. Over de rol van de enterprise architect een volgend keer meer.
De visie moet vervolgens na een financiële toetsing met zo min mogelijk risico's beheersbaar en gecontroleerd gerealiseerd worden, wat vaak projectmatig gedaan wordt. De categorie-architecten die zich hiermee bezig houdt, wordt vaak getypeerd als projectarchitect of solution architect. Ik zie een dergelijke tweedeling in elk geval terug bij diverse mondiale organisaties die ik de afgelopen jaren op dit vlak heb mogen ondersteunen. Ook een bedrijf als SAP maakt onderscheid tussen enterprise architects en solution architects, zoals bijvoorbeeld duidelijk wordt uit het SAP Enterprise Architecture Framework.
Wat per organisatie en ook per programma of project verschilt is de diepgang van de architectuuruitwerking bij de daadwerkelijke aanvang van een project. Hier komt de projectarchitect of solution architect in beeld, uiteraard afhankelijk van de omvang van het onderhavige project. Bij deze rol ligt de verantwoordelijkheid voor het naar het juiste detailniveau brengen van de oplossingsrichtingen. Richtlijnen voor het bepalen van het juiste detailniveau kun je bijvoorbeeld vinden in het e-book ArchitectedERP.
Het aantal invalshoeken van waaruit projectarchitecten naar de oplossingsrichtingen moeten (laten) kijken, is legio: denk aan beveiliging, duurzaamheid, gebruikersbeleving, de functionaliteit, herbruikbaarheid, de benodigde omgevingen voor het ontwerpen, bouwen, testen, laten draaien en beheren van de nieuwe oplossing en uiteraard tot slot de fysieke infrastructuur. De projectarchitect bewaakt en jaagt na dat de inhoudelijke besluiten over de belangrijkste onderdelen van de oplossing genomen kunnen worden door de belanghebbenden.
Het moge duidelijk zijn dat voor dergelijke rollen een behoorlijke dosis kennis en ervaring vereist is, om over competenties nog maar niet te spreken. Gelukkig zijn ze echt te vinden. Nu ik de juiste inhoudelijke stuurlui aan boord heb, blijken ze allesbehalve rare jongens, die ict-architecten!
Je kan dan wel op ICT architecten rarae snuiters vinden, maar je moet ook de andere zijde eens bekijken.
Als je als ICT architect een oplossing moet vinden voor het ondersteunen van een bedrijfsproces loop je nog voordat je aan een werkelijke oplossing kan beginnen aan tegen wat natuurlijke hindernissen. Om te beginnen zal het management een hel ander kijk hebben op de materie als de direct uitvoernde laag hieronder, over het algemeen is het management op kosten gefocuseerd en de uitvoerende op functionaliteit. Voeg hierbij de vaak gekleurde adviezen van software en hardware leveranciers, deze willen beide hun product slijten en hebben weinig boodschap aan prijs performance en uitvoerbaarheid en beheersbaarheid.
Belangrijk is een overeenstemming bij de uiteindelijke klant te zien te realiseren en vervolgens dit vertalen naar beschikbare infrastructuren, methoden en proces ondersteuning nog voordat je begint te denken aan hardware en software.
Het uitgangspunt ik wil deze hardware en deze software en “oh ja” het moet mijn bedrijfsproces volledig ondersteunen en dit voor de laagste prijs, is het uitgangspunt om aan een mislukking te beginnen, waarbij alle betrokkenen al halverwege het project elkaar de “de zwarte piet” toeschuiven, terwijl het het uitgangspunt al fout was.
En ja ik was een ICT architect, die kortgeleden opgehouden is met werken en dit meerdere malen meegemaakt heeft.
Ik verdien mijn brood in de markt als ICT architect. Voor een groot deel van het verhaal voel ik mij verwant aan de schrijver. Wat mij betreft mag hij in dit artikel nog wel wat verder gaan. Als wij kijken naar de functie van een architect in de bouw, dan kennen we geen enterprise architect en een solution architect. De tweede zou gewoon designer moeten heten. De architect in de bouw is een onafhankelijk persoon die op basis van de wensen van de klant een oplossing definieert met een plan en een kostencalculatie. Ofwel de klant stelt een pakket van eisen op en de architect ontwerpt het IT bouwwerk, definieert bestek, tijdsplan en budget. De klant kan zijn limieten stellen, wijzigingen aanbrengen etc. De architect zal daarop een bijstelling maken en een nieuw voorstel doen. Na goedkeuring wordt een aannemer geselecteerd, die het geheel zal realiseren conform de afspraken. Deze vorm van ICT ontwikkeling en implementatie kom ik zelden tegen. De architect is vaak al onderdeel van of werkzaam bij de aanbieder, die eigenlijk veel te vroeg in het traject is verschenen. In de huidige ICT wereld dient men daarom erg argwanend te zijn t.o.v de ICT architect. Niet vanwege zijn kennis van ICT solutions, maar vanwege de rol die hem toebedacht wordt. Het wordt tijd dat opdrachtgevers met de echte architect eerst hun “ICT huis” bedenken en definieren voordat de leverancier met zijn solution architects wordt uitgenodigd. Dan zal het aantal project mislukkingen waarbij ondermeer SAP vaak ten onrechte, in een kwaad daglicht wordt geplaatst, snel teruglopen.