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.
Von der FileMaker-Migration zur eigenen Plattform
Der ursprüngliche Ausgangspunkt von SchallOS war die Migration bestehender FileMaker-Lösungen. FileMaker hat sich über Jahrzehnte als leistungsfähige Umgebung für individuelle Datenbankanwendungen bewährt. Besonders die enge Verbindung von Datenmodell, Layout und Programmlogik ermöglicht eine schnelle und praxisnahe Entwicklung.
Eine gewachsene FileMaker-Lösung besteht jedoch aus weit mehr als Tabellen und sichtbaren Masken. Sie enthält Berechnungen, Skripte, Benutzerrechte, Drucklayouts, Schnittstellen und zahlreiche betriebliche Sonderfälle. Eine brauchbare Nachfolgeplattform muss diese Zusammenhänge aufnehmen und anschließend unabhängig weiterführen können.
Aus dieser Aufgabe entwickelte sich SchallOS schrittweise zu einer eigenständigen Plattform. Bestehende FileMaker-Lösungen sollen migriert werden können, zugleich lassen sich neue Anwendungen unmittelbar in SchallOS entwickeln. Nach einer vollständigen Migration wird FileMaker für den produktiven Betrieb nicht mehr benötigt.
Entwicklung, Laufzeit und Betrieb bleiben getrennt
Die SchallOS Entwicklungsplattform besteht aus mehreren Bereichen mit klaren Aufgaben.
- SchallOS Studio ist die Entwicklungsumgebung. Dort entstehen Datenstrukturen, Layouts, Formeln, Funktionen, Sprachen und Releases. Auch der Migrationsassistent für vorhandene FileMaker-Lösungen gehört zum Studio.
- SchallOS Runtime führt veröffentlichte Anwendungen aus. Sie stellt die Benutzeroberfläche und die benötigte Programmlogik bereit, ohne automatisch sämtliche Entwicklungswerkzeuge freizugeben.
- SchallOS Control verwaltet Deployment-Ziele, Datenbankverbindungen, Runtime-Profile, Updates und technische Prüfungen.
- SchallOS Cloud stellt Anwendungen als zentral betriebenen Onlinedienst bereit. Dabei soll kein getrenntes Cloud-Format entstehen. Lokale, serverbasierte und cloudbasierte Installationen verwenden dieselbe grundlegende Lösungsarchitektur.
Diese Trennung verhindert, dass Entwicklung, Anwendung und Administration unkontrolliert miteinander vermischt werden. Gleichzeitig bleiben alle Bereiche technisch aufeinander abgestimmt.
Eine Lösung für verschiedene Betriebsmodelle
Eine Business-Anwendung kann klein beginnen und später wachsen. Zunächst reicht möglicherweise ein lokaler Einzelplatz. Später kommen weitere Mitarbeiter, ein zentraler Server oder mehrere Standorte hinzu. SchallOS soll deshalb dieselbe grundsätzliche Lösung für unterschiedliche Betriebsformen bereitstellen können: lokal im Browser, als Windows- oder macOS-Anwendung, mit SQLite oder PostgreSQL sowie als SaaS-Lösung in der Cloud.
Nicht jede Betriebsform besitzt dieselben technischen Eigenschaften. Eine lokale Datenbank stellt andere Anforderungen als ein zentraler Mehrbenutzerbetrieb. Entscheidend ist jedoch, dass Layouts, Funktionen und Datenmodell nicht für jedes Ziel vollständig neu entwickelt werden müssen.
Der Lebenszyklus gehört zur Architektur
Dokumentation, Ereignisprotokolle und Updates werden bei SchallOS nicht erst nachträglich an eine fertige Anwendung angebaut. Sie gehören zur grundlegenden Architektur.
Struktur und produktive Daten werden getrennt verwaltet. Entwicklungsänderungen können protokolliert und zu Releases zusammengefasst werden. Updates lassen sich prüfen, verteilen und bei Problemen kontrolliert zurücksetzen. Die integrierte KI unterstützt nicht nur bei Formeln und Funktionen, sondern auch bei Dokumentation und Kundenkommunikation.
Damit verbindet SchallOS Bereiche, die in klassischen Projekten häufig getrennt behandelt werden. Die Entwicklung einer Anwendung ist nicht mehr das Ende des technischen Prozesses, sondern der erste Abschnitt eines langfristig geplanten Lebenszyklus.
SSC und SSD als portable Struktur- und Datencontainer
Viele Datenbankanwendungen speichern Struktur, Benutzeroberfläche, Programmlogik und produktive Daten in einer eng verbundenen Einheit. Das ist zu Beginn bequem, erschwert aber spätere Updates, Migrationen und unterschiedliche Betriebsformen. Sobald mehrere Kundeninstallationen, größere Datenbestände oder individuelle Erweiterungen hinzukommen, wird der Austausch einer kompletten Anwendungsdatei schnell problematisch.
SchallOS trennt deshalb die Beschreibung einer Lösung grundsätzlich von ihren Geschäftsdaten. Eine Anwendung besteht im Kern aus zwei zusammengehörigen Containern: dem SSC für die Struktur und dem SSD für die produktiven Daten.
Beide Container bilden gemeinsam die vollständige Lösung, erfüllen aber unterschiedliche Aufgaben. Der SSC beschreibt, wie die Anwendung aufgebaut ist und funktioniert. Der SSD enthält die Inhalte, die während ihrer Nutzung entstehen.
Der SSC beschreibt die Anwendung
Die SSC-Datei ist der portable Strukturcontainer einer SchallOS-Lösung. In ihm liegen unter anderem:
- Tabellen- und Felddefinitionen
- Beziehungen
- Layouts und Layoutobjekte
- Formeln und eigene Funktionen
- Funktionscontainer
- Trigger und Navigation
- Sprach- und Übersetzungsinformationen
- Dokumentation
- Versions- und Releaseangaben
Der SSC enthält damit nicht die Kunden, Artikel, Aufträge oder Rechnungen selbst. Er legt fest, welche Datenstrukturen vorhanden sind, wie sie dargestellt werden und welche Funktionen mit ihnen arbeiten.
Auch die semantische Bedeutung einer Lösung gehört in diesen Container. Ein Feld kann neben seinem technischen Namen eine fachliche Beschreibung, Übersetzungen, Validierungsregeln und Hinweise für die KI-Schicht besitzen. Dadurch wird die Struktur nicht nur maschinenlesbar, sondern auch für Entwickler, Dokumentation und Migration verständlicher.
Der SSC bildet somit ein portables Modell der Anwendung, das unabhängig von einem bestimmten Datenbestand weiterentwickelt und veröffentlicht werden kann.
Der SSD enthält die produktiven Daten
Die SSD-Datei ist der Datencontainer der Lösung. Er enthält die Datensätze, die im täglichen Betrieb entstehen, beispielsweise Kunden, Angebote, Aufträge, Rechnungen, Lagerbewegungen oder Termine. Zusätzlich können dort fachliche Historien und Datenereignisse gespeichert werden. Dazu gehören etwa Statuswechsel, Freigaben, Importe oder Änderungen an besonders wichtigen Feldern.
Die Bezeichnung SSD meint dabei keinen physischen Datenträger, sondern die logische Datenebene der Anwendung. Wie diese Daten technisch gespeichert werden, hängt vom gewählten Deployment und Datenbankadapter ab.
Für einen lokalen Einzelplatz kann IndexedDB verwendet werden. Eine Desktop-Anwendung kann mit SQLite arbeiten, während größere Mehrbenutzerinstallationen PostgreSQL einsetzen. Der SSD bleibt in allen Fällen der fachliche Datencontainer, auch wenn sich die technische Speicherung unterscheidet.
Zwei Container müssen eindeutig zusammengehören
Die Trennung von Struktur und Daten darf nicht dazu führen, dass beliebige Container miteinander kombiniert werden. SchallOS muss prüfen können, ob ein SSC und ein SSD tatsächlich derselben Lösung angehören und ob ihre Versionsstände zueinander passen.
Dafür können Lösungskennungen, Containerkennungen, Strukturversionen, Prüfsummen und Signaturen verwendet werden. Vor dem Start oder einem Update lässt sich dadurch feststellen, ob die Kombination gültig ist und ob notwendige Datenmigrationen bereits durchgeführt wurden.
Diese Prüfung verhindert beispielsweise, dass versehentlich der Strukturcontainer einer anderen Anwendung mit einem produktiven Datenbestand geöffnet wird. Sie schützt außerdem davor, dass eine neue SSC-Version aktiviert wird, obwohl der SSD noch nicht auf die dafür erforderliche Datenstruktur vorbereitet wurde.
Portabilität zwischen verschiedenen Betriebsformen
Die SSC-/SSD-Trennung schafft die Grundlage dafür, eine Anwendung in unterschiedlichen Umgebungen zu betreiben. Layouts, Formeln und Funktionslogik müssen nicht für jeden Datenbankadapter neu entwickelt werden.
Eine Lösung kann lokal mit IndexedDB beginnen, später auf SQLite übertragen und bei wachsender Benutzerzahl auf PostgreSQL umgestellt werden. Ebenso ist ein Wechsel in eine Cloud-Umgebung möglich.
Ein solcher Wechsel bleibt ein kontrollierter technischer Vorgang. Unterschiedliche Datenbanken besitzen eigene Möglichkeiten und Einschränkungen. Deshalb werden Daten nicht einfach über einen Schalter auf ein anderes System umgelegt. Übertragung, Prüfung und gegebenenfalls Rollback müssen ausdrücklich durchgeführt werden.
Die Architektur sorgt jedoch dafür, dass ein Wechsel der Datenhaltung nicht automatisch einen Neubau der gesamten Anwendung erfordert.
Updates ohne Austausch der Kundendaten
Ein wesentlicher Vorteil der Trennung zeigt sich bei neuen Versionen. Änderungen betreffen häufig Layouts, Formeln, Funktionen oder das Datenmodell. Die vorhandenen Geschäftsdaten sollen dabei bestehen bleiben.
Ein Entwickler kann deshalb eine neue SSC-Version veröffentlichen, während der SSD des Kunden am Einsatzort erhalten bleibt. Sind neue Felder oder Tabellen erforderlich, werden diese über definierte Migrationsschritte ergänzt.
Vor der Aktualisierung kann der bestehende Zustand gesichert werden. Anschließend werden Struktur, Datenmigration und Funktionsfähigkeit geprüft. Erst wenn SSC und SSD wieder einen konsistenten Zustand bilden, gilt das Update als abgeschlossen.
Diese Updatefähigkeit ist nicht nur für SchallOS selbst vorgesehen. Sie steht auch den mit SchallOS entwickelten Kundenlösungen zur Verfügung.
Kundenspezifische Varianten bleiben nachvollziehbar
Individuelle Business-Software entwickelt sich bei verschiedenen Kunden oft unterschiedlich weiter. Ein Kunde benötigt eigene Felder, ein anderer zusätzliche Layouts oder eine besondere Schnittstelle.
Ohne klare Struktur entstehen daraus schnell voneinander abweichende Komplettkopien, die sich nur noch schwer gemeinsam pflegen lassen. Im SSC können allgemeine Produktbestandteile und kundenspezifische Erweiterungen dagegen nachvollziehbar versioniert und dokumentiert werden.
Die Architektur nimmt dem Entwickler nicht die Entscheidung ab, welche Anpassung in das allgemeine Produkt gehört. Sie sorgt jedoch dafür, dass Herkunft und Abhängigkeiten einer Änderung sichtbar bleiben.
Zusammen mit Entwicklungsprotokollen und Releases lässt sich bei späteren Updates besser erkennen, welche Bestandteile ersetzt, ergänzt oder beibehalten werden müssen.
Mehrsprachigkeit gehört zur portablen Struktur
Auch die Sprachschicht ist im SSC verankert. Bezeichnungen werden nicht ausschließlich fest in einzelnen Layoutobjekten gespeichert, sondern können auf semantische Einträge mit mehreren Sprachfassungen verweisen.
Ein Feld wie „Rechnungsnummer“ kann dadurch in unterschiedlichen Sprachen dargestellt werden, ohne für jede Sprache ein vollständig neues Layout anzulegen. Eine migrierte FileMaker-Lösung kann während der Migration automatisch mehrsprachig umgesetzt und übersetzt werden.
Die automatische Übersetzung ersetzt keine fachliche Prüfung. Gerade juristische und branchenspezifische Begriffe müssen kontrolliert werden. Die Architektur sorgt jedoch dafür, dass Mehrsprachigkeit von Anfang an zur Lösung gehört und nicht später mühsam in jede Maske eingebaut werden muss.
Grundlage für langfristige Wartbarkeit
SSC und SSD wirken zunächst wie eine einfache Aufteilung in Anwendung und Daten. Tatsächlich bilden sie jedoch die Grundlage für Portabilität, Updates, unterschiedliche Datenbankadapter, getrennte Sicherungen und verschiedene Betriebsmodelle.
Der SSC beschreibt, was eine Lösung ist und wie sie funktioniert. Der SSD enthält das, was während ihrer Nutzung entsteht und für das jeweilige Unternehmen dauerhaft erhalten bleiben muss.
Durch diese klare Trennung kann sich die Anwendung weiterentwickeln, ohne dass bei jeder neuen Version der gesamte Datenbestand ausgetauscht werden muss. Gleichzeitig kann die technische Datenhaltung wachsen oder wechseln, ohne dass Layouts und Geschäftslogik vollständig neu aufgebaut werden müssen.
SchallOS Studio als integrierte Entwicklungsumgebung
SchallOS Studio ist der Bereich der Plattform, in dem neue Business-Anwendungen entstehen und bestehende FileMaker-Lösungen migriert oder weiterentwickelt werden. Dort werden Tabellen, Felder, Beziehungen, Layouts, Formeln, Funktionen, Sprachen und Releases innerhalb einer gemeinsamen Umgebung verwaltet.
Für FileMaker-Entwickler soll sich die grundsätzliche Arbeitsweise vertraut anfühlen. Änderungen werden nicht ausschließlich in abstrakten Quellcodedateien vorgenommen, sondern bleiben mit den sichtbaren Bestandteilen der Anwendung verbunden. Ein Entwickler kann ein Layout bearbeiten, ein Feld auswählen, dessen Eigenschaften ändern und unmittelbar prüfen, wie sich die Anpassung auf die Anwendung auswirkt.
SchallOS versucht dennoch nicht, FileMaker vollständig nachzubauen. Übernommen werden vor allem die bewährten Grundideen: schnelle Entwicklung, unmittelbare Rückmeldung und eine enge Verbindung zwischen Datenmodell, Benutzeroberfläche und Geschäftslogik. Die technische Grundlage wird dagegen neu organisiert und auf portable Strukturen, KI-gestützte Programmierung, Dokumentation und kontrollierte Veröffentlichungen ausgerichtet.
Layouts, Objekte und Eigenschaften
Ein wesentlicher Bestandteil von SchallOS Studio ist der Layout-Modus. Dort entstehen Eingabemasken, Listen, Dialoge, Navigationsbereiche und weitere Oberflächen einer Lösung.
Zu den möglichen Layoutobjekten gehören unter anderem Felder, Texte, Schaltflächen, Listenobjekte, Registerbereiche, Popover, Container und Navigationselemente. Die Objekte können ausgewählt, positioniert und über einen Inspektor konfiguriert werden.
Ein Layoutobjekt besitzt dabei nicht nur Angaben zu Größe, Position und Darstellung. Es kann zusätzlich mit Datenquellen, Triggern, Formeln, Funktionen und semantischen Bezeichnungen verbunden sein. Ein Feldobjekt verweist beispielsweise auf ein Feld im Datenmodell, kann eine sprachabhängige Beschriftung erhalten und beim Betreten oder Verlassen bestimmte Funktionen auslösen.
Da jedes Objekt Bestandteil des SSC ist, können Layoutänderungen versioniert, dokumentiert und später gezielt über ein Update verteilt werden. Die Benutzeroberfläche bleibt damit keine isolierte grafische Ebene, sondern ein strukturierter Bestandteil der gesamten Anwendung.
Datenmodell und semantische Beschreibungen
Tabellen, Felder und Beziehungen werden ebenfalls in SchallOS Studio angelegt und bearbeitet. Neue Anwendungen können dort vollständig aufgebaut werden. Bei einer FileMaker-Migration übernimmt der Migrationsassistent die vorhandenen Strukturen soweit möglich und stellt sie anschließend für die weitere Bearbeitung bereit.
Ein Feld besteht in SchallOS nicht nur aus einem technischen Namen und einem Datentyp. Es kann zusätzlich eine fachliche Beschreibung, Validierungsregeln, Standardwerte, Übersetzungen und Dokumentationshinweise erhalten.
Diese Informationen dienen mehreren Zwecken. Sie erleichtern anderen Entwicklern das Verständnis der Lösung, unterstützen die automatische Dokumentation und liefern der integrierten KI einen besseren Kontext. Statt lediglich zu erkennen, dass ein Feld „Status“ heißt, kann die Plattform beispielsweise wissen, ob es sich um einen Auftragsstatus, einen Zahlungsstatus oder einen internen Bearbeitungszustand handelt.
Auch Beziehungen zwischen Tabellen können beschrieben und in ihrem fachlichen Zusammenhang dokumentiert werden. Dadurch bleibt weniger Wissen ausschließlich im Kopf des ursprünglichen Entwicklers verborgen.
Formeln mit Berechnung in Echtzeit
SchallOS besitzt eine eigene Formelumgebung. Formeln werden im Formeleditor erstellt und während der Bearbeitung in Echtzeit berechnet. Änderungen an einem Ausdruck lassen sich dadurch unmittelbar mit geeigneten Testwerten oder dem aktuellen Datensatz prüfen.
Die Formelsprache unterstützt die typischen Berechnungen, die in Business-Anwendungen benötigt werden. Dazu gehören mathematische Operationen, Textverarbeitung, Datums- und Zeitberechnungen, logische Bedingungen, Feldreferenzen, Variablen und verschachtelte Ausdrücke.
Der verfügbare Befehlsumfang ist zunächst kleiner als der über Jahrzehnte gewachsene Funktionsbestand von FileMaker. SchallOS muss nicht jeden historischen FileMaker-Befehl unverändert nachbilden. Wichtiger ist eine klar strukturierte und erweiterbare Formelumgebung.
Zusätzliche Befehle können später ergänzt werden, wenn sie für bestimmte Lösungen oder Migrationen benötigt werden. Dabei kann auch die integrierte KI helfen, eine vorhandene Berechnung zu übertragen oder eine fehlende Funktion passend zur SchallOS-Architektur zu entwickeln.
Custom Functions für wiederverwendbare Berechnungen
Neben den integrierten Befehlen unterstützt SchallOS Custom Functions. Sie nehmen Parameter entgegen, führen eine definierte Berechnung aus und geben ein Ergebnis zurück. Damit lassen sich wiederkehrende Regeln an einer zentralen Stelle verwalten. Beispiele sind Preisberechnungen, Fristermittlungen, Formatierungen, Prüfungen von Nummernkreisen oder die Aufbereitung importierter Werte.
Custom Functions werden ebenfalls in Echtzeit berechnet und können unmittelbar im Formeleditor getestet werden. Wird eine Funktion später korrigiert oder erweitert, profitieren alle Formeln, die sie verwenden.
Zusätzlich können eigene Funktionen beschrieben und dokumentiert werden. Parameter, Rückgabewert, Beispiele und bekannte Fehlerfälle bleiben dadurch nachvollziehbar. Die Funktionssammlung einer Lösung entwickelt sich zu einer wiederverwendbaren Bibliothek, statt aus zahlreichen kopierten Einzelberechnungen zu bestehen.
Funktionscontainer für komplexere Abläufe
Umfangreichere Geschäftsprozesse werden in SchallOS über Funktionscontainer organisiert. Sie können beispielsweise Datensätze anlegen, Werte prüfen, Dialoge steuern, Dokumente erzeugen oder externe Schnittstellen ansprechen. Ein Funktionscontainer enthält nicht nur den ausführbaren Code. Zu ihm gehören außerdem eine fachliche Beschreibung, Eingabeparameter, Rückgabewerte, Abhängigkeiten, erlaubte Fähigkeiten und ausdrücklich ausgeschlossene Vorgänge.
Mehrere Layoutobjekte können denselben Funktionscontainer verwenden. Eine Funktion zum Erstellen einer Rechnung muss dadurch nicht für jede Schaltfläche oder jedes Layout erneut aufgebaut werden.
Bei migrierten Lösungen können vorhandene FileMaker-Skripte als Lern- und Referenzschicht im Hintergrund erhalten bleiben. Sie helfen dabei, die ursprüngliche Absicht und den bisherigen Ablauf zu verstehen. Der neue ausführbare Code wird jedoch passend zur Architektur von SchallOS erzeugt.
Migration und Neuentwicklung in derselben Umgebung
SchallOS Studio ist nicht ausschließlich ein Ziel für vorhandene FileMaker-Lösungen. Neue Anwendungen können vollständig innerhalb der Plattform entstehen.
Bei einer Migration übernimmt der Assistent zunächst vorhandene Tabellen, Felder, Beziehungen, Layouts und weitere erkennbare Bestandteile. Anschließend können Entwickler die importierte Struktur prüfen, bereinigen und schrittweise in die neue Funktionsarchitektur überführen.
Damit soll keine unveränderte Kopie sämtlicher früherer Besonderheiten entstehen. Historisch gewachsene Umwege können überprüft und durch klarere Strukturen ersetzt werden. Gleichzeitig bleibt das fachliche Wissen der bestehenden Lösung erhalten.
Neue und migrierte Anwendungen verwenden anschließend dieselben Werkzeuge, Container und Veröffentlichungswege.
Änderungen werden zu kontrollierten Releases
Eine Änderung im Studio wird nicht automatisch zu einem produktiven Update. Während der Entwicklung können unfertige Layouts, vorläufige Formeln oder noch nicht geprüfte Funktionen vorhanden sein.
Zusammengehörige Änderungen lassen sich deshalb in Change Sessions erfassen und später einem Release zuordnen. Erst nach Prüfung und Freigabe entsteht daraus eine veröffentlichte SSC-Version.
Ein Release kann neben der neuen Struktur auch notwendige Datenmigrationen, Versionsangaben, Abhängigkeiten, Prüfschritte und Dokumentation enthalten. Auf diese Weise bleibt die eigentliche Entwicklung klar von der Auslieferung an produktive Runtime-Instanzen getrennt.
SchallOS Studio bildet damit nicht nur den Ort, an dem eine Anwendung gestaltet und programmiert wird. Es verbindet visuelle Entwicklung, Datenmodell, Formeln, Funktionen, Dokumentation und Veröffentlichung in einer gemeinsamen Umgebung.
Die vertraute Nähe zwischen Entwickler und sichtbarer Anwendung bleibt erhalten. Gleichzeitig entsteht eine technische Grundlage, auf der Lösungen portabel, nachvollziehbar und langfristig wartbar weiterentwickelt werden können.
KI dort, wo Formeln und Funktionen entstehen
Künstliche Intelligenz wird in vielen Entwicklungsumgebungen bislang vor allem über ein zusätzliches Chatfenster angeboten. Der Entwickler beschreibt ein Problem, kopiert Quellcode oder Formeln in den Chat und überträgt das Ergebnis anschließend wieder in das Projekt. Dabei fehlen dem Sprachmodell häufig wichtige Informationen über Tabellen, Felder, Beziehungen und die fachliche Bedeutung der Anwendung.
SchallOS bindet die KI deshalb unmittelbar in die Entwicklungswerkzeuge ein. Sie steht dort zur Verfügung, wo Formeln, Custom Functions und Funktionscontainer bearbeitet werden. Dadurch erhält sie nicht nur eine einzelne Frage, sondern auch den aktuellen Zusammenhang der Lösung.
Im Formeleditor kennt die KI beispielsweise den bearbeiteten Ausdruck, verfügbare Felder und den erwarteten Ergebnistyp. Innerhalb eines Funktionscontainers kann sie zusätzlich auf dessen Beschreibung, Parameter, Fähigkeiten und Abhängigkeiten zugreifen.
Die KI wird damit nicht zu einem getrennten Hilfsprogramm, sondern zu einem Bestandteil der eigentlichen Entwicklungsumgebung.
Unterstützung im Formeleditor
Formeln steuern zahlreiche Vorgänge einer Business-Anwendung. Sie berechnen Preise, prüfen Bedingungen, ermitteln Fristen oder beeinflussen die Darstellung von Layoutobjekten. Die integrierte KI kann im Formeleditor unter anderem:
- eine bestehende Formel erklären
- mögliche Fehler untersuchen
- Bedingungen ergänzen
- einen Ausdruck vereinfachen
- eine FileMaker-Formel übertragen
- oder aus einer fachlichen Beschreibung eine neue Berechnung erstellen.
Ein Entwickler könnte beispielsweise vorgeben, dass Aufträge oberhalb eines bestimmten Nettowerts eine zusätzliche Freigabe benötigen, sofern kein Rahmenvertrag vorhanden ist. Die KI kann daraus eine Formel erzeugen und dabei auf die in der Lösung vorhandenen Felder zurückgreifen. Das Ergebnis bleibt als normale Formel sichtbar. Es kann gelesen, verändert und in Echtzeit berechnet werden. Die KI erzeugt somit keinen verborgenen Ablauf, dessen Verhalten nur schwer nachvollziehbar wäre.
Fehlt ein benötigter Befehl, kann die KI auch dabei helfen, eine geeignete Custom Function oder eine Erweiterung der Formelumgebung zu erstellen. Der zunächst kleinere Befehlsumfang von SchallOS bleibt dadurch erweiterbar.
Custom Functions aus fachlichen Vorgaben
Wiederkehrende Berechnungen lassen sich als Custom Functions zentral verwalten. Die KI kann aus einer Beschreibung eine Funktion mit eindeutigen Parametern, Rückgabewert und dokumentiertem Verhalten erzeugen.
Eine solche Funktion könnte beispielsweise Skontofristen berechnen, Nummernkreise prüfen oder importierte Werte vereinheitlichen. Neben dem eigentlichen Ausdruck können auch Testwerte, Beispiele und mögliche Fehlerfälle erstellt werden.
Das erleichtert nicht nur die erste Programmierung. Bei einer späteren Änderung kann die KI erkennen, welche Bedeutung die Funktion besitzt und an welchen Stellen sie verwendet wird.
Aus einer anonymen Berechnung wird damit ein dokumentierter und wiederverwendbarer Bestandteil der Lösung.
Funktionscontainer als beschriebene Programmlogik
Komplexere Abläufe werden in SchallOS über Funktionscontainer organisiert. Ein Funktionscontainer kann beispielsweise Datensätze anlegen, Eingaben prüfen, Dialoge steuern, Dokumente erzeugen oder externe Schnittstellen aufrufen. Die Grundlage bildet eine strukturierte Beschreibung. Sie kann festlegen:
- welche Aufgabe die Funktion erfüllt
- welche Parameter übergeben werden
- welches Ergebnis erwartet wird
- auf welche Tabellen und Felder zugegriffen werden darf
- welche weiteren Funktionen verwendet werden
- und welche Vorgänge ausdrücklich ausgeschlossen sind.
Auf Grundlage dieser Vorgaben programmiert die KI den ausführbaren Code des Funktionscontainers. Der Entwickler muss den Ablauf dadurch nicht mehr ausschließlich aus zahlreichen einzelnen Skriptschritten zusammensetzen. Seine Aufgabe verlagert sich stärker auf die genaue Beschreibung der gewünschten Funktion, ihre Grenzen und die anschließende Prüfung.
Der erzeugte Code bleibt dennoch sichtbar. Er kann gelesen, getestet, überarbeitet und zwischen verschiedenen Versionen verglichen werden. Auch frühere Fassungen lassen sich erhalten und bei Bedarf wiederherstellen. KI übernimmt damit die Programmierung, nicht jedoch die fachliche Verantwortung.
FileMaker-Skripte als Lernschicht
Bei migrierten FileMaker-Lösungen enthalten die vorhandenen Skripte häufig einen großen Teil der über Jahre entstandenen Geschäftslogik. Sie zeigen, welche Felder verändert, welche Bedingungen geprüft und welche weiteren Abläufe aufgerufen wurden.
Diese Skripte werden in SchallOS nicht dauerhaft als ausführbare Laufzeitschicht übernommen. Dadurch würden viele frühere technische Abhängigkeiten und Umwege lediglich in das neue System verlagert. Stattdessen kann das ursprüngliche FileMaker-Skript im Hintergrund des entsprechenden Funktionscontainers erhalten bleiben. Es dient der KI als Lern-, Referenz- und Verständnisschicht.
Die KI kann daraus die fachliche Absicht des bisherigen Ablaufs ableiten. Anschließend programmiert sie den neuen Code passend zur Architektur von SchallOS. Historische Konstruktionen wie häufige Layoutwechsel, globale Felder oder kontextabhängige Hilfsskripte müssen dabei nicht unverändert übernommen werden. Sie werden nur dann weitergeführt, wenn sie für den eigentlichen Geschäftsprozess tatsächlich erforderlich sind.
Das ursprüngliche Skript bleibt dennoch als Wissensquelle erhalten. Bei späteren Rückfragen lässt sich nachvollziehen, wie ein Ablauf in der FileMaker-Lösung ursprünglich gelöst wurde.
Fähigkeiten und Grenzen werden ausdrücklich definiert
Ein Funktionscontainer soll nicht allein aufgrund einer allgemeinen Beschreibung auf beliebige Bereiche der Anwendung zugreifen können. Deshalb lassen sich erlaubte Fähigkeiten und Ausschlüsse ausdrücklich festlegen.
Eine Funktion kann beispielsweise Datensätze in einer bestimmten Tabelle lesen und verändern dürfen, ohne gleichzeitig Löschvorgänge oder Änderungen an Systemkonfigurationen ausführen zu können. Verwendet der erzeugte Code eine nicht freigegebene Fähigkeit, kann SchallOS dies erkennen und die Ausführung oder Veröffentlichung blockieren.
Die Beschreibung eines Funktionscontainers dient damit nicht nur der Dokumentation. Sie wird Teil des Prüf- und Sicherheitsmodells. Gerade bei KI-generiertem Code ist diese Begrenzung wichtig. Das Sprachmodell erhält einen klaren Handlungsspielraum, während die Plattform kontrolliert, ob sich die erzeugte Funktion innerhalb dieses Rahmens bewegt.
Der richtige Kontext verbessert die Ergebnisse
Die Qualität einer KI-generierten Funktion hängt nicht allein von der Größe des verwendeten Sprachmodells ab. Entscheidend ist, ob das Modell die benötigten Informationen erhält. SchallOS kann den Kontext aus mehreren Ebenen zusammensetzen:
- der aktuellen Frage
- dem geöffneten Editor
- dem ausgewählten Feld oder Funktionscontainer
- den beteiligten Tabellen und Beziehungen
- vorhandenen Formeln und Funktionen
- semantischen Beschreibungen
- Dokumentation und Änderungshistorie
- sowie bei Migrationen dem ursprünglichen FileMaker-Skript.
Dadurch kann die KI wesentlich genauer arbeiten als bei einer isolierten Anfrage in einem allgemeinen Chat.
Gleichzeitig muss nicht bei jeder Aufgabe die gesamte Lösung bereitgestellt werden. Der Kontext kann auf die Informationen beschränkt werden, die für die jeweilige Funktion tatsächlich benötigt werden.
Austauschbare Modelle statt dauerhafter Bindung
Die KI-Schicht soll nicht dauerhaft von einem einzelnen Modell oder Anbieter abhängig sein. Unterschiedliche Aufgaben stellen verschiedene Anforderungen an Qualität, Geschwindigkeit, Kosten und Datenschutz.
Eine komplexe Migration kann ein besonders leistungsfähiges Modell erfordern. Eine einfache Erklärung oder Formelanpassung lässt sich möglicherweise mit einem kleineren Modell durchführen. Für sensible oder abgeschlossene Umgebungen können langfristig auch lokal betriebene Modelle eingesetzt werden.
Die dauerhafte Wissensbasis liegt deshalb nicht im Sprachmodell, sondern in der SchallOS-Lösung: in Beschreibungen, Strukturen, Skriptreferenzen, Code, Tests und Dokumentation. Das KI-Modell bleibt ein austauschbares Werkzeug, das aus diesem Kontext ausführbaren Code oder verständliche Vorschläge erzeugt.
Nachvollziehbare KI-gestützte Entwicklung
SchallOS verbindet die unmittelbare Arbeit an Business-Anwendungen mit KI-gestützter Programmierung. Formeln können direkt erklärt und erzeugt werden. Custom Functions entstehen aus wiederverwendbaren fachlichen Vorgaben. Funktionscontainer verbinden semantische Beschreibungen mit sichtbarem und prüfbarem Code.
Bei migrierten Lösungen bleiben FileMaker-Skripte als zusätzliche Lernschicht erhalten. Sie helfen, vorhandene Geschäftsprozesse zu verstehen, ohne frühere technische Abhängigkeiten dauerhaft fortzuführen.
Die Rolle des Entwicklers verschwindet dadurch nicht. Sie verändert sich. Präzise Anforderungen, sinnvolle Architektur, Tests und fachliche Kontrolle werden wichtiger als die manuelle Eingabe jedes einzelnen Programmschritts. Gerade bei geschäftskritischer Software bleibt diese Verantwortung unverzichtbar.
Huidig onderzoek naar het gebruik van lokale AI-systemen
Dokumentation und Ereignisprotokolle als Teil der Anwendung
Die Dokumentation einer Business-Anwendung wird häufig erst dann geschrieben, wenn eine Entwicklung bereits abgeschlossen ist. Unter Zeitdruck konzentriert sich die Arbeit zunächst auf neue Felder, Layouts, Formeln und Funktionen. Die Beschreibung der Änderungen soll später folgen.
Mit zunehmendem Abstand wird es jedoch schwieriger, die ursprünglichen Entscheidungen nachzuvollziehen. Oft ist nicht mehr genau bekannt, warum eine bestimmte Funktion ergänzt wurde, welche Objekte betroffen waren und welche Sonderfälle berücksichtigt werden mussten. SchallOS behandelt Dokumentation deshalb nicht als nachträgliche Zusatzaufgabe. Relevante Veränderungen werden bereits während der Entwicklung als Ereignisse erfasst und mit den betroffenen Bestandteilen der Lösung verbunden.
Aus diesen Informationen können anschließend technische Dokumentationen, Release Notes, Kundenberichte oder Leistungsprotokolle erzeugt werden. Die Dokumentation beruht damit nicht allein auf Erinnerungen oder manuell geführten Notizen, sondern auf den tatsächlich vorgenommenen Änderungen.
Ereignisse auf mehreren Ebenen
Eine SchallOS-Lösung besitzt nicht nur ein einziges allgemeines Protokoll. Die Plattform unterscheidet verschiedene Ereignisebenen mit eigenen Aufgaben.
- De Strukturprotokoll erfasst Änderungen am SSC. Dazu gehören beispielsweise neue Tabellen und Felder, angepasste Layouts, veränderte Formeln oder neue Funktionscontainer.
- De Datenereignisprotokoll gehört zum SSD. Dort werden fachlich relevante Vorgänge während der produktiven Nutzung festgehalten, etwa Statuswechsel, Freigaben, Stornierungen oder Änderungen wichtiger Datensätze.
- Hinzu kommen Betriebsereignisse aus Runtime und SchallOS Control. Dazu gehören unter anderem Deployments, Updates, Prüfungen, Sicherungen und Rollback-Vorgänge.
Diese Bereiche bleiben getrennt, können aber miteinander verbunden werden. Ein Entwicklungsprotokoll soll nicht durch alltägliche Änderungen an Kundendatensätzen unübersichtlich werden. Umgekehrt gehören interne technische Einzelheiten nicht automatisch in die fachliche Historie einer Rechnung oder eines Auftrags.
Das Strukturprotokoll zeigt die Entwicklung der Lösung
Änderungen an Tabellen, Feldern, Layouts, Formeln und Funktionscontainern können als strukturierte Ereignisse gespeichert werden. Ein Eintrag kann festhalten, welches Objekt verändert wurde, welcher frühere Zustand vorhanden war und welcher neue Zustand entstanden ist. Zusätzlich lassen sich Entwickler, Zeitpunkt, fachliche Begründung, zugehöriger Auftrag und geplante Releaseversion erfassen.
Wird beispielsweise ein neuer Freigabeprozess für Aufträge ergänzt, entstehen möglicherweise mehrere technische Änderungen. Ein Statusfeld wird angelegt, ein Layout erweitert, eine Formel angepasst und ein neuer Funktionscontainer programmiert.
Das Strukturprotokoll bewahrt diese Einzelereignisse. Gleichzeitig können sie unter einer gemeinsamen fachlichen Aufgabe zusammengefasst werden. Dadurch bleibt erkennbar, dass mehrere technische Änderungen gemeinsam einen neuen Geschäftsprozess bilden.
Change Sessions bündeln zusammengehörige Arbeiten
Eine Entwicklungsaufgabe besteht häufig aus vielen kleinen Schritten. Eine rein chronologische Liste einzelner Änderungen würde den eigentlichen Zusammenhang nur unzureichend darstellen.
SchallOS kann zusammengehörige Arbeiten deshalb in Change Sessions bündeln. Eine Change Session beschreibt eine konkrete Aufgabe, Erweiterung oder Fehlerkorrektur und sammelt alle dazugehörigen Ereignisse. Sie kann beispielsweise enthalten:
- die fachliche Aufgabenbeschreibung
- betroffene Tabellen und Layouts
- geänderte Formeln und Funktionen
- durchgeführte Tests
- offene Punkte
- sowie die Zuordnung zu einem Kunden oder Auftrag.
Mehrere Change Sessions können später einem Release zugeordnet werden. Auf diese Weise entsteht eine nachvollziehbare Verbindung zwischen Entwicklungsauftrag, technischen Änderungen und veröffentlichter Version.
Die KI bereitet technische Ereignisse verständlich auf
Die Dokumentationsschicht ist an die integrierte KI von SchallOS angebunden. Dadurch können die protokollierten Ereignisse automatisch für unterschiedliche Zielgruppen aufbereitet werden.
Ein technischer Entwicklerbericht benötigt andere Informationen als eine Kundenmitteilung. Während der Entwickler konkrete Feldnamen, Funktionscontainer und Datenmigrationen sehen möchte, interessiert den Kunden vor allem, welche Funktion ergänzt wurde und welchen Nutzen sie bietet. Die KI kann dieselben Ereignisse deshalb in unterschiedlichen Formen zusammenfassen:
- als interne technische Dokumentation
- als verständliche Kundeninformation
- als Release Notes
- als Projektbericht
- oder als Leistungsnachweis für eine Rechnung.
Die Texte entstehen nicht frei aus einer allgemeinen Beschreibung. Sie werden aus den Change Sessions, semantischen Objektbeschreibungen und tatsächlichen Strukturänderungen abgeleitet.
Der erzeugte Text bleibt dabei mit seinen Quellen verbunden. Der Entwickler kann prüfen, auf welchen Ereignissen eine Aussage beruht, und die Formulierung vor der Verwendung korrigieren oder freigeben.
Leistungsprotokolle für Entwickler und Kunden
Für Entwickler individueller Software ist die Dokumentation auch wirtschaftlich wichtig. Leistungen müssen einem Kunden verständlich erläutert und häufig nach Zeit oder Arbeitspaket abgerechnet werden.
In der Praxis werden solche Leistungsprotokolle oft erst kurz vor der Rechnungsstellung zusammengestellt. Dafür müssen E-Mails, Notizen und Erinnerungen durchsucht werden.
SchallOS kann die tatsächlich erfassten Entwicklungsereignisse einem Kunden, Projekt oder Auftrag zuordnen. Die KI erzeugt daraus geeignete Einträge für ein Leistungsprotokoll. Mehrere technische Änderungen können beispielsweise zu einer verständlichen Leistung zusammengefasst werden:
Erweiterung der Auftragsverwaltung um einen zweistufigen Freigabeprozess einschließlich Statusprüfung, Benutzerrechten und Anpassung der Eingabemaske.
Die zugrunde liegenden technischen Vorgänge bleiben weiterhin einsehbar. Die Kundenbeschreibung bildet lediglich eine verständliche Zusammenfassung. Die endgültige Auswahl bleibt beim Entwickler. Nicht jedes technische Ereignis ist automatisch abrechenbar, und interne Versuche oder Korrekturen müssen nicht einzeln auf einer Rechnung erscheinen.
Ereignisse auf der Datenebene
Auch im produktiven Betrieb können alle vorgesehenen Datenereignisse protokolliert werden. Dazu gehören das Anlegen und Ändern von Datensätzen, Statuswechsel, Freigaben, Importe, Exporte oder automatisch ausgeführte Prozesse. Ein Eintrag kann festhalten:
- welcher Benutzer oder Prozess die Aktion ausgelöst hat
- welcher Datensatz betroffen war
- welche Werte verändert wurden
- welche Funktion ausgeführt wurde
- und ob der Vorgang erfolgreich abgeschlossen wurde.
Die jeweilige Lösung bestimmt, welche Ereignisse in welcher Tiefe gespeichert werden. Eine kleine Textkorrektur besitzt eine andere Bedeutung als die Änderung einer bereits freigegebenen Rechnung. Das Datenereignisprotokoll bildet damit die fachliche Historie des SSD. Es unterstützt Support, Fehleranalyse und die Nachvollziehbarkeit wichtiger Geschäftsprozesse.
Ein solches Protokoll kann auch eine Grundlage für Audit-Anforderungen bilden. Ob damit alle rechtlichen oder branchenspezifischen Vorgaben erfüllt werden, muss jedoch für den jeweiligen Einsatzfall geprüft werden.
Dokumentation begleitet auch Releases und Updates
Die erfassten Entwicklungsereignisse fließen zugleich in die Release- und Update-Pipeline ein. Wird eine neue Version veröffentlicht, kann SchallOS automatisch zusammenstellen, welche Funktionen ergänzt, welche Fehler behoben und welche Datenstrukturen verändert wurden. Daraus entstehen technische Änderungslisten, Benutzerhinweise und Migrationsinformationen.
Nach der Installation bleibt nachvollziehbar, welche Version auf einer bestimmten Runtime-Instanz eingespielt wurde und welche Änderungen darin enthalten waren.
Auch Betriebsereignisse wie Sicherungen, Prüfungen oder ein möglicher Rollback werden dokumentiert. Dadurch lässt sich später nicht nur feststellen, was entwickelt wurde, sondern auch wann und mit welchem Ergebnis eine Änderung produktiv ausgerollt wurde.
Eine wachsende Wissensbasis
Die Verbindung aus Ereignisprotokoll, semantischen Beschreibungen und KI-Unterstützung schafft langfristig eine Wissensbasis über die gesamte Lösung. Bei einer späteren Änderung kann nicht nur der aktuelle Code betrachtet werden. Es bleibt auch erkennbar, wann eine Funktion eingeführt wurde, welcher Geschäftsgrund dahinterstand und welche anderen Bereiche damals betroffen waren.
Gerade bei über viele Jahre gewachsenen Business-Anwendungen ist dieses Wissen entscheidend. Ein scheinbar überflüssiger Sonderfall kann einen wichtigen historischen Grund besitzen. Ohne Dokumentation besteht die Gefahr, dass er bei einer späteren Überarbeitung versehentlich entfernt wird. SchallOS bewahrt deshalb nicht nur technische Zustände, sondern auch die Entwicklungsgeschichte und die damit verbundenen Entscheidungen.
Dokumentation wird damit zu einem aktiven Bestandteil der Anwendung. Sie unterstützt Entwicklung, Kundenkommunikation, Abrechnung, Support, Releases und langfristige Wartbarkeit – auf Grundlage der Ereignisse, die tatsächlich im System stattgefunden haben.
Eine systemweite Update-Pipeline für Plattform und Anwendungen
Business-Software bleibt selten über längere Zeit unverändert. Neue Anforderungen, gesetzliche Änderungen, Fehlerkorrekturen und technische Weiterentwicklungen führen regelmäßig zu neuen Versionen. Dabei genügt es nicht, lediglich Dateien auszutauschen. Vor jeder Aktualisierung muss geprüft werden, welche Version installiert ist, ob Datenstrukturen angepasst werden müssen und wie sich der vorherige Zustand im Fehlerfall wiederherstellen lässt.
Bei vielen individuellen Anwendungen entstehen solche Verfahren erst nachträglich. Updates werden dann mit manuellen Anweisungen, Sicherungskopien und kundenspezifischen Skripten verteilt. Mit jeder weiteren Installation wächst das Risiko, dass unterschiedliche Versionsstände und Sonderlösungen entstehen.
SchallOS behandelt Updates deshalb als systemweite Plattformfunktion. Über dieselbe grundlegende Pipeline werden sowohl SchallOS selbst als auch die mit der Plattform entwickelten Kundenlösungen aktualisiert.
Ein Entwickler muss für eine neue Anwendung damit nicht erst ein eigenes Updateverfahren entwerfen. Versionierung, Prüfung, Verteilung und Protokollierung gehören von Anfang an zur gemeinsamen Architektur.
Die Trennung von SSC und SSD schützt die produktiven Daten
Die Updatefähigkeit hängt unmittelbar mit der Trennung von Struktur und Daten zusammen. Der SSC enthält Layouts, Formeln, Funktionscontainer, Sprachdefinitionen und das Datenmodell der Anwendung. Der SSD enthält die produktiven Geschäftsdaten des jeweiligen Unternehmens.
Bei einer neuen Version wird deshalb nicht die gesamte Anwendung einschließlich aller Kundendaten ersetzt. Stattdessen kann ein neuer SSC veröffentlicht werden, während der vorhandene SSD am Einsatzort bestehen bleibt.
Erfordert die neue Struktur zusätzliche Felder, Tabellen oder veränderte Datenformate, werden dafür ausdrücklich definierte Migrationsschritte ausgeführt. Die produktiven Daten werden kontrolliert an die neue Struktur angepasst und nicht unbemerkt gegen einen anderen Datenbestand ausgetauscht.
Diese klare Trennung ermöglicht es, Anwendungen über viele Jahre weiterzuentwickeln, ohne bei jeder Aktualisierung sämtliche Geschäftsdaten in eine neue Komplettdatei übertragen zu müssen.
Vom Entwicklungsstand zum Release
Nicht jede Änderung in SchallOS Studio ist sofort für den produktiven Einsatz geeignet. Während der Entwicklung können vorläufige Layouts, unvollständige Funktionen oder noch nicht geprüfte Formeln vorhanden sein.
Zusammengehörige Änderungen werden deshalb zunächst in Change Sessions erfasst und einem geplanten Release zugeordnet. Erst nach Prüfung und Freigabe entsteht daraus eine veröffentlichte Version. Ein Release kann unter anderem enthalten:
- eine eindeutige Versionsnummer
- den aktualisierten SSC
- notwendige SSD-Migrationen
- technische Voraussetzungen
- Abhängigkeiten von Runtime oder Adaptern
- Prüf- und Testschritte
- Release Notes
- sowie Informationen für einen möglichen Rollback.
Die Dokumentationsschicht liefert dafür die Grundlage. Aus den protokollierten Entwicklungsereignissen können automatisch technische Änderungslisten und verständliche Benutzerhinweise erzeugt werden.
Ein Release besteht damit nicht nur aus veränderten Dateien. Es beschreibt zugleich, was geändert wurde, welche Voraussetzungen gelten und wie die Installation geprüft werden soll.
SchallOS Control steuert die Verteilung
SchallOS Control übernimmt die operative Verwaltung der Updates. Dort wird sichtbar, welche Instanzen vorhanden sind, welche Versionen installiert wurden und welche Aktualisierungen bereitstehen. Vor der Installation kann Control unter anderem prüfen:
- ob die Zielinstanz erreichbar ist
- welche Runtime- und SSC-Version verwendet wird
- welcher Datenbankadapter aktiv ist
- ob eine geeignete Sicherung erstellt werden kann
- und ob alle Voraussetzungen des Releases erfüllt sind.
Dadurch wird verhindert, dass ein Update auf einer technisch ungeeigneten oder unvollständig vorbereiteten Installation ausgeführt wird.
Ein Release muss außerdem nicht gleichzeitig an alle Systeme verteilt werden. Es kann zunächst in einer Testumgebung oder bei ausgewählten Installationen eingesetzt werden. Erst nach erfolgreicher Prüfung erfolgt der breitere Rollout.
Dafür können unterschiedliche Updatekanäle vorgesehen werden, beispielsweise stabile Produktivversionen, Vorabversionen, interne Tests oder kundenspezifische Releases.
Signaturen und eindeutige Versionsstände
Updatepakete können mit Prüfsummen und digitalen Signaturen versehen werden. SchallOS Control erkennt dadurch, ob ein Paket vollständig ist, aus der vorgesehenen Quelle stammt und seit seiner Veröffentlichung verändert wurde.
Zusätzlich wird geprüft, ob das Release tatsächlich zur jeweiligen Lösung gehört. Ein neuer SSC darf nicht versehentlich mit dem SSD einer anderen Anwendung verbunden werden.
Eindeutige Lösungskennungen, Strukturversionen und Datenmodellversionen sorgen dafür, dass der installierte Zustand nachvollziehbar bleibt. Auch erforderliche Zwischenschritte können erkannt werden. Eine Installation kann beispielsweise nicht direkt von einer sehr alten Version auf den neuesten Stand wechseln, wenn zuvor eine notwendige Datenmigration ausgeführt werden muss.
Sicherung, Migration und Verifikation
Vor einer strukturellen Aktualisierung wird der bestehende Zustand gesichert. Die konkrete Form der Sicherung richtet sich nach dem verwendeten Datenbankadapter. Eine lokale IndexedDB- oder SQLite-Installation benötigt andere Verfahren als ein PostgreSQL-Server.
Anschließend wird das Updatepaket geprüft, die neue Struktur installiert und eine gegebenenfalls notwendige Datenmigration ausgeführt. Nach der Aktivierung folgt die Verifikation. Dabei kann SchallOS beispielsweise kontrollieren:
- ob alle erwarteten Tabellen und Felder vorhanden sind,
- ob die Datenmigration vollständig durchgeführt wurde,
- ob Datensatzanzahlen und Prüfsummen stimmen,
- und ob wichtige Funktionen ordnungsgemäß ausgeführt werden.
Erst wenn diese Prüfungen erfolgreich abgeschlossen wurden, gilt das Update als installiert. Eine bloße Dateiübertragung reicht damit nicht aus. Entscheidend ist, dass Struktur, Daten und Runtime anschließend wieder einen konsistenten und funktionsfähigen Zustand bilden.
Rollback bei fehlgeschlagenen Updates
Trotz sorgfältiger Vorbereitung kann eine Aktualisierung scheitern. Unerwartete Altdaten, eine fehlerhafte Migration oder eine nicht berücksichtigte Abhängigkeit können dazu führen, dass eine neue Version nicht sicher aktiviert werden kann. Für solche Fälle gehört ein Rollback zum Updateverfahren. Dabei werden die frühere SSC-Version, der gesicherte SSD-Zustand und die vorherige Konfiguration wiederhergestellt.
Nicht jedes Update lässt sich jedoch beliebig lange zurücksetzen. Wurden nach der Installation bereits neue produktive Daten nach veränderten Regeln verarbeitet, kann eine vollständige Rückkehr problematisch sein. Ein Release muss deshalb festlegen, unter welchen Bedingungen ein Rollback möglich ist.
In manchen Fällen ist ein korrigierendes Folgeupdate sinnvoller als die Wiederherstellung eines älteren Datenbestands. Die Plattform stellt den technischen Rahmen bereit, die konkrete Entscheidung hängt jedoch von der jeweiligen Änderung und ihrer fachlichen Bedeutung ab.
Auch SchallOS selbst nutzt diese Pipeline
Die Update-Pipeline ist nicht nur für Kundenlösungen vorgesehen. Auch SchallOS Studio, Runtime, Control und weitere Plattformkomponenten werden über dieselben grundlegenden Mechanismen aktualisiert. Neue Plattformversionen können Erweiterungen der Formelumgebung, Verbesserungen der KI-Schicht, neue Datenbankadapter oder Sicherheitskorrekturen enthalten. Auch hier werden Versionsstände, Abhängigkeiten, Signaturen und Prüfungen benötigt.
Dadurch wird die Infrastruktur im laufenden Betrieb der Plattform selbst verwendet und fortlaufend erprobt. Die mit SchallOS entwickelten Anwendungen profitieren von denselben Verfahren.
Der Entwickler erhält somit keine lediglich theoretisch vorgesehene Updatefunktion, sondern eine Pipeline, die zugleich zum Betrieb und zur Weiterentwicklung des gesamten Systems gehört.
Ein vorgesehener Weg für zukünftige Versionen
Die Stärke der Update-Pipeline liegt nicht allein in der automatischen Verteilung neuer Dateien. Entscheidend ist die Verbindung von Entwicklung, Dokumentation, Sicherung, Migration, Prüfung und Rollback innerhalb eines gemeinsamen Ablaufs.
SchallOS selbst und die damit entwickelten Anwendungen verwenden dieselbe grundlegende Infrastruktur. Die Trennung von SSC und SSD sorgt dafür, dass sich die Struktur weiterentwickeln kann, während die produktiven Daten geschützt und kontrolliert angepasst werden.
Eine mit SchallOS entwickelte Lösung besitzt damit von Anfang an einen vorgesehenen Weg für zukünftige Versionen. Gerade bei Business-Software, die über viele Jahre eingesetzt werden soll, ist diese Updatefähigkeit keine Zusatzfunktion, sondern eine wesentliche Voraussetzung für dauerhafte Wartbarkeit und verlässlichen Betrieb.
Runtime, Control und Cloud für verschiedene Betriebsmodelle
Eine Entwicklungsumgebung benötigt weitreichende Möglichkeiten. Entwickler müssen Strukturen verändern, Layouts gestalten, Formeln bearbeiten und neue Funktionen veröffentlichen können. Im täglichen Betrieb einer fertigen Business-Anwendung werden diese Werkzeuge dagegen meist nicht benötigt.
SchallOS trennt deshalb Entwicklung, Ausführung und Verwaltung in unterschiedliche Bereiche. SchallOS Studio dient der Entwicklung. SchallOS Runtime führt veröffentlichte Anwendungen aus. SchallOS Control verwaltet ihre technische Bereitstellung. SchallOS Cloud bietet dieselbe grundlegende Architektur als zentral betriebenen Onlinedienst an.
Dabei entstehen keine voneinander unabhängigen Anwendungen. Alle Bereiche arbeiten mit denselben SSC- und SSD-Strukturen. Die Betriebsform wird über Deployment, Datenbankadapter und Runtime-Profil festgelegt.
SchallOS Runtime führt veröffentlichte Lösungen aus
SchallOS Runtime verbindet den SSC einer Anwendung mit dem zugehörigen SSD und stellt die darin definierten Layouts, Formeln und Funktionen bereit. Zur Laufzeit gehören unter anderem die Darstellung und Bedienung der Layouts, Lesen und Bearbeiten von Datensätzen, Berechnung von Formeln und Custom Functions, Ausführung von Funktionscontainern, Navigation und Dialogsteuerung, Mehrsprachigkeit sowie die Verbindung zum vorgesehenen Datenbankadapter.
Die Runtime enthält jedoch nicht automatisch sämtliche Werkzeuge von SchallOS Studio. Sie kann keine neuen SSC-/SSD-Lösungspaare anlegen und besitzt keinen Migrationsassistenten für FileMaker-Lösungen.
Damit bleibt eine ausgelieferte Kundenanwendung klar von der eigentlichen Entwicklungsumgebung getrennt.
Profile bestimmen die Fähigkeiten einer Runtime
Nicht jede Installation benötigt denselben Funktionsumfang. Eine reine Endbenutzeranwendung soll möglicherweise nur veröffentlichte Layouts und Geschäftsprozesse ausführen. Eine interne Installation kann zusätzliche Verwaltungs- oder Diagnosefunktionen benötigen.
SchallOS verwendet dafür Runtime- und Capability-Profile. Sie legen fest, welche technischen Fähigkeiten eine konkrete Instanz besitzt.
Ein Profil kann beispielsweise bestimmen, ob der Layout-Modus verfügbar ist, Daten importiert oder exportiert werden dürfen, administrative Dialoge angezeigt werden, lokale Einstellungen verändert werden können oder bestimmte Schnittstellen verwendet werden dürfen.
Diese Profile ergänzen die Benutzerrechte innerhalb der eigentlichen Lösung. Die Benutzerrechte bestimmen, was eine Person fachlich tun darf. Das Runtime-Profil legt dagegen fest, welche technischen Möglichkeiten die jeweilige Installation grundsätzlich bereitstellt.
Dadurch kann dieselbe Runtime-Basis für unterschiedliche Kundengruppen und Einsatzfälle verwendet werden, ohne für jede Variante eine eigene Programmfassung entwickeln zu müssen.
Vom lokalen Einzelplatz bis zum Serverbetrieb
Eine SchallOS-Lösung kann in verschiedenen Betriebsformen bereitgestellt werden. Für einen lokalen Einzelplatz kann der SSD beispielsweise in IndexedDB gespeichert werden. Eine installierte Desktop-Anwendung kann SQLite verwenden. Für größere Mehrbenutzerlösungen ist eine zentrale Datenbank wie PostgreSQL vorgesehen.
Die Betriebsmodelle besitzen unterschiedliche Eigenschaften. IndexedDB eignet sich vor allem für lokale Browseranwendungen. SQLite ist eine bewährte Grundlage für lokale Anwendungen und überschaubare Installationen. PostgreSQL bietet sich für zentrale Mehrbenutzersysteme mit professioneller Serververwaltung an.
SchallOS behandelt diese Technologien nicht als vollkommen austauschbare Speicherorte. Ein Wechsel des Adapters benötigt eine kontrollierte Datenübertragung, Prüfung und gegebenenfalls einen Rollback. Die gemeinsame SSC-/SSD-Architektur sorgt dafür, dass Layouts, Formeln und Geschäftslogik nicht für jeden Datenbankadapter vollständig neu entwickelt werden müssen.
Desktop-Anwendungen und Browserbetrieb
SchallOS-Lösungen sollen sowohl im Browser als auch als installierbare Anwendungen für Windows und macOS betrieben werden können. Eine Desktop-Runtime kann sich enger in das jeweilige Betriebssystem integrieren, lokale Dateien kontrolliert verwenden und bei geeigneter Konfiguration zeitweise offline arbeiten. Sie kann ihre Daten lokal mit IndexedDB oder SQLite speichern oder auf eine zentrale PostgreSQL-Datenbank zugreifen.
Im Browser wird die Anwendung durch die eigene SchallOS Runtime dargestellt. Dafür werden weder FileMaker Server noch FileMaker WebDirect benötigt. Eine migrierte FileMaker-Lösung läuft nach der Übertragung also nicht mehr auf einer FileMaker-Datei im Hintergrund. Layouts, Formeln und Funktionslogik werden innerhalb der SchallOS-Architektur ausgeführt.
SchallOS Control verwaltet die Instanzen
SchallOS Control bildet die betriebliche Schaltzentrale der Plattform. Dort wird verwaltet, welche Lösung auf welchem Zielsystem betrieben wird und welche technischen Voraussetzungen gelten. Control kann unter anderem anzeigen:
- welche SSC-/SSD-Paare bereitgestellt wurden
- welche Runtime-Version installiert ist
- welcher Datenbankadapter verwendet wird
- welches Capability-Profil gilt
- welche Updates verfügbar sind
- und wann eine Instanz zuletzt geprüft wurde.
Ein Deployment-Ziel kann beispielsweise eine lokale Windows-Anwendung, eine macOS-Runtime, ein eigener PostgreSQL-Server, eine Testumgebung oder eine Cloud-Instanz sein.
Betriebliche Angaben wie Serveradressen, Datenbankzugänge, Lizenzen oder lokale Gerätebindungen gehören dabei nicht in den portablen SSC. Sie werden in der geschützten Konfiguration der jeweiligen Instanz verwaltet.
Signierte Lösungen und kontrollierte Verteilung
Portable Lösungscontainer dürfen nicht bedeuten, dass jede Anwendung beliebig verändert oder auf nicht vorgesehenen Systemen gestartet werden kann. Veröffentlichte SSC-/SSD-Pakete können deshalb mit Lösungskennungen, Prüfsummen, Signaturen und Instanzinformationen verbunden werden. Die Runtime kann beim Start prüfen, ob der SSC unverändert und gültig signiert ist, der SSD zur richtigen Lösung gehört, beide Versionsstände miteinander kompatibel sind und ein gültiges Deployment-Profil vorliegt.
Je nach Lizenzmodell kann eine Bereitstellung an eine Instanz, einen Server, ein Gerät oder einen festgelegten Benutzerumfang gebunden werden. SchallOS Control verwaltet dabei auch notwendige Änderungen, etwa einen Serverwechsel, eine Neuaktivierung oder die Wiederherstellung einer Installation.
SchallOS Cloud als SaaS-Betriebsmodell
SchallOS Cloud stellt Anwendungen als zentral betriebenen Onlinedienst bereit. Die Cloud verwendet jedoch kein eigenes, davon abweichendes Lösungsformat. Eine in SchallOS Studio entwickelte Anwendung kann einer Cloud-Instanz zugewiesen und über den Browser bereitgestellt werden. Runtime, Datenbank, Sicherungen, Überwachung und Updates werden zentral verwaltet. Für Entwickler und Kunden entsteht daraus ein SaaS-Modell, ohne dass die Anwendung eigens für eine getrennte Cloud-Plattform neu entwickelt werden muss.
Die grundsätzliche Portabilität bleibt erhalten. Eine Lösung kann später auf einen eigenen Server oder in eine andere unterstützte Betriebsform übertragen werden, sofern Datenmenge, Funktionen und technische Voraussetzungen dies zulassen. Der Wechsel bleibt eine kontrollierte Migration, erfordert aber keinen vollständigen Neubau der Anwendung.
Eine Lösung kann mit ihren Anforderungen wachsen
Eine neue Anwendung kann zunächst lokal entwickelt und mit einem kleinen Datenbestand getestet werden. Später lässt sie sich als interne Runtime bereitstellen, auf SQLite oder PostgreSQL umstellen und schließlich als Server- oder Cloud-Lösung veröffentlichen. Tabellen, Layouts, Formeln, Funktionscontainer, Übersetzungen und Dokumentation bleiben dabei Teil derselben Lösungsstruktur.
Nicht jeder Prototyp wird ohne Anpassungen zu einer großen Unternehmensanwendung. Mehrbenutzerbetrieb, Sicherheit, Leistung und Sicherung müssen weiterhin sorgfältig geplant werden. Die Plattform verhindert jedoch, dass Wachstum zwangsläufig einen vollständigen Technologiewechsel erfordert.
Runtime, Control und Cloud verbinden damit unterschiedliche Betriebsmodelle innerhalb einer gemeinsamen Architektur. Die Anwendung wird einmal entwickelt und anschließend kontrolliert für den jeweiligen Einsatz bereitgestellt – lokal, auf einem eigenen Server oder als SaaS in der Cloud.
Gerne. Ich würde diesen Abschnitt direkt hinter dem KI-Kapitel oder als Ergänzung zu Kapitel 4 einfügen. Er greift einen wichtigen Gedanken auf: Die KI ist nicht fest an einen Anbieter gebunden, sondern wird wie Datenbankadapter als austauschbare Infrastruktur behandelt.
KI-Adapter statt Herstellerbindung
SchallOS trennt die eigentliche KI-Schicht bewusst von den verwendeten Sprachmodellen. Die Plattform arbeitet nicht ausschließlich mit einem einzelnen Anbieter oder einer bestimmten Laufzeitumgebung. Stattdessen können verschiedene KI-Adapter eingerichtet und zentral verwaltet werden.
Diese Adapter bilden die Verbindung zwischen SchallOS und den jeweils verwendeten Sprachmodellen. Dadurch bleibt die eigentliche Entwicklungsumgebung unabhängig davon, ob eine Anfrage an ein lokales Modell oder an einen Cloud-Dienst gesendet wird.
Die KI wird damit zu einem austauschbaren Bestandteil der Plattform – ähnlich wie die Datenbankadapter für IndexedDB, SQLite oder PostgreSQL.
Zentrale Verwaltung in SchallOS Control
Die Einrichtung der KI erfolgt zentral über SchallOS Control. Dort können beliebig viele KI-Adapter angelegt und verwaltet werden. Unterstützt werden sowohl lokale Modelle als auch Cloud-Dienste.
Lokale Modelle können beispielsweise über Ollama oder LM Studio eingebunden werden. Für viele Entwicklungsaufgaben reicht bereits ein kompaktes lokales Modell aus, das vollständig auf dem eigenen Rechner ausgeführt wird.
Zusätzlich lassen sich Cloud-Modelle wie ChatGPT, Claude oder weitere kompatible Dienste einrichten. Jeder Adapter besitzt dabei seine eigene Konfiguration, etwa Zugangsdaten, Endpunkte, Modellbezeichnungen oder weitere technische Einstellungen. Dadurch entsteht eine zentrale Übersicht über alle verfügbaren KI-Systeme innerhalb einer SchallOS-Installation.
Einmal eingerichtet, überall verfügbar
Ein großer Vorteil dieser Architektur besteht darin, dass ein einmal eingerichteter KI-Adapter nicht nur an einer einzelnen Stelle verwendet wird. Sobald ein Adapter in SchallOS Control eingerichtet wurde, steht er der gesamten Plattform zur Verfügung. Er kann beispielsweise verwendet werden:
- im Formeleditor
- innerhalb von Funktionscontainern
- für die automatische Dokumentation
- bei der Migration von FileMaker-Lösungen
- im Adapter Studio
- oder in zukünftigen KI-gestützten Entwicklungswerkzeugen.
Der Entwickler muss Zugangsdaten oder Modelle daher nicht mehrfach konfigurieren. Die Verwaltung erfolgt zentral, während die einzelnen Komponenten lediglich den gewünschten Adapter auswählen.
Das passende Modell für die jeweilige Aufgabe
Nicht jede Entwicklungsaufgabe benötigt dieselbe Rechenleistung. Für eine kurze Erklärung einer Formel genügt häufig ein kleines lokales Modell. Umfangreiche Migrationen oder komplexe Programmieraufgaben können dagegen von einem leistungsfähigeren Cloud-Modell profitieren.
SchallOS erlaubt deshalb die Auswahl unterschiedlicher Adapter je nach Anwendungsfall. Ein Entwickler kann beispielsweise festlegen, dass einfache Dokumentationen grundsätzlich lokal erstellt werden, während besonders umfangreiche Aufgaben an ein externes Modell übergeben werden. Dadurch lassen sich Geschwindigkeit, Datenschutz und Kosten besser aufeinander abstimmen.
Offen für zukünftige Modelle
Die Entwicklung im Bereich der künstlichen Intelligenz verläuft außerordentlich schnell. Neue Modelle erscheinen in kurzen Abständen, während bestehende Systeme kontinuierlich verbessert werden. SchallOS bindet sich deshalb nicht dauerhaft an einen einzelnen Anbieter. Entscheidend ist nicht der Name eines bestimmten Modells, sondern die standardisierte Adapter-Schnittstelle.
Neue lokale oder cloudbasierte KI-Systeme können dadurch später ergänzt werden, ohne die eigentliche Entwicklungsumgebung verändern zu müssen. Diese Offenheit entspricht der grundsätzlichen Architektur von SchallOS. Wie bei den Datenbankadaptern sollen auch KI-Adapter austauschbar bleiben, während Studio, Runtime und die eigentliche Anwendung unverändert weiterarbeiten können.
Dadurch wird künstliche Intelligenz zu einer dauerhaft integrierten Plattformfunktion – unabhängig davon, welche Modelle oder Anbieter sich in den kommenden Jahren am Markt durchsetzen.
Von der FileMaker-Migration zur unabhängigen Softwareplattform
SchallOS ist aus der langjährigen Arbeit mit FileMaker entstanden. Viele Grundideen der Plattform beruhen auf Erfahrungen mit individuellen Datenbank- und ERP-Lösungen, die über Jahre gemeinsam mit ihren betrieblichen Anforderungen gewachsen sind.
FileMaker besitzt besondere Stärken bei der schnellen Entwicklung. Datenmodell, Layouts und Programmlogik befinden sich nahe beieinander, Änderungen werden unmittelbar sichtbar, und erste funktionsfähige Lösungen lassen sich vergleichsweise schnell erstellen.
Diese Nähe zwischen Entwickler, Daten und Benutzeroberfläche soll in SchallOS erhalten bleiben. Die technische Grundlage wird jedoch neu aufgebaut. SchallOS verwendet eine eigene Runtime, eigene Struktur- und Datencontainer, eine KI-gestützte Funktionsschicht sowie eine eigene Infrastruktur für Dokumentation, Deployment und Updates.
FileMaker bleibt damit ein wichtiger Ausgangspunkt und eine mögliche Quelle für bestehende Lösungen. Für den späteren Betrieb ist es jedoch nicht mehr erforderlich.
Migration ist mehr als ein Layoutimport
Eine gewachsene FileMaker-Lösung besteht nicht nur aus Tabellen, Feldern und sichtbaren Masken. Ein großer Teil ihres fachlichen Wissens steckt in Formeln, Skripten, Triggern, Beziehungen, Wertelisten und zahlreichen Sonderfällen.
Eine brauchbare Migration muss diese Zusammenhänge erfassen und in eine neue Architektur überführen. Tabellen, Felder, Beziehungen und Layouts können dabei weitgehend strukturiert übernommen werden. Formeln und Custom Functions werden in die SchallOS-Formelumgebung übertragen oder angepasst.
Bei den FileMaker-Skripten steht zunächst das Verständnis ihrer fachlichen Aufgabe im Mittelpunkt. Sie können als Lern- und Referenzschicht im Hintergrund der neuen Funktionscontainer erhalten bleiben. Der ausführbare Code wird jedoch durch die KI passend zur SchallOS-Architektur neu programmiert. Dadurch entsteht keine FileMaker-Laufzeit innerhalb eines neuen Systems. Die vorhandene Lösung wird schrittweise zu einer eigenständigen SchallOS-Anwendung.
Unabhängiger Betrieb nach der Migration
Nach einer vollständigen Migration werden weder FileMaker Pro noch FileMaker Server oder WebDirect benötigt. Die neue Anwendung verwendet SchallOS Runtime, den SSC als Strukturcontainer und den SSD für die produktiven Daten. Formeln, Funktionscontainer, Mehrsprachigkeit, Dokumentation, Ereignisprotokolle und Updates werden durch die SchallOS-Plattform bereitgestellt.
Je nach Anforderungen kann die Lösung lokal, als Windows- oder macOS-Anwendung, auf einem eigenen Server oder als SaaS-Angebot in SchallOS Cloud betrieben werden.
Damit endet die Bindung an eine einzelne proprietäre Laufzeitumgebung. Technische Abhängigkeiten verschwinden dadurch nicht vollständig – jede moderne Software benötigt Betriebssysteme, Datenbanken und Serverdienste. Struktur, Geschäftslogik und Daten bleiben jedoch portabel und können über dokumentierte Adapter und Deployment-Wege betrieben werden.
Neue Möglichkeiten für FileMaker-Entwickler
Für FileMaker-Entwickler soll SchallOS keinen vollständigen Bruch mit der bisherigen Arbeitsweise darstellen. Kenntnisse über Datenmodelle, Layoutgestaltung und betriebliche Prozesse bleiben weiterhin wertvoll.
Verändert wird vor allem die Umsetzung der Programmlogik. An die Stelle langer Skriptketten treten semantisch beschriebene Funktionscontainer. Die KI programmiert den ausführbaren Code auf Grundlage definierter Aufgaben, Parameter und Grenzen. Der Entwickler prüft das Ergebnis und bleibt für Architektur und fachliche Richtigkeit verantwortlich.
Auch die Entwicklungsgeschichte wird stärker berücksichtigt. Änderungen können automatisch protokolliert, dokumentiert und zu Releases zusammengefasst werden. Dieselbe Update-Pipeline, über die SchallOS selbst aktualisiert wird, steht auch für eigene Kundenlösungen zur Verfügung.
Damit verlagert sich die Arbeit teilweise von der manuellen Eingabe einzelner Programmschritte hin zur präzisen Beschreibung, Prüfung und Strukturierung von Geschäftsprozessen.
Nicht nur für migrierte Anwendungen
Die FileMaker-Migration bleibt ein wichtiger Bestandteil von SchallOS, ist aber nicht der einzige Verwendungszweck. Neue Anwendungen können vollständig in SchallOS Studio entwickelt werden.
Langfristig könnten auch weitere Ausgangssysteme unterstützt werden. Eine solche Erweiterung benötigt jedoch jeweils eigene Analyse- und Migrationsverfahren. Unterschiedliche Entwicklungsplattformen besitzen eigene Konzepte, die sich nicht sinnvoll durch einen oberflächlichen Universalimport abbilden lassen.
Die Erfahrungen aus der FileMaker-Migration schaffen dafür eine Grundlage. Der eigentliche Zweck von SchallOS liegt jedoch in der Entwicklung und dem Betrieb unabhängiger Business-Anwendungen.
Geplanter Start im Herbst 2026
Der öffentliche Start von SchallOS ist für den Herbst 2026 vorgesehen. Bis dahin werden die tragenden Plattformbereiche weiter zusammengeführt, geprüft und für die ersten produktiven Einsatzfälle vorbereitet. Nicht jede langfristig geplante Funktion wird bereits zum Start vollständig ausgebaut sein. Entscheidend ist ein belastbarer Kern, auf dem weitere Datenbankadapter, KI-Funktionen, Migrationsmöglichkeiten und Betriebsmodelle kontrolliert aufbauen können.
Zunächst wird die gFM-NEXT ERP-Software von gofilemaker.de auf der neuen SchallOS-Plattform voraussichtlich im September 2026 veröffentlicht. Der Start der SchallOS Entwicklungsplattform etwas später im Herbst 2026 soll deshalb nicht das Ende der Entwicklung markieren, sondern den Beginn des praktischen Einsatzes.
Der vollständige Lebenszyklus einer Anwendung
SchallOS begann mit der Frage, wie sich bestehende FileMaker-Lösungen in eine moderne Umgebung übertragen lassen. Daraus ist eine Plattform entstanden, die nicht nur Migration und Entwicklung, sondern auch Dokumentation, Deployment, Datenhaltung, Updates und langfristigen Betrieb berücksichtigt. Studio, Runtime, Control und Cloud übernehmen dabei klar getrennte Aufgaben innerhalb einer gemeinsamen Architektur. Der Anspruch besteht deshalb nicht darin, FileMaker lediglich durch ein anderes Entwicklungswerkzeug zu ersetzen. SchallOS soll die bewährte Nähe zwischen Entwickler, Daten und Benutzeroberfläche mit portablen Containern, KI-gestützter Programmierung und einem durchgängigen Betriebsmodell verbinden.
Die FileMaker-DNA bildet den Ausgangspunkt. Das Ziel ist eine unabhängige Plattform, auf der bestehende und neue Business-Anwendungen langfristig entwickelt, betrieben und weitergeführt werden können.
Veelgestelde vragen
- Was genau ist SchallOS, und worin unterscheidet es sich von einer klassischen Datenbankanwendung?
SchallOS ist eine Plattform zur Entwicklung, Ausführung und Verwaltung individueller Business-Software. Sie umfasst nicht nur Tabellen, Layouts und Funktionen, sondern auch KI-gestützte Programmierung, Dokumentation, Ereignisprotokolle, Deployment und Updates. SchallOS Studio dient der Entwicklung, Runtime führt fertige Anwendungen aus, Control verwaltet Installationen und Cloud stellt Lösungen als SaaS bereit. Dadurch begleitet die Plattform eine Anwendung von ihrer Entstehung bis zum langfristigen Betrieb. - Für welche Entwickler und Unternehmen ist SchallOS vorgesehen?
SchallOS richtet sich insbesondere an FileMaker-Entwickler, Softwareunternehmen und Entwickler individueller Business-Anwendungen. Auch Unternehmen mit bestehenden FileMaker-Lösungen erhalten eine Möglichkeit, ihre Anwendungen schrittweise in eine unabhängige Umgebung zu überführen. Darüber hinaus können neue Lösungen vollständig in SchallOS entstehen. Für Geschäftsführer und technische Entscheider ist vor allem interessant, dass Entwicklung, Betrieb, Dokumentation, Updates und verschiedene Bereitstellungsformen innerhalb einer gemeinsamen Plattform organisiert werden. - Ist SchallOS hauptsächlich ein Ersatz für FileMaker?
FileMaker ist ein wichtiger Ausgangspunkt, aber nicht die dauerhafte technische Grundlage von SchallOS. Bewährte Ideen wie die visuelle Entwicklung und die enge Verbindung von Daten, Layouts und Funktionen werden übernommen. Die Runtime, Datenhaltung, Funktionslogik und Update-Infrastruktur werden jedoch eigenständig aufgebaut. SchallOS kann bestehende FileMaker-Lösungen migrieren, eignet sich aber ebenso für neue Anwendungen. Nach einer vollständigen Migration wird FileMaker für den produktiven Betrieb nicht mehr benötigt. - Kann meine bestehende FileMaker-Lösung vollständig automatisch migriert werden?
Tabellen, Felder, Beziehungen, Layouts und weitere definierte Strukturen lassen sich weitgehend automatisiert übernehmen. Bei komplexer Geschäftslogik ist jedoch eine zusätzliche Prüfung erforderlich. FileMaker-Skripte enthalten häufig Layoutwechsel, globale Variablen, Plugins oder historisch entstandene Sonderfälle. Die KI kann diese Abläufe analysieren und daraus neue Funktionscontainer erstellen. Eine umfangreiche Lösung sollte dennoch von einem Entwickler geprüft und gegebenenfalls bereinigt werden. Die Migration reduziert den manuellen Aufwand erheblich, ersetzt aber nicht das fachliche Verständnis der Anwendung. - Was geschieht nach der Migration mit den vorhandenen FileMaker-Skripten?
Die Skripte können im Hintergrund der neuen Funktionscontainer als Lern- und Referenzschicht erhalten bleiben. Sie werden jedoch nicht unverändert ausgeführt. Die KI analysiert, welche fachliche Aufgabe ein Skript erfüllt, welche Felder verwendet und welche Bedingungen geprüft werden. Anschließend programmiert sie den neuen ausführbaren Code passend zur SchallOS-Architektur. Das ursprüngliche Skript bleibt als historische Wissensquelle erhalten und kann bei späteren Fragen oder Erweiterungen weiterhin berücksichtigt werden. - Was sind SSC und SSD, und warum benötigt eine Lösung zwei Container?
Der SSC enthält die Struktur der Anwendung, darunter Tabellen, Felder, Layouts, Formeln, Funktionscontainer, Sprachen und Dokumentation. Der SSD enthält die produktiven Daten wie Kunden, Artikel, Aufträge oder Rechnungen. Beide Container gehören zusammen, besitzen aber unterschiedliche Aufgaben. Diese Trennung ermöglicht es, neue Strukturversionen zu installieren, ohne den gesamten Datenbestand auszutauschen. Außerdem können Datenhaltung, Sicherungen und Betriebsmodelle verändert werden, ohne die Anwendung vollständig neu entwickeln zu müssen. - Welche Vorteile bietet die Trennung von Struktur und Daten?
Updates, Sicherungen und Migrationen lassen sich dadurch wesentlich kontrollierter durchführen. Ein neuer SSC kann veröffentlicht werden, während der SSD mit den Kundendaten erhalten bleibt. Notwendige Strukturänderungen werden über definierte Datenmigrationen ausgeführt. Der SSC kann außerdem ohne vertrauliche Geschäftsdaten analysiert oder an einen anderen Entwickler übergeben werden. Auch ein Wechsel von IndexedDB zu SQLite, PostgreSQL oder in die Cloud wird erleichtert, weil Layouts und Funktionslogik nicht neu aufgebaut werden müssen. - Kann dieselbe Lösung lokal, auf einem Server und in der Cloud betrieben werden?
Grundsätzlich ja. Eine SchallOS-Lösung kann lokal im Browser, als Windows- oder macOS-Anwendung, mit SQLite, auf einem PostgreSQL-Server oder als SaaS in SchallOS Cloud betrieben werden. Die fachliche Anwendung bleibt dabei dieselbe. Unterschiedliche Betriebsformen besitzen jedoch eigene Anforderungen an Mehrbenutzerbetrieb, Sicherung, Leistung und Administration. Ein Wechsel erfolgt deshalb kontrolliert über Datenübertragung und Prüfung. Die SSC-/SSD-Architektur verhindert, dass für jedes Ziel ein vollständig neues Projekt gepflegt werden muss. - Benötige ich nach einer erfolgreichen Migration weiterhin FileMaker oder FileMaker Server?
Nein. Nach einer vollständigen Migration wird die Anwendung durch SchallOS Runtime ausgeführt. Auch für den Browserbetrieb werden weder FileMaker Server noch WebDirect benötigt. Das frühere FileMaker-System kann als Referenz oder Archiv erhalten bleiben, ist aber keine Voraussetzung für den produktiven Betrieb. Layouts, Formeln, Funktionen, Datenzugriff, Updates und Deployment werden von SchallOS übernommen. Damit entfallen auch die bisherigen FileMaker-Laufzeitabhängigkeiten für die migrierte Anwendung. - Wie ist die künstliche Intelligenz in SchallOS integriert?
Die KI steht unmittelbar im Formeleditor, in Custom Functions, Funktionscontainern und in der Dokumentationsschicht zur Verfügung. Sie kennt nicht nur die aktuelle Frage, sondern auch die betroffenen Felder, Tabellen, Beschreibungen und Abhängigkeiten. Bei migrierten Lösungen kann zusätzlich das ursprüngliche FileMaker-Skript als Hintergrundwissen dienen. Die KI kann Formeln erklären, Code erzeugen, Fehler untersuchen und Dokumentationen formulieren. Die Modelle sollen grundsätzlich austauschbar bleiben, damit Qualität, Kosten und Datenschutz berücksichtigt werden können. - Programmiert die KI tatsächlich den Code der Funktionscontainer?
Ja. Der Entwickler beschreibt Aufgabe, Parameter, erwartetes Ergebnis und erlaubte Fähigkeiten. Auf dieser Grundlage erzeugt die KI den ausführbaren Code. Dieser bleibt sichtbar, prüfbar und versionierbar. Der Entwickler kann Änderungen anfordern, Tests durchführen und frühere Fassungen vergleichen oder wiederherstellen. Die KI übernimmt damit einen großen Teil der Programmierarbeit, nicht aber die fachliche Verantwortung. Gerade bei geschäftskritischen Abläufen müssen Anforderungen, Rechte und mögliche Nebenwirkungen weiterhin sorgfältig kontrolliert werden. - Welche Möglichkeiten bietet der Formeleditor?
Der Formeleditor unterstützt typische mathematische, logische, textbezogene sowie Datums- und Zeitberechnungen. Formeln und Custom Functions werden in Echtzeit ausgewertet und können unmittelbar getestet werden. Der anfängliche Befehlsumfang ist kleiner als der langjährig gewachsene Funktionsbestand von FileMaker. Die Formelumgebung ist jedoch erweiterbar. Fehlende Funktionen können ergänzt oder durch eigene Custom Functions abgebildet werden. Auch dabei kann die integrierte KI vorhandene FileMaker-Formeln übertragen oder neue Berechnungen entwickeln. - Was dokumentiert SchallOS automatisch?
Auf Strukturebene werden Änderungen an Tabellen, Feldern, Layouts, Formeln und Funktionscontainern erfasst. Auf Datenebene können Datensatzänderungen, Statuswechsel, Freigaben, Importe und weitere fachliche Ereignisse protokolliert werden. Hinzu kommen Betriebsereignisse wie Deployments, Updates und Sicherungen. Zusammengehörige Entwicklungsarbeiten lassen sich in Change Sessions bündeln und später einem Release zuordnen. Dadurch entsteht eine nachvollziehbare Geschichte der Anwendung, statt nur eine Sammlung nachträglich geschriebener Notizen. - Kann SchallOS daraus Kunden- und Leistungsberichte erstellen?
Ja. Die integrierte KI kann aus den erfassten Ereignissen technische Dokumentationen, Kundenberichte, Release Notes oder Leistungsnachweise erzeugen. Mehrere technische Änderungen lassen sich dabei zu einer verständlichen Beschreibung des geschäftlichen Nutzens zusammenfassen. Die zugrunde liegenden Ereignisse bleiben weiterhin einsehbar, sodass der Entwickler die Formulierungen prüfen kann. Nicht jede Änderung ist automatisch abrechenbar. Auswahl, Bewertung und Freigabe des endgültigen Leistungsprotokolls bleiben deshalb beim Entwickler. - Wie funktioniert die Update-Pipeline?
Änderungen werden zunächst in Change Sessions gesammelt und zu einem Release zusammengefasst. Ein Release kann einen neuen SSC, notwendige SSD-Migrationen, Voraussetzungen, Signaturen, Prüfungen und Rollback-Informationen enthalten. SchallOS Control prüft die Zielinstanz, erstellt eine Sicherung und führt anschließend das Update aus. Nach der Installation wird kontrolliert, ob Struktur, Daten und wichtige Funktionen dem erwarteten Zustand entsprechen. Dieselbe grundlegende Pipeline wird für SchallOS selbst und für die damit entwickelten Kundenlösungen verwendet. - Worin unterscheiden sich Runtime, Control und Cloud?
SchallOS Runtime führt veröffentlichte Anwendungen aus und stellt Layouts, Formeln und Funktionscontainer bereit. SchallOS Control verwaltet Instanzen, Datenbankadapter, Runtime-Profile, Updates und technische Prüfungen. SchallOS Cloud bietet Runtime und Datenhaltung als zentral betriebenen SaaS-Dienst an. SchallOS Studio bleibt die eigentliche Entwicklungsumgebung. Alle Bereiche verwenden dieselben SSC- und SSD-Grundstrukturen, übernehmen aber klar voneinander getrennte Aufgaben innerhalb des Lebenszyklus einer Anwendung. - Wie werden Rechte, Installationen und sensible Daten geschützt?
Benutzerrechte bestimmen, welche fachlichen Aktionen eine Person innerhalb der Lösung durchführen darf. Runtime- und Capability-Profile legen zusätzlich fest, welche technischen Funktionen eine Installation überhaupt besitzt. SSC- und SSD-Pakete können mit Kennungen, Prüfsummen und Signaturen geschützt werden. Auch der KI-Kontext lässt sich begrenzen, sodass nicht automatisch sämtliche Kundendaten verarbeitet werden. Für besonders sensible Umgebungen können eigene Server oder künftig auch lokale KI-Modelle verwendet werden. Die konkrete Sicherheitskonfiguration richtet sich nach dem jeweiligen Einsatzfall. - Wann soll SchallOS verfügbar sein?
Der öffentliche Start ist für den Herbst 2026 vorgesehen. Im Mittelpunkt stehen zunächst Studio und Runtime, die Trennung von SSC und SSD, die Migration vorhandener FileMaker-Strukturen, Formeln, Custom Functions, KI-programmierte Funktionscontainer, Dokumentation, Ereignisprotokolle, Deployment und Updates. Auch SchallOS Control wird für die Verwaltung der Installationen eine zentrale Rolle übernehmen. Nicht jede langfristig geplante Funktion muss bereits zum Start vollständig ausgebaut sein. Entscheidend ist zunächst ein belastbarer Kern für erste produktive Anwendungen.
