Rare jongens, die ICT-architecten
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!
10-02 Het einde van het begin van cloud en virtualisatie
10-02 De windwakken van de cloud-sector
09-02 Citoto
09-02 Lang leve de hackers!
09-02 Modder gooien in ICT-land
08-02 Reseller verliest slag om het groene huishouden
08-02 Hadoop lijkt een alleskunner
07-02 Hou zicht op de informatie bij HNW
07-02 Eigen werknemer kan ook een vijand zijn
06-02 Krachtenbundeling NGI en TestNet is goede zaak
05-12 Traxion introduceert IAM4Cloud
02-12 Progress breidt RPM-suite verder uit
26-10 Infor presenteert Twitter-ERP
03-10 Macaw zet nieuw servicecentrum op
22-09 SOA en agile kunnen best door één deur
07-07 Compuware neemt Dynatrace Software over
22-06 IBM Rational levert nieuwe ontwikkelingstools
19-04 ROC Aventus: datakoppelingen en zeggenschap
13-04 HP wilde Tibco Software overnemen
31-03 'Ivent heeft te weinig kennis van SOA'
|
|
01-07-10 IT-architectuurverenigingen delen kennis
De gecombineerde kracht van JD Edwards en Salesforce.com
De integratie van JD Edwards en Salesforce.com drijft organisaties vaak tot wanhoop. Deze whitepaper beschrijft hoe......



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.