'EU bekijkt of Oracle overstap van klanten naar concurrentie belemmert'

De licentiepraktijken van Oracle zouden klanten verhinderen om over te stappen naar concurrerende leveranciers. Het bedrijf staat volgens bronnen van Reuters op de radar van de antitrustdivisie van de Europese Unie. In juli schikte de Duitse concurrent SAP met de EU over soortgelijke praktijken.

Antitrustmedewerkers van de Europese Commissie zouden nu informatie opvragen bij betrokken partijen, meldt Reuters op basis van ingewijde bronnen. Dat kan de basis vormen voor een formele zaak tegen Oracle. Ook kan de conclusie zijn dat er geen sprake is van misstanden of dat er te weinig bewijs is om een zaak te beginnen.

Oracle reageert tegenover Reuters niet op dit bericht. De Europese Commissie verklaart dat ze mogelijke concurrentieverstorende praktijken en machtsmisbruik in de techsector in de gaten blijft houden. Op dit moment is er geen sprake van een formeel onderzoek naar welk bedrijf dan ook, zegt een EC-woordvoerder tegen het Amerikaanse persbureau.

Makkelijkere overstap voor SAP-klanten

De Duitse Oracle-concurrent SAP bood in juli dit jaar voorzieningen aan waarmee klanten makkelijker kunnen overstappen naar andere leveranciers. Daarnaast moeten klanten hun contracten met het software- en cloudbedrijf makkelijker kunnen opzeggen. De EC accepteerde deze bindende beloftes van het techbedrijf.

SAP wendde daarmee de dreiging af van een Europese antitrustboete, aldus Reuters toen. De EU kan boetes opleggen van maximaal 10 procent van de wereldwijde jaaromzet van een bedrijf.

Oracle AI
Het software- en cloudaanbod van Oracle, met daarin ook AI, is de motor voor veel bedrijven. Bron: Oracle

Door Jasper Bakker

Nieuwsredacteur

02-09-2026 • 10:51

94

Submitter: JelleDJs

Reacties (94)

Sorteer op:

Weergave:

Altijd een beetje jammer dit soort gedrag. Blijkbaar is de kracht van het eigen product niet afdoende om klanten binnen boord te houden omdat ze dat graag willen, maar moeten er obstakels worden opgeworpen. Dat gebeurt natuurlijk op heel veel plekken zo, maar ik vind het wel iets om mismoedig van te worden. Als je nou gewoon betere spullen bouwt tegen een scherpe prijs, lopen je klanten niet weg en hoef je daar ook niet bang voor te zijn.
Bij zulke IT-bedrijven vraag ik me ook serieus af waarom anderen daar überhaupt mee willen werken. Het is als bedrijf zijnde echt wel bekend dat je jezelf helemaal klem zet als je daar aan begint. Maar dat interesseert de bestuurder die er maar een paar jaar zit niet, die wil alleen een project op z'n naam zetten waarmee kosten zijn "bespaard" en door naar het volgende bedrijf. Dat de volgende bestuurder er vervolgens niks meer mee kan, of de kosten de pan uitreizen zie je niet terug.
Inderdaad, dit soort bedrijven had je 20 jaar geleden al de deur moeten wijzen en de expertise zelf intern ontwikkelen en opslaan. Dit gedrag van Oracle is al 30 jaar bekend.

Alles wat niet in de offerte staat komt bovenop de prijs tegen extreme prijzen.
20 jaar geleden: 2006 Iedereen is net een paar jaar over van Windows NT 4.0 naar Windows XP... De IT markt is aan het herstellen van geen-IT-beheerders die per busladingen naar de NT4 examens werden gestuurd (en de antwoorden in het hoofd hadden gestampt) en nu opeens IT beheerder waren. Dit is een voorbeeld van Windowsbeheerders, maar dit was het geval voor een groot deel van de 'ITers' waar een groot te kort van was.

In diezelfde periode waren de meeste grote applicaties alleen maar compatibel met de grote database leveranciers, waaronder Oracle, AS400 en heel, heel af en toe MS SQL... MySQL werd vaak gezien als een hobby project of tenminste alleen geschikt voor bepaalde web applicaties. PostgreSQL was helemaal belabberd, er was waarschijnlijk meer ondersteuning voor MS Access... En als je al Oracle en AS400 draaide, dan pakte je niet snel iets anders erbij. Ik kan me nog herinneren dat we bij TOPdesk 3 de keuze hadden tussen MS SQL en Oracle, MS SQL moesten we zelf gaan beheren (als niet database beheerders) en we hadden een dba voor Oracle... Dan zijn keuzes snel gemaakt...

En als we het in de periode hadden over zelf applicaties ontwikkelen en dan al helemaal intern. Die kennis was in het gros van de organisaties niet intern aanwezig, die moest worden ingehuurd. IT personeel was een noodzakelijk kwaad en niet een geïntegreerd deel van je bedrijfsvoering. Software kocht je in, dat maakte je niet zelf! En als je dan toch iets custom nodig had, dan huurde je een bedrijf in om dat voor je te maken en dat was alles behalve een makkelijke ervaring. Daarnaast was er 0,0 ervaring binnen bedrijven voor het uitbesteden van software development, ownership van code, legal, etc.

Oracle is nooit een fijne partij geweest, een beetje hetzelfde als met VMware. Men heeft veel legacy en overstappen op iets anders kost VEEL tijd, zowel in onderzoek, als daadwerkelijke migratie en nazorg.
Oracle en AS400 in 1 zin is onmogelijk. IBM en Oracle zijn altijd rivalen geweest en AS400 (System i) is een IBM feestje (met DB2 als database).

Het Tweakers artikel blinkt niet uit in nauwkeurigheid. Oracle is een groot bedrijf en heeft naast hardware, database ook andere applicaties. Als je Oracle met SAP vergelijkt, dan zal het wel over ERP gaan.

Oracle heeft altijd een berg juristen in dienst gehad en qua licenties was het altijd al zo duur, dat je weg wilde, maar weggaan nog duurder was (ik beperk met tot de database/RDBMS). Een ander voorbeeld is hoe Java gelicenseerd werd. Maar daar is ook een open source variant van.

Ik kan me niet voorstellen dat met zoveel juristen in huis, de bedrijfsstructuur bij Oracle zo zou zijn dat als 1 onderdeel faalt (bijv AI) de rest ook om zal vallen.
Oracle en AS400 in 1 zin is onmogelijk. IBM en Oracle zijn altijd rivalen geweest en AS400 (System i) is een IBM feestje (met DB2 als database).
Wel hoor: ik heb vroeger Oracle beheerd op AS400, dat zal rond 2001 zijn geweest. Maar nu lijkt het niet meer mogelijk.
Ik heb nog een keer gezocht, maar kan niet vinden dat Oracle RDBMS op AS/400 heeft bestaan. Wel DB2, maar ook dat product week af van DB2 op Windows/Linux/andere UNIX smaken.

Wat wel kan is dat je een beheer cliënt had (Java wellicht) om een Oracle product te beheren. Het enige wat ik kan vinden is Oracle Access Manager voor AS/400. Zelf was mijn AS/400 avontuur beperkt. Blij dat we er op den duur vanaf waren. Het was zo anders (archaïsch) tov UNIX. Als je alle klinkers inslikt dan kom je in de buurt van ern gebruikelijk commando voor AS/400 8)7 .
Ik weet toch erg zeker dat het om de database ging. :D
https://docs.oracle.com/c...ways.102/b16223/intro.htm. Die database stond dan niet op de AS/400 doos, als ik het goed lees. Als waar is een wat je zegt, moet je zo een bron kunnen vinden met meer info. Google AI zegt niet. En een wiki pagina kon ik niet vinden. Wat niet perse een waterdicht bewijs is.

Mijn achtergrond in die tijd was o.a. zijdelingse betrokkenheid bij database driver ontwikkeling voor een ERP pakket. AS/400 zat in het portfolio en Oracle ook, maar niet als combi.
Dat MySQL een hobby project zou zijn is natuurlijk flauwekul, probleem was meer de schaalbaarheid op de hardware van toen als je het wilde gebruiken in een corporate omgeving waar er veel mutaties in de database gedaan werden. Data uitlezen was geen punt dat ging razendsnel, maar data wegschrijven en vooral data veranderen kostte erg veel resources op de server.

Daarnaast werd (en wordt nu nog steeds) de databases ook vaak niet goed ingericht waardoor er enorm veel meer resources verbruikt worden als de ontwerper van de database in de 2de normaalvorm is blijven steken dan wanneer je de database naar de 5de normaalvorm brengt. In een praktijk ervaring ging de query tijd van tientallen secondes per query met 3 gebruikers, naar sub 100ms met een paar honderd gebruikers.
Postgres vind ik echt wel het schoolvoorbeeld hoe het wel kan.
Natuurlijk is het geen hobby project, maar zo werd dat wel gezien door veel grote bedrijven en dba's. Als je toen eens een off the record discussie voerde met een software leverancier waarom ze geen MySQL ondersteunde terwijl hun applicatie daar prima op zou kunnen draaien. Dan was het antwoord dat de klanten waaraan ze probeerde te verkopen een Oracle of zelfs een MS SQL oplossing als professioneler zagen. Of het meer sales georiënteerd antwoord: Er is niet voldoende vraag naar... Terwijl als je op een event was voor applicatie xyz en je andere beheerders sprak, er wel degelijk vraag naar was vanuit die beheerders (maar of dat ook het geval was voor de beslissers is natuurlijk weer een heel ander verhaal).

Maar inderdaad hardware. Enorme servers met (voor toen) enorme sloten RAM om maar je DB te kunnen draaien, want zelfs RAID10 arrays met 15k schijven waren geen goede optie in bepaalde gevallen. SSDs waren nog niet echt betaalbaar of beschikbaar.

Ik weet nog dat ik zat te kwijlen toen CCP (EVE Online) een enorm Texas Memory Systems RAM SAN had. Ik heb het op het werk voorgesteld, ze vonden het allemaal VET, maar niet echt het budget voor... ;)

Het was pas begin 2008 toen ik m'n eerste SSDs kocht: MTRON SSD MOBI 3000 16GB (2x in RAID0 om er maar een uitgeklede versie van XP op te kunnen installeren op 32GB).
Sorry maar dit klopt niet in de context van 2000-2010.

Performance/schaalbaarheid, sorry, we hadden meestal de grootste machine ( die de organisatie kon betalen ) tot onze beschikking, als het daarop niet lukte werd er meestal tegen de gebruikers gezegd dat ze er maar aan moesten wennen.

Als DBA/beheerder had je maar 1 echte manier om ontslagen toen te worden. En dat was wanneer er data kwijt was. Als een backup niet lukte, was er toen echt een probleem en je voelde toen ook de druk. Ik deed nog regelmatig restore testen, omdat ik mijn backups niet vertrouwde. En als je het niet terug kon krijgen was het bij Oracle een Oracle probleem en was je in contact met support om het te fixen. En MySQL ( die toen nog niet ACID was ) was het mogelijk jouw baan. Ook nu nog zie je oude beheerders erop drukken dat er support contracten worden afgesloten en dat is echt niet omdat ze een HD vervangen zie worden.

In andere context wordt het probleem hier met vliegvelden uitgelegd: YouTube: Why Assistants Avoid Booking A Better Flight
In sommige gevallen zijn de opties erg klein.
Vooral als je via Europese aanbesteding iets doen, en zij komen volgens het score-formulier het beste eruit, dan ben je soms wettelijk gebonden (vooral als overheidsinstanties) om daarmee in zee te gaan.
Het is een raar wereldje soms.
dat is vrij eenvoudig te ondervangen door in je aanbesteding zaken als portabiliteit te eisen, of simpelweg zaken die niet passen binnen het gangbare licentie model van Oracle, dan druipen ze vaak al af
Klopt, dat werkt met de kennis van nu, maar veel van de huidige bedrijven zitten vast, omdat ze dat in het verleden niet gedaan hebben.
Hef is niet alsof het pas recent duidelijk is geworden dat je als ondernemer niet alleen voordeel bij een contract hebt. Dat ondernemers proberen te binden met eisen die concurrentie uit sluit of anders boetes of vergelding geeft is zelfs al eeuwen praktijk. Een behoorlijk ondernemer, onderhandelaar en jurist hebben daar weet van. Het is eerder dat er veel ondernemers zijn die liever hun kop in het zand steken alsof de risico's niet realistisch zijn. En dan achteraf gaan klagen.
Waar baseer je dit op? Zie weinig verschil tussen SAP, Oracle en andere SaaS applicaties op dit gebied.

Als je praat over de databases van Oracle kan ik je nog ergens in vinden maar het ik hoop dat dit gaat om dingen zoals de Oracle Fusion applicaties waarbij ze klanten een SaaS contract verkopen terwijl de klant in werkelijkheid een IaaS, PaaS, SaaS krijgen.
Zoals al gezegd: zorg dat je vooraf eisen stelt aan oa portabiliteit. En controleer die, in de praktijk is het altijd veel ingewikkelder dan het ene vinkje in de offerte suggereert.

Ook: nee je bent niet gebonden aan de uitkomst van een aanbesteding. Zolang je dat zo beschrijft kan je op elk moment de aanbesteding stoppen. Daarna kan je een nieuwe starten nadat je de benodigde wezenlijke wijzigingen hebt doorgevoerd,
Bij zulke IT-bedrijven vraag ik me ook serieus af waarom anderen daar überhaupt mee willen werken.
Oracle is een advocatenkantoor met een software divisie
Dat gevoel krijg ik steeds vaker bij grotere ondernemingen. Als alle uren die sales reps, team leads, managers, disctrict directors, consultants en cfo's nodig zijn voor keuzes maken domweg direct waren toegekend aan IT'ers die werkelijk iets maken, dan was er tijd en geld genoeg om wél te kunnen overstappen.
Das management overhead, heel anders dan Oracle waar procederen het primaire verdienmodel van het bedrijf is.
Vergeet ook niet de FUD tactics en jarenlang misbruik maken van overheden die toch niet weg kunnen. Maximaal uitmelken en weinig leveren.
https://goomics.net/62

Het is een oude comic, maar nog steeds relevant hier ;)
Omdat er gewoon niets beters is. Financiele- en banken sector, net als vele andere zit vast aan oracle en zal daar nooit van af kunnen stappen.
Er is genoeg beters. Er is letterlijk geen enkele developer die vandaag een applicatie maakt en denkt: Oracle, dat moet ik hebben, want er is niks beters.

Het probleem zit in de vendor lock-in. Het hele winst model van Oracle is gebaseerd op prijs indexatie van legacy klanten. En als die allemaal weg gaan stort het kaartenhuis in. Dus dan doe je er alles aan om dat te voorkomen.

[Reactie gewijzigd door JustRob op 2 september 2026 12:08]

Sterker nog, ons bedrijf heeft al meermalen opdrachten gehad om onze klanten van Oracle weg te migreren. Blijft een vervelend klusje omdat Oracle er alles aan doet om zijn producten net niet compatible te maken met de rest van de wereld.
Ik vind vendor lock in maar een dom begrip. Als je al je applicaties, kennis en alles wat daarbij komt kijken rondom ANY product bouwt, zit je 'vast' aan dat product. En NIEMAND gaat een applicatie maken op een database met PUUR SQL, want elk product heeft toch weer zijn eigen dingetjes. Zaken als partitioning bijvoorbeeld zitten in meerdere database producten, maar zijn niet overal hetzelfde geïmplementeerd. Dus ja, als je dan over wilt stappen, moet je wat werk verrichten. En als je PL/SQL of Transact/SQL gebruikt, moet je in een ander pakket ook weer de boel omzetten.

En wat veel mensen in hun anti-Oracle tirades vaak vergeten, is dat Oracle altijd de voorloper is geweest met database technologie. Heel veel zaken waren het eerst bij Oracle geïmplenteerd, en dat werd pas (veel) later toegepast bij anderen, en nóg veel later in ANSI SQL opgenomen. En toen verzon men een andere syntax, waardoor Oracle het zogenaamd anders deed. Die nieuwe syntax is misschien beter, maar bij Oracle zat het er bij wijze van spreken al in 1991 in, en toen hebben zij het maar zo bedacht. En dat geldt voor een hoop dingen.
Ik weet dat het rotzakken zijn met hun licenties, en ja...geef ze eens ongelijk. Oracle had en heeft nog steeds een hoop dingen mee: het is behoorlijk bullet proof, performt best goed, en barst van de mooie features. Kost een paar centen, maar het is niet alsof je er rommel voor krijgt. En ik hoor dat geklaag over die prijs nu ook al 35 jaar aan, maar Oracle is in die tijd alleen maar groter geworden.
En als wij met ons bedrijf erin slagen om alles over te zetten naar Postgress, zijn we in ieder geval wel een paar jaar verder, maar vervolgens zitten we nét zo vast aan Postgress als aan Oracle. Kost alleen wat minder. In ons geval niet heel veel minder, want wij hebben door goed advies een heel gunstig contract. En als je Postgress gebruikt als grote gebruiker, moet je natuurlijk wel ondersteuning hebben, dus die kosten komen erbij. En alles wat je in al die jaren aan kennis en ervaring hebt opgebouwd met Oracle, moet je ook weer opnieuw opdoen. Niets is gratis.
Oracle is zeker een voorloper geweest. Database omzetten lijkt niet al te moeilijk tot je klanten hebt die hun logica bijna helemaal in database procedures vastgelegd hebben en waar de applicatie niet veel meer is dan een frontend daarvoor. Dan zit je opeens veel meer vast dan je eigenlijk zou willen.
Precies. Database procedures/packages, triggers en constraints. Ook daar zullen onderling best verschillen in zijn. Maar voor mij als database specialist is dat wél 'hoe het heurt'...die logica zoveel mogelijk in de database, zodat het ook door de database afgedwongen wordt (declaratief door constraints en triggers). En de verwerking gaat in de meeste gevallen ook sneller als je het ín de database doet, dus bovenop je data, in plaats van het eerst over het netwerk te sleuren, verwerken en weer terugpompen. Het is dan ook allemaal native, dus geen vertaalslagen.
Ja, je zit dan vast aan een database, maar dat is met alle databases zo. In de jaren '90 was er iets als Uniface. Daar kon je een applicatie in maken en de database die eronder zat was flexibel. Je kon Oracle, DB2 of SQL Server gebruiken, wat je maar wilt. Maar het nadeel was dat ie een datamodel genereerde dat helemaal standaard was. Dus zelfs een Oracle sequence werd niet gebruikt, maar een of andere universele constructie. Dat was dus niet vooruit te branden. Er is een reden dat je er niets meer van hoort. Waarom zou je ook een applicatie bouwen die je elk moment op een andere database kunt draaien? Het klinkt leuk, maar is niet practisch en ook niet realistisch.
Blijft grappig. Developers gruwelen meestal juist van "alle logica in de database" omdat je dan allerlei uitdagingen krijgt die je met losse applicaties niet hebt (cleane architectuur, code versioning, automated testing, deployment, portability). Voor beide kanten valt wat te zeggen en ook binnen ons bedrijf hebben we een DB expert die het liefste de "alles in de database" oplossing kiest.
performance en data-integriteit is ook belangrijk.. :+
Vandaar dat ik zei "Voor beide kanten valt wat te zeggen".
Nagel op de kop, ecosystem lock-in en probeer maar alles over te zetten naar bv MS SQL, ben je wel even bezig alle stores procedures te recoden, maar het kan wel als je hard doorbijt.
Ja, als je alle logica in de database stopt is de portability nul komma nul.
Onder andere door het gedrag van Oracle, wat de EU nu gaat onderzoeken!


Het helpt niet dat de grote leveranciers/bouwers, zoals Centric, naar mijn idee diep in de zakken zitten van software boeren als Oracle.

Van mij mag er een Europese verplichting komt over te stappen naar goedkopere/betere/Europese alternatieven voor all overheden, verplicht te voldoen in 2040, met nieuwe aanbestedingen van bestaande software in 2035 en nieuw te ontwikkelen software per 2030.

Alternatieven bestaan al en zo niet, dan komt het niet van de grond juist door de monopolie en bemoeienis van de grote Amerikaanse jongens. Als er een tijd is om dit een halt toe te roepen, is het nu wel.
In het wereldje gaat over Oracle al tijden de opmerking dat het geen IT bedrijf is. Maar een advocaten kantoor met een software afdeling.
Oracle staat erom bekend klanten eerst volledig vast te zetten, om ze daarna als een citroen uit te knijpen. Hun licentiemodel is dan ook ronduit bizar klantonvriendelijk.
Oracle is erg goed in het verdienen van geld. Dat kun je als een slecht iets zien... dat kun je als een betrouwbaar iets zien.

Waar ik zelf echt van moest janken zijn de consultants. Oracle is er goed in om van versie A naar versie B zaken totaal te veranderen, want je verdient geen geld aan als alles maar hetzelfde blijft en geen constante ontwikkeling nodig heeft. Nu kun je consultants inhuren van Oracle zelf om je te helpen bij de transitie... maar die consultants snappen vervolgens alleen versie A. Dus gaan op jouw kosten leren hoe ze de transitie bij toekomstige klanten sukkels gaan doen.
Hoe is het 'goed in geld verdienen' als je je klanten in een houdgreep hout terwijl ze ontevreden zijn? SAP verdient volgens mij ook veel maar dan vergeet je even dat ik als medewerker een uur bezig ben als ik een declaratie moet invoeren. Ik heb echt nog nooit zo'n kut pakket gezien en heb ook niemand er positief over gehoord.
SAP is niet per definitie slecht. SAP is in essentie een ERP-platform waarin organisaties hun bedrijfsprocessen modelleren. Als die processen zelf inefficiënt, historisch gegroeid of onnodig complex zijn, dan digitaliseert SAP die ellende gewoon.

De klassieke fout bij ERP-implementaties is dat een organisatie probeert haar bestaande werkwijze 1-op-1 in het systeem te reproduceren. Dan krijg je schermen met twintig verplichte velden voor iets wat eigenlijk een eenvoudige declaratie zou moeten zijn.

Een goede ERP-implementatie begint niet met het pakket, maar met de vraag: "Waarom doen we dit proces eigenlijk op deze manier?" Daarna kijk je hoe het pakket dat proces ondersteunt en waar je processen kunt vereenvoudigen of standaardiseren.

Dat geldt overigens niet alleen voor SAP. Je ziet exact dezelfde problemen bij Dynamics 365, Oracle ERP, Infor, Unit4, AFAS, Exact en andere ERP-systemen. Als je slechte processen automatiseert, krijg je slechte processen op een snellere computer.
Ik weet er te weinig van, ik werk ook niet bij HR. Maar SAP voelt als een rommeltje van 6 verschillende interfaces door elkaar. Ik kan me ook niet voorstellen dat mijn bedrijf idiote logica heeft toegepast op het indienen van een declaratie.
Hoe verschilt dat met het model van het merendeel van de grotere consulting/implementatie partijen?

[Reactie gewijzigd door Bossie op 2 september 2026 12:02]

Het verschilt niet, maar de verwachting was nou juist dat consultants van Oracle beter opgeleid zijn in het gebruik van hun eigen product.
Iets kan goed of slecht zijn, betrouwbaar of onbetrouwbaar. Het mixen van die kwalificaties lijkt me niet logisch.
Als ik voor host patching live wil migreren naar een tijdelijke host en daarna terug, dan zou ik voor m'n hele contract periode 2x zoveel CPU licenties moeten aftikken. Voor enkele uurtjes migratie per jaar.

Dat kan je goed in het verdienen van geld noemen, maar niemand behalve de Oracle directie kan dit goedpraten.

Zelfs Microsoft staat dit 'gratis' toe in de licentievoorwaarden..
Huh? Microsoft vraagt toch echt om een Software Assurance overeenkomst. Heb je die niet, dan betaal je gewoon licentie kosten over je standby omgeving.
Bedrijven die dat soort maatregelen nemen voor HA hebben door de band genomen wel SA hoor...
Zeker maar dat is mijn punt niet. SA is niet gratis. Zonder SA betaal je gewoon per omgeving.
I stand corrected.

Er is wel een regel dat je na 90 dagen je licentie mag verhuizen, maar niet on-the-fly.

Ook nog een mention waard, al heb ik onderstaande niet geverifieerd:
in October 2022, Microsoft gave Windows Server the so-called Flexible Virtualisation Benefit. Like License Mobility, it also requires Software Assurance or a CSP subscription. And like License Mobility, it overrides the 90-day rule.
Als ik voor host patching live wil migreren naar een tijdelijke host en daarna terug, dan zou ik voor m'n hele contract periode 2x zoveel CPU licenties moeten aftikken. Voor enkele uurtjes migratie per jaar.
Waar baseer je dat op? Volgens https://www.oracle.com/contracts/docs/lic_definitions_and_rules_v061526.pdf pagina 37:
includes the right to run the licensed Program(s) on an unlicensed spare computer in a failover environment for up to a total of ten separate 24-hour periods in any given calendar year
Op wat onze Oracle-specialistisch bedrijf heeft uitgezocht met de licentie specialist.

Ik kan je daarom ook niks quoten.
Uit mijn eigen ervaring was dat bij SAP niets anders.
"Oracle - a law firm with a software company attached" (c) Ed Zitron (in een post over OpenAI).
De opmerking zelf ken ik al een jaar of 20, volgens mij bestond OpenAI toen nog niet, dus ik ben benieuwd of hij echt copyright kan claimen. Ik ken deze logica ook als plaatje (waarbij Legal een stuk groter en vertakter is dan Development, dat er zo ergens bij hangt).
Het is ook een enorm slecht programma. Ik weet even niet meer welke aanbieder we hiervoor hadden maar dat was perfect voor personeel administratie. Paar jaar geleden kregn we een 'verbetering' wat inhield over naar Oracle. Nu is die hele frontend een drama om uit te zoeken hoeveel verlof je hebt, om declaraties in te voeren etc. Ik geloof dus graag dat ze een vendor lock moeten doen
Er is geen vendor lock vast gesteld. Er is geeneens een onderzoek gestart.

De problemen zitten ook niet bij de data maar bij het data model. Als je een applicatie in licentie afneemt, dan neem je ook een licentie op het data model. Verloopt je licentie, dan kan je het data model ook niet meer gebruiken.

Dat is waar je tegen problemen aanloopt als je van applicatie wilt wisselen. Als de oude data niet in het nieuwe systeem past, dan heb je een probleem met je data in retentie.
Frontend heeft 0 te maken backend database, meer met de kwaliteit van de ontwikkelaar.
Ik denk dat het uiteindelijk eerder een geval is van "we willen er zoveel mogelijk geld uitknijpen". Want waarom zou je innoveren als je ook gewoon massaal geld kan trekken zonder extra R&D.
Als je nou gewoon betere spullen bouwt tegen een scherpe prijs, lopen je klanten niet weg en hoef je daar ook niet bang voor te zijn.
Als je klanten sowieso niet weglopen omdat je iets relatief unieks aanbiedt laat je daarmee een gigantische hoop geld liggen. Dat is iets waar bedrijven niet zomaar mee wegkomen van de aandeelhouders.
Altijd een beetje jammer dit soort gedrag. Blijkbaar is de kracht van het eigen product niet afdoende om klanten binnen boord te houden omdat ze dat graag willen, maar moeten er obstakels worden opgeworpen.
Dit zie je steeds meer. Microsoft, Apple, Google. Op slinkse wijze gebruikers vasthouden terwijl je ook je product kunt verbeteren. En ook bij bedrijven, hippe vlotte mensen pushen een product naar binnen met onwaarheden en je zit er ineens aan vast. SAP, Microsoft en PerfectView crm; ze doen het allemaal.
En waarom zit je vast? Omdat je business de standaard rapportages en tools is gaan gebruiken. Ze hebben hun werkwijze aangepast op wat het software pakket te bieden had.

Wil je dan tien jaar later migreren naar een andere leverancier, dan veranderd hun hele wereld. En dat willen ze niet, al kan het nieuwe pakket in principe hetzelfde maar het gaat op een andere manier dan ze gewend zijn. Daar zit de pijn.

Uiteindelijk is het heel eenvoudig, of je nu Oracle EBS, Exact of AFAS software voor je boekhouding gebruikt, alle drie werken prima voor een bedrijf. Alleen is de financiële afdeling gewend op de manier te werken die aangeboden wordt door het software pakket.

Gebruikte je vanaf dag één het pakket alleen als core systeem met eromheen je eigen UI en je eigen datawarehouse voor rapportages, dan is switchen ineens een stuk eenvoudiger.
maar dan moet je wel je ganse GUI zelf gaan inrichten, liefst nog op zo'n manier dat veranderen van backend / core niet a te veel impact heeft.
Maar heb je ook meer werk om die eigen UI en warehouse te onderhouden. Het idee van die grote tokos is nou net dat ze een alles-in-1 oplossing bieden, die vooral managers veel rust geeft, want je hebt nog maar 1 aanspreekpunt voor al je problemen.
Bij eigen speelgoed, of erger: 3 verschillende partijen, zul je altijd zien dat ze net even andere 'standaarden' hanteren, en uiteraard alleen maar met andere entities willen praten als dat via hun protocol (en hun halve implementatie van dat protocol) gaat.
Het gaat dus blijkbaar om de Oracle Application klanten. Want als je de database niet meer wilt gebruiken, kun je gewoon stoppen natuurlijk.

Niet om Oracle te verdedigen, maar dit is heel gebruikelijk. Ik heb ooit een aantal gemeentes geconsolideerd naar een samenwerkingsverband (dit is al heel lang verplicht vanuit de overheid) en dan krijg je te maken met Centric en Pink die belachelijke bedragen vragen om de data over te zetten. Je krijgt geen informatie over het datamodel en hoe je het zelf zou kunnen. Zij moeten het doen, voor veel teveel geld.
Ook bij andere klanten meegemaakt dat boekhoud- en administratiesoftware compleet op slot zit voor de klant. Die draaien dan niet op Oracle oid, maar op een eigen systeem (of xBase indertijd) en je mag/kan er niet zelf aan zitten. Moet je een migratiemodule of exportmodule kopen om je eigen data te ontsluiten.

Ik zei toen al dat de overheid een wet moet invoeren waarin zij de leveranciers van overheidssoftware verplichten om minimaal XML en/of CSV export aanbieden van alle data die in het systeem staat. Gewoon bij wet veplichten.
Dat is ook het gevolg van het wegbezuinigen en inkrimpen van overheidsinstanties en vrijwel alle kernactiviteiten uitbesteden aan een handjevol partijen. De kennis is niet meer thuis maar in handen van deze partijen

Het idee was dat commerciele bedrijven dit goedkoper en beter kunnen doen. Vervolgens krijg je een enorm project waar een handjevol bedrijf ter grootte van een Capgemini, CGI, Centric de enige zijn die hier in aanmerking voor komen en die kunnen vragen wat ze willen.
Nee, dat is het niet. Overheden hebben speciale software nodig. Bevolkingsadministratie en tot voor kort loonadministratie en nog heel veel andere zaken zijn specifiek voor overheid (lokaal/rijks). Er is heel veel waar je niet eens op komt als je er lang over nadenkt. Misschien kun je, als je je werkprocessen erop aanpast, zou je voor een aantal zaken standaardsoftware kunnen gebruiken. Maar dat is niet altijd mogelijk, al was het alleen al dat de overheid ook soms zaken op een specifieke manier moet uitvoeren en daarover rapporteren. Ook is ern een workflow met goedkeuringen etc. Zij zitten dus vast aan dergelijke leveranciers. Centric en Pink zijn de marktleiders en dan heb je nog een paar kleintjes die, waarschijnlijk doordat ze een keer een klusje bij een kleine gemeente hebben gedaan, ook iets aanbieden. Begraafplaatsadministratie of beheer van het zwembad...verzin het maar...

Dus die kennis hebben de gemeenten zelf niet in huis. Tegenwoordig moeten kleine gemeenten samen met anderen hun IT organiseren, zodat er een grotere organisatie ontstaat. Scheelt een hoop geld, maar dan moet je wel eerst al die software consolideren. En er zijn dan een aantal applicatiebeheerders die eea weten over die applicatie.

Maar de ontwikkeling van die applicaties is geen taak voor de gemeenten. Tenminste, sommigen proberen het, met wisselend succes. Dus helemaal niet gek dat zij dat uitbesteden. maar dan moet je wel zelf de baas zijn over je data. Dat moet gewoon in wetgeving vervat worden. Maar uiteindelijk blijft migreren naar een ander softwarepakket een hele klus.
Speciale software ja, maar het gaat er bij mij niet in dat gemeente X zoveel afwijjkt van gemeente Y. Zeker niet binnen 1 land.
Het zal je verbazen... :+

Gemeenten hebben blijkbaar de ruimte om wetgeving en regelingen naar eigen goeddunken te interpreteren en uit te voeren.

Maar het ging om software. Ook al doen de pakketten van Pink en Centric in essentie hetzelfde, je kunt je data niet zonder meer overpompen. Dat vereist toch weer wat migratiesoftware.
Heel het IT infrastructuur ligt in handen van consultants?
Bij de aanbestedingen waar ik de laatste tijd bij betrokken ben geweest, hebben wij in de voorwaarden gezet, dat er een goede exit-strategie aanwezig moet zijn en beschreven moet zijn in hun aanbod.
Daarmee kan je soms al heel veel van te voren inschatten wat de impact is.
Welke database ken jij die geen CSV export of XML export functie heeft? Data export is het probleem niet, maar waar naartoe ga je de data exporteren?

Een applicatie heeft een data model. Dat model is wel degelijk eigendom van het bedrijf dat het ontwikkeld heeft en mag je niet zomaar elders gebruiken zonder licentie. Wil je dat niet, dan zal je je eigen applicaties moeten ontwikkelen. Zoals gemeentes vroeger deden.

En dan krijg je de bijzondere situatie dat de overheid eerst al haar IT verkoopt aan de markt om dan later te klagen dat ze afhankelijk geworden zijn van die markt.
Welke database ken jij die geen CSV export of XML export functie heeft? Data export is het probleem niet, maar waar naartoe ga je de data exporteren?
Dat bedoel ik niet. Natuurlijk kan je je hele database exporteren. Maar in het geval van die klant met boekhoudsoftware zit de data in hun eigen database die je niet zelf kunt benaderen. Om je data eruit te krijgen, moet je een exportmodule kopen voor veel geld.

En in andere gevallen, als je bepaalde software van Centric of Pink gebruikt (typische overheidssoftware), heb je ook hulp nodig bij migraties. Als je zelf alles moet uitvogelen, ben je veel te lang bezig. Een datamodel bekijken is 1 ding, maar begrijpen is een ander ding. Je weet niet precies wat alle attributen doen bv, Dus zomaar zelf overpompen is geen optie.
Dat klopt, het datamodel is van de software leverancier en daar zit een licentie op.

Stop je met het afnemen van de licentie, dan zal je de data moeten migreren naar je eigen data model of het data model van je nieuwe leverancier.

Dat een data migratie zonder medewerking van de leverancier nauwelijks mogelijk is, ja dat klopt ook. Ik ken leveranciers met een datamodel met meer dan 15.000 unieke velden inclusief een heleboel redundantie in hun model. Het model is volledig geoptimaliseerd voor de software modules. Zelfs modules die je niet actief gebruikt maar in de toekomst wel zou kunnen gaan gebruiken.

In het onderliggende contract staan vaak je rechten en de kosten van een data engineer van de leverancier indien je wil migreren. En dat zijn vaak pittige tarieven. Al zijn ze vergeleken met het uurtarief van een notaris of advocaat ineens helemaal niet zo pittig meer.

Heb je de exit strategie het niet opgenomen in je contract, ja dan heb je een probleem. Dat worden lastige onderhandelingen. Maar anno 2026 zou dat nauwelijks meer voor moeten komen, de meeste hebben toch wel geleerd van de cloud egress fees.
Datamodel? Bedoel je het RDBMS?

Databasenormalisatie kan je in een paar dagen leren hoor... :P
Nee ik bedoel data model. Systemen als Oracle EBS komen met hun eigen datamodel en eigen rapportages eromheen. Dat heeft niets met normalisatie te maken, het data warehouse is geoptimaliseerd voor de rapportages, is dus juist niet genormaliseerd.
Het zou me niet verbazen als ze in de licentie voorwaarden dingen hebben opgenomen die de overstap moeilijk maken. Door de licentie over te laten gaan op bijvoorbeeld het aantal medewerkers in plaats van het aantal databases. In ieder geval door het ondoorzichtiger te maken en onvoorspelbaarder.
Bedrijven zouden bij aanschaf van een product de reputatie van de leverancier moeten meenemen in de selectie.
Het is al 15 jaar alom bekend dat je bij Oracle niet echt wordt gezien als klant(van oudsher iets waar je als leverancier een fatsoenlijke relatie mee wil hebben en houden), maar als melkkoe. Ze sturen liever juristen dan technisch personeel als er iets niet klopt.

Dat zijn een beetje onderbuikgevoelens, maar het kan je een boel geld en ellende schelen.
Hoe moet je deze reputatie onafhankelijk en feitelijk meten?

Dat het bekend is in de markt dat het "schurken" zijn die je heel graag volledig willen uitmelken. Maakt het niet iets wat je zomaar bij een uitvraag of aanbesteding als beoordeling zomaar mee kan nemen. Want er zullen genoeg rapportages van onderzoekbureau's zoals een Gartner bestaan die wel met allemaal feitjes zullen komen, dat ze wel integer en betrouwbaar en prima langere termijn relaties mee op te bouwen valt. Dit soort rapportages zullen wel als feitelijke waarheden gezien worden als je voor een rechter staat, in plaats van "de onderbuik" verhalen die er over deze leverancier rondgaan.
Feit is dat een goede klant <-> leverancier relatie heel belangrijk is(kan zijn). Dat feitje kan je ook benoemen en de voorwaarden daarvoor ook.
Natuurlijk blijft dit een lastige, maar je kan ook binnen aanbestedingen met je eisen een beetje sturen welke kant je wel/niet op wil (en dan moet je natuurlijk iets creatiever zijn dan de eis dat de tekst in logo van de inschrijver niet mag beginnen met een O en eindigen op racle).
Het is geen feit zolang er geen uitgebreide verslaglegging over de kwaliteit van deze relatie is. Als techneut roepen dat ze stom zijn, kan je niet meenemen in je aanbesteding. Hiervoor moet je dossier op orde zijn en ook bestand zijn voor het geval je bij de rechter staat.

Je kan zeker creatief zijn met je eisen binnen een aanbesteding, maar dan moet je wel kennis van zaken hebben en de eisen zo opschrijven dat het niet evident is dat je een bepaalde partij wilt voortrekken of uitsluiten.
Gezien de enorme risico's die Oracle genomen heeft/neemt in de AI-hype is het nog maar de vraag of zij over een paar jaar nog bestaan. Jezelf verantwoordelijk (en aansprakelijk) maken voor de bouw van datacenters waarvan je niet weet wanneer ze klaar zullen zijn en of ze überhaupt gebruikt gaan worden én daarvoor je eigen vermogen te gebruiken, lijkt me niet een valide business plan.
En dat gaan ze dan weer een probleem van de klant maken of zo?

En als ze overkop gaan, zullen er wel een paar anderen staan te springen om het over te nemen, dus we moeten niet vrezen voor een stop, alhoewel de overnemers nog meer poen kunnen gaan vragen voor dat spul…
Ik denk dat het wel mee zal vallen met de afschrijving. Bedenk dan maar zo, gisteren was het goedkoper om te bouwen dan morgen. Dus beter heb je al wat staan wat uiteindelijk toch wel voor "iets" gebruikt zal worden. Is het niet AI dan is het wel game-streamen oid
Het duurst is een gebouw dat nooit in gebruik genomen is, maar wel gebouwd is... En als de AI-boom een beetje de verkeerde kant op gaat, zit Oracle met een bak investeringen die ze niet terug gaan zien. Juist omdat iedereen en z'n grootmoeder nu datacenters aan het bouwen is, allemaal berekend op videokaarten die steeds duurder (en slechter leverbaar) zijn geworden, en allemaal uiteraard megalomaan groot.

[Reactie gewijzigd door FreezeXJ op 2 september 2026 15:15]

Ja, je verteld precies hetzelfde als ik:

Alles wordt duurder; daarom beter gisteren kopen ipv morgen.

Gebouw dat nooit gebruikt wordt; dat wordt dus anders ingezet dan voor AI.

Nu nog wachten op de ai bubbel, maar dat de investering van een datacenter 100% verloren wordt beschouwd ben ik niet van overtuigd.
Hoe belemmert oracle dan de overstap? Logisch dat je zelf maar moet zorgen dat je data overgezet kan worden van Oracle naar iets anders, ze hoeven je daar niet bij te helpen.
Als ze je data gijzelen, is dat toch wel degelijk het probleem van Oracle.
Oracle moet dus een export-knop of iets dergelijks voorzien waarmee de data naar een non-proprietary bestand kan worden omgezet.
Hoe die data er na gebruikt moet worden is inderdaad niet meer aan Oracle.
Alles ervoor dus wel.
Oracle is met afstand een van de onaangenaamste bedrijven om zaken mee te doen. Leveranciers worden benadeeld en partners uitgeknepen: verplichte opleidingen, een verplichte partnerstatus en anders geen business. Ook neemt Oracle zonder problemen contracten over van haar eigen partners. Niet voor niets zegt men na een overname door Oracle: "Oracle is the place where good software goes to die."
Oracle, het bedrijf dat heel enthousiast toegeeft onspreekbare 'scary tech' te ontwikkelen voor het Israelische leger? Je zou het niet zeggen.

YouTube: Oracle executive confirms new 'scary technologies' available to Israeli military
Relevant: het ooit zeer drukke Oracle kantoorgebouw in Amsterdam staat nu LEEG en is te huur.
Wel grappig de reacties hier vs de reacties van het pauper volk op X.

Daar is "iedereen" boos over de EU en dat ze Oracle (maar ook ChatGpt etc) in bedwang houden. 1000'en posts over hoe de EU met bureacratie zichzelf kapot maakt, en hoe het een evil empire is etc.
Hoe lang eer Trump de EU gaat uitkafferen?

Om te kunnen reageren moet je ingelogd zijn