De stille verstikking door ongebreidelde applicatiewildgroei
Applicatiewildgroei ontstaat zelden door één verkeerde beslissing. Meestal is het de optelsom van afdelingen die snel resultaat nodig hebben, medewerkers die zelf digitale hulpmiddelen aanschaffen en centrale IT-teams die onvoldoende ruimte bieden voor experimenten. Een marketingafdeling kiest een eigen klantdataplatform, operations bouwt een no-code workflow en finance houdt vast aan een oud rapportsysteem omdat het nieuwe alternatief niet alle uitzonderingen ondersteunt. Elke keuze kan lokaal rationeel zijn. Op organisatieniveau ontstaat echter een landschap waarin data dubbel wordt vastgelegd, verantwoordelijkheden vervagen en integraties steeds moeilijker te beheren zijn.
De spanning tussen afdelingsautonomie en centrale governance vormt daarmee de kern van het probleem. Een rigide IT-governance die vooral toetst, verbiedt en vertraagt, duwt de business richting schaduw-IT. Een volledig gedecentraliseerde aanpak leidt op haar beurt tot dubbele functionaliteit, uiteenlopende beveiligingsniveaus en onduidelijke eigenaarschap. Traditionele rationalisatieprojecten versterken dit patroon wanneer ze uitsluitend worden gepresenteerd als kostenbesparende sanering. Zodra een applicatie op een lijst met te elimineren systemen staat, verdedigt de verantwoordelijke afdeling vooral haar continuïteit. De discussie gaat dan niet meer over strategische waarde, maar over het voorkomen van verlies.
De verborgen rekening bestaat uit meer dan licenties. Citizen development zonder architectuurkaders kan nieuwe afhankelijkheden creëren, terwijl legacy-platforms kennis en processen vastzetten in verouderde protocollen. Ook ontstaan kosten door handmatige gegevenscorrecties, incidenten, maatwerkintegraties, auditwerk en de tijd die medewerkers verliezen aan het combineren van systemen. Een pragmatische aanpak behandelt rationalisatie daarom niet als een eenmalige opruimactie, maar als een portfolio discipline. Het doel is niet het laagst mogelijke aantal applicaties, maar een landschap dat risico beheerst, innovatie ondersteunt en aantoonbaar bijdraagt aan organisatiewaarde. Een goed ingericht application portfolio management-proces helpt die omslag van technologie naar besluitvorming te maken.
De dynamiek tussen wendbare business en IT-governance
Afdelingen grijpen naar eigen tools wanneer centrale IT niet snel genoeg reageert op een veranderende markt of een concreet operationeel probleem. De aanleiding kan klein zijn: een team wil klantfeedback sneller analyseren, een planner zoekt een betere capaciteitstool of een salesorganisatie wil zonder maandenlange ontwikkelcyclus een campagneproces automatiseren. SaaS-diensten, low-codeplatforms en generatieve AI maken die stap bovendien bijzonder laagdrempelig. De aanschaf of bouw lijkt goedkoop, maar de organisatorische consequenties komen vaak later. Wie beheert de gegevens, wie controleert toegangsrechten en wat gebeurt er wanneer de enthousiaste medewerker vertrekt?
Daarbij is het belangrijk onderscheid te maken tussen technische schuld en architecturale schuld. Technische schuld zit bijvoorbeeld in verouderde code, uitgestelde upgrades, ontbrekende tests of niet-ondersteunde componenten. Architecturale schuld gaat verder. Het betreft ook onduidelijke dataflows, overlappende applicaties, vendor lock-in, versnipperd eigenaarschap en een capability map die niet meer overeenkomt met de werkelijkheid. Zoals beschreven in de analyse over architecturale schuld, kan een organisatie daardoor strategische keuzes baseren op een onjuist beeld van haar eigen mogelijkheden.
Een centrale IT-afdeling kan innovatie onbedoeld afknijpen wanneer ieder initiatief door hetzelfde zware intakeproces moet. De oplossing is geen afschaffing van governance, maar proportionele governance. Kleine experimenten hebben andere eisen dan systemen die financiële transacties, personeelsgegevens of productiebesturing ondersteunen. Gedeeld eigenaarschap brengt die nuance in de praktijk. Iedere bedrijfskritische applicatie krijgt minimaal een business owner die waarde en procesverantwoordelijkheid bewaakt, en een IT-owner die techniek, beveiliging en levenscyclus beheert.
- De business owner bepaalt waarvoor de applicatie nodig is en welke resultaten moeten worden geleverd.
- De IT-owner bewaakt architectuur, integraties, beveiligingsmaatregelen en technische continuïteit.
- De enterprise architect bewaakt samenhang tussen domeinen en maakt afhankelijkheden bestuurbaar.
- Het portfolio-overleg beslist over investeringen, migraties, uitzonderingen en uitfasering.
De reële impact van een versnipperd applicatielandschap
Een versnipperd landschap moet op drie niveaus worden beoordeeld. Operationeel ontstaat fragiliteit doordat processen afhankelijk zijn van handmatige overdrachten, specialistische kennis of koppelingen die niemand nog volledig begrijpt. Financieel lopen niet alleen licentie- en hostingkosten op, maar ook integratie-, beheer- en migratiekosten. Op securityniveau groeit het aanvalsoppervlak door systemen die niet langer worden ondersteund, onvoldoende worden gemonitord of oude authenticatieprotocollen blijven gebruiken.
| Risicodomein | Typische oorzaak | Bestuurlijke consequentie |
|---|---|---|
| Operationeel | Dubbele systemen, kwetsbare koppelingen en persoonsafhankelijke kennis | Meer uitval, langere hersteltijd en lagere voorspelbaarheid |
| Financieel | Overlappende licenties en stijgende integratie- en onderhoudskosten | Minder budget voor vernieuwing en onduidelijke total cost of ownership |
| Security | Legacy, beperkte patchmogelijkheden en verouderde protocollen | Groter incidentrisico, compliance-druk en hogere verzekeringslasten |
| Strategisch | Versnipperde data en onduidelijke capabilities | Tragere besluitvorming en beperkte wendbaarheid bij transformatie |
Legacy vergroot het probleem wanneer systemen verouderde netwerk- of authenticatiepatronen gebruiken. NTLM is daarvan een bekend voorbeeld. Het protocol kan in omgevingen blijven voortbestaan doordat applicaties terugvallen op NTLM wanneer Kerberos verkeerd is geconfigureerd. Daardoor is vervanging niet altijd de eerste of beste stap. Eerst moet zichtbaar worden waar het protocol werkelijk wordt gebruikt, waarom de terugval plaatsvindt en welke systemen of gebruikers ermee verbonden zijn. Segmentatie, strengere toegangscontrole en gefaseerde vervanging beperken het risico terwijl de bedrijfsvoering doorgaat.
De richtlijnen van het NCSC benadrukken dat legacy-risico”s vaak moeten worden gemodificeerd met beschermende maatregelen. Denk aan het verwijderen van directe internettoegang, het scheiden van netwerkzones, gecontroleerde interfaces en monitoring van oost-westverkeer. Dit voorkomt dat een kwetsbaar systeem automatisch een springplank wordt naar andere delen van de organisatie. Rationalisatie vraagt dus om meer dan de vraag welke applicatie weg kan. De kernvraag luidt welke afhankelijkheid veilig kan worden afgebouwd en welke bescherming nodig is zolang dat nog niet kan.
Het pragmatische 5-fasen-raamwerk voor duurzame IT-rationalisatie
Een duurzaam rationalisatieprogramma combineert portfolio-inzicht met risicobeheersing en verandervermogen. Het begint niet met een lijst van systemen die moeten verdwijnen, maar met een betrouwbaar beeld van processen, data, eigenaarschap en afhankelijkheden. Daarbij is volledigheid belangrijk, maar overmatige registratie werkt averechts. Verzamel vooral gegevens die een besluit ondersteunen, zoals gebruik, kosten, kritikaliteit, lifecycle, integraties, risico”s en strategische fit.
- Breng het landschap in kaart. Inventariseer applicaties, platformen, dataflows, interfaces, gebruikersgroepen en bedrijfsprocessen. Laat business units en IT gezamenlijk ontbrekende informatie aanvullen. Een federatieve inventaris voorkomt dat centrale teams aannames maken over lokale systemen. Benoem per applicatie een business owner en IT-owner en gebruik waar mogelijk geautomatiseerde bronnen voor gebruiksdata, kosten en technische lifecycle.
- Beoordeel met TIME. Classificeer iedere applicatie als Tolerate, Invest, Migrate of Eliminate. TIME is geen mechanische scorekaart, maar een gesprek over businesswaarde, technische fit, risico, kosten en toekomstige positionering. Een middelmatig beoordeeld systeem kan tijdelijk worden getolereerd wanneer het een uniek productieproces ondersteunt. Een populaire applicatie kan toch moeten migreren wanneer zij data versnipperd of strategische afhankelijkheid van een leverancier creëert.
- Mitigeer resterende risico”s. Legacy die niet direct kan worden vervangen, krijgt tijdelijke bescherming. Segmenteer netwerkzones, beperk verbindingen tot noodzakelijke systemen, verwijder internetblootstelling en monitor afwijkend verkeer. Leg daarnaast herstelprocedures, leveranciersafspraken en kennisborging vast. Het doel is niet risico ontkennen, maar het expliciet maken, beleggen en beheersbaar houden.
- Migreer gecontroleerd. Ontwerp migraties rond bedrijfsprocessen in plaats van alleen rond technologie. Begin met een beperkte scope, test datakwaliteit en integraties, definieer terugvalscenario”s en plan overgangsmomenten samen met de operationele eigenaar. Parallelle verwerking, gefaseerde gebruikersgroepen en tijdelijke synchronisatie kunnen downtime beperken. Een applicatie is pas werkelijk uitgefaseerd wanneer dataretentie, contracten, autorisaties, rapportages en ondersteuningskennis zijn afgehandeld.
- Maak governance continu. Application Portfolio Management moet aansluiten op budgetcycli, projecten, architectuurprincipes, security en sourcing. Periodieke reviews beoordelen of waarde, risico en lifecycle nog overeenkomen met de actuele strategie. Dashboards tonen niet alleen hoeveel systemen zijn afgestoten, maar ook concentraties van technische schuld, naderende end-of-life-momenten, adoptie, incidenten en vrijgespeelde capaciteit.
De kwaliteit van het raamwerk staat of valt met de manier waarop informatie wordt gebruikt. Een visueel overzicht van applicaties en afhankelijkheden maakt duplicatie en kritieke knooppunten bespreekbaar, maar een diagram is geen eindproduct. De aanpak van applicatielandschappen tekenen is pas waardevol wanneer het model actueel blijft en wordt vertaald naar concrete roadmaps, investeringsbesluiten en operationele maatregelen.
Besluitvorming moet bovendien proportioneel en vergelijkbaar zijn. Een consistente rubricering van kritikaliteit, lifecycle, kosten, compliance en strategische fit voorkomt dat de luidste stakeholder het resultaat bepaalt. Daarmee ontstaat ruimte om investeringen te verschuiven naar systemen die differentiatie ondersteunen, terwijl standaardfunctionaliteit waar mogelijk wordt geconsolideerd. De volgende stap is steeds een expliciet besluit met eigenaar, tijdshorizon, financiering en meetbaar resultaat.
Duurzaam samenwerken zonder de rem op innovatie
Federated governance werkt alleen wanneer eigenaarschap daadwerkelijk wordt erkend. Business units krijgen ruimte om behoeften te formuleren en te experimenteren, terwijl centrale IT kaders biedt voor identiteit, data, integratie, security en continuïteit. Dual ownership voorkomt twee klassieke fouten: een business die een applicatie als eigen privébezit behandelt, en IT die verantwoordelijk wordt gemaakt voor een proces waarvan de waarde en prioriteit niet duidelijk zijn.
No-code en citizen development kunnen binnen zulke kaders juist een krachtig innovatie-instrument zijn. Een organisatie kan bijvoorbeeld veilige bouwblokken, goedgekeurde dataconnectors en standaardrollen beschikbaar stellen. Voor experimenten gelden lichtere eisen; zodra een oplossing bedrijfskritisch wordt, verschuift zij naar een formeel beheermodel met documentatie, logging, back-up, toegangsbeheer en een exitplan.
- Meet doorlooptijd van ideeën naar werkende oplossingen.
- Volg adoptie, gebruikerswaarde en proceskwaliteit naast kosten.
- Registreer uitzonderingen en maak de vervaldatum ervan zichtbaar.
- Rapporteer vermeden risico”s, vereenvoudigde dataflows en vrijgespeelde capaciteit.
De enterprise architect vervult hierin een strategische rol als businesspartner. Niet door ieder lokaal initiatief vooraf te blokkeren, maar door de gevolgen van keuzes zichtbaar te maken in termen van afhankelijkheden, risico”s, toekomstige capabilities en veranderkosten. Architecten moeten daarvoor niet alleen modellen beheren, maar ook besluitvorming beïnvloeden. Heldere scenario”s, dashboards en businesscases maken architecturale schuld bespreekbaar op directieniveau. Zo ontstaat centrale rust zonder lokale slagkracht op te offeren.
Bouw aan een adaptief fundament voor toekomstige groei
IT-rationalisatie levert pas blijvende waarde op wanneer de organisatie overstapt van een eenmalige opruimactie naar continue portfolio-discipline. Het gaat niet om het behalen van een symbolisch reductiepercentage, maar om aantoonbare verbetering van risicobeheersing, datakwaliteit, investeringsruimte en verandervermogen. Sommige applicaties verdwijnen, andere worden gemoderniseerd, beschermd of bewust getolereerd. Het verschil zit in de kwaliteit van het besluit en de discipline waarmee het wordt opgevolgd.
Voor leiders ligt de eerste stap daarom niet bij een nieuwe saneringslijst, maar bij inzicht en federatief eigenaarschap. Breng het landschap bestuurbaar in kaart, benoem verantwoordelijken, pas TIME consequent toe en bescherm legacy totdat vervanging verantwoord kan plaatsvinden. Wie centrale standaarden verbindt met lokale kennis, bouwt een adaptief fundament waarop innovatie schaalbaar blijft. Dat is de balans die applicatiewildgroei temt zonder de organisatie haar wendbaarheid te ontnemen.