RecordWebArchitekturführung · Zielbild und Übergang
1 / 12
RecordWeb · Architekturperspektive
Netz statt Inseln.
Vom anwendungsgebundenen Records Management zu einer vernetzten Informationsarchitektur.
Keine Big-Bang-Migration. Eine langfristige Architekturentscheidung.
Szene 1 · Das Zielbild
Records können über Organisations- und Anwendungsgrenzen hinweg verbunden sein.
Im Fragestunde-PoC führen Parlament und Regierung je ihr eigenes Geschäft. Einzelne Records sind jedoch miteinander verknüpft, ohne sie zu replizieren oder in ein gemeinsames Dossier zu kopieren.
RWP-natives Zielbild · Jede Anwendung führt ihre eigenen Records
Parlament
Fragenmanagement · eigener Case
Case: Parlamentarische Frage
Planung RWP nativ
Chat RWP nativ
Frage RWP nativ
Regierung / Bundeskanzlei
Antwortmanagement · eigener Case
Case: Beantwortung der Frage
Antwort RWP nativ
Chat RWP nativ
Planung RWP nativ
Planung
Chat
Frage
Antwort
Szene 2 · Die heutige Integrationsspinne
Heute wächst mit jeder Anwendung eine neue Informationsinsel.
Fachanwendungen, Kollaborationswerkzeuge, Office-Dateien, E-Mail und Records-Management-Systeme bilden jeweils eigene Daten- und Kontextgrenzen.
Records Management System
Fachanwendung Aeigene Objekte, eigene Metadaten
Fachanwendung Beigene Schnittstellen, eigene Logik
Das Kernproblem ist nicht ein fehlendes System. Es fehlt eine gemeinsame, anwendungsübergreifende Ebene für Identität, Beziehungen, Zuständigkeit und langfristige Auflösung von Records.
Szene 3 · Wo Kontext heute verloren geht
Das System of Record sieht oft nur einen Teil der tatsächlichen Arbeit.
Governance Modell
Das Geschäft wird im System of Record geführt
Relevante Unterlagen werden sauber übertragen
Metadaten und Zuordnung sind vollständig
Das Dossier bildet den Geschäftskontext ab
Tatsächliche Arbeitslandschaft
Antwortentwürfe entstehen in Office-Werkzeugen
Abstimmungen erfolgen im Chat und per E-Mail
Fachwissen liegt in spezialisierten Anwendungen
Übertragungen und Zuordnungen erfolgen nachträglich, wenn überhaupt
Nicht weil Mitarbeitende die Nachvollziehbarkeit nicht wichtig finden. Sondern weil die eigentliche Aufgabe bereits erfüllt ist, wenn die Information nachträglich noch übertragen werden müsste.
Szene 4 · Der Architekturwechsel
Vom Container als Zentrum zum Record als Primärobjekt.
Heute: Kontext durch Container
Datei im Dossier
Exportierter Chat im Dossier
Frage im Dossier
Antwort im Dossier
→
RecordWeb: Kontext durch Beziehungen
Frage · eigenständiger Record
Chat · eigenständiger Record
Antwort · eigenständiger Record
Planung · eigenständiger Record
Ein Geschäft oder Dossier bleibt als Sicht wichtig. Aber es muss nicht mehr der einzige Ort sein, an dem Beziehungen und Bedeutung hergestellt werden. Es wird zur Sicht auf einen zusammenhängenden Kontext bestehend aus Records.
Szene 5 · Die gemeinsame Architektur-Ebene
RecordWeb gibt verteilten Anwendungen eine gemeinsame Sprache.
Identität
Ein Record erhält einen dauerhaften, anwendungsübergreifend referenzierbaren Identifikator.
Beziehungen
Frage, Bearbeitung, Antwort und weitere Records werden explizit miteinander verknüpft.
Auflösung
Ein Resolver vermittelt, wo ein Record im aktuellen Verantwortungs- und Bereitstellungskontext erreichbar ist.
RWP schafft keinen zusätzlichen monolithischen Datencontainer, sondern ein Protokoll für ein Netz aus Records.
Szene 6 · Integration statt Ersatz
Die heutige Anwendungslandschaft muss nicht verschwinden.
Wo eine Anwendung RWP noch nicht nativ unterstützt, kann eine Integrationsschicht die Verbindung zum RecordWeb herstellen.
Bestehende AnwendungChat, Fachanwendung oder Kollaborationswerkzeug bleibt der Arbeitsort.
→
SoXIntegrations- und Connector-Schichtordnet relevante Arbeit dem RecordWeb-Kontext zu
→
RecordWebRecords, Beziehungen, Identitäten und auflösbare Endpoints.
Integration ist kein Behelf neben der Zielarchitektur. Sie ist der Weg in die Zielarchitektur.
Szene 7 · Drei Zustände derselben Landschaft
Die Architektur kann Anwendung für Anwendung wachsen.
Die Übergangsarchitektur akzeptiert, dass Anwendungen unterschiedliche Reifegrade haben.
HeuteFachanwendungen, Teams und weitere Werkzeuge erzeugen Informationen. Die Übernahme ins Records Management erfolgt teilweise nachträglich und manuell.
→
ÜbergangFachanwendung ist RWP-fähig. MiniChat und Teams werden über SoX-Connectoren angebunden.
→
Zielbild wächstEin neu beschaffter MiniChat ist RWP-nativ. Teams bleibt zunächst über SoX integriert, bis auch dort ein natürlicher Erneuerungszeitpunkt erreicht ist.
Wichtig: Nicht alle Systeme müssen gleichzeitig denselben Reifegrad erreichen. Die Architektur trägt die Koexistenz von nativer RWP-Fähigkeit und Integration.
Szene 8 · Der normale Entwicklungsrahmen
RecordWeb wird nicht ausgerollt. Es wird bei jeder Veränderung mitgebaut.
1
Orientieren
Relevante Informationsflüsse und die Anwendungen identifizieren, in denen Kontext heute verloren gehen kann.
2
Integrieren
Geeignete erste Fälle über eine Schicht wie SoX mit dem RecordWeb verbinden.
3
Erneuern
Bei Weiterentwicklung, Ablösung und Neubeschaffung RWP-Fähigkeit architektonisch berücksichtigen.
4
Ausbauen
Das Netz erweitert sich schrittweise über weitere Anwendungen, Organisationen und Geschäftsprozesse.
Beschaffung als Hebel: Behörden erneuern Anwendungen ohnehin in geregelten Verfahren. RecordWeb-Fähigkeit kann zunächst als Qualitätsaspekt berücksichtigt und später verbindlicher Teil der ausgeschriebenen Anforderungen werden.
Szene 9 · Die Architekturentscheidung
Die Frage ist nicht: „Welches System ersetzt welches?“
Die strategische Frage lautet:
Welche gemeinsame Architektur-Ebene brauchen wir, damit Records aus unterschiedlichen Anwendungen über ihre gesamte Lebensdauer hinweg identifizierbar, verknüpfbar und erreichbar bleiben?
Ohne gemeinsame Ebene
Neue Anwendungen erzeugen neue Informationsgrenzen
Kontext wird kopiert, exportiert oder manuell übertragen
Integration bleibt punktuell und projekthaft
Langfristige Nachvollziehbarkeit wird nachträglich hergestellt
Mit RecordWeb als Zielrahmen
Neue Anwendungen werden schrittweise anschlussfähig
Records bleiben über Beziehungen vernetzt
Integration und native Fähigkeiten können koexistieren
Nachvollziehbarkeit wird Teil der Entstehungsarchitektur
Szene 10 · Was auf die Roadmap gehört
Ein erster Architekturschritt ist klein, aber richtungsweisend.
1. Zielbild bestätigen
RecordWeb als langfristigen Referenzrahmen für vernetzte, anwendungsübergreifende Records anerkennen.
2. Pilotarchitektur nutzen
Den PoC-Fragestunde mit Fragenmanagement, Antwortmanagement, MiniChat, Teams-Integration, SoX, Konformitätsprüfung, MiniChat-Migration bis Archivierung als Lernumgebung verwenden.
3. Erneuerungen ausrichten
Bei passenden Weiterentwicklungen, Ablösungen und Beschaffungen die Anschlussfähigkeit gezielt prüfen.
Die erste Entscheidung ist nicht, alles umzubauen. Sie ist, künftig keine neuen Informationsinseln ohne Anschlussfähigkeit zu planen.
RecordWeb · Architekturperspektive
Das Web im Namen ist Programm.
Nicht ein weiteres zentrales System. Ein Netz aus eigenständigen Records, verantworteten Anwendungen und nachvollziehbaren Beziehungen.
Keine Big-Bang-Migration. Eine Architektur, die mit jeder Erneuerung wächst.