Digitale soevereiniteit en je Oracle-database: welke keuzes heb je echt?

In het kort:

• Digitale soevereiniteit betekent dat je zelf bepaalt waar je data staat, wie er technisch bij kan en of je kunt overstappen naar een andere leverancier.
• Oracle biedt meerdere varianten, van een EU-regio in Amsterdam tot een volledige cloudregio in je eigen datacenter.
• Voor de meeste organisaties is EU Sovereign Cloud de juiste balans: dezelfde services en prijzen als de commerciële cloud, maar beheerd door EU-personeel vanuit Europese rechtspersonen.
• Een migratie van je Oracle-database verloopt meestal via ‘Zero Downtime Migration’ met Data Guard, en valt of staat bij de voorbereiding.
• Het herziene rijksbrede cloudbeleid van juli 2026 maakt datalocatie, sleutelbeheer en een getest exitplan tot harde eisen voor gevoelige informatie.

Ongeveer twee jaar geleden schreef ik over Oracle EU Sovereign Cloud, toen nog vooral als antwoord op de vraag waar je data fysiek staat. Die vraag is inmiddels de makkelijkste geworden. Wat klanten me nu vragen is wie er in hun omgeving kan, onder welke wetgeving die partij valt, en of ze nog weg kunnen als ze weg willen.

In dit artikel zet ik op een rij wat soevereiniteit praktisch inhoudt, welke opties Oracle biedt, waar de grenzen liggen en hoe een databasemigratie naar een soevereine omgeving er echt uitziet.

Wat is digitale soevereiniteit?

Onder digitale soevereiniteit verstaan we de mate waarin je organisatie zelf controle houdt over haar data en systemen: waar de gegevens staan, wie er technisch en juridisch bij kan, en of je van leverancier kunt wisselen zonder je bedrijfsvoering te breken. Het is dus geen product dat je koopt, maar een eigenschap van de inrichting die je kiest.

In de praktijk lopen drie dingen door elkaar.

• Datalocatie: waar staan je gegevens fysiek.
• Operationele controle: wie beheert de omgeving.
• Rechtsmacht: onder welke rechtsmacht valt die partij.
• Technische vrijheid: kun je weg als je weg wilt.

Die laatste is de meest onderschatte. Een exitplan dat alleen op papier bestaat is geen exitplan. Weinig organisaties testen hun exitplan ook echt technisch. Dat geeft onzekerheid en maakt het lastig om in te schatten wat de impact is als je van platform wisselt.

Waarom soevereiniteit nu op tafel ligt

De Nederlandse overheid stelde in december 2025 de Visie Digitale autonomie en soevereiniteit vast, en op 3 juli 2026 volgde de herziening van het rijksbrede cloudbeleid. De lijn is duidelijk: open waar het kan, beschermen waar het moet. Voor gevoelige informatie gelden strengere eisen aan datalocatie, sleutelbeheer en exitplannen.

Dat beleid raakt niet alleen ministeries. Ook gemeenten, woningcorporaties, zorginstellingen en ISV’s die aan de overheid leveren krijgen de eisen via aanbestedingen alsnog op hun bord. En in de private sector speelt hetzelfde, alleen met een ander motief, namelijk continuïteit.

Sinds de onrust op het geopolitieke toneel vragen steeds meer organisaties zich af of een Amerikaans platform voor hen de juiste keuze is.

Welke soevereine cloudopties biedt Oracle?

Oracle heeft vijf varianten, die van elkaar verschillen in waar de data staat en/of wie het beheer doet:

Oracle EU Sovereign Cloud

Aparte regio’s in Frankfurt en Madrid, fysiek en logisch gescheiden van de commerciële OCI-regio’s. De hardware en datacentercontracten zitten in Europese rechtspersonen, beheer en support worden gedaan door personeel dat in de EU woont. Het serviceaanbod en de prijzen zijn vrijwel gelijk aan de publieke cloud. Dat laatste is belangrijker dan het klinkt: je betaalt geen toeslag voor soevereiniteit, en je team heeft er geen nieuwe kennis voor nodig.

Exadata Cloud@Customer

Exadata-infrastructuur als clouddienst in je eigen datacenter. Je data verlaat het pand niet, je betaalt per gebruik en je krijgt de voordelen van moderne diensten zoals ‘Autonomous Database’. Let op een detail dat vaak wordt overgeslagen: het beheerkanaal loopt wel naar een OCI-regio. De data blijft bij jou, het control plane niet helemaal.

OCI Dedicated Region

Een complete Oracle-cloudregio in je eigen datacenter, met een lokaal control plane. Dat betekent dat de omgeving zichzelf kan beheren zonder verbinding met Oracle. De zwaarste variant qua controle en regie, maar ook qua investering en doorlooptijd.

Wil jij enige vorm van soevereiniteit, maar wil je niet je eigen omgeving beheren? Dan is de EU Sovereign Cloud een geschikte oplossing. Wil je verder gaan en je data volledig in eigen handen hebben, dan zijn Cloud@Customer of Dedicated Regions een passende keuze.

Is Oracle EU Sovereign Cloud soeverein genoeg?

Oracle blijft een Amerikaans moederbedrijf, en dat is precies waar critici op wijzen als het over de CLOUD Act gaat. Oracle heeft dat afgedekt via aparte Europese entiteiten, EU-personeel en processen die gescheiden zijn van de wereldwijde cloudoperatie. Dat is substantieel meer dan alleen een datacenter in Frankfurt neerzetten, en het maakt het een stuk lastiger om via de CLOUD Act bij je data te komen. Helemaal uitsluiten kan niet. Het moederbedrijf blijft Amerikaans, en wat er gebeurt als Amerikaanse en Europese wetgeving met elkaar botsen, moet de praktijk nog uitwijzen. Of dat restrisico acceptabel is, hangt af van je risicoprofiel en de classificatie van je data. Is het dat niet, dan kies je voor Cloud@Customer of Dedicated Region, waarbij je data in je eigen datacenter staat.

Hoe migreer je een Oracle-database naar een soevereine omgeving?

De voorbereiding bepaalt het succes. Grofweg doorlopen we zeven stappen:

• Welke databases, welke versies, welke features en welke licenties. Vooral dat laatste levert verrassingen op, want niet elke feature die on-premises meeliep mag zomaar mee naar een clouddienst.
• Per database bepalen hoe gevoelig de data is. De uitkomst is bijna nooit “alles naar één platform”.
• Doelplatform kiezen. Autonomous Database, Base Database Service of Exadata, in de public cloud, EU Sovereign Cloud of in eigen huis.
• Migratiemethode bepalen. Voor de meeste Oracle-naar-Oracle-trajecten werkt Zero Downtime Migration goed, met Data Guard eronder. Bij versieverschillen of platformwissels zijn er alternatieve methodes.
• Eén keer testmigreren is (soms) te weinig. We oefenen de cutover tot de doorlooptijd voorspelbaar is.
• Kort venster, vooraf afgesproken terugvalscenario, duidelijk go/no-go moment.
• Monitoring, patchbeleid, back-ups, en een exitplan dat je echt hebt getest.

Een migratie kan maanden voorbereiding vragen, terwijl de migratie zelf in 1 of 2 weekenden wordt uitgevoerd. Hoe lang het precies duurt, verschilt per omgeving en hangt onder meer af van het aantal databases.

In de praktijk zijn er een aantal afhankelijkheden die invloed hebben op het succes van een migratie. Om deze afhankelijkheden in kaart te brengen en te minimaliseren, is een goede inventarisatie van essentieel belang.

Wat wij als Nederlands bedrijf bijdragen

Wij zitten in Leerdam, onze consultants en DBA’s werken vanuit Nederland en ons 24/7 beheer draait hier. Dat is geen detail. Bij soevereiniteit gaat het niet alleen om waar de infrastructuur staat, maar ook om wie er dagelijks in je omgeving werkt en onder welke wetgeving die partij valt.

Daarnaast investeren we in kennis, en dat is misschien het meest onderschatte stuk van digitale autonomie. Het overheidsbeleid noemt eigen vakmanschap expliciet als voorwaarde. Via onze opleidingen leiden we DBA’s en ontwikkelaars op die hun eigen omgeving snappen, zodat je niet voor elke wijziging afhankelijk bent van een externe partij, ook niet van ons.

Agentic RAG: van kennis ontsluiten naar taken uitvoeren

Veel organisaties gebruiken generatieve AI inmiddels voor algemene taken: een mail opstellen, iets opzoeken, een tekst samenvatten. Veel minder organisaties krijgen AI aan het werk binnen hún bedrijfsprocessen – met hún data en hún kennis. En dat is nou net waar het interessant wordt, want daar haal je als bedrijf de meeste waarde uit, maar heb je wel een systeem voor nodig waar medewerkers en klanten dagelijks op durven te vertrouwen. Hiervoor heb je geordende data, autorisatie, monitoring en evaluatie nodig. Met een pilot die niet opschaalt kom je er dan niet.

Retrieval-Augmented Generation is daarvoor de sleuteltechnologie. In een eerder artikel legden we uit hoe RAG werkt en waarom een Oracle-database daar een logische plek voor is. Dit stuk gaat over de stap daarna: wat er gebeurt als je een AI-agent om die RAG-opzet heen bouwt.

Wat is agentic RAG?

Agentic RAG is een RAG-opzet waarin een AI-agent zelf bepaalt hoe een vraag wordt beantwoord: hij plant de stappen, kiest welke bronnen hij raadpleegt, beoordeelt of het gevonden antwoord goed genoeg is en zoekt zo nodig opnieuw, voordat hij antwoord geeft. Klassieke RAG doet één zoekactie per vraag, agentic RAG mag er meerdere doen en kan ook zelf tussendoor bijsturen.

Een klassieke RAG-opzet is in de kern een eenmalige actie: één vraag, één zoekactie, één antwoord. Dat werkt uitstekend voor gerichte kennisvragen. Maar het loopt tegen grenzen aan zodra een vraagstuk meerdere stappen vraagt, informatie uit verschillende systemen nodig heeft, of een stukje eigen beoordeling vereist.

Vergelijk het zo. Klassieke RAG is één keer een naslagwerk openslaan. Agentic RAG is een assistent die zelf bepaalt welke boeken hij pakt, checkt of het klopt wat hij vindt, en pas daarna met een onderbouwd antwoord komt. Desnoods na een paar tussenstappen.

Wat een agent kan wat een chatbot niet kan

Voor organisaties is dit een grotere stap dan hij op het eerste gezicht lijkt. Een chatbot beantwoordt vragen over documenten. Een agent neemt zelf beslissingen over wat er moet gebeuren en voert dat ook uit.

Denk aan:

• Een schademelding beoordelen én zelf bepalen of hij genoeg weet om dat te doen. Is de melding eenvoudig en duidelijk gedekt, dan stelt hij zelf een besluit voor. Ontbreekt cruciale informatie, dan vraagt hij daar gericht naar, in plaats van te gokken. Is het bedrag hoog of de situatie twijfelachtig, dan routeert hij de melding door naar een medewerker. Steeds is het de agent zelf die bepaalt welke van deze drie routes past.
• Een offerte samenstellen waarbij de agent zelf beslist welke systemen hij nodig heeft. Hij start bij de klantgegevens en afhankelijk van wat hij daar aantreft, een lopend contract of een speciale afspraak, besluit hij zelf of hij ook het prijzensysteem of de contracthistorie moet raadplegen. Geen vaste route die altijd hetzelfde rijtje systemen afloopt, maar een keuze die per klant kan verschillen.
• Een routinematige, ondubbelzinnige aanvraag zelf afronden, inclusief het vastleggen van het besluit in het systeem, niet alleen een advies opstellen dat een medewerker nog moet natrekken. Alleen de twijfelgevallen legt hij voor.

Vergelijk dat met ‘een conceptadvies opstellen dat een medewerker alleen nog hoeft na te lopen’. Dat kan een chatbot met RAG al. Daar wordt niets zelf besloten of uitgevoerd, alleen tekst gegenereerd op basis van wat is opgehaald. Het verschil met een agent zit ’m dus niet in hoeveel bronnen er worden geraadpleegd of hoe knap het antwoord klinkt, maar in de vraag of het systeem zelf bepaalt wat de volgende stap is: welke bron nodig is, of er genoeg informatie is en of er een actie volgt in plaats van alleen een tekst.

Hier ontstaat wel een verschil dat je vooraf moet kennen. Voor het beantwoorden van vragen heb je je bestaande applicaties niet per se nodig: je leest alleen en die data is meestal goed bereikbaar, vaak zonder dat je iets aan de bestaande software hoeft te veranderen.

Bij het uitvoeren van taken ligt het anders. Dan moet de agent ook de regels kennen die bepalen wat er mag gebeuren: wie iets mag goedkeuren, welke controles verplicht zijn en in welke volgorde stappen moeten gebeuren. Een deel van die regels ligt vast in de techniek onder de motorkap en daar kan een agent bij. Maar bij oudere systemen zit een groot deel van die regels verstopt in de schermen zelf, in de manier waarop de applicatie is gebouwd, niet in de data erachter. Buiten die schermen om bestaat die kennis dan simpelweg niet. Het gevolg: de agent kan dan wel lezen, maar niet zelf handelen.

Dat is geen reden om te wachten. De basis, de kennis die de agent nodig heeft om vragen goed te beantwoorden, kun je nu al opbouwen. Blijkt later dat je ook taken wilt laten uitvoeren, dan weet je precies waar de grens ligt en wat nodig is om die te verleggen. Vaak kan het nuttig zijn om de onderliggende verouderde applicatie dan te vervangen of te moderniseren. Dit proces, ook wel ‘replatformen’ genoemd, biedt Transfer Solutions ook aan en gebeurt met behulp van onze nieuw ontwikkelde AI Factory.

In alle gevallen geldt: het antwoord komt zelden uit één bron, maar is een samenstelling van meerdere. De agent moet dus kunnen bepalen welke bron voor welk deel dient én weten wanneer hij genoeg weet om een betrouwbaar antwoord te geven of een actie te starten.

De valkuil: een agent is niet kieskeurig

Hoe autonomer het systeem, hoe zwaarder het leunt op wat eronder ligt. Een model kiest niet vanzelf de juiste versie van een document. Het haalt net zo makkelijk een verouderde polisvoorwaarde op als de meest recente, tenzij je je datafundament goed hebt ingericht. En omdat het uiteindelijk nog steeds een taalmodel is dat de tekst schrijft, blijft er een risico op hallucinaties. Kleiner dan bij een kaal taalmodel, maar niet nul.

Bij agentic RAG telt dat zwaarder dan bij een gewone kennisbot. Een fout in stap één werkt door in alle vervolgstappen, en de gebruiker ziet alleen het eindresultaat. Daarom horen bronvermelding en een herleidbaar spoor van de genomen stappen wat ons betreft standaard in zo’n systeem te zitten. Daarnaast verandert er na de oplevering steeds iets: brondocumenten worden bijgewerkt, modellen vervangen, vragen verschuiven. Daarom bouwen we altijd een monitoringstap in, die de kwaliteit blijft meten en afwijkingen signaleert.

Wij behandelen een RAG-traject dan ook nooit als AI-project, maar als datavraagstuk. Welke bronnen zijn betrouwbaar en actueel? Hoe is de data gestructureerd? Wie stelt de vraag, en welke documenten mag die persoon in dat geval terugkrijgen? En hoe borg je governance en compliance, zeker als er persoonsgegevens in het spel zijn of als je in een gereguleerde sector zit?

Waarom het dataplatform eronder het verschil maakt

Transfer Solutions is al jaren de grootste onafhankelijke Oracle-specialist van Nederland, met daarnaast een sterke Microsoft-samenwerking. We kennen de databases, platformen en data-architecturen van onze klanten door en door, of het nu gaat om Oracle 23ai en 26ai of om Azure Document Intelligence en semantic chunking.

Dat is precies waar agentic RAG staat of valt: op de kwaliteit van de data eronder, niet op de AI erboven. We bouwen geen los AI-laagje bovenop een bestaand landschap.

Dit zien we dagelijks terug. Bij een klantenservice, waar antwoorden direct en correct moeten zijn op basis van actuele productinformatie. Bij interne kennisbanken, waar nieuwe medewerkers sneller wegwijs raken. Bij verkoopondersteuning op basis van actuele catalogi. En bij compliance- en juridische vraagstukken, waar herleidbaarheid naar de bron cruciaal is.

Zo pakken we een traject aan

Klein beginnen, snel iets werkends laten zien, pas daarna opschalen. Concreet:

• Fase 1, Proof of Value. Binnen twee weken een eerste werkende functionaliteit, op basis van je eigen data en actuele embeddingmodellen
• Fase 2, Ontwikkeling. Iteratief uitbreiden naar volledige functionaliteit, in korte sprints met tussentijdse toetsing
• Fase 3, Implementatie. Integratie in bestaande systemen, uitrol naar vestigingen of afdelingen, inclusief training en begeleiding
• Fase 4, Beheer. Doorlopende kwaliteitscontroles en een meetbaar resultaat op conversie of advieskwaliteit. Geen vage belofte, maar een afgesproken metric

Geen hype, wel resultaat

RAG is niet nieuw meer, de eerste onderzoekspublicaties dateren uit 2020. Het is inmiddels volwassen genoeg om productiewaardig te zijn, mits de datafundamenten kloppen. Agentic RAG is daar de logische volgende stap op: van kennis ontsluiten naar taken uitvoeren.

Wij geloven niet in AI die los van je organisatie staat, maar in AI die eromheen gebouwd is. Vertrekkend vanuit je eigen kennis en processen, met bewijs in plaats van beloftes.

Wil je weten wat agentic RAG voor jouw organisatie kan betekenen? In een sessie van een uur kijken we samen waar het bij jullie het snelst concrete waarde oplevert. Neem dan contact met ons op door het formulier op deze pagina in te vullen.

Verder lezen: Oracle AI vector search, Microsoft over RAG in Azure.

RAG met Oracle: AI die jouw bedrijfsdata écht kent

Iedere organisatie wil vandaag de dag aan de slag met generatieve AI. Chatbots, AI Agents, virtuele assistenten, slimme zoekfuncties, de beloftes zijn groot. Maar wie ermee heeft gewerkt, loopt al snel tegen dezelfde muur aan: een generiek taalmodel weet simpelweg niet wat er speelt binnen jóuw organisatie. Het kent je klantendossiers niet, je actuele voorraadstanden niet, en al helemaal niet het contract dat gisteren is getekend.

Dat is precies het probleem dat Retrieval-Augmented Generation (RAG) oplost, een technologie waar wij bij Transfer Solutions dagelijks mee werken.

Wat is RAG en hoe werkt het?

Retrieval-Augmented Generation (RAG) is een techniek waarbij een taalmodel bij elke vraag eerst relevante informatie ophaalt uit een externe kennisbank met je eigen data, en die informatie meeneemt bij het formuleren van het antwoord. Zo geeft het model antwoorden die kloppen, actueel zijn en te herleiden naar de bron, zonder dat het model hoeft te worden hertraind.

Waarom dat nodig is: een large language model (LLM) is getraind op enorme hoeveelheden data, maar die training stopt op een gegeven moment. Alles wat daarna gebeurt, nieuwe producten, actuele cijfers, recente besluiten, kent het model niet. Voor een chatbot die vragen moet beantwoorden over jouw organisatie is dat een serieus probleem. Het model gokt, of erger, het verzint een antwoord dat overtuigend klinkt maar feitelijk onjuist is.

RAG lost dit op door het taalmodel te koppelen aan een actuele, doorzoekbare kennisbank van je eigen data: databases, documenten, foto’s, contracten, e-mails en handgeschreven teksten. Stelt een gebruiker een vraag, dan wordt eerst de relevante informatie uit die kennisbank opgehaald via vectorzoekopdrachten. Die context gaat vervolgens samen met de oorspronkelijke vraag naar het taalmodel.

Je hoeft hiervoor het onderliggende model niet te hertrainen, iets wat kostbaar en tijdrovend is. De kennisbank werk je continu en tegen lage kosten bij, waardoor de AI altijd met de meest recente informatie werkt.

Waarom RAG het verschil maakt voor klantenservice en kennisdeling

Denk aan een klantenservice-chatbot die precies weet welk contract een klant heeft, wat de status van een lopende order is en wat er in het laatste supportgesprek is besproken. Of een interne kennisassistent die medewerkers direct het juiste antwoord geeft uit beleidsdocumenten, in plaats van dat ze zelf door tientallen PDF’s moeten zoeken.

Dat is de belofte van RAG: AI die niet slim klinkt, maar klopt. Met bronvermelding erbij, zodat fouten snel te herleiden en te corrigeren zijn.

Autorisatie bij RAG: wie mag welke informatie zien?

Een vraag die bij vrijwel elk RAG-traject binnen een paar weken op tafel komt: wie mag welke informatie terugkrijgen? Een kennisbank die alle documenten van de organisatie bevat, is razendsnel opgebouwd. Maar een medewerker van de servicedesk hoort geen salarisgegevens of overnamedocumenten terug te krijgen, ook niet als hij er handig naar vraagt.

Autorisatie hoort daarom niet achteraf op de chatbot geplakt te worden, maar ingebouwd te zitten in de ophaalstap zelf. Alleen documenten waar de gebruiker recht op heeft, komen in de context terecht. Juist dit stuk onderschatten organisaties bij een eerste proof of concept, en juist hier komt jarenlange ervaring met databasebeveiliging en governance van pas.

RAG implementeren met Oracle 23ai en 26ai

Als grootste onafhankelijke Oracle-specialist van Nederland, met daarnaast een sterk Microsoft– en Power BI-partnerschap, zien wij RAG niet los van de rest van ons vakgebied. Het bouwt voort op waar we al decennialang goed in zijn: het structureren en ontsluiten van bedrijfskritische data. RAG is voor ons geen nieuwe discipline, maar een volgende zet in een spel dat we goed kennen.

Binnen onze Data, Analytics & AI-unit vertalen we RAG-technologie naar concrete oplossingen, onder meer op basis van Oracle Database 23ai en het nieuwere 26ai. Daarin zijn vectoropslag en vectorzoekfunctionaliteit (AI Vector Search) native geïntegreerd in de database. Dat scheelt: organisaties die al op Oracle draaien, hoeven geen aparte vectordatabase naast hun bestaande platform op te tuigen. De kennisbank, de governance en de beveiliging blijven op dezelfde vertrouwde infrastructuur staan.

We begeleiden klanten daarbij niet alleen op de technologie, maar door het hele traject: van het structureren van ongestructureerde data, via het opzetten van een betrouwbare kennisbank, tot een productieklare toepassing die medewerkers en klanten echt beter bedient.

Van geordende data naar bruikbare AI

RAG is een middel, geen doel. En het is geen wondermiddel dat je zomaar over je kennisbank heen legt. Het vraagt om een doordachte aanpak van datamodellering, kwaliteitscontrole en een proces om onjuiste of verouderde informatie weer uit de kennisbank te halen. Daar ligt onze meerwaarde. We combineren diepgaande Oracle-databasekennis met AI-expertise, zodat RAG-implementaties niet blijven steken in een proof of concept maar waarde toevoegen in productie.

Benieuwd wat RAG voor jouw organisatie kan betekenen? In een gesprek van een uur kijken we samen naar je huidige data-landschap en welke toepassing de meeste waarde oplevert. Neem contact met mij op, Jonathan van Vianen 0345 616 888.

Lees meer over Agentic RAG

 

CB kiest voor Oracle Exadata Cloud@Customer

CB (voorheen Centraal Boekhuis) vervult een centrale rol in de logistiek en distributie van boeken in Nederland, België en steeds vaker daarbuiten. De IT‑omgeving ondersteunt bedrijfskritische processen die direct impact hebben op de dagelijkse operatie. Tegelijk stond CB voor een herkenbaar moment: de bestaande Exadata‑omgeving is aan vervanging toe, terwijl een traditionele vervanging opnieuw zou leiden tot een forse investering in capaciteit die vooraf moet worden bepaald, terwijl het daadwerkelijke gebruik blijft variëren.

CB heeft daarom bewust niet gekozen voor een één op één vervanging of een volledige overstap naar de Oracle public cloud, maar voor een model dat beter past bij hoe de organisatie zich ontwikkelt. Samen met Transfer Solutions gaat CB een Oracle Exadata Cloud@Customer omgeving inrichten en migreren. Daarmee combineert CB de voordelen van de cloud met de zekerheid en regie van een eigen, on‑premise omgeving.

De keuze: opnieuw investeren of anders sturen op gebruik

De afweging die hier speelt, zien we bij veel organisaties terug. Het vervangen van infrastructuur is zelden alleen een technische beslissing, maar vooral een moment waarop zichtbaar wordt of het bestaande model nog logisch is.

In een traditionele situatie wordt capaciteit vooraf bepaald en voor meerdere jaren vastgelegd. Dat biedt zekerheid, maar maakt het tegelijkertijd lastig om in te spelen op veranderingen in gebruik. Tegelijkertijd is een volledige overstap naar de public cloud niet altijd passend, met name vanwege de manier waarop kosten zich ontwikkelen en afhankelijkheden ontstaan.

Daarmee verschuift de vraag van technologie naar regie: hoe flexibel wil je omgaan met capaciteit en kosten?

Een financieel model dat meebeweegt met gebruik

Voor CB was dit een doorslaggevende reden om voor Cloud@Customer te kiezen. De oplossing maakt een duidelijk onderscheid tussen infrastructuur en gebruik.

De hardware wordt afgenomen tegen een vast bedrag, vergelijkbaar met een leaseconstructie. Daarmee blijven de kosten voorspelbaar en wordt een nieuwe grote investering voorkomen. De softwarelaag, waaronder databases en compute capaciteit, wordt niet vooraf als licentie ingekocht, maar flexibel gebruikt en afgerekend op basis van daadwerkelijk gebruik.

In de praktijk betekent dit dat een omgeving met bijvoorbeeld grote aantallen databases periodiek kan worden opgeschaald en afgeschaald, waarbij alleen wordt betaald voor het deel dat op dat moment in gebruik is. Dat wijkt fundamenteel af van traditionele licentiemodellen, waarbij capaciteit vooraf wordt ingekocht en kosten blijven doorlopen, ook als het gebruik afneemt.

Juist deze flexibiliteit maakt het model financieel interessant. Niet alleen bij de vervanging zelf, maar vooral in de jaren daarna, waarin gebruik verandert en de rol van Oracle binnen de organisatie kan meebewegen. Daarmee ontstaat ruimte om kosten actief te sturen in plaats van ze vooraf vast te zetten.

“We stonden voor de vervanging van onze bestaande Exadata‑omgeving, waarbij opnieuw investeren in capaciteit niet meer vanzelfsprekend was. Met Cloud@Customer behouden we de functionaliteit en performance die we nodig hebben, terwijl we de infrastructuur anders kunnen afnemen. Door een vast bedrag voor de hardware te combineren met een flexibel gebruik van databasecapaciteit, kunnen we beter sturen op zowel gebruik als kosten. Tegelijkertijd houden we onze data lokaal en onder eigen regie. Dat maakt deze aanpak voor ons een logische volgende stap.”
Marco Klooster, Manager IT Operations CB

Passend binnen een bredere IT‑ontwikkeling

De keuze voor Cloud@Customer past binnen een bredere ontwikkeling van CB richting een flexibeler IT‑landschap en een hybride‑cloud situatie, waarin ook andere platformen een rol spelen. In zo’n context is het belangrijk dat infrastructuur niet vastzet, maar juist meebeweegt met veranderingen in applicaties en platformkeuzes.

Door capaciteit te kunnen afbouwen zonder dat kosten op het oorspronkelijke niveau blijven, ontstaat ruimte om deze ontwikkeling gefaseerd en beheerst vorm te geven.

Inrichting en migratie door Transfer Solutions

Binnen dit traject verzorgt Transfer Solutions het ontwerp, de inrichting en de migratie naar de nieuwe Cloud@Customer‑omgeving. De uitvoering van het project start in de komende periode.

Daarbij ligt de nadruk op een overgang die niet alleen technisch klopt, maar ook aansluit op het gekozen model. Vanaf de start wordt gekeken naar de inzet van capaciteit, de inrichting van omgevingen en de manier waarop wordt voorkomen dat oude licentie‑denkwijzen worden voortgezet in een nieuwe omgeving.

Relevant voor organisaties die nu dezelfde stap overwegen

De situatie bij CB is herkenbaar voor organisaties waarvan de infrastructuur aan vervanging toe is, terwijl het bestaande investeringsmodel steeds minder goed aansluit op de praktijk. In dat soort situaties verschuift de discussie al snel van technologie naar flexibiliteit, kosten en regie.

De keuze voor Cloud@Customer laat zien dat er een alternatief is waarbij infrastructuur wordt gemoderniseerd, terwijl tegelijkertijd ruimte ontstaat om capaciteit en kosten mee te laten bewegen met de ontwikkeling van de organisatie.

Niet iedere organisatie heeft de schaal en rekenkracht van Exadata nodig. Met Base Database Cloud@Customer brengt Oracle het Cloud@Customer-model ook naar kleinere en middelgrote workloads. Zo kunnen ook deze organisaties hun data lokaal houden en capaciteit flexibel afnemen. Lees meer over Base Database Cloud@Customer voor kleinere, lokale omgevingen.

Benieuwd hoe Cloud@Customer zich verhoudt tot andere opties? Bekijk de vijf keuzes voor je Oracle-database.

Ook toe aan vervanging van je Exadata omgeving?

Een vervangingsmoment is een goed moment om opnieuw te kijken naar capaciteit, kosten, compliance en governance. We brengen graag in kaart welk model technisch en financieel bij jouw organisatie past.

 

Bespreek je situatie

Data in de wielersport

In de wielersport telt elke seconde. Achter al die seconden zit een grote hoeveelheid data. Als technologiesponsor van Soudal Quick-Step helpt Transfer Solutions om ruwe data om te zetten in waardevolle inzichten.

Inzichten die prestaties ondersteunen

Data krijgt pas waarde als je er de juiste informatie uit kunt halen. Door gegevens overzichtelijk en bruikbaar te maken, ontstaan inzichten die helpen om betere keuzes te maken en prestaties gericht te verbeteren.

In onderstaande video zie je in 27 seconden waar de samenwerking tussen Transfer Solutions en Soudal Quick-Step om draait: insights that drive performance.

 

Van sportdata naar inzicht

Wat binnen de wielersport geldt, geldt ook voor organisaties. Veel organisaties beschikken over grote hoeveelheden data, maar benutten deze nog niet optimaal. Gegevens staan verspreid over verschillende systemen, rapportages sluiten niet goed aan op de informatiebehoefte of medewerkers zijn afhankelijk van IT om inzichten te verkrijgen.

Transfer Solutions helpt organisaties om data toegankelijk, betrouwbaar en bruikbaar te maken. Van datastrategie en datakwaliteit tot dashboards, Business Intelligence en slimme toepassingen met AI. Daarbij kijken we niet alleen naar de techniek, maar ook naar de mensen, processen en doelen van de organisatie.

Zo verandert data van een verzameling gegevens in informatie waarmee je sneller kunt sturen en betere beslissingen kunt nemen.

Haal meer waarde uit je data

Wil je weten hoe jouw organisatie meer waarde uit data kan halen? Lees meer over onze oplossingen voor data analytics. Want of het nu gaat om topsport of bedrijfsvoering, betere inzichten helpen je om beter te presteren.

 

Als Solution Engineer Middleware ben je verantwoordelijk voor het ontwerpen, implementeren, beheren en waarborgen van een betrouwbare en veilige IT-infrastructuur voor onze klanten. Je fungeert als technisch expert op het gebied van middleware-technologieën en adviseert klanten over de beste oplossingen. Je werkt nauw samen met ontwikkelaars en infrastructuurteams om innovatieve oplossingen te realiseren die aansluiten bij de wensen van de klant.

Bij Transfer Managed Services werk je aan IT-oplossingen met echte impact. Of je nu databases optimaliseert of middleware beheert: jouw werk houdt organisaties in vitale sectoren draaiende, van bloedvoorziening en transport tot productie en financiën. Als Solution Engineer ben je een onmisbare schakel in de digitale infrastructuur van Nederland.

Kerntaken en verantwoordelijkheden

• Ontwerpen en implementeren van middleware-oplossingen (on-premise en cloud).
• Beheren en optimaliseren van middleware-architecturen.
• Waarborgen van prestaties, stabiliteit, schaalbaarheid, beveiliging en kostenbeheersing.
• Adviseren van klanten over middleware-technologieën en infrastructuurvraagstukken.
• Samenwerken met ontwikkelteams en infrastructuurspecialisten.
• Monitoren en verbeteren van middlewareoplossingen.

Vereiste kwalificaties

• HBO of WO werk- en denkniveau, bij voorkeur een opleiding in Informatica of vergelijkbaar.
• Certificeringen zoals Oracle Cloud (OCI) zijn een pré.

• Minimaal 3 jaar ervaring met Oracle Cloud Infrastructure, Oracle Fusion Middleware en Apache is een must, ervaring met Azure, Amazons Cloud (AWS), loadbalancers, Ansible, Terraform, LDAP-structuren is een pré.

Gewenste competenties

• Communicatief sterk en klantgericht.
• Analytisch en probleemoplossend vermogen.
• Stressbestendig en zelfstandig.
• Proactieve houding en teamspeler.
• Flexibel en energiek: je houdt van afwisseling en schakelt moeiteloos tussen verschillende klanten, systemen en uitdagingen.

Locatie & Werkomgeving

• Standplaats: Leerdam.
• Je werkt grotendeels remote en ondersteunt meer dan 120 klanten uit diverse sectoren.

Wat wij jou bieden:

Bij ons draait jouw rol niet alleen om techniek, maar ook om ontwikkeling, samenwerking en maatschappelijke impact.

• Vrijheid & ondersteuning: Jij kiest hoe je werkt, met deskundige begeleiding op de achtergrond
• Groei & ontwikkeling: Trainingen, coaching en toegang tot ons Transfer Opleidingscentrum
• Zorg voor elkaar: Ondersteuning bij professionele én persoonlijke uitdagingen
• Erkenning & succes: We waarderen jouw bijdrage en vieren resultaten samen
• Impactvol & duurzaam werk:  Je bouwt aan systemen die essentieel zijn voor een veerkrachtige samenleving

 

Stuur je CV en motivatie naar august.de.vries@transfer-solutions.com.

Heb je nog niet alle ervaring, maar wel de passie? Geen probleem! We bieden een uitgebreid opleidingsprogramma en coachingstrajecten en gaan graag met jou in gesprek.

Heb je vragen of wil je meer informatie over deze vacature neem dan contact op met August de Vries via telefoonnummer 0345 616 888

How to Model Supertypes and Subtypes in OutSystems

Without Creating a Monster Entity

The other day I was looking at a data model with several types of customers.

All customers had a name, an email address and a registration date. Private customers also had a date of birth and an emergency contact. Business customers had a company name, a Chamber of Commerce number and several contact persons.

So, how do you model this in OutSystems?

The easiest solution is to create one large Customer entity with every possible attribute. Add a CustomerTypeId, make most attributes optional and you are done.

Simple, right?

It is. Until a few months later, when the entity contains thirty attributes, half of them are empty and nobody remembers whether an empty CompanyName is allowed or just forgotten.

Let’s look at the different options and see when a supertype-subtype model is a better choice.

The examples and screenshots in this article use OutSystems 11 and Service Studio. The same modeling principles can also be used in ODC, although some names and implementation details may be different.

What Are Supertypes and Subtypes?

A supertype contains the information that is shared by several related types.

A subtype contains the information that only belongs to one specific type.

For our example, we use a sports club application. The application has private and business customers.

The shared customer attributes are shown in the sketch below. The application also has two subtypes:

1. PrivateCustomer
2. BusinessCustomer

Press enter or click to view image in full size

A private customer is a customer. A business customer is also a customer.

That “is a” sentence is a simple way to recognize a subtype.

A contact person is not a business customer. A business customer has contact persons. That is a relationship, not a subtype. We will come back to this later.

Option 1: One Customer Entity

Use one Customer entity with a CustomerTypeId when the customer types are mostly alike. Shared and type-specific attributes then stay together in one record.

How the Model Works

Press enter or click to view image in full size

The Customer entity contains attributes shared by all customers and attributes that apply to only one type. CustomerTypeId must be mandatory and reference a valid static entity record such as Private or Business, because it determines which rules apply.

This approach is often called single-table inheritance. OutSystems does not have real entity inheritance, but a type attribute provides a simple practical equivalent.

When It Works Well

This model is a strong fit when the differences between customer types are small and their processes are largely the same.

For example, if a business customer only needs a company name and a Chamber of Commerce number, creating several entities may add more complexity than value.

It also keeps Aggregates and integrations simple: every customer is in the same table, so a list of all customers does not need joins.

For simple situations in OutSystems, this is often the most practical model.

Trade-offs and Validation

The trade-off is that attributes that apply only to one customer type must remain optional.

A private customer does not have a Chamber of Commerce number, and a company normally does not have a date of birth. The application must therefore validate attributes based on CustomerTypeId.

For example, in pseudocode:

If Customer.CustomerTypeId = Entities.CustomerType.Business
 Customer.CompanyName is mandatory
 Customer.ChamberOfCommerceNumber is mandatory

These rules may be needed in screens, REST APIs, imports and Server Actions. In screens, validate early for helpful feedback, but do not make the screen the only safeguard.

Use custom create and update wrapper Server Actions as the server-side safeguard. Each wrapper validates the complete Customer input and then calls the generated Entity Action.

Every write path, including screens, REST APIs, imports and other Server Actions, must use these wrappers. Otherwise, screen validation can be bypassed and duplicate rules will eventually drift apart.

Fit Checklist

• Few types. There are only a few customer types
• Mostly shared data. Most attributes are shared
• Limited type-specific data. Each type has only a few specific attributes
• Mostly shared processes. The customer types use mostly the same processes

Option 2: Separate Subtype Entities

Use separate subtype entities when customer types share a common identity but differ substantially in attributes or processes.

How the Model Works

Keep the shared attributes in Customer and place the type-specific attributes in PrivateCustomer and BusinessCustomer. Each subtype is linked to the same Customer record.

Press enter or click to view image in full size

Enforcing At Most One Record per Subtype

Customer 1 ─── 0..1 PrivateCustomer
Customer 1 ─── 0..1 BusinessCustomer

This is the relationship we want, but it is not automatically enforced just by adding a normal CustomerId reference.

If the subtype has its own identifier, a normal CustomerId reference creates a one-to-many relationship. OutSystems will not stop you from creating two PrivateCustomer records for the same customer.

To enforce at most one record per customer within each subtype entity, you can:

1. Use CustomerId as the identifier of the subtype.
2. Give the subtype its own identifier and create a unique index on CustomerId.

I prefer the first solution when the subtype cannot exist without the customer. The subtype then uses the same identifier as its parent, which prevents duplicate rows in that subtype entity but does not require a subtype record to exist.

Choose the Delete Rule on the subtype’s Customer reference deliberately. Use Delete when the subtype should be removed automatically with its Customer, or use Protect when a lifecycle action must handle the dependent record before the Customer can be deleted. Avoid Ignore, because it can leave an orphaned subtype record.

I also made an Umbrella Talks video about one-to-one relationships in OutSystems. If you want some more background on how this works, you can watch it here: Umbrella Talks — One-to-One Relationships.

Press enter or click to view image in full size

Make this decision before you publish the entity for the first time. Changing the identifier later is not easy and may require creating a new entity and migrating the existing data. That is a lot of work for something that originally took one right-click.

Validation and Lifecycle Actions

Suppose customer 42 is a private customer. We do not want this:

Customer 42
 ├── PrivateCustomer 107
 └── PrivateCustomer 284

Using CustomerId as the subtype identifier prevents this. An identifier is unique, so there can only be one PrivateCustomer record for customer 42.

But there is another rule. In our sports club, a customer is either private or business. A customer cannot be both.

The identifier prevents two records in the same subtype entity. It does not prevent the same customer from having a record in both PrivateCustomer and BusinessCustomer.

The database does not compare both subtype entities, so we need application logic for this.

I would create Server Actions such as:

1. CreatePrivateCustomer
2. CreateBusinessCustomer
3. ChangeCustomerType

CreatePrivateCustomer and CreateBusinessCustomer create or update the Customer and the matching subtype together. Before creating a subtype, they check whether the other subtype already exists.

ChangeCustomerType removes or archives the old subtype, creates the new subtype and updates CustomerTypeId in the same transaction. If any step fails, the transaction must roll back.

Screens, imports and integrations should all use these actions. Do not let each screen create the records in its own way. That usually works well until the second screen is added.

Keeping CustomerTypeId in Sync

When using subtype entities, the customer type can be found by looking at the subtype record.

If a customer exists in PrivateCustomer, it is private. If it exists in BusinessCustomer, it is business.

This means that CustomerTypeId is not always needed.

But storing it can make Aggregates, reports and integrations easier. You can filter by customer type without joining both subtype entities.

Both options are valid:

1. Determine the type from the subtype record.
2. Store CustomerTypeId and update it atomically with the subtype in the central lifecycle actions.

I normally store the type when it is used a lot in filters or integrations. But then all updates must use the same logic. Otherwise, CustomerTypeId may say Private while only a BusinessCustomer record exists.

The database will accept this. The developer investigating the problem on Friday afternoon probably will not.

Contacts: Subtype or Related Entity?

Now it gets a little more interesting.

A private customer can have one emergency contact. A business customer can have several contact persons, such as a manager, administrator and financial contact.

You may be tempted to model these contacts as more subtypes. But a business customer is not a contact person. A business customer has contact persons.

That makes ContactPerson a related entity.

The relationship is:

BusinessCustomer 1 ─── 0..* ContactPerson

Press enter or click to view image in full size

A business customer still has one BusinessCustomer subtype record. That subtype can have several contact persons.

The emergency contact can remain directly on PrivateCustomer, because only one is allowed.

Customer
 ├── PrivateCustomer
 │      └── One emergency contact
 │
 └── BusinessCustomer
 └── Multiple ContactPerson records

The important difference is:

A subtype describes what something is. A related entity describes what something has.

If something can occur several times for the same parent, it is probably not a subtype.

What If Both Are Just Contacts?

You could also create one ContactPerson entity with a reference to Customer.

Customer 1 ─── 0..* ContactPerson

A business customer may have several contacts, while a private customer may only have one.

In that model, the custom contact wrapper Server Action must enforce a maximum of one contact for private customers. For example, in pseudocode:

If Customer.CustomerTypeId = Entities.CustomerType.Private
 and a ContactPerson already exists
 Do not create another contact

This is a good solution when both contact types have the same attributes and behavior.

If an emergency contact and a business contact have a different meaning or lifecycle, I would keep them separate. Having a name and a phone number does not automatically make them the same business concept.

Fit Checklist

• Shared identity. The types share one Customer identity and are managed as parts of the same customer lifecycle.
• Substantial differences. Each type has enough type-specific attributes or processes to justify a separate subtype entity.
• Dependent existence. A subtype cannot exist without its Customer.
• Single occurrence. Each subtype can occur at most once per Customer; repeating information belongs in a related entity.

Option 3: Separate Customer Entities

Use separate customer entities only when the customer types do not share the same business identity or lifecycle.

How the Model Works

PrivateCustomer and BusinessCustomer are independent entities. Each contains its own copy of Name, EmailAddress, PhoneNumber, RegistrationDate and IsActive.

Press enter or click to view image in full size

When It Works Well

This can work when both customer types are almost completely independent, for example when they are used in different applications and never appear in the same processes. For our sports club, it is not a good fit.

Trade-offs

Common attributes and validations are duplicated. Searching all customers requires combining data from two entities, integrations must support two customer structures, and every new shared attribute must be added to both entities.

Fit Checklist

• Independent identity. The customer types do not share the same business identity or lifecycle.
• Acceptable duplication. Duplicating shared data and validation is acceptable.

Which Solution Should You Choose?

Use the decision tree below for the detailed choice.

Press enter or click to view image in full size

The table below provides the same choice as a quick reference.

For our sports club, I would use:

• Model. Use Customer as the supertype and PrivateCustomer and BusinessCustomer as optional one-to-one subtype extensions, each keyed by CustomerId.

• Lifecycle. Manage the complete customer through central Server Actions.

• Contacts. Store the single emergency contact on PrivateCustomer and use ContactPerson for the business customer’s repeatable contacts.

Wrapping Up

Start with identity and lifecycle, then compare the type-specific data and behavior. If information can occur more than once for the same parent, model it as a related entity rather than a subtype.

Choose the simplest model that represents those rules clearly and that another developer can understand by looking at it.

Preferably without first having to read twenty pages of documentation.

 

Working with Mentor in ODC: Lessons from Practice

Mentor Studio and Mentor Web have been generally available in ODC since April 2026 and is becoming an increasingly useful useful AI-assisted development tool within the ODC development experience. This article focuses specifically on Mentor Studio or also called Mentor in the IDE, (the popup or side panel inside ODC Studio, as shown in the screendump below).

Mentor is already capable of creating and modifying significant parts of an application, but getting good results requires understanding how it works and how to communicate the desired outcome clearly.

This blog is based on my practical experience using it for ODC development.

Use Mentor for patterns and repetitive work

One of the areas where Mentor is particularly effective is creating common OutSystems patterns quickly. Static entities, popup Web Blocks, lists, and screens looking like on existing screens can be created in a fraction of the time it would take to build everything from scratch.

Another useful scenario is resolving large numbers of errors after a structural change. For example, changing an entity can result in more than 100 errors across an application. Having Mentor analyse and resolve these errors can save considerable manual effort.

The important point is that Mentor is not necessarily about doing something that a developer cannot do. Its value is often in accelerating work that the developer already knows how to perform.

Good prompting makes a difference

The quality of the result depends strongly on the quality of the instruction. When modifying an existing screen, I find it useful to structure the prompt by first identifying the screen, block, panel or container, followed by what is currently working and finally what should change.

I also recommend always asking Mentor for a plan first. This makes it possible to review the proposed approach before changes are made and provides an opportunity to correct any misunderstanding of the requirement.

Gebruikers willen een extra scherm, een rapportage moet worden aangepast, er is een nieuwe koppeling nodig of een technische verbetering blijft liggen. Ieder verzoek afzonderlijk lijkt overzichtelijk. Maar ondertussen groeit de lijst sneller dan het ontwikkelteam hem kan wegwerken.

In gesprekken met klanten hoor ik vaak hetzelfde. De applicatie draait, de dagelijkse operatie gaat door en daardoor voelt de backlog niet direct als een groot risico. Totdat wijzigingen steeds langer duren, tijdelijke oplossingen ontstaan en belangrijke kennis bij één of twee mensen blijkt te zitten.

Een applicatie blijft veranderen

Een applicatie die intensief wordt gebruikt, is eigenlijk nooit af. Processen veranderen, wetgeving wordt aangepast, gebruikers stellen andere eisen en systemen moeten steeds meer informatie met elkaar uitwisselen.

Dat geldt zeker voor applicaties die met Oracle APEX zijn gebouwd. APEX maakt het mogelijk om snel nieuwe functionaliteit te ontwikkelen. Maar daarvoor moet er natuurlijk wel voldoende tijd en kennis beschikbaar zijn.

In de praktijk krijgt de dagelijkse operatie bijna altijd voorrang. Incidenten moeten worden opgelost, gebruikers hebben vragen en nieuwe projecten vragen aandacht. Werk dat belangrijk is, maar niet direct urgent voelt, schuift door naar de volgende planning.

En daarna vaak nog een keer.

De applicatie draait, maar de ontwikkeling staat stil

Zolang de applicatie blijft functioneren, lijkt uitstel beheersbaar. Toch worden de gevolgen langzaam zichtbaar.

Handmatige tussenstappen blijven bestaan. Gebruikers houden eigen lijstjes bij in Excel. Schermen sluiten niet meer goed aan op het proces en koppelingen vragen steeds meer onderhoud. Ondertussen loopt ook de technische schuld op.

Het grootste risico is meestal niet dat de applicatie morgen uitvalt. Het risico is dat de ruimte om te veranderen steeds kleiner wordt. Iedere volgende aanpassing vraagt meer voorbereiding, omdat documentatie niet meer actueel is of omdat de benodigde kennis bij een beperkt aantal mensen zit.

Op een gegeven moment kost een kleine wijziging daardoor opvallend veel tijd. Dat is meestal het moment waarop een capaciteitsprobleem langzaam een continuïteitsprobleem wordt.

Vijf signalen dat extra APEX capaciteit zinvol is

Herken je een of meer van deze situaties?

1. Dezelfde wijzigingen schuiven meerdere planningsrondes door
2. Eén ontwikkelaar kent het grootste deel van de applicatie
3. Technisch onderhoud concurreert voortdurend met nieuwe functionaliteit
4. Gebruikers maken tijdelijke oplossingen buiten de applicatie
5. Een upgrade, integratie of moderniseringsstap heeft geen duidelijke eigenaar

Eén signaal hoeft niet direct een probleem te zijn. Maar als meerdere situaties tegelijk spelen, is het verstandig om te bepalen wat echt moet bewegen en welke kennis of capaciteit daarvoor ontbreekt.

Klein beginnen kan

Bij een groeiende backlog gaat het gesprek soms direct over volledige vervanging of een groot moderniseringstraject. Dat kan nodig zijn, maar lang niet altijd.

Vaak is het verstandiger om eerst een duidelijk onderdeel van de backlog op te pakken. Bijvoorbeeld een koppeling die al maanden wacht, een serie gebruiksverbeteringen of technisch onderhoud dat telkens wordt doorgeschoven.

Een ervaren APEX developer kan tijdelijk aansluiten op het bestaande team. Een andere mogelijkheid is een backlog sprint, waarin een afgebakend pakket aan werkzaamheden wordt geanalyseerd, gebouwd, getest en overgedragen.

Voor een groter onderdeel kan een klein deliveryteam worden ingezet. Op onze pagina over het inhuren van een APEX developer lees je welke inzetvormen mogelijk zijn.

Het doel is niet om zomaar extra mensen toe te voegen. Het doel is om gericht werk af te ronden en het bestaande team weer ruimte te geven.

Tijdelijke versterking

Extra capaciteit werkt het beste wanneer er duidelijke prioriteiten zijn en de developer toegang krijgt tot de juiste functionele en technische kennis.

De externe developer hoeft de applicatie niet volledig over te nemen. Juist de samenwerking met het interne team is belangrijk. Het bestaande team kent de organisatie, de gebruikers en de historie. De externe specialist brengt extra capaciteit, ervaring en soms precies de technische kennis die op dat moment ontbreekt.

De werkzaamheden kunnen uiteenlopen van nieuwe functionaliteit, SQL en PL/SQL, JavaScript en REST integraties tot upgrades, security, performance en technische optimalisatie.

Ook bij oudere APEX applicaties of Oracle Forms omgevingen kan een kleine eerste stap veel duidelijkheid geven. Lees hierover ook onze praktijkervaring met het moderniseren van Oracle Forms.

Wanneer extra capaciteit niet genoeg is

Tijdens het wegwerken van werkzaamheden kan blijken dat het probleem dieper zit. De applicatie is complex geworden, technische risico’s lopen op of de beveiliging voldoet niet meer aan de huidige eisen. Alleen extra capaciteit toevoegen is dan niet voldoende.

Met Re-platform Move & Improve zetten we onze AI Factory in om de bestaande applicatie te doorgronden én te moderniseren, bijvoorbeeld naar Oracle APEX. AI versnelt het analyse- en ontwikkelwerk, waardoor moderniseren sneller, eenvoudiger en goedkoper wordt. Onze professionals bewaken de architectuur, security en bedrijfslogica en controleren of de nieuwe applicatie doet wat hij moet doen.

Kennis borgen

Tijdelijke capaciteit heeft pas blijvende waarde als de opgedane kennis binnen de organisatie blijft.

Daarom horen documentatie, werken volgens bestaande ontwikkelstandaarden en actieve kennisoverdracht bij de opdracht. Het interne team moet na afloop begrijpen wat er is aangepast en zelfs verder kunnen.

Dat voorkomt dat tijdelijke ondersteuning een nieuwe afhankelijkheid creëert.

Begin

Je hoeft niet eerst de hele backlog opnieuw uit te werken. Begin met de werkzaamheden die al te lang blijven liggen en stel drie vragen:

1. Waarom wordt dit werk steeds doorgeschoven?
2. Welke kennis of capaciteit ontbreekt?
3. Wat moet er concreet zijn opgeleverd om weer verder te kunnen?

De antwoorden maken meestal snel duidelijk of één APEX developer, een korte backlog sprint of een deliveryteam het beste past.

Blijft er APEX werk liggen?

In een gesprek van 30 minuten kijken we welke werkzaamheden prioriteit hebben, welke expertise nodig is en welke vorm van extra slagkracht daarbij past.

APEX Developer inhuren

Loopt je Oracle APEX backlog op? Nieuwe functionaliteit wacht, technisch werk stapelt zich op en je eigen team heeft geen ruimte. Onze Oracle APEX developers sluiten tijdelijk aan op je team of pakken een afgebakend onderdeel zelfstandig op. Voor doorontwikkeling, onderhoud, integraties of een concrete moderniseringsstap.

Herken je dit?

• De backlog groeit sneller dan je team hem kan wegwerken
• Een belangrijke ontwikkelaar valt uit of is moeilijk te vervangen
• Nieuwe functionaliteit moet wachten op technisch onderhoud
• Een upgrade, integratie of securityverbetering blijft liggen
• Je wilt moderniseren, maar hebt nog geen ruimte voor een groot traject
• Je zoekt APEX kennis die verder gaat dan alleen het bouwen van schermen

Tijdelijk versterken, gericht resultaat

Je hoeft niet meteen een nieuw team op te bouwen om weer voortgang te krijgen. Onze APEX developers werken zelfstandig of sluiten aan op je bestaande ontwikkelteam. Samen bepalen we welk werk prioriteit heeft, welke kennis nodig is en welk resultaat je wilt bereiken.

De inzet kan draaien om extra capaciteit, specialistische expertise of een duidelijk pakket aan werkzaamheden. Zo houd je zelf de regie en ontstaat er snel weer beweging.

Wat we kunnen oppakken

• Doorontwikkeling van bestaande Oracle APEX applicaties
• Nieuwe functionaliteit en gebruiksvriendelijkere schermen
• SQL en PL/SQL ontwikkeling en optimalisatie
• JavaScript, REST koppelingen en integraties
• Technisch onderhoud, upgrades en kwaliteitsverbetering
• Securityreviews en het oplossen van Technical debt
• Modernisering van oudere APEX of Oracle Forms applicaties
• Testen, documentatie en kennisoverdracht
• Ondersteuning en coaching van je eigen ontwikkelteam

Kies de inzet die past

 Eén APEX developer 

Voor tijdelijke versterking van je bestaande team. De developer werkt mee binnen jullie planning, tooling, architectuur en ontwikkelstandaarden.

 APEX Backlog Sprint 

Voor een duidelijk afgebakend pakket aan verbeteringen. We bepalen samen de prioriteiten, voeren het werk uit en leveren de wijzigingen getest en overdraagbaar op.

 APEX Deliveryteam 

Voor organisaties die een groter onderdeel zelfstandig willen laten uitvoeren. We stellen een passend team samen voor analyse, ontwikkeling, testen en overdracht.

Zo starten we

1. Korte intake
   In een gesprek van ongeveer 30 minuten bespreken we de applicatie, de backlog en de expertise die nodig is
2. Voorstel voor de inzet
   Je krijgt een voorstel voor een developer, backlog sprint of deliveryteam, inclusief een duidelijke scope en aanpak
3. Aan de slag
   Onze specialisten sluiten aan op jullie werkwijze of voeren het afgesproken onderdeel zelfstandig uit
4. Overdracht en vervolg
   We documenteren wat is gedaan en dragen de kennis over. Daarna bepaal je zelf of verdere ondersteuning nodig is

APEX modernisering in de praktijk

Voor IVO Rechtspraak vernieuwde Transfer Solutions de voorkant van het bestaande systeem voor civiele rechtszaken. De oude Oracle Forms applicatie werd omgebouwd naar Oracle APEX, terwijl de achterliggende data behouden bleven. Het resultaat is een modernere, gebruiksvriendelijkere en beter aanpasbare applicatie.

Lees de case van IVO Rechtspraak

Meer dan alleen APEX

Een APEX applicatie staat zelden op zichzelf. Daarom kijken onze specialisten ook naar de Oracle Database, PL/SQL, koppelingen, infrastructuur, security en beheer. Dat voorkomt dat een snelle oplossing later een nieuw probleem veroorzaakt.

Transfer Solutions kan daarnaast helpen met Cloud migratie, architectuur, trainingen, modernisering en het structurele beheer van je omgeving.

Wil je een oudere applicatie breder aanpakken? Met Re-platform Move & Improve brengen we met behulp van AI eerst de werking, afhankelijkheden en technische risico’s in kaart. Daarna bepalen we welke moderniseringsroute past.

Misschien ligt er geen groot project, maar wel een wijziging die al maanden wacht. Ook dan kijken we graag mee. Een kleine inzet kan voldoende zijn om de backlog weer beheersbaar te maken of om te bepalen welke vervolgstap verstandig is.

Blijft er APEX werk liggen?

Vertel ons kort wat er speelt. In een gesprek van 30 minuten kijken we welke expertise en inzetvorm het beste past. Je zit nergens aan vast