CTO-Perspektive · 2. September 2026

Wenn Anwendungen zu Ansichten auf ein gemeinsames System werden.

TagDB und TagNet verbinden langlebige fachliche Daten mit Beziehungen, Ansichten, Capabilities und laufenden Teilnehmern. Das Versprechen ist nicht „noch eine Plattform“. Es ist eine Architektur, in der neue Anwendungen zunehmend aus bereits vorhandener Bedeutung entstehen.

Hebel: Wiederverwendung fachlicher Bedeutung
Einführung: Sidecar statt Big Bang
Kontrolle: Capabilities statt implizitem Vertrauen
Ergebnis: Viele Projektionen, ein nachvollziehbarer Zusammenhang

Das Problem hinter den Anwendungen

Unternehmen besitzen selten zu wenig Software. Sie besitzen zu viele getrennte Wahrheiten.

ERP, Shop, Kundenportal, Verzeichnisdienst, Werkstattansicht, Logistik, Website und Dokumentablage erfüllen jeweils eine Aufgabe. Doch dieselbe Person, dasselbe Produkt, derselbe Vertrag und dasselbe Asset erscheinen überall unter anderen IDs, mit anderen Ausschnitten und eigenen Regeln.

Integration wird zum Dauerzustand.

Jede neue Oberfläche braucht wieder Identitätsabgleich, Mapping, Cache, Rechte, Fehlerbehandlung und Synchronisation.

Kontext verschwindet an Systemgrenzen.

Quellen liefern Felder. Die fachliche Beziehung – warum etwas zusammengehört und wer es sehen darf – landet oft nur im Anwendungscode.

Aus kleinen Änderungen werden Projekte.

Eine zusätzliche Rolle, Ansicht oder Ausgabeform berührt Backend, API, Frontend, Datenmodell und Deployment zugleich.

TagDB versucht nicht, alle Quellsysteme zu ersetzen. Es macht ihre Aussagen adressierbar, verbindet sie mit zusätzlicher Bedeutung und projiziert daraus die jeweils benötigte Sicht.

Das System in zwei Teilen

TagDB hält den Zusammenhang. TagNet bringt ihn in Bewegung.

TagDBGedächtnis und Bedeutung

Ein Graph, der mehr als Daten kennt

Nodes und Relationen beschreiben Dinge, Identitäten, Quellen, Beobachtungen, Rollen und Provenienz. Schemas, Views, Apps, Widgets und Presets können ebenfalls Daten sein und dadurch versioniert, verbunden und kontextabhängig ausgewählt werden.

stabile interne und externe Identitäten
Relationen statt versteckter Fremdschlüsselkonventionen
Views für klassische Tabellen und SQL-Zugriff
Schemas und Renderer für unterschiedliche Ansichten
Claims und Evidence für unsichere Aussagen
Instructions und Workflows als nachvollziehbare Absicht

TagNetPresence und Ausführung

Ein Netz aus adressierbaren Teilnehmern

Browser, Dienste, Geräte und Adapter melden ihre Fähigkeiten an. TagNet verteilt Ereignisse, private Subscriptions und Commands und liefert benötigte Apps oder Module bedarfsgerecht. Der Graph entscheidet nicht allein; die konkrete Capability wird am Ziel erneut autorisiert.

WebSocket-basierte Presence und Kommunikation
adressierte Events statt globalem Nachrichtenrauschen
Adapter zu bestehenden Fachsystemen
lazy geladene Apps und UI-Module
registrierte Host-Capabilities
kleiner Vertrauensanker für ausführbaren Code

Vom Quellsystem bis zur Handlung

ERP, Shop, Datei oder Gerät
Adapter und externe Identität
Node, Relation und Provenienz
Actor, Scope und Capability
View, Schema oder App
Anzeige, Anfrage oder autorisierte Handlung

Was bereits als Baustein gedacht ist

Die Plattform beginnt nicht bei null.

Graph und Provenienz

Dinge, Aussagen, Quellen, Revisionen und Beziehungen bleiben unterscheidbar. Fremde Daten müssen nicht vereinnahmt werden.

Views und SQL

Portable View-Nodes können als klassische Listen und echte SQLite-Views erscheinen. Bestehende Consumer dürfen weiterhin „Tabelle“ denken.

Schemas und UI

Dasselbe Asset kann beim Kunden, im Service und in der Logistik anders aussehen – ohne drei unabhängige Fachobjekte zu erzeugen.

Capabilities und Workflows

„Anzeigen“, „tauschen“, „zurückgeben“ oder „freigeben“ sind explizite, eng begrenzte Fähigkeiten statt zufälliger Nebenwirkungen einer Route.

Realtime und Subscriptions

Kleine Ereignisse invalidieren Projektionen. Die autoritative Quelle wird anschließend erneut gelesen; ein Event muss nicht die ganze Wahrheit transportieren.

DAV, PDF und Materialisierung

Ein Vertrag kann Webseite, PDF oder Datei im Finder sein. Öffentliche Seiten können statisch materialisiert werden, ohne den lebenden Graphen preiszugeben.

Apps und Widgets als Daten

Auswahl, Komposition, Konfiguration und Bereitstellung wandern in den Graphen. Ausführbarer Code bleibt registriert und überprüfbar.

Importer und Adapter

Deterministische Profile, getrennte Writer und Evidence ermöglichen die Verbindung wechselnder Quellen ohne stille Überschreibung.

Shop und Fachmodelle

Neutrale Begriffe für Produkte, Angebote, Preise und Bestellungen können konkrete ERP- und Shopmodelle verbinden, ohne sie gleichzusetzen.

Der wirtschaftliche Hebel

Nicht jede neue Oberfläche braucht ein neues Backend.

Heute häufig	Mit gemeinsamem semantischem Unterbau	CTO-Relevanz
Fachobjekt pro Anwendung erneut modellieren	bestehenden Node in neuem Kontext projizieren	weniger Duplikation und Drift
REST-Endpunkt und DTO für jede Ansicht	View, Schema und Capability komponieren	kürzere Wege vom Bedarf zur Oberfläche
Integration als nächtlicher Vollimport	Provenienz, Beobachtung, Event und Reconciliation trennen	sichtbarere Aktualität und Fehler
Rechte in Controllerlogik verteilen	Actor, Scope und Ziel-Capability explizit prüfen	prüfbare Sicherheitsgrenzen
Legacy-System komplett ablösen	Sidecar-Projektion und gezielte neue Writer	geringeres Migrationsrisiko
Wissen nur in Code und Köpfen	Beziehungen, Status und Provenienz als Daten	bessere Discovery für Menschen und Agenten

Beispielhafter Zusammenhang

Ein Unternehmen, mehrere Bereiche und Kanäle – aber ein nachvollziehbarer fachlicher Zusammenhang.

Ein Unternehmen verkauft und betreut langlebige Produkte. Kunden können Einzelpersonen, Familien, Organisationen oder Einrichtungen sein. Beratung, Service, Logistik und Verwaltung arbeiten am selben realen Gegenstand, benötigen aber andere Ausschnitte und Handlungen.

Kunde oder Organisation

Produkte, Verträge, Status und Dokumente sehen; erlaubte Anfragen wie Service oder Rückgabe auslösen.

Einrichtung

Viele Verträge, berechtigte Mitglieder, Standorte und Übergaben gemeinsam verwalten.

Service

Assetzustand, Zubehör, Verlauf und genau die Capabilities sehen, die für die Arbeit benötigt werden.

Logistik und Verwaltung

Lieferung, Abholung, Vertragsbezug und Quellsystem-Workflows im Zusammenhang bearbeiten.

<Unternehmen>
  ├─ vertreibt ─────────────→ Produkt ────────────→ Kunde
  ├─ betreut ───────────────→ konkretes Asset
  └─ verbindet ─────────────→ Beratung, Service, Logistik, Verwaltung

Kunde / Organisation / Einrichtung
  └─ besitzt oder nutzt ────→ Vertrag ──→ konkretes Asset
                                      ├─→ Dokumente und Status
                                      ├─→ Übergabe und Lieferung
                                      └─→ Servicefall oder Rückgabe

Das Kundenportal wäre in diesem Modell keine separate Kundendatenbank. Es wäre eine autorisierte Projektion desjenigen Teilbaums, der nach der Anmeldung für diesen Actor sichtbar und handlungsfähig ist.

Architektur- und Sicherheitsgrenzen

„Alles kann Daten sein“ heißt nicht „alles darf ausgeführt werden“.

Quellen behalten Autorität.

ERP, Shop, Verzeichnisdienst oder Gerät bleiben Writer ihrer Aussagen, bis eine andere Verantwortung bewusst beschlossen und migriert wurde.

Code bleibt Code.

Protokolle, Kryptographie, Datenbankkernel, Netzwerkadapter und DOM-Primitiven bleiben geprüfte Implementierung. Der Graph wählt und konfiguriert registrierte Fähigkeiten.

Discovery ist keine Autorisierung.

Eine sichtbare App oder angebotene Capability erlaubt noch keine Handlung. Das Ziel prüft Actor, Scope, Parameter und konkrete Revision erneut.

Caches sind Beobachtungen.

Eine schnelle erste Ansicht darf „last observed“ sein. Herkunft, Alter und Refresh bleiben sichtbar; die echte Quelle wird progressiv nachgeladen.

Writer bleiben getrennt.

Ein universeller SQL-Writer darf nicht beiläufig fachliche Relationen erfinden. Consumer besitzen die Semantik ihrer Schreibvorgänge.

Projektionen sind widerrufbar.

Views, HTML, PDF, DAV und Apps zeigen Daten. Sie werden nicht automatisch zu neuen führenden Datensätzen.

Einführung ohne Plattformprogramm

Mit einem echten Zusammenhang anfangen, nicht mit einem Weltmodell.

Einen wertvollen Slice wählen.Zum Beispiel Kunde → Vertrag → Asset → Dokument, einschließlich einer erlaubten Anfrage.
Autoritäten benennen.Für jede Aussage festhalten, welches System Writer ist und welche externe Identität stabil bleibt.
Verlustfrei projizieren.Quellen zunächst als Sidecar verbinden. Keine erzwungene Migration, keine stillen Überschreibungen.
Zwei Perspektiven bauen.Dasselbe Asset für Kunde und Mitarbeiter verschieden darstellen. Damit wird Wiederverwendung messbar.
Eine Capability durchziehen.Nicht nur lesen: eine eng begrenzte Anfrage samt Autorisierung, Audit und Rückmeldung vollständig abbilden.
Betrieb beweisen.Refresh, Reconciliation, Backup, Fehlerzustand, Trace und Deployment in den Slice einbeziehen.
Erst danach verbreitern.Weitere Quellen, Rollen und Ausgaben werden an den bewährten Verträgen ergänzt.

Was ein CTO kritisch prüfen sollte

Der Ansatz verschiebt Komplexität. Er lässt sie nicht verschwinden.

Semantische Disziplin: Ein flexibler Graph kann ebenso leicht zum ungeordneten Graphen werden. Ownership, Namensräume, Status und Provenienz brauchen klare Konventionen.
Plattformgrenze: Universelle Funktionen gehören upstream; Fachlogik bleibt beim Consumer. Wird diese Grenze unscharf, entstehen entweder ein Monolith oder viele lokale Kopien.
Beobachtbarkeit: Wenn Daten, Projektionen und Capabilities dynamisch komponiert werden, müssen Herkunft, Auswahlentscheidung und Ausführung durchgehend nachvollziehbar sein.
Reifegrade: Produktiv, implementiert, lokal getestet, beschlossen und geplant sind verschiedene Zustände. Architekturkommunikation darf sie nicht vermischen.
Bus-Faktor: Das System muss aus Feature-Katalogen, ADRs, Schemas und laufenden Beispielen rekonstruierbar sein – nicht nur aus dem Wissen einzelner Personen.
Exit-Fähigkeit: Offene Formate, klassische Views, statische Materialisierungen und klar getrennte Quellsysteme sind nicht Komfort, sondern Teil der Risikobegrenzung.

Die eigentliche Entscheidung

Wann ist TagDB + TagNet der richtige Denkraum?

Ein guter Kandidat

mehrere Quellen beschreiben dieselben realen Dinge
Beziehungen und Provenienz sind geschäftlich relevant
verschiedene Rollen brauchen verschiedene Ansichten
Web, App, Tabelle, Dokument und Realtime greifen auf denselben Zusammenhang zu
Schemata und Anforderungen ändern sich häufig
bestehende Systeme sollen schrittweise verbunden werden

Wahrscheinlich zu viel

eine kleine, stabile CRUD-Anwendung mit genau einer Quelle
ein isolierter Workflow ohne wiederverwendbare Beziehungen
ein kurzlebiger Import ohne Provenienz- oder Synchronisationsbedarf
ein Problem, das eine klassische Tabelle dauerhaft vollständig beschreibt