RecordWeb · Für Implementierende

RWP für Implementierende.

Wie Anwendungen Records nicht nur speichern, sondern als verknüpfte, verantwortete und langfristig anschlussfähige Informationsobjekte führen können.

Ihre Anwendung muss nicht zum einzigen System werden.
Sie kann zu einem verantworteten Knoten im RecordWeb werden.

Szene 1 · Die Produktrealität

Ihre Anwendung ist bereits wichtig, aber sie ist nicht allein.

In einer Verwaltung entstehen geschäftsrelevante Informationen in Fachanwendungen, Chat, E-Mail, Office-Werkzeugen, Records Management und Portalen.

Ihre Kundinnen und Kunden erwarten trotzdem, dass diese Informationen später zusammenhängen, verständlich bleiben und bei Bedarf über Systemgrenzen hinweg verfügbar sind.

SW

Software-Herstellerentwickelt eine Fach- oder Records-Management-Anwendung

Ihre Anwendung

eigene Fachlogik · eigene Benutzeroberfläche

Szene 2 · Die Integrationsfalle

Heute wird Zusammenhang oft pro Anwendung und pro Projekt neu gebaut.

Einzelintegration

Jede neue Schnittstelle verbindet zwei Produkte für einen konkreten Zweck, mit eigener Semantik und eigener Betriebsverantwortung.

Nachträgliche Capture

Relevante Arbeitsinformationen werden exportiert, kopiert oder manuell in ein anderes System übertragen.

Systemablösung

Bei EoL werden Daten, Beziehungen und Nachweise oft erst nach Jahren bereinigt, konvertiert und rekonstruiert.

Kunden kaufen nicht nur eine Funktion. Sie kaufen die Fähigkeit, ihre Informationen über Anwendungen und Zeit hinweg verantwortbar zu führen.

Szene 3 · Die Rolle von RWP

RWP ist eine gemeinsame Ebene – nicht eine neue Fachanwendung.

Ihre AnwendungFachlogik, Prozess, Benutzeroberfläche und eigene Daten bleiben bei Ihnen.

→

RWP-FähigkeitRecords erhalten Identität, Status, Versionen, Beziehungen und einen auflösbaren Kontext.

→

RecordWebAndere berechtigte Anwendungen können Records referenzieren, prüfen und in ihren Geschäfts-Kontext einbeziehen.

RWP standardisiert nicht Ihr Fachverfahren. Es schafft Anschlussfähigkeit für die Records, die in Ihrem Fachverfahren entstehen.

Szene 4 · Die vier Produktfähigkeiten

RWP-Fähigkeit beginnt mit vier klaren Verantwortungen.

1

Record führen

Geschäftsrelevante Information als eigenständigen Record erzeugen, bearbeiten und finalisieren.

2

Identität auflösen

Einen stabilen Record-Bezug bereitstellen und über den eigenen Namespace bzw. Resolver auflösbar machen.

3

Beziehungen ausdrücken

Records mit Cases, Quellen, Ergebnissen, Auslösern oder anderen Records verbinden.

4

Übergang begleiten

Beim EoL eine kontrollierte Übergabe an Nachfolgeanwendung oder AIS ermöglichen.

Szene 5 · Ein Record-Lebenszyklus

Der Record wird im Arbeitsprozess fertig, nicht erst im späteren Ablieferungsprojekt.

1Erzeugen

Die Anwendung erzeugt einen Record mit Typ, verantworteter Identität und notwendigem Kontext.

2Bearbeiten

Entwürfe und Arbeitsstände können weitergeführt werden, solange der Record noch nicht finalisiert ist.

3Finalisieren

Eine berechtigte Person oder Rolle macht eine verbindliche Fassung erkennbar und schützt sie vor stiller Änderung.

4Bereitstellen

Der Record bleibt über seinen zuständigen Kontext und Endpoint auflösbar.

5Überführen

Bei EoL: kontrollierter custodyTransfer an eine Nachfolgeanwendung oder an ein AIS.

Finalisierung ist ein fachlicher und technischer Wendepunkt: Der Record ist bereit, auch wenn seine Anwendung noch viele Jahre weiterläuft.

Szene 6 · Wie andere Anwendungen einen Record finden

Eine DID bleibt der Bezugspunkt. Der Resolver findet den aktuellen Endpoint.

DIDdid:rwp:namespace:uuid
Stabiler Name des Records.

→

Namespace-ResolverLöst die DID auf und liefert das DID-Dokument mit dem zuständigen RecordEndpoint.

→

RecordEndpointIhre Anwendung stellt den Record im aktuell verantworteten Kontext bereit.

DID-Dokument · vereinfachter AuszugRWP-Auflösung

{
  "id": "did:rwp:s73f42a3:787475d4-5572-44a2-a62e-b4aaf7d590e3",
  "recordEndpoint": "https://…/api/records/787475d4-5572-44a2-a62e-b4aaf7d590e3",
  "currentVersion": "sha256:…",
  "controller": "did:rwp:s73f42a3",
  "record": {
    "recordType": "MiniChat",
    "status": "finalized",
    "version": 1
  }
}

Szene 7 · Regeln, die eine Anwendung erfüllen kann

SchemaRecords definieren, was ein RecordType können muss.

SchemaRecordBeschreibt Struktur, Pflichtfelder, erlaubte Zustände und Zustandsübergänge eines RecordType.Beispiel: Fragestunde — Antwort mit Übergang von draft zu finalized.

prüfbare
Regeln

Ihre AnwendungValidiert Payload, Statuswechsel und weitere Regeln beim Erzeugen und Finalisieren der Records.Sie kann nachweisen, auf welcher Schemaversion ein Record beruht.

Ein Schema ist nicht bloss ein Datenformular. Es ist ein versionierter Vertrag darüber, welche Eigenschaften ein RecordType haben soll.

Szene 8 · Nicht jede Anwendung startet RWP-nativ

SoX zeigt den Einstieg über Integration.

Für bestehende Produkte kann eine Connector- und Integrationsschicht die RWP-Fähigkeit zunächst vermitteln. Das schafft einen Übergang, ohne Benutzeroberfläche oder Fachlogik sofort neu zu bauen.

Bestehendes ProduktZum Beispiel Teams, ein Legacy-Fachsystem oder eine bestehende Kollaborationslösung.

→

SoXConnector- und Integrationsschichtführt integrierte Records im verantworteten Kontext

→

RecordWebDie relevanten Records und Beziehungen werden anwendungsübergreifend referenzierbar.

Produktchance: Ein Hersteller kann zuerst Integrationsfähigkeit anbieten und später RWP-Fähigkeiten nativ in das Produkt übernehmen.

Szene 9 · Implementierung muss prüfbar sein

Interoperabilität entsteht nicht durch Selbsterklärung, sondern durch Tests.

✓DID-Auflösung

Kann ein unabhängiger Client die DID auflösen und den zuständigen Endpoint finden?

✓Schema-Bindung

Kann die Anwendung nachweisen, nach welchem Schema und welcher Schemafassung sie einen Record erzeugt?

✓Integrität und Finalisierung

Sind Payload, Snapshot und finale Fassung nachvollziehbar; werden unzulässige Änderungen verhindert?

Die Frage lautet nicht nur: „Unterstützt das Produkt RWP?“ Sondern: „Welche Profile, Rollen und Testfälle erfüllt diese konkrete Produktversion nachweisbar?“

Szene 10 · Ein realistischer Entwicklungspfad

RWP-Fähigkeit kann iterativ in ein Produkt wachsen.

1

Abgrenzen

Ein oder zwei RecordTypes mit hohem Geschäftswert auswählen.

2

Führen

Diese Records mit Identität, Status, Finalisierung, Schema und nachvollziehbarer Fassung im Produkt führen.

3

Vernetzen

Resolver und Beziehungen zu Cases, Quellen oder Records anderer Anwendungen ergänzen.

4

Nachweisen

Profiles, Tests und gegebenenfalls Konformitätsnachweise für konkrete Produktversionen aufbauen.

Kein Big Bang: Eine erste RWP-Fähigkeit kann klein beginnen, aber sie sollte von Anfang an echte, auflösbare und verantwortete Records erzeugen.

Szene 11 · Was wir gemeinsam konkretisieren können

Herstellerwissen und RecordWeb-Governance gehören zusammen.

Software-Hersteller kennen ihre Produkte, Einsatzrealitäten und Integrationsgrenzen. RecordWeb schafft einen offenen Rahmen für gemeinsame Anforderungen, Profile, Testfälle und Interoperabilität.

Die nächste sinnvolle Frage ist deshalb nicht: „Können Sie morgen alles umsetzen?“

Sondern: „Welcher RecordType und welcher konkrete Anwendungsfall eignen sich für eine erste, nachweisbare RWP-Integration?“

RW

Gemeinsamer erster SchrittHersteller · Fachseite · Records Management · Architektur

Beispiel-Pilot

Ein formeller Entscheid wird als erster RecordType RWP-fähig geführt, aufgelöst und geprüft.

klein beginnen · interoperabel wachsen

RecordWeb · RWP für Implementierende

Ihre Anwendung wird nicht kleiner,
wenn sie anschlussfähig wird.

Sie behält ihre Fachlogik und Benutzererfahrung. Mit RWP kann sie Records jedoch so führen, dass diese über Anwendungen, Organisationen und Systemwechsel hinweg referenzierbar, verantwortet und prüfbar bleiben.

Nicht noch eine Sonderintegration.
Ein offener Weg in ein Netz aus Records.