Wie krijgt de rol van transformer?
Een nieuw 'huis'
In het jaar voor mijn examenjaar, kochten mijn ouders een oude boerderij. Toch even kijken wat die 'ouwe' heeft gekocht. Ik trof een net-niet-bouwval aan waar we in zouden gaan wonen en een stal met een scheefgezakte muur. In het plafond in de woonkamer zaten groten spleten. Deze verdieping was niet bereikbaar met een trap, maar met een ladder. Buiten liepen kippen, en een oude manke kat. Moest ik hier nog gaan wonen, voordat ik het ouderlijk huis zou verlaten?
Acht maanden later vroeg mijn vader of ik kon komen helpen. Er was aan de eettafel veel gesproken de afgelopen maanden, over de tegenvallers en meevallers die gepaard gingen met de verbouwing. Maar ik moet zeggen, ik was verder niet goed op de hoogte. Toen ik aan kwam, trof ik een totaal ander huis aan. Het was nog niet af, maar hier was iets bijzonders gaande.
Een nieuw thuis
Een maand later verhuisden we. Ik settelde me in mijn kleine slaapkamertje, heel efficient ingedeeld met een mooie inbouwkast, verse gestuukte witte muren en een authentiek raam dat liep van de vloer tot het plafond, naast mijn bureau. Het raam bood een uitzicht verder dan ik kon kijken. Misschien moest ik hier toch nog even blijven wonen. Mijn vader had deze woning niet veranderd maar getransformeerd!
Transformeren of veranderen?
Toen ik in mijn gemeubileerde studentenkamer trok, heb ik enkele nieuwe planten in de vensterbank gezet, de bank verplaatst, en een nieuwe poster opgehangen. Ik had de kamer veranderd.
Veranderen is een taak voor managers en consultants. Transformeren, veranderen hoe een IT-organisatie werkt, is een taak voor een IT-architect.
Waarom de IT-architect?
Transformeren is riskant en uitdagend. Ik heb een tester ooit horen zeggen: ‘Toch niet weer zo een service, hè’. De system engineer begint de gesprekken standaard met ‘wat jullie willen, gaat niet werken’. Van de ontwerpers hoor ik 'Wat we hadden, werkte toch goed. Waarom doen we zo ingewikkeld?' De IT-architect kan denken ‘waarom ik?'. Hulp van een consultant kan zeker bijdragen aan een succesvolle transformatie. Maar blijvende verandering wordt niet vorm gegeven met een slide-deck dat uit de lade komt van een bureau ergens buiten je organisatie. Blijvende verandering begint met modellen waarin stakeholders hun organisatie herkennen, en heldere antwoorden. Antwoorden op vragen van zowel product managers aan de business kant, als de system engineers die mee werken aan de oplossing. Modelleren, stakeholder management, duidelijk maken wat de trade-offs zijn, presenteren en overtuigen. Is het niet de IT-architect die kennis heeft van deze methoden en deze vaardigheden beheerst? Om een transformatie vorm te geven is een goed management voorwaardelijk. Het management moet wel weten wat moet worden veranderd.
Technologische innovatie, agile werken en DevOps
Transformaties worden meer dan vroeger gedreven door technologische innovaties. DevOps verandert de trade-offs. Moeten we nog wel kiezen tussen kwaliteit en snelheid? Agile werken zou autonome teams moeten leveren. Maar hoe autonoom zijn ze als ze vaak afhankelijk zijn van andere teams om werkende software te kunnen releasen? Hoe gaan we onze teams indelen? Het zijn vragen waar een IT-architect vaak het antwoord op heeft^.
Bronnen:
Digital Transformation Course, Arcitura
The Software Architect Elevator, Gregor Hohpe, 2020 (part V, p. 271, part VI p. 327)
