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.

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

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

 

Met Base Database Cloud@Customer maakt Oracle hybride cloud en private AI eindelijk ook haalbaar voor afdelingen en organisaties die geen volledige Exadata nodig hebben.

Oracle heeft een nieuwe hybride clouddienst aangekondigd: Base Database Cloud@Customer. Het idee is niet nieuw, Oracle biedt met Exadata Cloud@Customer al langer een oplossing om databases en infrastructuur lokaal te draaien met cloudbeheer vanuit Oracle. Nieuw is dat er nu ook een instap komt die past bij kleinere en middelgrote workloads, zonder de rekenkracht en het volume van een Exadata omgeving.

De dienst draait op eigen Oracle hardware die bij de klant op locatie of in het datacenter staat. Oracle beheert de infrastructuur op de achtergrond, terwijl de organisatie zelf de regie houdt over databases, applicaties en AI agenten. Zowel Oracle AI Database 26ai tot Oracle Database 19c worden ondersteund, in alle edities.

Voor organisaties die door regelgeving, dataresidentie of koppelingen met lokale systemen niet naar de publieke cloud kunnen, is dit precies het soort tussenweg dat vaak ontbreekt.

Hoge beschikbaarheid, zonder overcapaciteit

Databases kunnen automatisch opschalen binnen één server, of verdeeld worden over twee servers voor hoge beschikbaarheid (HA) bij storingen of onderhoud. Daarbovenop zit ondersteuning voor Oracle Real Application Clusters en Data Guard, plus ‘usage-based’ facturatie. Organisaties betalen zo geen rekenkracht die ze niet gebruiken tijdens rustige periodes.

Private AI, dicht bij de data

Op dezelfde infrastructuur kunnen ook AI workloads draaien: AI Vector Search, een Private Agent Factory en een Private AI Services Container. Daarmee blijft gevoelige data achter de eigen firewall, terwijl de organisatie wel gebruik kan maken van AI agents en zoekfuncties. Oracle noemt zelf onder meer AI gestuurde kwaliteitscontrole in productieomgevingen als voorbeeld.

Wat dit betekent voor jouw organisatie

Of dit ook daadwerkelijk tot lagere kosten leidt, hangt af van het concrete verbruik en de benodigde opslag. Wat wel duidelijk is: Oracle maakt hybride cloud en lokale AI nu ook toegankelijk voor organisaties die tot nu toe net buiten de boot vielen van Exadata Cloud@Customer.

Bij Transfer Solutions zien we dagelijks hoe belangrijk dit is voor onze klanten. Herkenbaar? We denken graag met je mee over wat dit voor jouw omgeving kan betekenen.

Gebaseerd op berichtgeving van ITdaily, 23 juli 2026.

Benieuwd wat dit voor jouw organisatie betekent?

Plan een vrijblijvende Discovery Session van 30 minuten. Geen verkooppraatje, gewoon een goed gesprek over waar jij nu staat.
Vul het formulier hiernaast in, dan nemen wij snel contact met je op.

Tijdens ons jaarlijks KlantEvent 2026 The Data Express stonden twee thema’s centraal die op het eerste gezicht weinig met elkaar te maken hebben: AI en digitale soevereiniteit. Toch komen ze samen op een plek waar je het misschien niet meteen verwacht. Namelijk bij de systemen die je organisatie al jaren draaiende houden.

Soevereiniteit wordt vaak verengd tot de vraag waar je data staat en bij welke hyperscaler. Maar de kern ligt dieper. Het gaat om de vrijheid om te kiezen. Kun je je bedrijfskritische functies verplaatsen naar een ander platform als dat nodig is, om wat voor reden dan ook, of het nu gaat om kosten, privacy of strategie? Voor veel organisaties is het antwoord nee. Hun belangrijkste processen draaien op maatwerksystemen die zijn vastgegroeid aan één platform. Dat is geen vrijheid. Dat is afhankelijkheid.

Die afhankelijkheid heeft een prijs. Het beheer wordt steeds duurder, vaak zo duur dat het budget opgaat aan het draaiende houden van wat er is. Daardoor blijft er nauwelijks ruimte over voor vernieuwing. De kennis zit in de hoofden van mensen die met pensioen gaan, en de documentatie ontbreekt. Zo wordt een systeem langzaam een black box waar niemand meer aan durft te komen. Tegelijkertijd hangen kritische processen er volledig van af. En de business vraagt ondertussen om dingen die het oude platform simpelweg niet kan: mobiele toegang, moderne koppelingen, en juist die AI mogelijkheden waar iedereen het over heeft.

De oplossing heet re-platformen: je applicatie verhuizen naar een modern fundament. Het probleem was altijd dat dit traag en duur was. Ook merkte de business er op korte termijn weinig van. Dezelfde functie, alleen op een nieuwer platform. Dus werd het uitgesteld, jaar na jaar. Daardoor werd de drempel alleen maar hoger.

En precies hier raken de twee thema’s elkaar. Want AI verandert de rekensom. Wat vroeger een langdurig en kostbaar handmatig traject was, kan nu sneller, goedkoper en met beperkte inzet van je eigen mensen. Daarmee wordt soevereiniteit ineens haalbaar in plaats van een mooi voornemen. AI is niet alleen iets wat je op je nieuwe platform gaat gebruiken. Het is ook het gereedschap dat je er naartoe brengt.

Bij Transfer Solutions doen we dit met een bewezen aanpak. We combineren ervaren mensen met digitale ondersteuning, en bij elk re-platform project leren we bij. Die kennis nemen we weer mee naar het volgende project. Zelf doen kan natuurlijk ook. Maar dan bouw je kennis op die je daarna eigenlijk niet meer nodig hebt. Veel zinvoller is het om je energie te richten op de situatie ná het re-platformen: hoe je met AI, low-code en cloud native oplossingen je business sneller, beter en veiliger bedient. Daarom werken we met Voordoen, Meedoen en Zelfdoen, zodat de kennis die telt bij jou terechtkomt.

Om te laten zien wat er kan, bieden we een AI Re-platform Proof of Value aan. Gratis en geheel vrijblijvend. Je levert een stukje van je eigen applicatie aan, bijvoorbeeld één scherm of functie, en wij re-platformen dat met AI naar een modern platform: Oracle APEX, OutSystems of een open source stack. We brengen mee waar je vandaan komt, of dat nu Oracle Forms, Reports, een oudere APEX applicatie, .NET, Uniface of zelfs Cobol is. In twee afspraken, een korte intake en een demonstratie, laten we het werkende resultaat zien. Daarna bespreken we hoe een aanpak voor je hele landschap eruit kan zien.

Was je bij The Data Express, dan heb je het thema al voorbij zien komen. Was je er niet bij, dan is dit je kans om alsnog aan te haken.

Benieuwd wat AI met jouw systeem doet?

Neem contact op met je accountmanager of vul het formulier op deze pagina in, dan plannen we een vrijblijvende Discovery Session van 30 minuten

 

 

 

 

 

 

 

 

Wil jij AI niet alleen bedenken, maar ook echt ontwerpen, bouwen en duurzaam in productie brengen? Bij Transfer Solutions werk je aan AI-oplossingen die organisaties direct verder helpen. Geen losse experimenten, maar een samenhangende aanpak waarin strategie, architectuur, governance en techniek bij elkaar komen. Je helpt klanten bij het opzetten van een AI Factory, ontwikkelt concrete toepassingen met LLM’s en machine learning en zorgt dat oplossingen beheersbaar, veilig en uitlegbaar blijven. Samen met ervaren collega’s werk je aan projecten waar techniek, impact en samenwerking samenkomen.

Wat maakt deze vacature interessant?

Bij veel AI-vacatures ligt de nadruk op experimenteren. Bij ons ligt de nadruk op realiseren.

Je krijgt de ruimte om:

• AI-oplossingen van idee tot productie te brengen
• te werken aan concrete vraagstukken bij klanten
• direct impact te zien van wat je bouwt
• mee te denken over hoe AI organisaties écht verder helpt

Je werkt samen met ervaren collega’s die inhoudelijk sterk zijn, maar ook nuchter blijven. We houden van slimme oplossingen, zonder het ingewikkeld te maken.

Jouw rol als AI Consultant

Als AI Consultant beweeg je je op het snijvlak van technologie, processen en samenwerking.

De ene keer help je een organisatie bij het inrichten van een AI Factory: van use case-selectie en governance tot ontwikkelstraat, deployment en beheer. De andere keer ontwerp en bouw je zelf AI-functionaliteit in applicaties, zoals kennisassistenten, documentverwerking, voorspellingen, classificatiemodellen of RAG-oplossingen. Je adviseert niet alleen, je realiseert ook. Juist die combinatie maakt deze rol interessant: je schakelt tussen boardroom, architectuur en implementatie en ziet wat je maakt daadwerkelijk terug in gebruik.

Wat ga je doen?

Je helpt organisaties om AI concreet, beheersbaar en schaalbaar te maken. Daarbij werk je aan oplossingen die passen binnen bestaande systemen, processen en compliance-eisen.

Je:

• vertaalt AI use cases naar architectuur, oplossingsrichtingen en een realistische implementatieaanpak
• helpt klanten bij het opzetten van een AI Factory, inclusief intakeproces, prioritering, ontwikkelstandaarden, evaluatie en beheer
• ontwikkelt en integreert AI-functionaliteit in bestaande en nieuwe applicaties
• werkt met LLM’s, RAG, prompt orchestration, tool use en retrieval om betrouwbare assistenten en workflows te bouwen
• zet machine-learningoplossingen op voor classificatie, voorspellingen, aanbevelingen en patroonherkenning waar dat beter past dan een LLM
• richt governance in rond security, privacy, toegangsbeheer, logging, evaluatie, modelkeuze en verantwoord gebruik
• beoordeelt de AI-maturity van teams en organisaties en helpt deze stapsgewijs te verhogen
• werkt samen met ontwikkelaars, data engineers, architecten en productowners
• deelt actief kennis binnen het team en helpt standaarden opbouwen die herbruikbaar zijn over meerdere klanten en projecten

Voorbeelden van AI-oplossingen waar je aan werkt

Je werkt aan toepassingen die organisaties direct helpen en die technisch en organisatorisch houdbaar zijn:

• AI-assistenten op basis van interne kennis, documenten en bedrijfsprocessen, met retrieval, autorisatie en bronverwijzing
• RAG-oplossingen met vector search, metadatafiltering, chunking-strategie en evaluatie op relevantie en betrouwbaarheid
• slimme documentverwerking voor extractie, classificatie, samenvatting en routing van informatie
• machine-learningmodellen voor voorspellingen, anomaliedetectie, segmentatie of aanbevelingen
• AI-gedreven workflows waarin LLM’s, business rules en bestaande systemen samenkomen
• AI Factory-inrichtingen waarin intake, experiment, validatie, productiegang en beheer als geheel worden georganiseerd
• Dit zijn geen demo’s, maar oplossingen die aantoonbaar gebruikt worden in de praktijk en die passen binnen architectuur, governance en beheer.

Naast techniek kijk je ook naar de volwassenheid van de organisatie. Veel klanten hebben losse ideeën of pilots, maar missen nog een consistente manier van werken. Daarom help je met governance, bijvoorbeeld rond dataherkomst, privacy, security, modelselectie, evaluatiecriteria, monitoring en verantwoordelijkheden in beheer. Ook breng je AI-maturity in kaart: waar staat een organisatie nu, wat is nodig om verantwoord op te schalen en welke technische en organisatorische bouwstenen ontbreken nog?

Wat breng je mee?

Je hebt een stevige basis in softwareontwikkeling en kunt meedenken over architectuur en oplossingen.

Daarnaast

• maak je abstracte AI-ideeën concreet
• werk je gestructureerd en met oog voor kwaliteit en beheerbaarheid
• communiceer je helder met collega’s en klanten
• Je houdt jezelf voortdurend op de hoogte van nieuwe ontwikkelingen
• beheers je de Nederlandse taal goed

Technische richting (indicatief)

• ervaring met cloud- en AI-platformen zoals Azure AI, Azure OpenAI, OpenAI, Claude, Vertex AI, OCI of vergelijkbare diensten
• kennis van LLM’s en hun toepassingsverschillen, bijvoorbeeld op het gebied van contextvenster, latency, kosten, kwaliteit en inzetbaarheid per use case
• ervaring met RAG, embeddings, vector databases, search, reranking en retrievalstrategieën
• begrip van promptontwerp, structured output, tool calling, agents, evaluatie en guardrails
• ervaring met machine learning en data science, bijvoorbeeld voor classificatie, regressie, forecasting, clustering of aanbevelingsmodellen
• kennis van Python, SQL, notebooks, API’s en integratiepatronen voor het aansluiten van AI op bestaande applicaties en databronnen
• affiniteit met MLOps en LLMOps, zoals versiebeheer, modelregistratie, evaluatie, monitoring, logging en gecontroleerde uitrol
• begrip van security-by-design, identity, autorisatie, dataminimalisatie en privacyvraagstukken rond AI-toepassingen
• kennis van softwarearchitectuur en integratie, zodat AI geen los eiland wordt maar onderdeel van een werkende oplossing
• nieuwsgierigheid naar nieuwe modellen, frameworks en evaluatiemethoden, gecombineerd met het vermogen om hype en werkelijke waarde van elkaar te scheiden

Werken bij Transfer Solutions

Transfer Solutions is een onafhankelijke IT-dienstverlener met meer dan 30 jaar ervaring. We werken aan bedrijfskritische systemen en combineren technologie met praktische toepasbaarheid.

Wat je bij ons merkt:

• korte lijnen en een informele sfeer
• collega’s die kennis delen en elkaar verder helpen
• ruimte om jezelf te ontwikkelen
• focus op oplossingen die echt werken

Wat krijg je van ons?

Je krijgt een rol met veel vrijheid, inhoudelijke uitdaging en ruimte om te groeien.

Daarnaast

• arbeidsvoorwaarden op maat
• 28 vakantiedagen en een goede pensioenregeling
• leaseauto of mobiliteitsbudget
• Bonusregeling
• thuiswerkregeling en onkostenvergoeding
• opleidingen, certificeringen en kennissessies

Enthousiast?

Voldoe je niet aan alles, maar krijg je hier energie van? Dan maken we graag kennis met je.

We kijken vooral naar motivatie, nieuwsgierigheid en potentieel. Ontwikkeling vinden we belangrijk en we investeren actief in jouw groei. Neem contact op via 0345 616888 of mail naar solliciteren@transfer-solutions.com

Transfer Solutions verlengt de samenwerking met wielerteam Soudal Quick-Step. De samenwerking richt zich op data-integratie, analytics en performance optimalisatie binnen het team.

Als technologiepartner ondersteunt Transfer Solutions het team met een geïntegreerde dataomgeving waarin verschillende databronnen samenkomen, van trainings- en performance data tot wedstrijdinformatie. Met behulp van advanced analytics worden deze datasets vertaald naar inzichten waarmee renners, coaches en staf betere en snellere beslissingen kunnen nemen.

Wim De Wolf, trainer bij Soudal Quick-Step:
“Wij zijn blij dat we de samenwerking met Transfer Solutions verlengen. Hun expertise helpt ons om de data die we dagelijks genereren beter te begrijpen en optimaal te benutten. Daarmee blijven we ons als team ontwikkelen.”

Jonathan van Vianen, Business Manager Data & AI bij Transfer Solutions:
“Binnen deze samenwerking leveren we een robuuste en geïntegreerde data-architectuur waarin meerdere databronnen samenkomen. Door deze data te structureren en te verrijken met analytics, vertalen we complexe datasets naar concrete inzichten die coaches en renners ondersteunen in hun prestaties.”

De samenwerking onderstreept het belang van data en AI binnen topsport en laat zien hoe technologie direct kan bijdragen aan performance en strategische besluitvorming.

 

Jurgen Foré, CEO Soudal Quick-Step & René Hol, CCO Transfer Solutions