Het begint meestal klein.
Een team wil iets aanpassen. Geen herontwerp, geen koerswijziging. Gewoon een extra veld. Een kleine afwijking in een workflow. Iets wat logisch voelt, omdat de praktijk zich nu eenmaal niet netjes aan het oorspronkelijke ontwerp houdt.
En dan blijkt die kleine wijziging ineens niet klein te zijn.
Niet omdat het inhoudelijk ingewikkeld is, maar omdat het platform het niet toelaat. Of alleen via een omweg. Of tegen voorwaarden die niemand vooraf scherp had.
Dat is vaak het eerste moment waarop volledig beheerde SaaS zijn echte karakter laat zien.
Aan de voorkant voelt alles soepel
Volledig beheerde SaaS wordt verkocht als volwassenheid. Minder zorgen. Minder techniek. Meer focus op businesswaarde. Teams hoeven niet meer te bouwen, alleen te configureren. Integraties liggen klaar. Dashboards zien er strak uit. De demo werkt.
In het begin klopt dat beeld ook. De eerste stappen gaan snel. Teams leveren. Iedereen is tevreden.
Totdat er iets verandert.
Niet groots. Niet disruptief. Gewoon een logische vervolgstap. En precies daar begint het te wringen.
Ecosystemen klinken open, maar zijn het zelden
Leveranciers spreken graag over ecosystemen. Over partners, extensies, marktplaatsen. Het klinkt alsof je keuzevrijheid koopt.
Wat je in de praktijk koopt, is een set vooraf gemaakte keuzes. Het datamodel ligt vast. De kernlogica zit diep in het platform. Integraties zijn afgestemd op die logica. Configuratie voelt flexibel, maar beweegt binnen harde grenzen.
Je ontwerpt niet meer echt. Je past aan wat al bedacht is.
Dat voelt efficiënt. Totdat je iets wilt wat net buiten het kader valt.
Waarom dit schuurt in een agile omgeving
Agile werken betekent leren terwijl je beweegt. Teams experimenteren. Ze stellen bij. Ze passen modellen aan op basis van nieuwe inzichten.
Maar in een volledig beheerde SaaS-omgeving zijn die modellen niet van jou. Ze zijn verweven met processen, validaties en integraties die je niet beheert.
Een kleine aanpassing raakt ineens meerdere onderdelen. Rapportages moeten mee. API’s veranderen. Downstream-systemen reageren anders. Wat voor het team voelt als een kleine iteratie, blijkt een ketenbesluit te zijn.
En die beslissing ligt vaak niet bij het team.
Configuratie geeft rust, maar neemt zicht weg
Configuratie lijkt veilig. Geen code. Minder risico. Minder onderhoud.
Maar configuratie verbergt ontwerpkeuzes. Aannames verdwijnen achter vinkjes en dropdowns. Alternatieven zijn niet zichtbaar. Uitzonderingen worden lastig.
Architectuur verdwijnt naar de achtergrond. Tot het moment dat je wilt afwijken. Dan blijkt dat die architectuur er wel degelijk is, alleen niet van jou.
Het moment waarop het echt pijn doet
De echte pijn zit niet in migraties of exits. Die schuiven organisaties graag vooruit.
De pijn zit in die ene wijziging die logisch voelt, maar ineens complex wordt. Een team wil sneller leveren, maar merkt dat het platform de snelheid dicteert. Een proces moet net anders, maar past niet in het standaardpad.
Dan hoor je zinnen die iedereen herkent.
“Dat kan, maar niet standaard.”
“Daar is het platform niet voor bedoeld.”
“Dat vraagt maatwerk.”
Op dat moment wordt duidelijk wie bepaalt hoe wendbaar je bent.
Contractueel is dit allemaal netjes geregeld
In contracten staat vaak keurig dat de leverancier bepaalt hoe het platform zich ontwikkelt. Dat functionaliteit kan wijzigen. Dat extensies niet gegarandeerd zijn.
Juridisch is daar weinig tegenin te brengen.
Maar architectonisch betekent het dat jouw wendbaarheid afhankelijk is van een roadmap waar je geen invloed op hebt. En dat schuurt met het idee van autonome teams.
Agile werken binnen vaste, externe kaders voelt misschien snel, maar het is geen wendbaarheid. Het is bewegen binnen grenzen die je niet zelf beheert.
Waarom dit zo vaak te laat wordt gezien
Omdat de focus bij de start ligt op snelheid en ontzorging. Op kosten. Op implementatie.
De vraag hoe je hier ooit weer uitkomt, wordt vooruitgeschoven. Exit bestaat op papier. In de praktijk is het datamodel leidend. En dat model is van de leverancier.
Zolang alles loopt, voelt dat acceptabel. Tot verandering nodig is. En verandering is precies waar agile om draait.
Wat dit vraagt van architectuur
Dit is geen pleidooi tegen SaaS. Het is een pleidooi tegen blind vertrouwen.
Als architect moet je zichtbaar maken waar keuzes vastliggen. Waar configuratie ontwerp vervangt. Waar teams autonomie verliezen zonder dat ze het doorhebben.
Niet om alles dicht te timmeren, maar om bewust te kiezen. Wendbaarheid ontstaat niet vanzelf uit tooling. Het is het resultaat van ontwerpkeuzes, ook als je kiest voor een platform.
Conclusie
Vendor lock-in is nooit verdwenen. Het heeft alleen een vriendelijkere naam gekregen.
Het heet nu ecosysteem. Of platform. Of managed convenience.
De echte test komt niet bij de start, maar bij de eerste afwijking. De eerste kleine wijziging die ineens groot wordt.
Wie dat moment niet meeneemt in zijn ontwerp, ruilt snelheid in voor afhankelijkheid.
En dat is geen agile compromis. Dat is een architectuurkeuze.