De IT-architect die niet wiebelt

Waarom lukt het ons niet?

Waar voorheen we elkaar nauwelijks uit lieten praten, vielen nu lange stiltes. We hadden de opdracht gekregen van het management om ons werk te evalueren. Een jaar geleden waren we begonnen met het inrichten van IT-architectuur in een organisatie met een IT-afdeling met ontwerpers, testers, ontwikkelaars en infra-specialisten. Gewapend met mijn kennis uit het boek ‘DYA - dynamische architectuur - stap voor stap naar professionele enterprise-architectuur’ en het geleerde in de cursus ‘IT-architectuur in de praktijk’ was ik met ons team zeer enthousiast begonnen aan het opstellen en uitvoeren van ons 100-dagen-plan. Het begon met een sessie met het management. Die waren makkelijk te overtuigen van het nut van IT-architectuur. Logisch natuurlijk, ze hadden ons immers net de opdracht gegeven. De project managers lieten zich iets minder makkelijk overtuigen. Maar in ze gaven aan dat ze voornamelijk stuurden op tijd en geld. Sturen op kwaliteit misten zij, en ze waren bereid dat te gaan doen; voor de start van het project zou nu ook een project start architectuur (PSA) worden opgeleverd. Maar vaak kon de klant niet wachten en dus kwam het opstellen van de PSA dus nu even niet uit. En wanneer er dan in de PSA duidelijk was dat de interface beschreven zou worden op basis van het target data model en vervolgens een vertaling zou plaatsvinden, betekende dat niet altijd dat de ontwerper dat ook zo zou uitwerken in zijn ontwerp. Zo gaf een ontwerper mij ooit het antwoord, ‘ja, dat is een mooie oplossing die is beschreven in de PSA, maar ik wist niet dat ik dat ook echt moest toepassen’. We werkten hard, we hadden samen veel kennis. Veel kennis van het IT-landschap en veel kennis van de technologieën. In de avonduren bestuurde ik patterns en de verschillende methoden van de IT-architect. Maar waarom werkte dit dan niet?

Probleem

Wanneer we denken aan wat een goede architect moet weten en kunnen, denken we in eerste instantie dat hij of zij de methoden moet kennen en een overzicht moet hebben van de beschikbare technologieën en patterns en deze goed weet toe te passen. Ook al zijn de ideeën en oplossingen van de IT-architect nog zo goed, wanneer hij of zij de stakeholders niet weet te overtuigen, dan is het harde werken vrijwel voor niets, krijgt IT-architectuur een slechte naam en gaat het management twijfelen of er nog schaarse resources besteed moeten worden aan architectuur. De architect zit op een kruk met slechts één poot. Mocht hij of zij zitten op een kruk met twee poten, dan nog zou de kruk omvallen.

Oplossing

Als IT-architect zorg je ervoor dat de mensen om je heen op je kunnen rekenen. Je zult de technologieën en patterns moeten kennen zodat je de juiste besluiten kunt nemen voor de organisatie waarvoor je werkt. Daarnaast zul je de mensen om je heen en met name de persoon die besluit over de inzet van mensen en budgetten, moeten kunnen overtuigen. Wanneer dat gelukt is, ben je er nog niet, je zult de teams die de oplossingen realiseren, moeten motiveren, ondersteunen en af en toe moeten corrigeren. Kortom je moet technisch leiderschap tonen.

Bronnen:

• The Software Architect Elevator, 2020, Gregor Hohpe.

• https://www.linkedin.com/pulse/maximizing-value-it-architecture-hans-blok/