Technisch onderhoud hoort zijn rechtmatige plek op de backlog te krijgen én te houden. Daarom moeten al je techneuten minimaal eens in de maand bij elkaar komen om het daarover te hebben. We noemen dat een architectuurmeeting. Met hun input plant de product owner technisch onderhoud in. Zo blijft je IT-landschap flexibel en stabiel.
Zodra je digitale product live is, heeft het onderhoud nodig. Doorontwikkelen en nieuwe functies toevoegen is geweldig. Maar let op; het kost steeds meer tijd als je het verbeteren van de onderliggende techniek en de ontwikkelomgeving te lang laat liggen. Ook de stabiliteit van je product kan uiteindelijk in gevaar komen.
Het is belangrijk dat je developers regelmatig de gelegenheid krijgen om goed naar die stabiliteit te kijken. Minimaal één keer in de maand. Zo’n bijeenkomst noemen we de ‘architectuurmeeting’.
Wat we bedoelen met ‘architectuur’
Maar, laten we één stapje terug doen. Want wat bedoelen we eigenlijk met ‘architectuur’? Grof gezegd is je ‘architectuur’ alles wat bepaalt hoe je IT-landschap in elkaar zit. Maar ook hoe alle onderdelen van dat landschap samenwerken. In een goede architectuur praat alles efficiënt met elkaar. Niet alleen je eigen systemen, maar ook externe diensten. Denk daarbij aan;
- kassasystemen,
- een ERP-systeem van een SaaS-aanbieder,
- je Warehouse Management System,
- kiosk-zuilen in winkels,
- openbare beeldschermen,
- labelprinters,
- je koppeling met de post,
- etc.
Je architectuur kan dus vrij snel ingewikkeld worden. Hoe beter je deze complexiteit onder controle houdt, hoe makkelijker je alles kunt onderhouden. En hoe minder moeite het kost om individuele systemen te vervangen, te upgraden of aan te passen. Daarom is het belangrijk om kritisch naar je architectuur te blijven kijken.
Het doel van een architectuurmeeting
Een architectuurmeeting is geen management- of planningsmeeting. In een architectuurmeeting kijken we niet naar de roadmap, de functionele backlog of de wensen van de business. Het doel van een architectuurmeeting is juist om, met techneuten onder elkaar, uit te vinden wat er moet gebeuren om het technische landschap stabiel en onderhoudbaar te houden.
De architectuurmeeting is voor developers een moment om uit de waan van de dag te zijn. Waar ze vanuit een technisch perspectief naar de stabiliteit van het landschap te kijken. Waar zit technical debt en hoe kunnen we die wegwerken? Hebben we in het verleden onder tijdsdruk beslissingen genomen die ons later kunnen gaan hinderen? Is er code die we moeten herschrijven om mee te kunnen met nieuwe inzichten en methoden? Kunnen we systemen ontkoppelen om in de toekomst sneller en flexibeler te kunnen ontwikkelen?
De output van een architectuurmeeting
De output van een architectuurmeeting is meestal een lange lijst van verbeterpunten. Het developmentteam voorziet die van een prioriteitsscore. Die lijst gaat naar de Product Owner. Die PO heeft dan de taak om het onderhoudswerk op een goede manier in de backlog op te nemen.
In ieder project is er onderhoudsbudget om de verbeterpunten op te pakken. Maar soms is dat niet nodig. Soms kan onderhoudswerk ook worden gecombineerd met ontwikkelwerk dat er toch al aan zat te komen. Het ontwikkelen van een nieuwe functie gaat namelijk sneller als je eerst wat oude rommel opruimt. Het kan ook zijn dat de Product Owner inmiddels weet dat bepaalde systemen of componenten binnenkort vervangen gaan worden. Dan heeft het natuurlijk geen zin om er nog onderhoud aan te doen. De uitwisseling van informatie tussen de Product Owner en het developmentteam is één van de vele positieve effecten van een architectuurmeeting. Je wilt een PO die weet waar de technical debt zit. Alleen dan kan hij veel beter inschatten hoeveel tijd aanpassingen kosten en dus de business goed informeren.
Wat is de waarde van een architectuurmeeting?
Laat ik maar even duidelijk zijn: een architectuurmeeting is extreem belangrijk maar levert geen directe businesswaarde. Het hele idee is juist om het even niet over businesswaarde te hebben. Maar om te werken aan de basis waar de businesswaarde op rust. Maar het onderhoudswerk dat voortkomt uit zo’n architectuurmeeting draagt wél bij aan de waarde van het digitaal landschap.
Een paar voorbeelden:
- Vaak gaat het in de architectuurmeeting over monitoring. Door het toevoegen van monitoring in het landschap, zien wij als developers beter wat er gebeurt. Zo kunnen we problemen sneller vinden en tegengaan. Resultaat: minder storingen, betere performance en uiteindelijk dus ook meer omzet.
- Trendspotting staat ook op de agenda. Bijvoorbeeld dat we weten dat het aantal orders binnenkort sterk gaat groeien. En dat we daarbij ook weten dat een koppeling met het ordersysteem regelmatig hapert. Dan zetten we zo’n issue hoog op de prioriteitenlijst.
- Een ander punt dat vaak langskomt is het toevoegen van tests of het verbeteren van bestaande tests. Door testen te automatiseren kunnen we met minder werk een hogere softwarekwaliteit garanderen. Ook dat leidt weer tot blijere gebruikers en meer business.
- Het verbeteren van de ontwikkelomgeving. Af en toe kritisch naar de ontwikkelomgeving kijken. Het zorgt er voor dat we ook in de toekomst snel, goed en flexibel kunnen blijven werken.
- Datastromen filteren zorgt dat we data alleen verzenden waar ze echt nodig zijn. Dit verbetert performance, privacy en veiligheid.
- Updates zijn belangrijk voor veiligheid, stabiliteit en uitbreidbaarheid. Maar ze kunnen ook een bron van stress zijn. In de architectuurmeeting kijken we welke systemen er geüpdatet moeten worden en maken daar een plan voor. Hoe beter je je updates plant, hoe minder impact ze hebben op je operatie.
- Moderne manieren van werken invoeren. Technieken als test-driven development (TDD) en domain-driven design (DDD) kunnen je op de lange termijn veel voordeel opleveren. Maar op de korte termijn vragen ze een investering in het aanpassen van je processen en toolset.
- Beter API-management en ontkoppelen van je landschap. Een ‘ontkoppeld’ landschap, waarin systemen onafhankelijk van elkaar opereren en via API’s communiceren levert je flexibiliteit, schaalbaarheid en overzicht op. In de architectuurmeeting denken we altijd na over hoe we binnen de architectuur systemen minder afhankelijk van elkaar kunnen maken.
Het belang van een ontkoppeld landschap
Dat laatste punt verdient wat extra toelichting. Wij streven altijd naar een landschap dat zo ‘ontkoppeld’ mogelijk is. Dat wil zeggen dat iedere component van het systeem:
- Een duidelijke verantwoordelijkheid heeft. Dus het e-mailsysteem verstuurt e-mails en heeft daarvoor klantgegevens nodig, maar het beheer van die gegevens hoort in het CRM.
- Makkelijk vervangen kan worden. Dat betekent ook dat we heel veel functionaliteit extern kunnen inkopen en integreren, zodat we hem niet zelf hoeven te bouwen.
- Communiceert met andere systemen via een standaardprotocol. Door strak te definiëren hoe we data tussen systemen verzenden en welke data dat moeten zijn (bekend als ‘API-management’, hebben we altijd overzicht over het landschap en de afhankelijkheden erin.
Soms kost het bouwen van nieuwe functionaliteit door deze eisen meer tijd. Want we nemen niet de snelste weg van A naar B. We doen wat extra dingen. Juist om te zorgen dat het landschap na de aanpassing nog net zo flexibel, schaalbaar en onderhoudbaar is als ervoor. Althans, zo gaat het in een perfecte wereld. In de praktijk komt het voor dat tijdsdruk of andere randvoorwaarden ons dwingen om niet-optimale keuzes te maken. En soms zien we gewoon iets over het hoofd. Want we zijn dan misschien ervaren developers, we zijn ook allemaal mensen. In die situaties moeten we achteraf terug de code in en een aantal zaken verbeteren, zodat ze later geen hindernis vormen.
Architectuurmeetings in grote organisaties
Meestal is het hele ontwikkelteam bij de architectuurmeeting. Maar in een grote organisatie met meerdere ontwikkelteams is dat niet altijd praktisch. Dan is het vaak handiger om ieder team te laten vertegenwoordigen door een senior developer of een architect. Wij vinden het belangrijk om ook externe development- en infrastructuurpartners bij de architectuurmeeting te betrekken. Zij hebben veel kennis en kennen ook de architecturen van andere bedrijven. Bovendien brengen zij meestal een kritische buitenstaandersblik mee.
Wil je meer leren over ontkoppelde architectuur en het belang van API’s? Kijk dan deze aflevering van Enrise Business Talks, waarin Steven uitlegt hoe het werkt.
Download ook ons Handboek API-management om meer te lezen over onderhoudbare en uitbreidbare architecturen.
