Van FileMaker naar de cloud: hoe SchallOS bedrijfssoftware combineert met AI, runtime en updates

Bij de ontwikkeling van een bedrijfsapplicatie staan in eerste instantie de zichtbare taken centraal. Er worden tabellen aangemaakt, relaties gedefinieerd, invoerformulieren ontworpen en bedrijfsprocessen geautomatiseerd. Zodra de eerste gebruikers met de oplossing aan de slag kunnen, lijkt een groot deel van het project voltooid te zijn. In de praktijk begint dan echter de fase die op de lange termijn veeleisender is. Een bedrijfsapplicatie moet worden onderhouden, uitgebreid en aangepast aan nieuwe eisen. Wijzigingen moeten worden gedocumenteerd, nieuwe versies moeten worden uitgerold en bestaande gegevens moeten veilig worden overgezet. Daarbij komen nog verschillende gebruikersrechten, back-ups, foutanalyses en de vraag of een oplossing lokaal, op een eigen server of in de cloud moet worden gehost.

Veel ontwikkelingsplatforms richten zich vooral op het bouwen van de eigenlijke applicatie. Voor updates, documentatie, implementatie en beheer worden later aanvullende tools en individuele procedures toegevoegd. Na verloop van tijd ontstaat er een technische omgeving die bestaat uit veel losstaande onderdelen, die alleen met aanzienlijke inspanning bij elkaar kunnen worden gehouden. SchallOS hanteert daarom een meer omvattende aanpak. Het platform moet een bedrijfsapplicatie niet alleen tijdens de ontwikkeling begeleiden, maar gedurende de gehele levenscyclus: van ontwikkeling en documentatie tot implementatie, updates en continu beheer.

Sociale kwesties van nu

Tandheelkundige gezondheid en CMD - meer dan een klein beetje. Wat heeft de toekomst in petto?

Tandheelkundige gezondheid en CMD - meer dan een klein beetje. Wat heeft de toekomst in petto?

Dieter Hallervorden - Meer dan Didi: Portret van een ongemakkelijke vrije geest

Dieter Hallervorden - Meer dan Didi: Portret van een ongemakkelijke vrije geest

Toen ik aan de telefoon was met een robot - hoe AI de telefoon verovert en hoe je het kunt herkennen

Toen ik aan de telefoon was met een robot - hoe AI de telefoon verovert en hoe je het kunt herkennen

Dieter Bohlen in klare taal: Waarom Duitsland faalt door zijn eigen bureaucratie

Dieter Bohlen in klare taal: Waarom Duitsland faalt door zijn eigen bureaucratie

Het laatste nieuws over SchallOS Studio

12.08.2026: De ontwikkeling van SchallOS vordert gestaag. Inmiddels is de AI- en kennislaag Het platform is grotendeels voltooid en diep geïntegreerd in de ontwikkelomgeving. SchallOS beschikt daarmee over een zelflerende kennislaag die ervaringen uit de praktijk van de ontwikkeling verwerkt en zich in de loop van de tijd kan aanpassen aan de programmeerstijl en de voorkeursoplossingen van de betreffende ontwikkelaar.

Via een open adaptersysteem kunnen willekeurige lokale en cloudgebaseerde AI-modellen integreren. Voor een aanbieder of een model kunnen daarbij ook meerdere toegangen of API-sleutels worden opgeslagen. Meerdere modellen kunnen parallel worden ingezet en op basis van hun mogelijkheden, snelheid en eerdere resultaten voor verschillende taken worden ingezet. De keuze van het model gebeurt daarbij automatisch door de geïntegreerde Composer – de ontwikkelaar hoeft zich tijdens de ontwikkeling geen zorgen te maken over welk model geschikt is voor welke taak. Reeds bekende en beproefde oplossingen kunnen uit de kennislaag worden hergebruikt, zodat niet elke taak opnieuw volledig door een AI-model hoeft te worden verwerkt.

Direct in SchallOS Studio beschikbaar gespecialiseerde AI-agenten voor verschillende ontwikkelingsopdrachten. Hiertoe behoort een Formule-agent voor berekeningen en formules, een Functiecontainer-agent voor het programmeren van functiecontainers en een Layout-agent voor het werken aan gebruikersinterfaces. Functiecontainers kunnen bovendien rechtstreeks via hun lay-outobjecten worden bewerkt en met behulp van AI worden geprogrammeerd. Een bovenliggende Systeemagent kan de gespecialiseerde agenten aansturen, bijvoorbeeld wanneer er volledig nieuwe modules of uitgebreidere functies moeten worden ontwikkeld.

De AI-laag wordt aangevuld met de Adapter-Studio in SchallOS Control. Hiermee kunnen ontwikkelaars hun eigen netwerk- en gegevensadapters maken, bijvoorbeeld voor de koppeling met externe ERP-systemen, databases of bedrijfsplatforms zoals SAP en Oracle. De daarvoor benodigde kennis, modelprofielen en oplossingsspecifieke ervaringen worden binnen de kennisarchitectuur in versies beheerd. SchallOS ontwikkelt zich daarmee steeds meer van een klassieke ontwikkelomgeving naar een platform waarin ontwikkelaars, de kennislaag en verschillende AI-modellen gezamenlijk aan een softwareoplossing werken.

Kennislaag ook voor gebruikers en bedrijfskennis

De kennislaag beperkt zich echter niet alleen tot softwareontwikkeling. Ook op Oplossingsniveau Toepassingen kunnen worden uitgerust met eigen AI-agenten die de gebruiker ondersteunen bij dagelijkse werkprocessen – bijvoorbeeld bij het opstellen van facturen, het analyseren van gegevens of bij andere terugkerende taken binnen een softwareoplossing. Daarbij kan een oplossing eigen kennis opbouwen en deze beschikbaar stellen aan haar agenten.

Dit onderdeel zal in de toekomst nog aanzienlijk worden uitgebreid. Het is onder andere de bedoeling om kennis uit verschillende externe bronnen over te nemen, bijvoorbeeld uit e-mailsystemen, documenten en bedrijfsgegevens, evenals via gestandaardiseerde uitwisselingsformaten zoals Google’s Open Knowledge Format (OKF) en kennisgrafieken zoals Neo4j. Op deze manier moet de kennis van een SchallOS-oplossing op de lange termijn niet alleen uit de eigen database bestaan, maar ook uit verschillende informatiebronnen binnen een onderneming.

Van de FileMaker-migratie naar een eigen platform

Het oorspronkelijke uitgangspunt van SchallOS was de migratie van bestaande FileMaker-oplossingen. FileMaker heeft zich gedurende decennia bewezen als een krachtige omgeving voor individuele databasetoepassingen. Met name de nauwe koppeling tussen datamodel, lay-out en programmalogica maakt een snelle en praktijkgerichte ontwikkeling mogelijk.

Een uitgebouwde FileMaker-oplossing bestaat echter uit veel meer dan alleen tabellen en zichtbare schermen. Ze bevat berekeningen, scripts, gebruikersrechten, afdruklay-outs, koppelingen en talrijke bedrijfsspecifieke uitzonderingsgevallen. Een bruikbaar opvolgplatform moet deze samenhangen kunnen overnemen en vervolgens zelfstandig verder kunnen uitbouwen.

Vanuit deze opdracht heeft SchallOS zich stap voor stap ontwikkeld tot een op zichzelf staand platform. Bestaande FileMaker-oplossingen moeten kunnen worden gemigreerd, terwijl tegelijkertijd nieuwe applicaties direct in SchallOS kunnen worden ontwikkeld. Na een volledige migratie is FileMaker niet langer nodig voor de productieve werking.

Ontwikkeling, uitvoering en exploitatie blijven gescheiden

Het SchallOS-ontwikkelingsplatform bestaat uit verschillende onderdelen met duidelijk omschreven taken.

• SchallOS Studio is de ontwikkelomgeving. Daar worden gegevensstructuren, lay-outs, formules, functies, talen en releases ontwikkeld. Ook de migratie-assistent voor bestaande FileMaker-oplossingen maakt deel uit van de Studio.
• SchallOS Runtime voert gepubliceerde applicaties uit. Het biedt de gebruikersinterface en de benodigde programmalogica, zonder automatisch alle ontwikkeltools vrij te geven.
• SchallOS Control beheert implementatiedoelen, databaseverbindingen, runtime-profielen, updates en technische controles.
• SchallOS Cloud biedt applicaties aan als een centraal beheerde online dienst. Daarbij is het niet de bedoeling dat er een afzonderlijk cloudformaat ontstaat. Lokale, servergebaseerde en cloudgebaseerde installaties maken gebruik van dezelfde basisarchitectuur.

Deze scheiding voorkomt dat ontwikkeling, gebruik en beheer op ongecontroleerde wijze met elkaar verweven raken. Tegelijkertijd blijven alle onderdelen technisch op elkaar afgestemd.

Een oplossing voor verschillende bedrijfsmodellen

Een bedrijfsapplicatie kan klein beginnen en later uitbreiden. In het begin volstaat wellicht één lokale werkplek. Later komen er meer medewerkers, een centrale server of meerdere vestigingen bij. SchallOS moet daarom dezelfde basisoplossing kunnen bieden voor verschillende bedrijfsvormen: lokaal in de browser, als Windows- of macOS-toepassing, met SQLite of PostgreSQL, en als SaaS-oplossing in de cloud.

Niet elke bedrijfsvorm heeft dezelfde technische kenmerken. Een lokale database stelt andere eisen dan een centraal systeem voor meerdere gebruikers. Het is echter van cruciaal belang dat lay-outs, functies en het gegevensmodel niet voor elk doel volledig opnieuw hoeven te worden ontwikkeld.

De levenscyclus maakt deel uit van de architectuur

Documentatie, gebeurtenislogboeken en updates worden bij SchallOS niet pas achteraf aan een voltooide toepassing toegevoegd. Ze maken deel uit van de basisarchitectuur. Structuur en productieve gegevens worden gescheiden beheerd. Wijzigingen tijdens de ontwikkeling kunnen worden gelogd en gebundeld tot releases. Updates kunnen worden gecontroleerd, gedistribueerd en bij problemen op een gecontroleerde manier worden teruggedraaid. De geïntegreerde AI ondersteunt niet alleen bij formules en functies, maar ook bij documentatie en klantcommunicatie.

Op die manier brengt SchallOS aspecten samen die in klassieke projecten vaak afzonderlijk worden behandeld. De ontwikkeling van een applicatie is niet langer het einde van het technische proces, maar de eerste fase van een levenscyclus die op de lange termijn is gepland.

SSC en SSD als draagbare structuur- en gegevenscontainers

Veel databasetoepassingen slaan de structuur, de gebruikersinterface, de programmalogica en de productieve gegevens op in één nauw met elkaar verbonden geheel. Dat is in het begin handig, maar bemoeilijkt latere updates, migraties en verschillende bedrijfsmodellen. Zodra er meerdere klanten, grotere gegevensbestanden of individuele uitbreidingen bijkomen, wordt het uitwisselen van een compleet applicatiebestand al snel problematisch.

SchallOS scheidt daarom de beschrijving van een oplossing altijd van de bedrijfsgegevens. Een applicatie bestaat in wezen uit twee bij elkaar horende containers: de SSC voor de structuur en de SSD voor de productieve gegevens.

Beide containers vormen samen de complete oplossing, maar vervullen verschillende taken. De SSC beschrijft hoe de applicatie is opgebouwd en werkt. De SSD bevat de inhoud die tijdens het gebruik wordt gegenereerd.

De SSC beschrijft de toepassing

Het SSC-bestand is de draagbare structuurcontainer van een SchallOS-oplossing. Daarin bevinden zich onder andere:

• Tabel- en velddefinities
• Relaties
• Lay-outs en lay-outelementen
• Formules en eigen functies
• Functionele container
• Triggers en navigatie
• Informatie over talen en vertalingen
• Documentatie
• Versie- en release-informatie

De SSC bevat dus niet de klanten, artikelen, orders of facturen zelf. Het legt vast welke gegevensstructuren er zijn, hoe deze worden weergegeven en welke functies ermee werken. Ook de semantische betekenis van een oplossing hoort in deze container thuis. Een veld kan naast zijn technische naam een functionele beschrijving, vertalingen, validatieregels en aanwijzingen voor de AI-laag bevatten. Hierdoor wordt de structuur niet alleen machinaal leesbaar, maar ook begrijpelijker voor ontwikkelaars, documentatie en migratie.

Het SSC vormt daarmee een draagbaar toepassingsmodel dat onafhankelijk van een specifieke dataset verder kan worden ontwikkeld en gepubliceerd.

De SSD bevat de productieve gegevens

Het SSD-bestand is de gegevenscontainer van de oplossing. Het bevat de gegevensrecords die tijdens de dagelijkse bedrijfsvoering ontstaan, zoals klanten, offertes, orders, facturen, voorraadmutaties of afspraken. Daarnaast kunnen daar ook vakgerelateerde historieken en gegevensgebeurtenissen worden opgeslagen. Hieronder vallen bijvoorbeeld statuswijzigingen, vrijgaven, importen of wijzigingen in bijzonder belangrijke velden. De term SSD verwijst hierbij niet naar een fysieke gegevensdrager, maar naar het logische gegevensniveau van de applicatie. Hoe deze gegevens technisch worden opgeslagen, hangt af van de gekozen implementatie en databaseadapter.

Voor een lokale werkplek kan IndexedDB worden gebruikt. Een desktoptoepassing kan met SQLite werken, terwijl grotere applicaties voor meerdere gebruikers PostgreSQL gebruiken. De SSD blijft in alle gevallen de functionele gegevenscontainer, ook al verschilt de technische opslag.

Twee containers moeten duidelijk bij elkaar horen

De scheiding tussen structuur en gegevens mag er niet toe leiden dat willekeurige containers met elkaar worden gecombineerd. SchallOS moet kunnen controleren of een SSC en een SSD daadwerkelijk tot dezelfde oplossing behoren en of hun versienummers op elkaar aansluiten. Hiervoor kunnen oplossings-ID's, container-ID's, structuurversies, controlesommen en handtekeningen worden gebruikt. Zo kan vóór de start of een update worden vastgesteld of de combinatie geldig is en of de benodigde gegevensmigraties al zijn uitgevoerd.

Deze controle voorkomt bijvoorbeeld dat per ongeluk de structuurcontainer van een andere toepassing met een productieve dataset wordt geopend. Daarnaast voorkomt het dat een nieuwe SSC-versie wordt geactiveerd, terwijl de SSD nog niet is voorbereid op de daarvoor benodigde gegevensstructuur.

Overdraagbaarheid tussen verschillende bedrijfsvormen

De scheiding tussen SSC en SSD vormt de basis om een toepassing in verschillende omgevingen te laten draaien. Lay-outs, formules en functielogica hoeven niet voor elke databaseadapter opnieuw te worden ontwikkeld.

Een oplossing kan lokaal beginnen met IndexedDB, later worden overgezet naar SQLite en bij een groeiend aantal gebruikers worden omgezet naar PostgreSQL. Ook is een overstap naar een cloudomgeving mogelijk.

Een dergelijke overstap blijft een gecontroleerd technisch proces. Verschillende databases hebben hun eigen mogelijkheden en beperkingen. Daarom worden gegevens niet zomaar met één druk op de knop naar een ander systeem overgezet. De overdracht, controle en, indien nodig, het terugdraaien moeten expliciet worden uitgevoerd.

De architectuur zorgt er echter voor dat een verandering in de gegevensopslag niet automatisch betekent dat de gehele applicatie opnieuw moet worden gebouwd.

Updates zonder dat de klantgegevens worden gewijzigd

Een belangrijk voordeel van deze scheiding komt vooral tot uiting bij nieuwe versies. Wijzigingen hebben vaak betrekking op lay-outs, formules, functies of het gegevensmodel. De bestaande bedrijfsgegevens moeten daarbij behouden blijven.

Een ontwikkelaar kan daarom een nieuwe SSC-versie publiceren, terwijl de SSD van de klant op de locatie blijft staan. Als er nieuwe velden of tabellen nodig zijn, worden deze via gedefinieerde migratiestappen toegevoegd. Vóór de update kan de huidige status worden opgeslagen. Vervolgens worden de structuur, de gegevensmigratie en de functionaliteit gecontroleerd. Pas wanneer SSC en SSD weer een consistente status vormen, wordt de update als voltooid beschouwd.

Deze updatemogelijkheid is niet alleen bedoeld voor SchallOS zelf. Ze is ook beschikbaar voor de klantoplossingen die met SchallOS zijn ontwikkeld.

Varianten op maat blijven traceerbaar

Maatwerkbedrijfsoftware ontwikkelt zich bij verschillende klanten vaak op verschillende manieren. De ene klant heeft eigen velden nodig, de andere extra lay-outs of een speciale interface. Zonder duidelijke structuur ontstaan hierdoor al snel onderling afwijkende volledige kopieën, die moeilijk gezamenlijk kunnen worden onderhouden. In het SSC kunnen algemene productonderdelen en klantspecifieke uitbreidingen daarentegen op een traceerbare manier worden geversioniseerd en gedocumenteerd.

De architectuur neemt de beslissing niet uit handen van de ontwikkelaar over welke aanpassing in het algemene product thuishoort. Ze zorgt er echter wel voor dat de herkomst en de afhankelijkheden van een wijziging zichtbaar blijven.

In combinatie met ontwikkelingslogboeken en releases is het bij latere updates beter te zien welke onderdelen moeten worden vervangen, aangevuld of behouden.

Meertaligheid maakt deel uit van de draagbare structuur

Ook de taal laag is in het SSC geïntegreerd. Benamingen worden niet uitsluitend vast opgeslagen in afzonderlijke lay-outobjecten, maar kunnen verwijzen naar semantische vermeldingen met meerdere taalversies.

Een veld zoals „Factuurnummer“ kan zo in verschillende talen worden weergegeven, zonder dat er voor elke taal een volledig nieuwe lay-out hoeft te worden aangemaakt. Een gemigreerde FileMaker-oplossing kan tijdens de migratie automatisch meertalig worden geïmplementeerd en vertaald.

De automatische vertaling is geen vervanging voor een vakkundige controle. Juist juridische en branchespecifieke termen moeten worden gecontroleerd. De architectuur zorgt er echter voor dat meertaligheid vanaf het begin deel uitmaakt van de oplossing en niet later moeizaam in elk scherm moet worden ingebouwd.

Basis voor onderhoudbaarheid op lange termijn

SSC en SSD lijken op het eerste gezicht een eenvoudige scheiding tussen applicatie en gegevens. In werkelijkheid vormen ze echter de basis voor overdraagbaarheid, updates, verschillende databaseadapters, afzonderlijke back-ups en diverse bedrijfsmodellen.

De SSC beschrijft wat een oplossing is en hoe deze werkt. De SSD bevat de gegevens die tijdens het gebruik ervan ontstaan en die voor de betreffende onderneming permanent bewaard moeten blijven.

Door deze duidelijke scheiding kan de applicatie zich verder ontwikkelen zonder dat bij elke nieuwe versie de volledige gegevensset hoeft te worden vervangen. Tegelijkertijd kan het technische gegevensbeheer uitbreiden of veranderen zonder dat lay-outs en bedrijfslogica volledig opnieuw moeten worden opgebouwd.

SchallOS Studio als geïntegreerde ontwikkelomgeving

SchallOS Studio is het gedeelte van het platform waar nieuwe bedrijfsapplicaties worden ontwikkeld en bestaande FileMaker-oplossingen worden gemigreerd of verder ontwikkeld. Daar worden tabellen, velden, relaties, lay-outs, formules, functies, talen en releases binnen één gemeenschappelijke omgeving beheerd.

Voor FileMaker-ontwikkelaars zou de algemene werkwijze vertrouwd moeten aanvoelen. Wijzigingen worden niet uitsluitend in abstracte broncodebestanden aangebracht, maar blijven gekoppeld aan de zichtbare onderdelen van de toepassing. Een ontwikkelaar kan een lay-out bewerken, een veld selecteren, de eigenschappen daarvan wijzigen en direct controleren wat het effect van de aanpassing op de toepassing is.

SchallOS probeert echter niet om FileMaker volledig na te bouwen. Vooral de beproefde basisideeën worden overgenomen: snelle ontwikkeling, directe feedback en een nauwe koppeling tussen datamodel, gebruikersinterface en bedrijfslogica. De technische basis wordt daarentegen opnieuw georganiseerd en afgestemd op draagbare structuren, AI-ondersteunde programmering, documentatie en gecontroleerde releases.

Lay-outs, objecten en eigenschappen

Een essentieel onderdeel van SchallOS Studio is de lay-outmodus. Daarin worden invoerformulieren, lijsten, dialoogvensters, navigatiegebieden en andere gebruikersinterfaces van een oplossing gemaakt.

Tot de mogelijke lay-outobjecten behoren onder andere velden, tekst, knoppen, lijstobjecten, tabbladen, popovers, containers en navigatie-elementen. De objecten kunnen worden geselecteerd, gepositioneerd en via een inspecteur worden geconfigureerd.

Een lay-outobject bevat daarbij niet alleen informatie over grootte, positie en weergave. Het kan bovendien worden gekoppeld aan gegevensbronnen, triggers, formules, functies en semantische benamingen. Een veldobject verwijst bijvoorbeeld naar een veld in het gegevensmodel, kan een taalafhankelijk label krijgen en bij het betreden of verlaten ervan bepaalde functies activeren.

Aangezien elk object deel uitmaakt van het SSC, kunnen wijzigingen in de lay-out worden geversioniseerd, gedocumenteerd en later gericht worden verspreid via een update. De gebruikersinterface blijft daarmee geen op zichzelf staand grafisch niveau, maar een gestructureerd onderdeel van de gehele applicatie.

Gegevensmodel en semantische beschrijvingen

Tabellen, velden en relaties worden eveneens in SchallOS Studio aangemaakt en bewerkt. Nieuwe toepassingen kunnen daar volledig worden opgebouwd. Bij een FileMaker-migratie neemt de migratie-assistent de bestaande structuren zoveel mogelijk over en stelt deze vervolgens beschikbaar voor verdere bewerking.

Een veld bestaat in SchallOS niet alleen uit een technische naam en een gegevenstype. Het kan bovendien worden voorzien van een functionele beschrijving, validatieregels, standaardwaarden, vertalingen en documentatie-opmerkingen.

Deze informatie dient meerdere doelen. Ze maakt het voor andere ontwikkelaars gemakkelijker om de oplossing te begrijpen, ondersteunt de automatische documentatie en biedt de geïntegreerde AI een betere context. In plaats van alleen maar te herkennen dat een veld „Status“ heet, kan het platform bijvoorbeeld weten of het om een orderstatus, een betalingsstatus of een interne verwerkingsstatus gaat.

Ook relaties tussen tabellen kunnen worden beschreven en in hun functionele context worden gedocumenteerd. Hierdoor blijft er minder kennis uitsluitend in het hoofd van de oorspronkelijke ontwikkelaar verborgen.

Formules met berekening in realtime

SchallOS beschikt over een eigen formuleomgeving. Formules worden in de formule-editor gemaakt en tijdens het bewerken in realtime berekend. Wijzigingen in een uitdrukking kunnen daardoor onmiddellijk worden getoetst met geschikte testwaarden of de huidige dataset.

De formuletaal ondersteunt de typische berekeningen die in zakelijke toepassingen nodig zijn. Hiertoe behoren wiskundige bewerkingen, tekstverwerking, datum- en tijdberekeningen, logische voorwaarden, veldverwijzingen, variabelen en geneste uitdrukkingen.

Het beschikbare aantal commando's is in eerste instantie kleiner dan de functieset van FileMaker, die in de loop van decennia is gegroeid. SchallOS hoeft niet elk historisch FileMaker-commando ongewijzigd na te bootsen. Belangrijker is een duidelijk gestructureerde en uitbreidbare formuleomgeving.

Later kunnen er extra commando’s worden toegevoegd als die nodig zijn voor bepaalde oplossingen of migraties. Daarbij kan de geïntegreerde AI ook helpen om een bestaande berekening over te zetten of een ontbrekende functie te ontwikkelen die past bij de SchallOS-architectuur.

Aangepaste functies voor herbruikbare berekeningen

Naast de geïntegreerde commando’s ondersteunt SchallOS ook aangepaste functies. Deze accepteren parameters, voeren een gedefinieerde berekening uit en geven een resultaat terug. Zo kunnen terugkerende regels op één centrale plek worden beheerd. Voorbeelden hiervan zijn prijsberekeningen, het bepalen van termijnen, opmaak, controles van nummerreeksen of het verwerken van geïmporteerde waarden.

Aangepaste functies worden eveneens in realtime berekend en kunnen direct in de formule-editor worden getest. Als een functie later wordt gecorrigeerd of uitgebreid, profiteren alle formules die er gebruik van maken daarvan.

Daarnaast kunnen eigen functies worden beschreven en gedocumenteerd. Parameters, retourwaarden, voorbeelden en bekende foutgevallen blijven zo overzichtelijk. De verzameling functies van een oplossing groeit uit tot een herbruikbare bibliotheek, in plaats van te bestaan uit talloze gekopieerde afzonderlijke berekeningen.

Functiecontainers voor complexere processen

Omvangrijkere bedrijfsprocessen worden in SchallOS georganiseerd via functiecontainers. U kunt bijvoorbeeld gegevensrecords aanmaken, waarden controleren, dialoogvensters aansturen, documenten genereren of externe interfaces aansturen. Een functiecontainer bevat niet alleen de uitvoerbare code. Daartoe behoren ook een functionele beschrijving, invoerparameters, retourwaarden, afhankelijkheden, toegestane bevoegdheden en uitdrukkelijk uitgesloten bewerkingen.

Meerdere lay-outobjecten kunnen dezelfde functiecontainer gebruiken. Daardoor hoeft een functie voor het aanmaken van een factuur niet voor elke knop of elke lay-out opnieuw te worden opgebouwd.

Bij gemigreerde oplossingen kunnen bestaande FileMaker-scripts op de achtergrond behouden blijven als leer- en referentielaag. Ze helpen om de oorspronkelijke bedoeling en de huidige werkwijze te begrijpen. De nieuwe uitvoerbare code wordt echter gegenereerd in overeenstemming met de architectuur van SchallOS.

Migratie en nieuwe ontwikkeling in dezelfde omgeving

SchallOS Studio is niet uitsluitend bedoeld voor bestaande FileMaker-oplossingen. Nieuwe toepassingen kunnen volledig binnen het platform worden ontwikkeld.

Bij een migratie neemt de wizard eerst de bestaande tabellen, velden, relaties, lay-outs en andere herkenbare onderdelen over. Vervolgens kunnen ontwikkelaars de geïmporteerde structuur controleren, opschonen en stapsgewijs overzetten naar de nieuwe functionele architectuur.

Het is niet de bedoeling dat er een ongewijzigde kopie van alle vroegere bijzonderheden ontstaat. Historisch gegroeide omwegen kunnen worden herzien en vervangen door duidelijkere structuren. Tegelijkertijd blijft de vakkennis van de bestaande oplossing behouden.

Nieuwe en gemigreerde applicaties maken vervolgens gebruik van dezelfde tools, containers en publicatiemethoden.

Wijzigingen worden omgezet in gecontroleerde releases

Een wijziging in de studio leidt niet automatisch tot een productieve update. Tijdens de ontwikkeling kunnen er onvoltooide lay-outs, voorlopige formules of nog niet geteste functies aanwezig zijn.

Bij elkaar horende wijzigingen kunnen daarom in Change Sessions worden vastgelegd en later aan een release worden toegewezen. Pas na controle en goedkeuring ontstaat hieruit een gepubliceerde SSC-versie.

Een release kan naast de nieuwe structuur ook de nodige gegevensmigraties, versie-informatie, afhankelijkheden, teststappen en documentatie bevatten. Op deze manier blijft de daadwerkelijke ontwikkeling duidelijk gescheiden van de levering aan productieve runtime-instanties.

SchallOS Studio is daarmee niet alleen de plek waar een applicatie wordt ontworpen en geprogrammeerd. Het combineert visuele ontwikkeling, datamodel, formules, functies, documentatie en publicatie in één gemeenschappelijke omgeving.

De vertrouwde band tussen de ontwikkelaar en de zichtbare toepassing blijft behouden. Tegelijkertijd ontstaat er een technische basis waarop oplossingen op een overdraagbare, traceerbare en op de lange termijn onderhoudbare manier verder kunnen worden ontwikkeld.

AI op de plek waar formules en functies ontstaan

Kunstmatige intelligentie wordt tot nu toe in veel ontwikkelomgevingen vooral via een extra chatvenster aangeboden. De ontwikkelaar beschrijft een probleem, kopieert broncode of formules naar de chat en voert het resultaat vervolgens weer in het project in. Daarbij ontbreekt het taalmodel vaak aan belangrijke informatie over tabellen, velden, relaties en de functionele betekenis van de applicatie.

SchallOS integreert de AI daarom rechtstreeks in de ontwikkeltools. De AI is beschikbaar op de plekken waar formules, aangepaste functies en functiecontainers worden bewerkt. Daardoor krijgt de AI niet alleen een losse vraag, maar ook de actuele context van de oplossing.

In de formule-editor kent de AI bijvoorbeeld de bewerkte uitdrukking, de beschikbare velden en het verwachte resultaattype. Binnen een functiecontainer heeft ze bovendien toegang tot de beschrijving, parameters, mogelijkheden en afhankelijkheden daarvan.

De AI wordt daarmee geen afzonderlijk hulpprogramma, maar een integraal onderdeel van de eigenlijke ontwikkelomgeving.

Ondersteuning in de formule-editor

Formules sturen talrijke processen in een bedrijfsapplicatie aan. Ze berekenen prijzen, controleren voorwaarden, bepalen termijnen of beïnvloeden de weergave van lay-outelementen. De geïntegreerde AI kan in de formule-editor onder andere:

• een bestaande formule uitleggen
• mogelijke fouten onderzoeken
• Voorwaarden aanvullen
• een uitdrukking vereenvoudigen
• een FileMaker-formule overbrengen
• of op basis van een technische beschrijving een nieuwe berekening maken.

Een ontwikkelaar zou bijvoorbeeld kunnen instellen dat opdrachten boven een bepaalde nettowaarde een extra goedkeuring vereisen, tenzij er een raamovereenkomst is. De AI kan hieruit een formule genereren en daarbij gebruikmaken van de velden die in de oplossing aanwezig zijn. Het resultaat blijft zichtbaar als een normale formule. Deze kan worden gelezen, gewijzigd en in realtime worden berekend. De AI creëert dus geen verborgen proces waarvan het gedrag moeilijk te doorgronden zou zijn.

Als een benodigde opdracht ontbreekt, kan de AI ook helpen bij het maken van een geschikte aangepaste functie of een uitbreiding van de formuleomgeving. Hierdoor blijft de aanvankelijk beperkte reeks opdrachten van SchallOS uitbreidbaar.

Aangepaste functies op basis van functionele specificaties

Terugkerende berekeningen kunnen centraal worden beheerd als aangepaste functies. De AI kan op basis van een beschrijving een functie genereren met unieke parameters, een retourwaarde en gedocumenteerd gedrag.

Een dergelijke functie zou bijvoorbeeld kortingstermijnen kunnen berekenen, nummerreeksen kunnen controleren of geïmporteerde waarden kunnen harmoniseren. Naast de eigenlijke afdruk kunnen ook testwaarden, voorbeelden en mogelijke foutgevallen worden gegenereerd.

Dat maakt niet alleen de eerste programmering eenvoudiger. Bij een latere wijziging kan de AI herkennen welke betekenis de functie heeft en op welke plaatsen deze wordt gebruikt.

Zo wordt een anonieme berekening een gedocumenteerd en herbruikbaar onderdeel van de oplossing.

Functiecontainers als beschreven programmalogica

Complexere processen worden in SchallOS georganiseerd via functiecontainers. Een functiecontainer kan bijvoorbeeld gegevensrecords aanmaken, invoer controleren, dialoogvensters aansturen, documenten genereren of externe interfaces aanroepen. De basis hiervoor wordt gevormd door een gestructureerde beschrijving. Daarin kan het volgende worden vastgelegd:

• welke functie de functie vervult
• welke parameters worden doorgegeven
• welk resultaat wordt verwacht
• tot welke tabellen en velden toegang mag worden verleend
• welke andere functies worden gebruikt
• en welke handelingen uitdrukkelijk zijn uitgesloten.

Op basis van deze specificaties programmeert de AI de uitvoerbare code van de functiecontainer. Daardoor hoeft de ontwikkelaar het proces niet langer uitsluitend uit talrijke afzonderlijke scriptstappen samen te stellen. Zijn taak verschuift meer naar het nauwkeurig beschrijven van de gewenste functie, de grenzen daarvan en de daaropvolgende controle.

De gegenereerde code blijft echter zichtbaar. Deze kan worden gelezen, getest, aangepast en tussen verschillende versies worden vergeleken. Ook eerdere versies kunnen worden bewaard en indien nodig worden hersteld. AI neemt daarmee het programmeren voor zijn rekening, maar niet de vaktechnische verantwoordelijkheid.

FileMaker-scripts als leermateriaal

Bij gemigreerde FileMaker-oplossingen bevatten de bestaande scripts vaak een groot deel van de bedrijfslogica die in de loop der jaren is ontstaan. Ze laten zien welke velden zijn gewijzigd, welke voorwaarden zijn gecontroleerd en welke verdere processen zijn aangeroepen.

Deze scripts worden in SchallOS niet permanent als uitvoerbare runtime-laag overgenomen. Hierdoor zouden veel eerdere technische afhankelijkheden en omwegen alleen maar naar het nieuwe systeem worden verplaatst. In plaats daarvan kan het oorspronkelijke FileMaker-script op de achtergrond van de bijbehorende functiecontainer behouden blijven. Het dient voor de AI als leer-, referentie- en begripslaag.

De AI kan hieruit de functionele bedoeling van het bestaande proces afleiden. Vervolgens programmeert ze de nieuwe code in overeenstemming met de architectuur van SchallOS. Historische opzetelementen, zoals frequente lay-outwijzigingen, globale velden of contextgebonden hulpscripts, hoeven daarbij niet ongewijzigd te worden overgenomen. Ze worden alleen behouden als ze daadwerkelijk noodzakelijk zijn voor het eigenlijke bedrijfsproces.

Het oorspronkelijke script blijft niettemin bewaard als kennisbron. Bij latere vragen kan zo worden nagegaan hoe een bepaald proces in de FileMaker-oplossing oorspronkelijk werd opgelost.

Vaardigheden en beperkingen worden uitdrukkelijk omschreven

Een functiecontainer mag niet louter op basis van een algemene beschrijving toegang krijgen tot willekeurige delen van de toepassing. Daarom kunnen toegestane bevoegdheden en uitsluitingen uitdrukkelijk worden vastgelegd.

Een functie kan bijvoorbeeld wel gegevensrecords in een bepaalde tabel lezen en wijzigen, zonder tegelijkertijd verwijderingen of wijzigingen aan de systeemconfiguraties te kunnen uitvoeren. Als de gegenereerde code gebruikmaakt van een niet-toegestane bevoegdheid, kan SchallOS dit detecteren en de uitvoering of publicatie blokkeren.

De beschrijving van een functiecontainer dient dus niet alleen ter documentatie. Ze maakt deel uit van het test- en veiligheidsmodel. Juist bij door AI gegenereerde code is deze beperking belangrijk. Het taalmodel krijgt een duidelijke speelruimte, terwijl het platform controleert of de gegenereerde functie binnen dit kader blijft.

De juiste context leidt tot betere resultaten

De kwaliteit van een door AI gegenereerde functie hangt niet alleen af van de omvang van het gebruikte taalmodel. Het is van cruciaal belang of het model de benodigde informatie ontvangt. SchallOS kan de context op verschillende niveaus samenstellen:

1. de huidige vraag
2. in de geopende editor
3. het geselecteerde veld of de geselecteerde functiecontainer
4. de betrokken tabellen en relaties
5. bestaande formules en functies
6. semantische beschrijvingen
7. Documentatie en wijzigingsgeschiedenis
8. en bij migraties het oorspronkelijke FileMaker-script.

Hierdoor kan de AI aanzienlijk nauwkeuriger werken dan bij een op zichzelf staande vraag in een algemene chat.

Tegelijkertijd hoeft niet bij elke opdracht de volledige oplossing te worden gegeven. De context kan worden beperkt tot de informatie die daadwerkelijk nodig is voor de betreffende functie.

Verwisselbare modellen in plaats van een permanente verbintenis

De AI-laag mag niet permanent afhankelijk zijn van één enkel model of één enkele aanbieder. Verschillende taken stellen uiteenlopende eisen aan kwaliteit, snelheid, kosten en gegevensbescherming.

Voor een complexe migratie kan een bijzonder krachtig model nodig zijn. Een eenvoudige uitleg of aanpassing van een formule kan mogelijk met een kleiner model worden uitgevoerd. Voor gevoelige of gesloten omgevingen kunnen op de lange termijn ook lokaal draaiende modellen worden ingezet.

De permanente kennisbasis ligt daarom niet in het taalmodel, maar in de SchallOS-oplossing: in beschrijvingen, structuren, scriptverwijzingen, code, tests en documentatie. Het AI-model blijft een vervangbaar hulpmiddel dat vanuit deze context uitvoerbare code of begrijpelijke voorstellen genereert.

Transparante, door AI ondersteunde ontwikkeling

SchallOS combineert het directe werken aan bedrijfsapplicaties met AI-ondersteunde programmering. Formules kunnen direct worden uitgelegd en gegenereerd. Aangepaste functies worden gegenereerd op basis van herbruikbare vaktechnische specificaties. Functiecontainers koppelen semantische beschrijvingen aan zichtbare en controleerbare code.

Bij gemigreerde oplossingen blijven FileMaker-scripts behouden als extra leerniveau. Ze helpen om bestaande bedrijfsprocessen te begrijpen, zonder eerdere technische afhankelijkheden blijvend in stand te houden.

De rol van de ontwikkelaar verdwijnt hierdoor niet. Ze verandert. Nauwkeurige vereisten, een doordachte architectuur, tests en vaktechnische controle worden belangrijker dan het handmatig invoeren van elke afzonderlijke programmastap. Juist bij bedrijfskritische software blijft deze verantwoordelijkheid onmisbaar.

Huidig onderzoek naar het gebruik van lokale AI-systemen

Documentatie en gebeurtenislogboeken als onderdeel van de applicatie

De documentatie van een bedrijfsapplicatie wordt vaak pas opgesteld als de ontwikkeling al is afgerond. Onder tijdsdruk richt men zich in eerste instantie op nieuwe velden, lay-outs, formules en functies. De beschrijving van de wijzigingen volgt later.

Naarmate de tijd verstrijkt, wordt het echter moeilijker om de oorspronkelijke beslissingen te achterhalen. Vaak is niet meer precies bekend waarom een bepaalde functie is toegevoegd, welke objecten hierdoor werden beïnvloed en met welke speciale gevallen rekening moest worden gehouden. SchallOS beschouwt documentatie daarom niet als een achteraf uitgevoerde extra taak. Relevante wijzigingen worden al tijdens de ontwikkeling als gebeurtenissen vastgelegd en gekoppeld aan de betreffende onderdelen van de oplossing.

Op basis van deze informatie kunnen vervolgens technische documentatie, release notes, klantrapporten of prestatierapporten worden opgesteld. De documentatie is dus niet alleen gebaseerd op herinneringen of handmatig bijgehouden aantekeningen, maar op de daadwerkelijk doorgevoerde wijzigingen.

Gebeurtenissen op verschillende niveaus

Een SchallOS-oplossing beschikt niet slechts over één algemeen protocol. Het platform maakt onderscheid tussen verschillende gebeurtenisniveaus met elk hun eigen taken.

• De Structuurprotocol registreert wijzigingen in het SSC. Hieronder vallen bijvoorbeeld nieuwe tabellen en velden, aangepaste lay-outs, gewijzigde formules of nieuwe functiecontainers.
• De Logboek van gegevensgebeurtenissen maakt deel uit van de SSD. Daarin worden tijdens het productieve gebruik vaktechnisch relevante gebeurtenissen vastgelegd, zoals statuswijzigingen, vrijgaven, annuleringen of wijzigingen in belangrijke gegevensrecords.
• Daarnaast zijn er nog Bedrijfsgebeurtenissen uit Runtime en SchallOS Control. Hiertoe behoren onder andere implementaties, updates, controles, back-ups en rollback-procedures.

Deze onderdelen blijven gescheiden, maar kunnen met elkaar worden gekoppeld. Een ontwikkelingslogboek mag niet onoverzichtelijk worden door dagelijkse wijzigingen in klantgegevens. Omgekeerd horen interne technische details niet automatisch thuis in de functionele geschiedenis van een factuur of een opdracht.

Het structuurprotocol toont de ontwikkeling van de oplossing

Wijzigingen aan tabellen, velden, lay-outs, formules en functiecontainers kunnen als gestructureerde gebeurtenissen worden opgeslagen. Een vermelding kan vastleggen welk object is gewijzigd, wat de eerdere toestand was en wat de nieuwe toestand is geworden. Daarnaast kunnen de ontwikkelaar, het tijdstip, de functionele motivering, de bijbehorende opdracht en de geplande releaseversie worden vastgelegd.

Als er bijvoorbeeld een nieuw goedkeuringsproces voor opdrachten wordt toegevoegd, kan dit tot verschillende technische wijzigingen leiden. Er wordt een statusveld aangemaakt, een lay-out uitgebreid, een formule aangepast en een nieuwe functiecontainer geprogrammeerd.

Het structuurprotocol bewaart deze afzonderlijke gebeurtenissen. Tegelijkertijd kunnen ze worden gebundeld onder een gemeenschappelijke functionele taak. Daardoor blijft duidelijk dat meerdere technische wijzigingen samen een nieuw bedrijfsproces vormen.

Change-sessies bundelen onderling samenhangende werkzaamheden

Een ontwikkelingsopdracht bestaat vaak uit veel kleine stappen. Een puur chronologische lijst van afzonderlijke wijzigingen zou het daadwerkelijke verband onvoldoende weergeven.

SchallOS kan daarom verwante werkzaamheden bundelen in Change Sessions. Een Change Session beschrijft een concrete taak, uitbreiding of foutcorrectie en verzamelt alle bijbehorende gebeurtenissen. Deze kan bijvoorbeeld het volgende bevatten:

• de functionele taakomschrijving
• betrokken tabellen en lay-outs
• gewijzigde formules en functies
• uitgevoerde tests
• openstaande punten
• en de toewijzing aan een klant of opdracht.

Meerdere Change Sessions kunnen later aan een release worden toegewezen. Op die manier ontstaat er een traceerbaar verband tussen de ontwikkelingsopdracht, de technische wijzigingen en de gepubliceerde versie.

De AI zet technische gebeurtenissen op een begrijpelijke manier uiteen

De documentatielaag is gekoppeld aan de geïntegreerde AI van SchallOS. Hierdoor kunnen de geregistreerde gebeurtenissen automatisch worden verwerkt voor verschillende doelgroepen.

Een technisch ontwikkelingsrapport vereist andere informatie dan een mededeling aan de klant. Terwijl de ontwikkelaar concrete veldnamen, functiecontainers en gegevensmigraties wil zien, is de klant vooral geïnteresseerd in welke functie is toegevoegd en welk nut deze biedt. De AI kan dezelfde gebeurtenissen daarom in verschillende vormen samenvatten:

• als interne technische documentatie
• als begrijpelijke klantinformatie
• als release-opmerkingen
• als projectverslag
• of als bewijs van levering bij een factuur.

De teksten ontstaan niet zomaar op basis van een algemene beschrijving. Ze worden afgeleid uit de Change Sessions, semantische objectbeschrijvingen en daadwerkelijke structuurwijzigingen.

De gegenereerde tekst blijft daarbij gekoppeld aan zijn bronnen. De ontwikkelaar kan nagaan op welke gebeurtenissen een uitspraak is gebaseerd en de formulering vóór gebruik corrigeren of goedkeuren.

Prestatieverslagen voor ontwikkelaars en klanten

Voor ontwikkelaars van maatwerksoftware is documentatie ook vanuit economisch oogpunt belangrijk. De geleverde diensten moeten op een begrijpelijke manier aan de klant worden uitgelegd en worden vaak per tijdseenheid of per werkpakket gefactureerd.

In de praktijk worden dergelijke prestatierapporten vaak pas kort voor het opstellen van de factuur samengesteld. Hiervoor moeten e-mails, notities en herinneringen worden doorzocht.

SchallOS kan de daadwerkelijk geregistreerde ontwikkelingsgebeurtenissen toewijzen aan een klant, project of opdracht. De AI genereert hieruit geschikte vermeldingen voor een prestatierapport. Meerdere technische wijzigingen kunnen bijvoorbeeld worden samengevat tot één begrijpelijke prestatie:

Uitbreiding van het orderbeheer met een goedkeuringsproces in twee fasen, inclusief statuscontrole, gebruikersrechten en aanpassing van het invoerscherm.

De onderliggende technische processen blijven zichtbaar. De beschrijving voor de klant vormt slechts een begrijpelijke samenvatting. De uiteindelijke keuze ligt bij de ontwikkelaar. Niet elke technische gebeurtenis is automatisch factureerbaar, en interne tests of correcties hoeven niet afzonderlijk op een factuur te worden vermeld.

Gebeurtenissen op gegevensniveau

Ook tijdens de productieve werking kunnen alle beoogde gegevensgebeurtenissen worden gelogd. Hieronder vallen het aanmaken en wijzigen van gegevensrecords, statuswijzigingen, vrijgaven, importen, exporten of automatisch uitgevoerde processen. Een logboekvermelding kan het volgende vastleggen:

• welke gebruiker of welk proces de actie heeft geactiveerd
• welk record hierdoor werd beïnvloed
• welke waarden zijn gewijzigd
• welke functie is uitgevoerd
• en of het proces succesvol is afgerond.

De gekozen oplossing bepaalt welke gebeurtenissen in welke mate worden opgeslagen. Een kleine tekstcorrectie heeft een andere betekenis dan de wijziging van een reeds goedgekeurde factuur. Het gegevenslogboek vormt daarmee de functionele geschiedenis van het SSD. Het ondersteunt de ondersteuning, foutanalyse en de traceerbaarheid van belangrijke bedrijfsprocessen.

Een dergelijk protocol kan ook als basis dienen voor auditvereisten. Of hiermee aan alle wettelijke of branchespecifieke voorschriften wordt voldaan, moet echter per concreet geval worden gecontroleerd.

De documentatie gaat ook gepaard met releases en updates

De geregistreerde ontwikkelingsgebeurtenissen worden tegelijkertijd opgenomen in de release- en update-pijplijn. Wanneer er een nieuwe versie wordt uitgebracht, kan SchallOS automatisch in kaart brengen welke functies zijn toegevoegd, welke fouten zijn verholpen en welke gegevensstructuren zijn gewijzigd. Hieruit ontstaan technische wijzigingslijsten, gebruikersinstructies en migratie-informatie.

Na de installatie blijft duidelijk welke versie op een bepaalde runtime-instantie is geïnstalleerd en welke wijzigingen daarin zijn opgenomen.

Ook bedrijfsgebeurtenissen zoals back-ups, controles of een eventuele rollback worden gedocumenteerd. Hierdoor kan later niet alleen worden vastgesteld wat er is ontwikkeld, maar ook wanneer en met welk resultaat een wijziging in productie is genomen.

Een groeiende kennisbasis

De combinatie van een gebeurtenislogboek, semantische beschrijvingen en AI-ondersteuning zorgt op de lange termijn voor een kennisbasis over de gehele oplossing. Bij een latere wijziging kan niet alleen de huidige code worden bekeken. Het blijft ook duidelijk wanneer een functie is geïntroduceerd, welke zakelijke reden daarachter schuilging en welke andere gebieden destijds hierdoor werden beïnvloed.

Juist bij bedrijfsapplicaties die in de loop van vele jaren zijn gegroeid, is deze kennis van cruciaal belang. Een ogenschijnlijk overbodig speciaal geval kan een belangrijke historische reden hebben. Zonder documentatie bestaat het risico dat het bij een latere herziening per ongeluk wordt verwijderd. SchallOS bewaart daarom niet alleen technische toestanden, maar ook de ontwikkelingsgeschiedenis en de daarmee samenhangende beslissingen.

Documentatie wordt zo een actief onderdeel van de applicatie. Ze ondersteunt de ontwikkeling, de communicatie met klanten, de facturering, de ondersteuning, releases en het onderhoud op lange termijn – op basis van de gebeurtenissen die daadwerkelijk in het systeem hebben plaatsgevonden.

Een systeemwijde updatepijplijn voor het platform en de applicaties

Bedrijfssoftware blijft zelden langere tijd ongewijzigd. Nieuwe eisen, wetswijzigingen, foutcorrecties en technische ontwikkelingen leiden regelmatig tot nieuwe versies. Daarbij volstaat het niet om alleen maar bestanden uit te wisselen. Vóór elke update moet worden gecontroleerd welke versie installiert is, of gegevensstructuren moeten worden aangepast en hoe de vorige toestand in geval van een fout kan worden hersteld.

Bij veel individuele toepassingen worden dergelijke procedures pas achteraf ontwikkeld. Updates worden dan verspreid met behulp van handmatige instructies, back-ups en klantspecifieke scripts. Met elke nieuwe installatie neemt het risico toe dat er verschillende versies en speciale oplossingen ontstaan.

SchallOS beschouwt updates daarom als een systeembrede platformfunctie. Via dezelfde basis-pipeline worden zowel SchallOS zelf als de met het platform ontwikkelde klantoplossingen bijgewerkt.

Een ontwikkelaar hoeft voor een nieuwe applicatie dus niet eerst een eigen updateprocedure te ontwerpen. Versiebeheer, controle, distributie en logboekregistratie maken vanaf het begin deel uit van de gemeenschappelijke architectuur.

De scheiding tussen SSC en SSD beschermt de productieve gegevens

De mogelijkheid om updates uit te voeren hangt rechtstreeks samen met de scheiding tussen structuur en gegevens. De SSC bevat lay-outs, formules, functiecontainers, taaldefinities en het gegevensmodel van de toepassing. De SSD bevat de productieve bedrijfsgegevens van de betreffende onderneming.

Bij een nieuwe versie wordt daarom niet de volledige applicatie, inclusief alle klantgegevens, vervangen. In plaats daarvan kan een nieuwe SSC worden gepubliceerd, terwijl de bestaande SSD op de locatie blijft staan.

Als de nieuwe structuur extra velden, tabellen of gewijzigde gegevensformaten vereist, worden hiervoor uitdrukkelijk gedefinieerde migratiestappen uitgevoerd. De productieve gegevens worden op gecontroleerde wijze aangepast aan de nieuwe structuur en worden niet onopgemerkt vervangen door een andere gegevensset.

Dankzij deze duidelijke scheiding kunnen applicaties gedurende vele jaren verder worden ontwikkeld, zonder dat bij elke update alle bedrijfsgegevens naar een nieuw, compleet bestand moeten worden overgezet.

Van ontwikkelingsfase tot release

Niet elke wijziging in SchallOS Studio is direct geschikt voor productief gebruik. Tijdens de ontwikkeling kunnen er voorlopige lay-outs, onvolledige functies of nog niet geteste formules aanwezig zijn.

Gerelateerde wijzigingen worden daarom eerst vastgelegd in Change Sessions en toegewezen aan een geplande release. Pas na controle en goedkeuring ontstaat hieruit een gepubliceerde versie. Een release kan onder andere het volgende bevatten:

• een uniek versienummer
• de bijgewerkte SSC
• noodzakelijke SSD-migraties
• technische vereisten
• Afhankelijkheden van runtime of adapters
• Controle- en teststappen
• Release-opmerkingen
• en informatie voor een eventuele rollback.

De documentatielaag vormt hiervoor de basis. Op basis van de geregistreerde ontwikkelingsgebeurtenissen kunnen automatisch technische wijzigingslijsten en begrijpelijke gebruikersinstructies worden gegenereerd.

Een release bestaat dus niet alleen uit gewijzigde bestanden. Daarin wordt ook beschreven wat er is gewijzigd, welke vereisten gelden en hoe de installatie moet worden gecontroleerd.

SchallOS Control regelt de verdeling

SchallOS Control zorgt voor het operationele beheer van de updates. Daar is te zien welke instanties er zijn, welke versies zijn geïmplementeerd en welke updates beschikbaar zijn. Vóór de installatie kan Control onder andere het volgende controleren:

• of de doelinstantie bereikbaar is
• welke Runtime- en SSC-versie wordt gebruikt
• welke databaseadapter actief is
• of er een geschikte beveiliging kan worden opgezet
• en of aan alle voorwaarden voor de release is voldaan.

Hierdoor wordt voorkomen dat een update wordt uitgevoerd op een installatie die technisch niet geschikt is of nog niet volledig is voorbereid.

Een release hoeft bovendien niet tegelijkertijd naar alle systemen te worden gedistribueerd. Deze kan eerst in een testomgeving of bij geselecteerde installaties worden ingezet. Pas na een succesvolle test volgt de bredere uitrol.

Hiervoor kunnen verschillende updatekanalen worden ingesteld, bijvoorbeeld stabiele productieversies, bètaversies, interne tests of klantspecifieke releases.

Referenties en unieke versienummers

Updatepakketten kunnen worden voorzien van controlesommen en digitale handtekeningen. Hierdoor kan SchallOS Control vaststellen of een pakket compleet is, afkomstig is van de beoogde bron en sinds de publicatie ervan is gewijzigd.

Daarnaast wordt gecontroleerd of de release daadwerkelijk bij de betreffende oplossing hoort. Een nieuwe SSC mag niet per ongeluk worden gekoppeld aan de SSD van een andere toepassing.

Unieke oplossings-ID’s, structuurversies en datamodelversies zorgen ervoor dat de install-status traceerbaar blijft. Ook noodzakelijke tussenstappen kunnen worden geïdentificeerd. Een installatie kan bijvoorbeeld niet direct van een zeer oude versie naar de nieuwste versie worden bijgewerkt als er eerst een noodzakelijke gegevensmigratie moet worden uitgevoerd.

Back-up, migratie en verificatie

Voorafgaand aan een structurele update wordt de huidige toestand opgeslagen. De concrete manier waarop dit gebeurt, hangt af van de gebruikte database-adapter. Voor een lokale IndexedDB- of SQLite-installatie zijn andere procedures nodig dan voor een PostgreSQL-server.

Vervolgens wordt het updatepakket gecontroleerd, de nieuwe structuur install geïmplementeerd en wordt een eventueel noodzakelijke gegevensmigratie uitgevoerd. Na de activering volgt de verificatie. Daarbij kan SchallOS bijvoorbeeld het volgende controleren:

• of alle verwachte tabellen en velden aanwezig zijn,
• of de gegevensmigratie volledig is uitgevoerd,
• of het aantal records en de controlesommen kloppen,
• en of belangrijke functies naar behoren worden uitgevoerd.

Pas wanneer deze controles met succes zijn afgerond, wordt de update als installiert beschouwd. Het louter overzetten van bestanden is dus niet voldoende. Het is van cruciaal belang dat de structuur, de gegevens en de runtime daarna weer een consistente en goed functionerende toestand vormen.

Terugdraaien bij mislukte updates

Ondanks een zorgvuldige voorbereiding kan een update mislukken. Onverwachte oude gegevens, een foutieve migratie of een niet-meegenomen afhankelijkheid kunnen ertoe leiden dat een nieuwe versie niet veilig kan worden geactiveerd. Voor dergelijke gevallen maakt een rollback deel uit van het updateproces. Daarbij worden de eerdere SSC-versie, de opgeslagen SSD-status en de vorige configuratie hersteld.

Niet elke update kan echter naar believen worden teruggedraaid. Als er na de installatie al nieuwe productieve gegevens volgens gewijzigde regels zijn verwerkt, kan een volledige terugkeer problematisch zijn. In een release moet daarom worden vastgelegd onder welke voorwaarden een rollback mogelijk is.

In sommige gevallen is een corrigerende vervolgupdate zinvoller dan het herstellen van een oudere gegevensset. Het platform biedt het technische kader, maar de concrete beslissing hangt af van de betreffende wijziging en de zakelijke betekenis ervan.

Ook SchallOS maakt zelf gebruik van deze pijplijn

De updatepijplijn is niet alleen bedoeld voor klantoplossingen. Ook SchallOS Studio, Runtime, Control en andere platformcomponenten worden via dezelfde basismechanismen bijgewerkt. Nieuwe platformversies kunnen uitbreidingen van de formuleomgeving, verbeteringen aan de AI-laag, nieuwe databaseadapters of beveiligingscorrecties bevatten. Ook hier zijn versienummers, afhankelijkheden, handtekeningen en controles nodig.

Hierdoor wordt de infrastructuur tijdens de dagelijkse werking van het platform zelf gebruikt en voortdurend getest. De met SchallOS ontwikkelde toepassingen profiteren van dezelfde procedures.

De ontwikkelaar krijgt dus niet alleen een louter theoretisch voorziene updatefunctie, maar een pijplijn die zowel deel uitmaakt van de exploitatie als van de verdere ontwikkeling van het gehele systeem.

Een geplande koers voor toekomstige versies

De kracht van de updatepijplijn ligt niet alleen in de automatische distributie van nieuwe bestanden. Doorslaggevend is de integratie van ontwikkeling, documentatie, back-up, migratie, controle en rollback binnen één gezamenlijk proces.

SchallOS zelf en de daarmee ontwikkelde toepassingen maken gebruik van dezelfde basisinfrastructuur. De scheiding tussen SSC en SSD zorgt ervoor dat de structuur zich verder kan ontwikkelen, terwijl de productieve gegevens worden beschermd en op gecontroleerde wijze worden aangepast.

Een met SchallOS ontwikkelde oplossing beschikt daarmee vanaf het begin over een vastgelegd traject voor toekomstige versies. Juist bij bedrijfssoftware die jarenlang in gebruik zal blijven, is deze updatebaarheid geen extra functie, maar een essentiële voorwaarde voor duurzame onderhoudbaarheid en betrouwbare werking.

Runtime, Control en Cloud voor verschillende bedrijfsmodellen

Een ontwikkelomgeving moet uitgebreide mogelijkheden bieden. Ontwikkelaars moeten structuren kunnen aanpassen, lay-outs kunnen ontwerpen, formules kunnen bewerken en nieuwe functies kunnen publiceren. Bij het dagelijkse gebruik van een voltooide bedrijfsapplicatie zijn deze tools daarentegen meestal niet nodig.

SchallOS verdeelt daarom ontwikkeling, uitvoering en beheer in verschillende onderdelen. SchallOS Studio is bedoeld voor de ontwikkeling. SchallOS Runtime voert gepubliceerde applicaties uit. SchallOS Control beheert de technische implementatie ervan. SchallOS Cloud biedt dezelfde basisarchitectuur aan als een centraal beheerde online dienst.

Hierbij ontstaan geen onderling onafhankelijke toepassingen. Alle onderdelen werken met dezelfde SSC- en SSD-structuren. De bedrijfsmodus wordt bepaald via de deployment, de databaseadapter en het runtime-profiel.

SchallOS Runtime voert gepubliceerde oplossingen uit

SchallOS Runtime koppelt de SSC van een toepassing aan de bijbehorende SSD en stelt de daarin gedefinieerde lay-outs, formules en functies beschikbaar. Tot de runtime behoren onder andere de weergave en bediening van de lay-outs, het lezen en bewerken van gegevensrecords, het berekenen van formules en aangepaste functies, het uitvoeren van functiecontainers, navigatie en dialoogbesturing, meertaligheid en de verbinding met de daarvoor bestemde databaseadapter.

De runtime bevat echter niet automatisch alle tools van SchallOS Studio. Deze kan geen nieuwe SSC-/SSD-oplossingsparen aanmaken en beschikt niet over een migratie-assistent voor FileMaker-oplossingen.

Zo blijft een opgeleverde klanttoepassing duidelijk gescheiden van de eigenlijke ontwikkelomgeving.

Profielen bepalen de mogelijkheden van een runtime

Niet elke installatie heeft dezelfde functionaliteit nodig. Een applicatie die uitsluitend voor eindgebruikers is bedoeld, hoeft mogelijk alleen gepubliceerde lay-outs en bedrijfsprocessen uit te voeren. Een interne installatie kan aanvullende beheer- of diagnosefuncties nodig hebben.

SchallOS maakt hiervoor gebruik van runtime- en capability-profielen. Deze bepalen over welke technische mogelijkheden een specifieke instantie beschikt.

Een profiel kan bijvoorbeeld bepalen of de lay-outmodus beschikbaar is, of gegevens mogen worden geïmporteerd of geëxporteerd, of beheerdersdialoogvensters worden weergegeven, of lokale instellingen kunnen worden gewijzigd of dat bepaalde interfaces mogen worden gebruikt.

Deze profielen vormen een aanvulling op de gebruikersrechten binnen de eigenlijke oplossing. De gebruikersrechten bepalen wat iemand inhoudelijk mag doen. Het runtime-profiel bepaalt daarentegen welke technische mogelijkheden de betreffende installatie in principe biedt.

Hierdoor kan dezelfde runtime-basis worden gebruikt voor verschillende klantgroepen en toepassingen, zonder dat voor elke variant een aparte programmaversie hoeft te worden ontwikkeld.

Van lokale werkstations tot serveromgevingen

Een SchallOS-oplossing kan in verschillende bedrijfsmodi worden geïmplementeerd. Voor een lokale werkplek kan de SSD bijvoorbeeld in IndexedDB worden opgeslagen. Een install-desktoptoepassing kan gebruikmaken van SQLite. Voor grotere oplossingen met meerdere gebruikers is een centrale database zoals PostgreSQL voorzien.

De bedrijfsmodellen hebben verschillende kenmerken. IndexedDB is vooral geschikt voor lokale browsertoepassingen. SQLite is een beproefde basis voor lokale toepassingen en overzichtelijke installaties. PostgreSQL is geschikt voor centrale systemen met meerdere gebruikers en professioneel serverbeheer.

SchallOS beschouwt deze technologieën niet als volledig onderling uitwisselbare opslaglocaties. Bij het wisselen van adapter is een gecontroleerde gegevensoverdracht, controle en eventueel een rollback nodig. De gezamenlijke SSC-/SSD-architectuur zorgt ervoor dat lay-outs, formules en bedrijfslogica niet voor elke databaseadapter volledig opnieuw hoeven te worden ontwikkeld.

Desktoptoepassingen en het gebruik van browsers

SchallOS-oplossingen moeten zowel in de browser als in de vorm van 1TP12-toepassingen voor Windows en macOS kunnen worden gebruikt. Een desktop-runtime kan nauwer in het betreffende besturingssysteem worden geïntegreerd, op gecontroleerde wijze gebruikmaken van lokale bestanden en, mits correct geconfigureerd, tijdelijk offline werken. De runtime kan gegevens lokaal opslaan met IndexedDB of SQLite, of toegang krijgen tot een centrale PostgreSQL-database.

In de browser wordt de applicatie weergegeven door de eigen SchallOS Runtime. Hiervoor zijn noch een FileMaker-server, noch FileMaker WebDirect nodig. Een gemigreerde FileMaker-oplossing draait na de migratie dus niet meer op een FileMaker-bestand op de achtergrond. Lay-outs, formules en functielogica worden binnen de SchallOS-architectuur uitgevoerd.

SchallOS Control beheert de instanties

SchallOS Control vormt het operationele controlecentrum van het platform. Daar wordt beheerd welke oplossing op welk doelsysteem wordt uitgevoerd en welke technische vereisten van toepassing zijn. Control kan onder andere het volgende weergeven:

• welke SSC-/SSD-combinaties zijn ingezet
• welke runtime-versie installiert is
• welke databaseadapter wordt gebruikt
• welk capaciteitsprofiel is van toepassing
• welke updates beschikbaar zijn
• en wanneer een instantie voor het laatst is gecontroleerd.

Een implementatiedoel kan bijvoorbeeld een lokale Windows-toepassing, een macOS-runtime, een eigen PostgreSQL-server, een testomgeving of een cloudinstantie zijn.

Bedrijfsgegevens zoals serveradressen, databasetoegangen, licenties of lokale apparaatkoppelingen horen niet thuis in de draagbare SSC. Deze worden beheerd in de beveiligde configuratie van de betreffende instantie.

Gesigneerde oplossingen en gecontroleerde distributie

Draagbare oplossingscontainers mogen niet betekenen dat elke toepassing willekeurig kan worden gewijzigd of op niet-voorziene systemen kan worden gestart. Gepubliceerde SSC-/SSD-pakketten kunnen daarom worden gekoppeld aan oplossings-ID’s, controlesommen, handtekeningen en instantie-informatie. De runtime kan bij het opstarten controleren of de SSC ongewijzigd en geldig is ondertekend, of de SSD bij de juiste oplossing hoort, of beide versies compatibel zijn en of er een geldig implementatieprofiel aanwezig is.

Afhankelijk van het licentiemodel kan een toewijzing worden gekoppeld aan een instantie, een server, een apparaat of een bepaalde groep gebruikers. SchallOS Control beheert daarbij ook de nodige wijzigingen, zoals een serverwissel, een heractivering of het herstellen van een installatie.

SchallOS Cloud als SaaS-bedrijfsmodel

SchallOS Cloud biedt applicaties aan als een centraal beheerde online dienst. De cloud maakt echter geen gebruik van een eigen, afwijkend oplossingsformaat. Een in SchallOS Studio ontwikkelde applicatie kan aan een cloudinstantie worden toegewezen en via de browser beschikbaar worden gesteld. Runtime, database, back-ups, monitoring en updates worden centraal beheerd. Voor ontwikkelaars en klanten ontstaat hierdoor een SaaS-model, zonder dat de applicatie speciaal voor een afzonderlijk cloudplatform opnieuw hoeft te worden ontwikkeld.

De principiële overdraagbaarheid blijft behouden. Een oplossing kan later worden overgezet naar een eigen server of naar een andere ondersteunde bedrijfsvorm, mits de gegevensomvang, de functies en de technische vereisten dit toelaten. De overstap blijft een gecontroleerde migratie, maar vereist geen volledige herbouw van de applicatie.

Een oplossing kan meegroeien met de behoeften

Een nieuwe applicatie kan in eerste instantie lokaal worden ontwikkeld en met een kleine dataset worden getest. Later kan deze als interne runtime worden geïmplementeerd, worden omgezet naar SQLite of PostgreSQL en uiteindelijk als server- of cloudoplossing worden gepubliceerd. Tabellen, lay-outs, formules, functiecontainers, vertalingen en documentatie blijven daarbij deel uitmaken van dezelfde oplossingsstructuur.

Niet elk prototype wordt zonder aanpassingen een grote bedrijfsapplicatie. Het gebruik door meerdere gebruikers, de beveiliging, de prestaties en de back-ups moeten nog steeds zorgvuldig worden gepland. Het platform voorkomt echter dat groei onvermijdelijk een volledige technologische omschakeling vereist.

Runtime, Control en Cloud combineren zo verschillende bedrijfsmodellen binnen één gemeenschappelijke architectuur. De applicatie wordt één keer ontwikkeld en vervolgens op een gecontroleerde manier beschikbaar gesteld voor de betreffende toepassing – lokaal, op een eigen server of als SaaS in de cloud.

Graag. Ik zou dit gedeelte direct na het hoofdstuk over AI invoegen, of als aanvulling op hoofdstuk 4. Het pikt een belangrijke gedachte op: AI is niet vast gekoppeld aan één aanbieder, maar wordt – net als database-adapters – behandeld als uitwisselbare infrastructuur.

AI-adapter in plaats van gebondenheid aan een fabrikant

SchallOS scheidt de eigenlijke AI-laag bewust van de gebruikte taalmodellen. Het platform werkt niet uitsluitend met één enkele aanbieder of een bepaalde runtime-omgeving. In plaats daarvan kunnen verschillende AI-adapters worden geconfigureerd en centraal worden beheerd.

Deze adapters vormen de verbinding tussen SchallOS en de gebruikte taalmodellen. Hierdoor blijft de eigenlijke ontwikkelomgeving onafhankelijk van het feit of een verzoek naar een lokaal model of naar een clouddienst wordt verzonden.

De AI wordt daarmee een vervangbaar onderdeel van het platform – net als de database-adapters voor IndexedDB, SQLite of PostgreSQL.

Centraal beheer in SchallOS Control

De configuratie van de AI gebeurt centraal via SchallOS Control. Daar kunnen zoveel AI-adapters als gewenst worden aangemaakt en beheerd. Zowel lokale modellen als clouddiensten worden ondersteund.

Lokale modellen kunnen bijvoorbeeld via Ollama of LM Studio worden geïntegreerd. Voor veel ontwikkelingsopdrachten volstaat een compact lokaal model dat volledig op de eigen computer wordt uitgevoerd.

Daarnaast kunnen cloudmodellen zoals ChatGPT, Claude of andere compatibele diensten worden ingesteld. Elke adapter heeft daarbij zijn eigen configuratie, zoals inloggegevens, eindpunten, modelnamen of andere technische instellingen. Zo ontstaat een centraal overzicht van alle beschikbare AI-systemen binnen een SchallOS-installatie.

Eenmaal ingesteld, overal beschikbaar

Een groot voordeel van deze architectuur is dat een eenmaal geconfigureerde AI-adapter niet slechts op één plek wordt gebruikt. Zodra een adapter in SchallOS Control is geconfigureerd, is deze beschikbaar voor het hele platform. Hij kan bijvoorbeeld worden gebruikt:

• in de formule-editor
• binnen functiecontainers
• voor de automatische documentatie
• bij de migratie van FileMaker-oplossingen
• in de Adapter Studio
• of in toekomstige, door AI ondersteunde ontwikkeltools.

De ontwikkelaar hoeft toegangsgegevens of modellen dus niet meerdere keren te configureren. Het beheer gebeurt centraal, terwijl de afzonderlijke componenten alleen de gewenste adapter selecteren.

Het juiste model voor de betreffende taak

Niet elke ontwikkelingsopdracht vereist dezelfde rekenkracht. Voor een korte uitleg van een formule volstaat vaak een klein lokaal model. Omvangrijke migraties of complexe programmeertaken kunnen daarentegen baat hebben bij een krachtiger cloudmodel.

SchallOS biedt daarom de mogelijkheid om, afhankelijk van de toepassing, verschillende adapters te kiezen. Een ontwikkelaar kan bijvoorbeeld instellen dat eenvoudige documentatie altijd lokaal wordt aangemaakt, terwijl bijzonder omvangrijke taken worden overgedragen aan een extern model. Hierdoor kunnen snelheid, gegevensbescherming en kosten beter op elkaar worden afgestemd.

Open voor toekomstige modellen

De ontwikkelingen op het gebied van kunstmatige intelligentie gaan buitengewoon snel. Er verschijnen met korte tussenpozen nieuwe modellen, terwijl bestaande systemen voortdurend worden verbeterd. SchallOS legt zich daarom niet permanent vast op één enkele aanbieder. Niet de naam van een bepaald model is doorslaggevend, maar de gestandaardiseerde adapterinterface.

Nieuwe lokale of cloudgebaseerde AI-systemen kunnen hierdoor later worden toegevoegd zonder dat de eigenlijke ontwikkelomgeving hoeft te worden aangepast. Deze openheid sluit aan bij de basisarchitectuur van SchallOS. Net als bij de database-adapters moeten ook AI-adapters uitwisselbaar blijven, terwijl Studio, Runtime en de eigenlijke toepassing ongewijzigd kunnen blijven werken.

Hierdoor wordt kunstmatige intelligentie een permanent geïntegreerde platformfunctie – ongeacht welke modellen of aanbieders zich de komende jaren op de markt zullen doorzetten.

Een zelflerende AI-laag in plaats van statische prompts

Een belangrijke vooruitgang van SchallOS is dat de geïntegreerde AI niet langer uitsluitend met statische systeemprompts werkt. In plaats daarvan ontstaat er een zelflerende AI-laag die haar werkwijze voortdurend verbetert aan de hand van echte ontwikkelingsprojecten.

Elke programmeercyclus van een functiecontainer kan – indien de ontwikkelaar dat wenst – geanonimiseerde kwaliteitsgegevens opleveren. Daarnaast zijn er reproduceerbare benchmarktests beschikbaar, waarbij echte functiecontainers van een oplossing automatisch worden getest met verschillende lokale en cloud-AI-modellen. SchallOS beoordeelt daarbij niet alleen de snelheid, maar vooral ook de kwaliteit van de gegenereerde resultaten, gedetecteerde fouten, reparatiecycli en de naleving van gedefinieerde programmeerovereenkomsten.

Op basis van deze gegevens worden automatisch gemarkeerde modelprofielen, leerpatronen en anti-patronen gegenereerd. Het platform leert zo niet alleen welke prompt beter werkt, maar ook welke strategieën daadwerkelijk hun nut hebben bewezen voor bepaalde modelfamilies, taken en foutensituaties.

AI-kwalificatie van L1 tot L4

SchallOS introduceert een meerfasige kwalificatie van de gebruikte AI-modellen. In plaats van elk model zonder meer als „geschikt“ of „ongeschikt“ te classificeren, vindt er een beoordeling plaats op basis van verschillende taakgebieden. Een model kan bijvoorbeeld voor FileMaker-migraties het hoogste kwalificatieniveau bereiken, terwijl het voor semantische nieuwe ontwikkelingen in eerste instantie slechts in beperkte mate wordt aanbevolen. De classificatie is niet gebaseerd op gegevens van de fabrikant, maar uitsluitend op reproduceerbare benchmarks en daadwerkelijke productieruns.

Hierdoor kan SchallOS automatisch bepalen welk model voor een bepaalde taak de grootste kans op succes biedt en wanneer het zinvol is om een krachtiger of alternatief model in te zetten.

Slimme modelprofielen in plaats van klassieke prompts

Elk ondersteund AI-model krijgt voortaan een eigen, van een versienummer voorzien modelprofiel. Dit beschrijft niet alleen de eigenlijke systeeminstructie, maar bevat ook de ervaringen die in de praktijk zijn opgedaan met precies dit model.

SchallOS zal voortaan onder andere onderscheid maken tussen profielen voor:

• semantische functiecontainers
• FileMaker-migraties
• latere migraties naar Microsoft Access, 4D of Oracle
• en andere bronsystemen

Deze profielen worden aangevuld met bewerkbare basisteksten voor profielen, die door de ontwikkelaar kunnen worden aangepast of verder kunnen worden ontwikkeld via automatische optimalisatiecampagnes. Hierdoor kan SchallOS 's nachts verschillende varianten testen en de meest succesvolle strategieën automatisch overnemen.

Solution Capabilities als intelligente vakgebonden interface

Naast de technische platformmogelijkheden introduceert SchallOS in de toekomst ook oplossingsmogelijkheden. Deze beschrijven de functionele mogelijkheden van een concrete toepassing en vormen de openbare interface tussen AI en bedrijfslogica. Voorbeelden hiervan zijn functies zoals:

• Klant aanmaken
• Een offerte opstellen
• Opdracht aannemen
• Factuur aanmaken
• Betaling boeken

De AI mag uitsluitend via deze vrijgegeven capabilities met een oplossing communiceren. Directe toegang tot interne functiecontainers is bewust uitgesloten. Hierdoor blijft te allen tijde traceerbaar welke acties een AI daadwerkelijk mag uitvoeren.

De ontwikkelaar kan op een gebruiksvriendelijke manier eigen Solution Capabilities definiëren en van een versie voorzien. Deze worden samen met de oplossing opgeslagen in het SSC en staan zowel ter beschikking van de ontwikkelings-AI als later van de eindgebruikers.

Leren van echte projecten

De geïntegreerde benchmark-engine werkt niet met kunstmatige voorbeeldprogramma's, maar gebruikt desgewenst echte functiecontainers van de betreffende oplossing als testbasis. Hierdoor ontstaat voor elke toepassing een individuele AI-kwalificatie die precies is afgestemd op de eigen programmeerstijl, de gebruikte bedrijfsobjecten en de beschikbare functiecontainers.

Hoe langer een oplossing wordt gebruikt en verder ontwikkeld, hoe uitgebreider de bijbehorende leerpatronen worden en hoe nauwkeuriger SchallOS geschikte modellen kan selecteren, fouten kan voorkomen en automatisch nieuwe functies kan genereren.

De eigenlijke intelligentie ligt dus niet meer uitsluitend in het taalmodel zelf, maar in toenemende mate in de oplossing en de voortdurend groeiende ervaringskennis daarvan.

Adapter Studio als universeel integratieplatform

Met de nieuwe Studio-adapter ontwikkelt SchallOS zich tot een open integratieplatform. Externe systemen kunnen voortaan via gestandaardiseerde adapters worden geïntegreerd – of het nu gaat om databases, clouddiensten, REST-interfaces of AI-systemen.

Hierdoor ontstaan er geen starre, propriëtaire integraties meer. In plaats daarvan kunnen ontwikkelaars via Solution Capabilities willekeurige externe systemen aan hun applicatie koppelen. Zelfs complexe hybride oplossingen, waarbij meerdere ERP-systemen parallel worden gebruikt, kunnen op deze manier op elegante wijze worden gecoördineerd. De AI maakt daarbij uitsluitend gebruik van gedefinieerde Capabilities en hoeft noch interne gegevensstructuren, noch technische details van de aangesloten systemen te kennen.

Kennis wordt het eigenlijke kapitaal

Met SchallOS verschuift het zwaartepunt van de moderne softwareontwikkeling aanzienlijk. Niet langer vormt de eigenlijke programmacode de grootste waarde van een toepassing, maar de gestructureerde kennis daarover. SchallOS ondersteunt ook het nieuwe OKF-formaat, dat Google in juni 2026 heeft gepubliceerd om kennis later ook op een draagbare manier te kunnen integreren of delen.

Functiecontainers, kennislagen, leerpatronen, capaciteitscontracten, benchmarkresultaten en modelgeoptimaliseerde profielen vormen samen een onderdeel van de oplossing en kunnen samen met deze oplossing worden overgedragen, van een versie worden voorzien en voortdurend verder worden ontwikkeld.

Daardoor ontwikkelt elke SchallOS-toepassing in de loop van de tijd haar eigen, steeds beter wordende AI-competentie, die direct aan de oplossing gekoppeld blijft.

Van de FileMaker-migratie naar een onafhankelijk softwareplatform

SchallOS is voortgekomen uit de jarenlange samenwerking met FileMaker. Veel basisideeën van het platform zijn gebaseerd op ervaringen met individuele database- en ERP-oplossingen, die in de loop der jaren samen met de bedrijfsbehoeften zijn meegegroeid.

FileMaker blinkt uit in snelle ontwikkeling. Het gegevensmodel, de lay-outs en de programmalogica liggen dicht bij elkaar, wijzigingen zijn direct zichtbaar en de eerste werkende oplossingen kunnen relatief snel worden gerealiseerd.

Deze nauwe band tussen ontwikkelaar, gegevens en gebruikersinterface moet in SchallOS behouden blijven. De technische basis wordt echter opnieuw opgebouwd. SchallOS maakt gebruik van een eigen runtime, eigen structuur- en gegevenscontainers, een AI-ondersteunde functielaag en een eigen infrastructuur voor documentatie, implementatie en updates.

FileMaker blijft daarmee een belangrijk uitgangspunt en een mogelijke bron voor bestaande oplossingen. Voor de latere exploitatie is het echter niet meer nodig.

Migratie is meer dan alleen het importeren van een lay-out

Een uitgebouwde FileMaker-oplossing bestaat niet alleen uit tabellen, velden en zichtbare schermen. Een groot deel van de vakkennis zit verwerkt in formules, scripts, triggers, relaties, waardelijsten en talrijke speciale gevallen.

Een succesvolle migratie moet deze verbanden in kaart brengen en naar een nieuwe architectuur overbrengen. Tabellen, velden, relaties en lay-outs kunnen daarbij grotendeels gestructureerd worden overgenomen. Formules en aangepaste functies worden overgebracht naar de SchallOS-formuleomgeving of aangepast.

Bij de FileMaker-scripts staat in eerste instantie het begrip van hun functionele taak centraal. Ze kunnen als leer- en referentielaag op de achtergrond van de nieuwe functiecontainers behouden blijven. De uitvoerbare code wordt echter door de AI opnieuw geprogrammeerd, zodat deze aansluit bij de SchallOS-architectuur. Hierdoor ontstaat er geen FileMaker-runtime binnen een nieuw systeem. De bestaande oplossing wordt stapsgewijs omgevormd tot een zelfstandige SchallOS-toepassing.

Onafhankelijke werking na de migratie

Na een volledige migratie zijn noch FileMaker Pro, noch FileMaker Server, noch WebDirect nog nodig. De nieuwe applicatie maakt gebruik van SchallOS Runtime, de SSC als structuurcontainer en de SSD voor de productieve gegevens. Formules, functiecontainers, meertaligheid, documentatie, gebeurtenislogboeken en updates worden door het SchallOS-platform geleverd.

Afhankelijk van de vereisten kan de oplossing lokaal, als Windows- of macOS-toepassing, op een eigen server of als SaaS-oplossing in SchallOS Cloud worden gebruikt.

Hiermee komt er een einde aan de afhankelijkheid van één enkele propriëtaire runtime-omgeving. Technische afhankelijkheden verdwijnen hierdoor niet volledig – elke moderne software heeft besturingssystemen, databases en serverdiensten nodig. De structuur, de bedrijfslogica en de gegevens blijven echter draagbaar en kunnen via gedocumenteerde adapters en implementatiemethoden worden gebruikt.

Nieuwe mogelijkheden voor FileMaker-ontwikkelaars

Voor FileMaker-ontwikkelaars moet SchallOS geen volledige breuk met de huidige werkwijze betekenen. Kennis van datamodellen, lay-outontwerp en bedrijfsprocessen blijft waardevol.

Wat vooral verandert, is de manier waarop de programmalogica wordt geïmplementeerd. Lange reeksen scripts maken plaats voor semantisch beschreven functiecontainers. De AI programmeert de uitvoerbare code op basis van gedefinieerde taken, parameters en grenzen. De ontwikkelaar controleert het resultaat en blijft verantwoordelijk voor de architectuur en de inhoudelijke juistheid.

Ook wordt er meer rekening gehouden met de ontwikkelingsgeschiedenis. Wijzigingen kunnen automatisch worden geregistreerd, gedocumenteerd en gebundeld in releases. Dezelfde updatepijplijn waarmee SchallOS zelf wordt bijgewerkt, is ook beschikbaar voor eigen klantoplossingen.

Hierdoor verschuift het werk gedeeltelijk van het handmatig invoeren van afzonderlijke programmastappen naar het nauwkeurig beschrijven, controleren en structureren van bedrijfsprocessen.

Niet alleen voor gemigreerde applicaties

De FileMaker-migratie blijft een belangrijk onderdeel van SchallOS, maar is niet het enige toepassingsgebied. Nieuwe toepassingen kunnen volledig in SchallOS Studio worden ontwikkeld.

Op de lange termijn zouden ook andere bronsystemen kunnen worden ondersteund. Een dergelijke uitbreiding vereist echter telkens eigen analyse- en migratieprocedures. Verschillende ontwikkelingsplatforms hebben hun eigen concepten, die niet op zinvolle wijze kunnen worden weergegeven door middel van een oppervlakkige universele import.

De ervaringen die zijn opgedaan bij de FileMaker-migratie vormen hiervoor een basis. Het eigenlijke doel van SchallOS ligt echter in de ontwikkeling en het beheer van onafhankelijke bedrijfsapplicaties.

Geplande start in het najaar van 2026

De officiële lancering van SchallOS staat gepland voor het najaar van 2026. Tot die tijd zullen de belangrijkste onderdelen van het platform verder worden geïntegreerd, getest en voorbereid voor de eerste productieve toepassingen. Niet elke functie die op de lange termijn is gepland, zal bij de lancering al volledig zijn uitgebouwd. Cruciaal is een robuuste kern waarop verdere database-adapters, AI-functies, migratiemogelijkheden en bedrijfsmodellen op gecontroleerde wijze kunnen worden uitgebouwd.

Allereerst wordt de gFM-NEXT ERP-software van gofilemaker.de zal naar verwachting in september 2026 op het nieuwe SchallOS-platform worden gepubliceerd. De lancering van het SchallOS-ontwikkelingsplatform iets later in het najaar van 2026 betekent daarom niet het einde van de ontwikkeling, maar het begin van de praktische toepassing.

De volledige levenscyclus van een applicatie

SchallOS begon met de vraag hoe bestaande FileMaker-oplossingen naar een moderne omgeving kunnen worden overgezet. Hieruit is een platform ontstaan dat niet alleen rekening houdt met migratie en ontwikkeling, maar ook met documentatie, implementatie, gegevensbeheer, updates en langdurig gebruik. Studio, Runtime, Control en Cloud vervullen daarbij duidelijk gescheiden taken binnen een gemeenschappelijke architectuur. Het is dan ook niet de bedoeling om FileMaker louter te vervangen door een andere ontwikkeltool. SchallOS moet de beproefde nauwe band tussen ontwikkelaar, gegevens en gebruikersinterface combineren met draagbare containers, AI-ondersteunde programmering en een doorlopend bedrijfsmodel.

Het FileMaker-DNA vormt het uitgangspunt. Het doel is een onafhankelijk platform waarop bestaande en nieuwe bedrijfsapplicaties op de lange termijn kunnen worden ontwikkeld, geëxploiteerd en onderhouden.

Huidige artikelen over kunstmatige intelligentie

Onsterfelijkheid door technologie: hoe ver zijn onderzoek en AI nu echt gekomen?

Onsterfelijkheid door technologie: hoe ver zijn onderzoek en AI nu echt gekomen?

Hoe AI-specialisten vandaag de dag kunnen worden opgeleid - mogelijkheden voor bedrijven en cursisten

Hoe AI-specialisten vandaag de dag kunnen worden opgeleid - mogelijkheden voor bedrijven en cursisten

AI Studio 2025: Welke hardware is echt de moeite waard - van de Mac Studio tot de RTX 3090

AI Studio 2025: Welke hardware is echt de moeite waard - van de Mac Studio tot de RTX 3090

Software ontwikkelen met Codex, ChatGPT en AI: een praktische gids voor ontwikkelaars

Software ontwikkelen met Codex, ChatGPT en AI: een praktische gids voor ontwikkelaars

Veelgestelde vragen

1. Wat is SchallOS precies, en waarin verschilt het van een klassieke databaseapplicatie?
   SchallOS is een platform voor de ontwikkeling, uitvoering en het beheer van op maat gemaakte bedrijfssoftware. Het omvat niet alleen tabellen, lay-outs en functies, maar ook AI-ondersteunde programmering, documentatie, gebeurtenislogboeken, implementatie en updates. SchallOS Studio dient voor de ontwikkeling, Runtime voert voltooide applicaties uit, Control beheert installaties en Cloud stelt oplossingen als SaaS beschikbaar. Zo begeleidt het platform een applicatie vanaf het ontstaan tot en met de langdurige exploitatie.
2. Voor welke ontwikkelaars en bedrijven is SchallOS bedoeld?
   SchallOS richt zich met name op FileMaker-ontwikkelaars, softwarebedrijven en ontwikkelaars van maatwerktoepassingen. Ook bedrijven met bestaande FileMaker-oplossingen krijgen de mogelijkheid om hun toepassingen stapsgewijs over te zetten naar een onafhankelijke omgeving. Bovendien kunnen nieuwe oplossingen volledig binnen SchallOS worden ontwikkeld. Voor bedrijfsleiders en technische besluitvormers is het vooral interessant dat ontwikkeling, beheer, documentatie, updates en verschillende implementatievormen binnen één gemeenschappelijk platform worden georganiseerd.
3. Is SchallOS vooral een vervanging voor FileMaker?
   FileMaker is een belangrijk uitgangspunt, maar vormt niet de permanente technische basis van SchallOS. Beproefde ideeën, zoals visuele ontwikkeling en de nauwe koppeling tussen gegevens, lay-outs en functies, worden overgenomen. De runtime, gegevensopslag, functielogica en update-infrastructuur worden echter zelfstandig opgebouwd. SchallOS kan bestaande FileMaker-oplossingen migreren, maar is eveneens geschikt voor nieuwe toepassingen. Na een volledige migratie is FileMaker niet langer nodig voor de productieve werking.
4. Kan mijn bestaande FileMaker-oplossing volledig automatisch worden gemigreerd?
   Tabellen, velden, relaties, lay-outs en andere gedefinieerde structuren kunnen grotendeels automatisch worden overgenomen. Bij complexe bedrijfslogica is echter een aanvullende controle nodig. FileMaker-scripts bevatten vaak lay-outwijzigingen, globale variabelen, plug-ins of historische uitzonderingsgevallen. De AI kan deze processen analyseren en op basis daarvan nieuwe functiecontainers aanmaken. Een uitgebreide oplossing moet echter nog steeds door een ontwikkelaar worden gecontroleerd en indien nodig worden bijgewerkt. De migratie vermindert de handmatige inspanning aanzienlijk, maar vervangt niet het vakkundige inzicht in de toepassing.
5. Wat gebeurt er na de migratie met de bestaande FileMaker-scripts?
   De scripts kunnen op de achtergrond van de nieuwe functiecontainers behouden blijven als leer- en referentielaag. Ze worden echter niet ongewijzigd uitgevoerd. De AI analyseert welke functionele taak een script vervult, welke velden worden gebruikt en welke voorwaarden worden gecontroleerd. Vervolgens programmeert de AI de nieuwe uitvoerbare code, afgestemd op de SchallOS-architectuur. Het oorspronkelijke script blijft behouden als historische kennisbron en kan bij latere vragen of uitbreidingen nog steeds in aanmerking worden genomen.
6. Wat zijn SSC en SSD, en waarom heeft een oplossing twee containers nodig?
   De SSC bevat de structuur van de applicatie, waaronder tabellen, velden, lay-outs, formules, functiecontainers, talen en documentatie. De SSD bevat de productieve gegevens, zoals klanten, artikelen, orders of facturen. Beide containers horen bij elkaar, maar hebben verschillende taken. Door deze scheiding is het mogelijk om nieuwe structuurversies te implementeren zonder de volledige gegevensset te hoeven vervangen. Bovendien kunnen gegevensbeheer, back-ups en bedrijfsmodellen worden aangepast zonder dat de applicatie volledig opnieuw hoeft te worden ontwikkeld.
7. Welke voordelen biedt het scheiden van structuur en gegevens?
   Updates, back-ups en migraties kunnen hierdoor veel gecontroleerder worden uitgevoerd. Er kan een nieuwe SSC worden gepubliceerd, terwijl de SSD met de klantgegevens behouden blijft. Noodzakelijke structuurwijzigingen worden uitgevoerd via gedefinieerde gegevensmigraties. De SSC kan bovendien zonder vertrouwelijke bedrijfsgegevens worden geanalyseerd of aan een andere ontwikkelaar worden overgedragen. Ook een overstap van IndexedDB naar SQLite, PostgreSQL of naar de cloud wordt vereenvoudigd, omdat lay-outs en functionele logica niet opnieuw hoeven te worden opgebouwd.
8. Kan dezelfde oplossing lokaal, op een server en in de cloud worden gebruikt?
   In principe wel. Een SchallOS-oplossing kan lokaal in de browser, als Windows- of macOS-toepassing, met SQLite, op een PostgreSQL-server of als SaaS in de SchallOS Cloud worden gebruikt. De functionele toepassing blijft daarbij hetzelfde. Verschillende bedrijfsvormen stellen echter hun eigen eisen aan het gebruik door meerdere gebruikers, back-ups, prestaties en beheer. Een overstap vindt daarom op gecontroleerde wijze plaats via gegevensoverdracht en controle. De SSC-/SSD-architectuur voorkomt dat voor elk doel een volledig nieuw project moet worden onderhouden.
9. Heb ik na een succesvolle migratie nog steeds FileMaker of FileMaker Server nodig?
   Nee. Na een volledige migratie wordt de applicatie uitgevoerd door SchallOS Runtime. Ook voor gebruik in de browser zijn noch FileMaker-servers, noch WebDirect nodig. Het vroegere FileMaker-systeem kan als referentie of archief behouden blijven, maar is geen vereiste voor productief gebruik. Lay-outs, formules, functies, gegevenstoegang, updates en implementatie worden door SchallOS overgenomen. Hierdoor vervallen ook de eerdere FileMaker-afhankelijkheden van de runtime voor de gemigreerde applicatie.
10. Hoe is de kunstmatige intelligentie in SchallOS geïntegreerd?
    De AI is direct beschikbaar in de formule-editor, in aangepaste functies, functiecontainers en in de documentatielaag. Ze kent niet alleen de huidige vraag, maar ook de betreffende velden, tabellen, beschrijvingen en afhankelijkheden. Bij gemigreerde oplossingen kan bovendien het oorspronkelijke FileMaker-script als achtergrondkennis dienen. De AI kan formules uitleggen, code genereren, fouten onderzoeken en documentatie opstellen. De modellen moeten in principe uitwisselbaar blijven, zodat rekening kan worden gehouden met kwaliteit, kosten en gegevensbescherming.
11. Programmeert de AI daadwerkelijk de code van de functiecontainers?
    Ja. De ontwikkelaar beschrijft de taak, de parameters, het verwachte resultaat en de toegestane mogelijkheden. Op basis daarvan genereert de AI de uitvoerbare code. Deze blijft zichtbaar, controleerbaar en kan in versies worden vastgelegd. De ontwikkelaar kan wijzigingen aanvragen, tests uitvoeren en eerdere versies vergelijken of herstellen. De AI neemt daarmee een groot deel van het programmeerwerk voor zijn rekening, maar niet de vaktechnische verantwoordelijkheid. Juist bij bedrijfskritische processen moeten vereisten, rechten en mogelijke neveneffecten zorgvuldig blijven worden gecontroleerd.
12. Welke mogelijkheden biedt de formule-editor?
    De formule-editor ondersteunt typische wiskundige, logische en tekstgerelateerde berekeningen, evenals datum- en tijdberekeningen. Formules en aangepaste functies worden in realtime verwerkt en kunnen direct worden getest. Het aanvankelijke aantal commando’s is kleiner dan de in de loop der jaren gegroeide functiebibliotheek van FileMaker. De formuleomgeving is echter uitbreidbaar. Ontbrekende functies kunnen worden aangevuld of door eigen aangepaste functies worden gerealiseerd. Ook daarbij kan de geïntegreerde AI bestaande FileMaker-formules overnemen of nieuwe berekeningen ontwikkelen.
13. Wat registreert SchallOS automatisch?
    Op structuurniveau worden wijzigingen aan tabellen, velden, lay-outs, formules en functiecontainers vastgelegd. Op gegevensniveau kunnen wijzigingen in gegevensrecords, statuswijzigingen, vrijgaven, importen en andere functionele gebeurtenissen worden geregistreerd. Daarnaast zijn er operationele gebeurtenissen zoals implementaties, updates en back-ups. Bijbehorende ontwikkelingswerkzaamheden kunnen worden gebundeld in wijzigingssessies en later aan een release worden toegewezen. Zo ontstaat een traceerbare geschiedenis van de applicatie, in plaats van slechts een verzameling achteraf geschreven notities.
14. Kan SchallOS hiermee klant- en prestatierapporten opstellen?
    Ja. De geïntegreerde AI kan op basis van de geregistreerde gebeurtenissen technische documentatie, klantrapporten, release notes of prestatierapporten genereren. Meerdere technische wijzigingen kunnen daarbij worden samengevat tot een begrijpelijke beschrijving van de zakelijke voordelen. De onderliggende gebeurtenissen blijven zichtbaar, zodat de ontwikkelaar de formuleringen kan controleren. Niet elke wijziging komt automatisch in aanmerking voor facturering. De selectie, beoordeling en goedkeuring van het definitieve prestatieverslag blijven daarom bij de ontwikkelaar.
15. Hoe werkt de update-pijplijn?
    Wijzigingen worden eerst verzameld in Change Sessions en gebundeld tot een release. Een release kan een nieuwe SSC, noodzakelijke SSD-migraties, vereisten, handtekeningen, controles en rollback-informatie bevatten. SchallOS Control controleert de doelinstantie, maakt een back-up en voert vervolgens de update uit. Na de installatie wordt gecontroleerd of de structuur, gegevens en belangrijke functies overeenkomen met de verwachte toestand. Dezelfde basis-pipeline wordt gebruikt voor SchallOS zelf en voor de daarmee ontwikkelde klantoplossingen.
16. Wat is het verschil tussen Runtime, Control en Cloud?
    SchallOS Runtime voert gepubliceerde applicaties uit en stelt lay-outs, formules en functiecontainers ter beschikking. SchallOS Control beheert instanties, databaseadapters, runtime-profielen, updates en technische controles. SchallOS Cloud biedt runtime en gegevensopslag aan als een centraal beheerde SaaS-dienst. SchallOS Studio blijft de eigenlijke ontwikkelomgeving. Alle onderdelen maken gebruik van dezelfde SSC- en SSD-basisstructuren, maar vervullen duidelijk van elkaar gescheiden taken binnen de levenscyclus van een applicatie.
17. Hoe worden rechten, installaties en gevoelige gegevens beschermd?
    Gebruikersrechten bepalen welke zakelijke handelingen een persoon binnen de oplossing mag uitvoeren. Runtime- en capability-profielen leggen bovendien vast over welke technische functies een installatie überhaupt beschikt. SSC- en SSD-pakketten kunnen worden beveiligd met identificatiecodes, controlesommen en handtekeningen. Ook de AI-context kan worden beperkt, zodat niet automatisch alle klantgegevens worden verwerkt. Voor bijzonder gevoelige omgevingen kunnen eigen servers of in de toekomst ook lokale AI-modellen worden gebruikt. De concrete beveiligingsconfiguratie is afhankelijk van de specifieke toepassing.
18. Wanneer komt SchallOS op de markt?
    De officiële lancering staat gepland voor het najaar van 2026. De focus ligt in eerste instantie op Studio en Runtime, de scheiding tussen SSC en SSD, de migratie van bestaande FileMaker-structuren, formules, aangepaste functies, door AI geprogrammeerde functiecontainers, documentatie, gebeurtenislogboeken, implementatie en updates. Ook SchallOS Control zal een centrale rol spelen bij het beheer van de installaties. Niet elke functie die op lange termijn is gepland, hoeft bij de start al volledig te zijn uitgebouwd. In eerste instantie is een robuuste kern voor de eerste productieve toepassingen van cruciaal belang.

Huidige artikelen over kunst & cultuur

Dieter Bohlen in klare taal: Waarom Duitsland faalt door zijn eigen bureaucratie

Dieter Bohlen in klare taal: Waarom Duitsland faalt door zijn eigen bureaucratie

Helge Schneider: Houding, humor en de vrijheid om jezelf niet te hoeven verantwoorden

Helge Schneider: Houding, humor en de vrijheid om jezelf niet te hoeven verantwoorden

Toekomst met een oplader - Mr von L'oreot koopt een e-scooter

Toekomst met een oplader - Mr von L'oreot koopt een e-scooter

Jan-Josef Liefers: Een portret van houding, afkomst en artistieke vrijheid

Jan-Josef Liefers: Een portret van houding, afkomst en artistieke vrijheid