Spaghetti-architectuur

Als je dit samenvat in een diagram met alle relaties, zie je in dat plaatje wat de afhankelijkheden zijn. Zonder een dergelijke virtuele foto van de globale architectuur worden troubleshooting evenals onderhoud en vernieuwen een drama. Ik heb wekelijks architectuurgerelateerde vraagstukken.

Zo hadden we laatst bij een bedrijf performanceproblemen met een database, en klagende gebruikers. Na analyse bleek dat de oorzaak lag bij een uitgevallen teamingnetwerkinterface in een van de servers. De vraag is natuurlijk: waarom is de database zo afhankelijk van deze netwerkkaart? Ondersteunt de database zelf geen redundantie? Worden er niet te veel data op verkeerde manier in query's opgehaald? Is deze database op dit moment wellicht beter af met een SAN?

Complexe en niet of slecht gedocumenteerde architecturen zorgen voor vervelende storingen

Zo levert een storing binnen de architectuur nieuwe architectuurvraagstukken op. Een ander voorbeeld. Een partner van een bank heeft bij twee financiële medewerkers een Windowsapp geïnstalleerd, die een bedrijfseigen databasebestand gebruiken, gedeeld op een fileserver tussen beide werknemers. De financiële afdeling verzorgt hiermee factoring bij een bank, waarbij de facturen dagelijks automatisch worden geüpload. De databaseapp haalt de facturen van die dag op die vanuit het CRM-systeem ’s nachts worden geëxporteerd en verplaatst ze via een ingebouwd SFTP-protocol naar de bank. Op enig moment ontvangt de bank geen facturen meer. Omdat beide werknemers thuiswerkten vanwege corona, stonden de werkplek-pc’s uit. Maar de upload draait op de werkplek. Het is een verkeerde architectuur als je bedrijfsprocessen laat afhangen van het al dan niet ingeschakeld zijn van een werkplek en bovendien bedrijfsprocessen de firewall en bedrijfspolicy laat omzeilen.

Complexe en niet of slecht gedocumenteerde architecturen zorgen voor vervelende storingen. Eigenlijk zijn wij zelf schuldig. Wij maken er als IT-bedrijven een spaghetti-architectuur van. Componenten zijn te pas en te onpas aan elkaar geplakt, we bouwen voort op legacy oplossingen en consolideren te weinig, wellicht door tijdgebrek. Je trekt voor aan een touwtje, en achter kiept iets om.