Technologische dierentuin in projecten: wat het is, oorzaken en methoden

Wat is een technologische dierentuin in een project

Technologische dierentuin — een situatie waarin in één project of bedrijf een overmatig aantal diverse tools wordt gebruikt die dezelfde taak oplossen. Bijvoorbeeld drie verschillende HTTP-cliënten (Alamofire, OkHttp, Ktor), twee staatsmanagers (Redux, MobX) en drie databases (Realm, CoreData, SQLite).

Het verschil tussen een dierentuin en een bewuste keuze van verschillende tools voor verschillende taken is het ontbreken van een strategie. Als team A React Native kiest, team B — Flutter, en team C — Kotlin Multiplatform zonder gezamenlijk besluit — is dit een dierentuin. Diversiteit op zich is niet schadelijk, schadelijk is het gebrek aan controle.

Elke nieuwe stack in het project verhoogt de cognitieve belasting van ontwikkelaars. Om efficiënt te werken, moeten ze de nuances van alle gebruikte technologieën onthouden. Volgens Google (2024) vermindert contextwisseling tussen verschillende stacks de productiviteit van een ontwikkelaar met 23% in vergelijking met werken in een uniforme technologische omgeving.

Oorzaken van het ontstaan van een technologische dierentuin

Gedecentraliseerde beslissingen — de belangrijkste oorzaak. Elk team kiest technologieën voor zijn eigen project zonder rekening te houden met de algemene strategie. Het backendteam gebruikt Kotlin, het ML-team — Python, het mobiele team — Flutter. Afzonderlijk zijn de beslissingen juist, maar samen creëren ze een dierentuin.

Fusies en overnames — wanneer een bedrijf een ander overneemt, worden technologische stacks samengevoegd. Twee systemen lossen dezelfde taken op verschillende manieren op. Voorbeeld: na de overname van een startup krijgt het grote bedrijf zijn stack op Ruby on Rails, terwijl de interne standaard Java Spring is. De vraag rijst: herschrijven of twee stacks parallel onderhouden.

Verandering van modetrends — elke hype-cyclus voegt een nieuwe stack toe. In 2015 schreef iedereen in AngularJS, in 2017 — in React, in 2020 — in Svelte. Zonder discipline verzamelt het project lagen uit verschillende tijdperken. Legacy-modules die werken maar niet worden onderhouden, voegen diversiteit toe zonder de mogelijkheid om deze snel te elimineren.

Waarom de dierentuin gevaarlijk is voor team en bedrijf

Onboarding van nieuwe ontwikkelaars verandert in het leren van 5+ verschillende technologieën in plaats van één. In plaats van een week om vertrouwd te raken met het project, besteedt een beginner een maand om alle gebruikte tools onder de knie te krijgen. Tijd om productiviteit te bereiken neemt evenredig toe met het aantal stacks in het project.

Contextwisseling — een ontwikkelaar die met 3+ stacks per dag werkt, verliest tot 30% van de tijd aan het herstellen van de context na elke wisseling. Volgens University of California (2023) zijn er na elke wisseling 23 minuten nodig om terug te keren naar het oorspronkelijke productiviteitsniveau. Bij 5 wisselingen per dag — bijna 2 uur verloren.

Beveiligingsrisico’s — elke stack vereist updates, monitoring van kwetsbaarheden en kennis van best practices. Een team kan niet tegelijkertijd expert zijn in alle technologieën. Afhankelijkheidsmoeheid — wanneer het aantal gebruikte bibliotheken het vermogen van het team om ze te volgen en bij te werken overtreft — is een directe bedreiging voor de productbeveiliging.

Complexiteit van infrastructuur — CI/CD moet voor elke stack worden geconfigureerd. Verschillende buildsysteem (Gradle, CocoaPods, npm, pip), verschillende omgevingsvereisten. Het infrastructuurteam besteedt middelen aan het onderhouden van diverse pipelines in plaats van ze te verbeteren.

Hoe diagnoseer je het probleem in een project

Stackinventarisatie — stel een volledige lijst op van gebruikte technologieën: talen, frameworks, databases, CI/CD, monitorsystemen. Markeer voor elke technologie het aantal projecten/modules, het ondersteuningsniveau en het aantal ontwikkelaars dat deze op professioneel niveau beheerst.

Technology Radar — een methode van ThoughtWorks die technologieën in 4 kwadranten verdeelt: Adopt, Trial, Assess, Hold. Adopt — aanbevolen stacks, Trial — experimenteel, Assess — in evaluatie, Hold — niet aanbevolen voor gebruik. Voorbeeld: Flutter in Adopt, React Native in Hold — teams weten wat ze moeten kiezen.

Metrica van onderhoudskosten — schat hoeveel engineeringsuren per maand worden besteed aan het onderhouden van elke stack. Als een stack 10% van de middelen verbruikt maar in 2% van de modules wordt gebruikt — is het een kandidaat voor vervanging. Hittekaart van de stack: assen ‘aantal projecten’ vs ‘onderhoudscomplexiteit’ toont probleemgebieden.

Methoden voor standaardisatie van de technologische stack

Architecture Decision Records (ADR) — documenteren van architectuurbeslissingen met motivatie voor de technologiekeuze. Elke ADR bevat context, overwogen alternatieven en argumenten voor de keuze. Michael Nygard (2022) heeft deze aanpak gepopulariseerd en vandaag is ADR een standaard voor teams die technologische diversiteit controleren.

Technologiebeoordelingscommissie — een commissie van senior ontwikkelaars die nieuwe technologieën in het project goedkeurt. Beslissingen worden genomen op basis van criteria: compatibiliteit met bestaande stack, community-ondersteuning, migratiekosten, beschikbaarheid van talent. Spotify gebruikt sinds 2018 een vergelijkbare commissie.

Poort voor nieuwe projecten — regel: elke nieuwe service of module gebruikt alleen de goedgekeurde stack. Uitzonderingen zijn mogelijk via ADR met motivatie. Voorbeeld: een nieuwe microservice mag alleen in Kotlin worden geschreven als het team bewijst dat Java niet geschikt is voor deze taak. Het gebruik van willekeurige technologieën zonder barrières is verboden.

Stapsgewijze vermindering van stackdiversiteit

Fase 1: Bevriezen — nieuwe projecten op niet-ondersteunde stacks worden gestopt. Voor elke stack in het Hold-kwadrant wordt een end-of-life datum vastgesteld. Nieuwe functionaliteit wordt alleen op goedgekeurde stacks geschreven. Legacy-modules blijven werken maar worden niet verder ontwikkeld.

Fase 2: Consolidatie — voor elke taak wordt één tool gekozen. Één HTTP-cliënt, één staatsmanager, één database. Modules op alternatieve stacks worden gepland voor migratie op prioriteit. Strangler Fig-patroon — de belangrijkste methode voor vervanging zonder het systeem te stoppen.

Fase 3: Migratie — elk sprint besteedt het team 20% van de tijd aan het herschrijven van kritieke modules van verouderde naar goedgekeurde stacks. Doelarchitectuur wordt vastgelegd in een document en wordt niet gewijzigd zonder beslissing van de commissie. Het proces duurt 6 tot 24 maanden, afhankelijk van de omvang van de dierentuin.

Voorbeeld: migratie van HTTP-cliënten

// Voor: 3 verschillende HTTP-cliënten in één project
class HttpClientResolver {
    def resolve(moduleName) {
        switch(moduleName) {
            case "payments": return new OkHttpClient()
            case "chat": return new KtorClient()
            case "analytics": return new RetrofitClient()
        }
    }
}