This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Mirrored from /mnt/DATA/Nextcloud/ADD ideas UG/Products/govoplan/govoplan_concept_dev.md. Origin: product:govoplan. Active tasks and changing state belong in Gitea issues; this wiki page is durable project context.

Ableitung einer Zielarchitektur für govoplan

Ergebnis vorab

Die bestehende Struktur ist der benötigten Zielarchitektur bereits deutlich näher, als es die frühere Aufteilung in core, campaign, mail und files vermuten lässt. Die GovOPlaN-Organisation umfasst inzwischen 72 Repositories. govoplan-core ist bereits ausdrücklich als schlanker Laufzeitkern definiert; fachliche und plattformbezogene Funktionen sollen von Modulen übernommen werden. Gleichzeitig unterscheidet die Architekturdokumentation bereits zwischen Plattform-, Dienst-, Fach- und Konnektormodulen. (gitea@add-ideas.de)

Die wesentliche Aufgabe lautet daher nicht:

Möglichst viele weitere Module ergänzen.

Sondern:

Die vorhandenen Module zu einer konsistenten institutionellen Architektur ordnen, ihre Zuständigkeiten schärfen und einige noch fehlende grundlegende Governance-Objekte ergänzen.

Meine zentralen Schlussfolgerungen sind:

Der bestehende Kernansatz ist richtig: govoplan-core sollte klein bleiben.
Native Funktionen und externe Systeme dürfen parallel unterstützt werden. Das sollte kein Sonderfall, sondern ein allgemeines Architekturprinzip sein.
Vier grundlegende horizontale Fachkontexte fehlen noch: Aufgaben und Mandate, Leistungen, Verfahrensbeteiligte sowie Entscheidungen.
Viele vorhandene Repositories sind richtig gedacht, aber teilweise falsch klassifiziert oder noch nicht hinreichend voneinander abgegrenzt.
Logische Modularität sollte nicht automatisch ein eigenes Repository bedeuten.
Produktpakete und Sektorkonfigurationen sollten oberhalb der Module liegen und keine neuen Plattform-Forks erzeugen.

Die bestehende Roadmap beschreibt GovOPlaN bereits als verbindende, governancebewusste Betriebsschicht und nicht als universellen Ersatz aller vorhandenen Systeme. Sie sieht ausdrücklich unterschiedliche Quellen der Wahrheit sowie native, externe und hybride Betriebsweisen vor. Die von dir vorgeschlagene Richtung entspricht damit dem bestehenden Leitbild. (gitea@add-ideas.de)

1. Das grundlegende Architekturprinzip: nicht „integriert oder angebunden“, sondern unterschiedliche Betriebsmodelle

Für jede grundsätzlich austauschbare Fähigkeit sollte GovOPlaN mehrere Betriebsmodelle unterstützen.

Betriebsmodell	Bedeutung	Beispiel
Nativ und führend	GovOPlaN ist das maßgebliche System für diese Daten und Funktionen.	Organisationsfunktionen, Delegationen oder interne Projektportfolios
Extern und führend	Ein externes System bleibt alleinige Quelle der Wahrheit; GovOPlaN nutzt dessen Schnittstellen.	SAP für Buchhaltung oder ein Personalverwaltungssystem
Extern mit lokaler Spiegelung	Externe Daten werden lesend übernommen und für Suche, Verknüpfung oder Ausfallsicherheit lokal vorgehalten.	Beschäftigtendaten aus einem HR-System
Gesteuerte Synchronisation	Daten werden zwischen GovOPlaN und einem externen System abgeglichen; Konflikte und Zuständigkeiten sind definiert.	Konten- und Gruppenzuordnung über SCIM
Governance-Überlagerung	Sach- oder Stammdaten bleiben extern, während GovOPlaN Zuständigkeit, Freigabe, Nachweise, Delegationen und Regeln verwaltet.	Externes ERP plus lokale Mittelverantwortung und Beschlussverknüpfung
Verknüpfung ohne Datenübernahme	GovOPlaN kennt nur Referenz, Status und Aufrufziel.	Verweis auf einen Vorgang in einem hoch spezialisierten Fachverfahren

Diese Betriebsweise sollte nicht nur je Modul, sondern nötigenfalls je:

Mandant,
Organisationseinheit,
Leistung,
Objekttyp,
Datenfeld,
Prozessschritt

festgelegt werden können.

Ein Beispiel aus dem IDM:

Name und Beschäftigungsstatus stammen aus dem Personalverwaltungssystem.
Anmeldung erfolgt über einen externen OIDC-Anbieter.
die organisatorische Funktion wird nativ in GovOPlaN geführt;
die zeitlich begrenzte Vertretung wird nativ in GovOPlaN geführt;
technische Gruppen werden anschließend über SCIM in ein externes Verzeichnis geschrieben;
die fachliche Befugnis ergibt sich aus einem in GovOPlaN geführten Mandat;
die konkrete Zugriffsentscheidung trifft govoplan-access zusammen mit govoplan-policy.

Damit ist kein System pauschal „führend“. Die Führungsverantwortung wird nach Informationsart getrennt.

Gemeinsamer Vertrag für austauschbare Anbieter

Jede hybride Fähigkeit sollte einen einheitlichen Anbieter- oder Providervertrag besitzen. Dieser muss mindestens beschreiben:

welche Objekte und Felder der Anbieter besitzt;
welche Operationen er unterstützt;
ob nur Lesen oder auch Schreiben möglich ist;
welche Version oder Revisionskennung gilt;
wie aktuell die Daten sind;
ob der Anbieter erreichbar und funktionsfähig ist;
ob Vorschau oder Probelauf möglich sind;
wie Konflikte erkannt werden;
wie unklare Ausführungszustände behandelt werden;
welche Nachweise entstehen;
wie eine Rückabwicklung oder Abstimmung erfolgt;
welches Verhalten bei Ausfall vorgesehen ist.

Das ist insbesondere bei öffentlichen Einrichtungen wichtig. Eine fehlgeschlagene Operation darf nicht nur als technischer Fehler erscheinen. Die Plattform muss unterscheiden können zwischen:

beabsichtigter Handlung;
freigegebener Handlung;
an das externe System übermittelter Handlung;
möglicherweise ausgeführter Handlung;
bestätigter Wirkung;
abgestimmtem Endzustand.

2. Empfohlene Zielarchitektur

Die folgende Gliederung beschreibt Architekturschichten, nicht zwingend einzelne Repositories.

Ebene 0: System, Laufzeit und Modulverwaltung

Bestehende Bausteine

govoplan
govoplan-core

Zuständigkeit

govoplan bleibt das übergreifende System- und Distributionsrepository. govoplan-core besitzt ausschließlich:

Anwendungsstart und Laufzeit;
Datenbank- und Sitzungsgrundlagen;
Modulerkennung;
Modulregistrierung;
Migrationskoordination;
Capability- und Schnittstellenverzeichnis;
Installations- und Aktualisierungsorchestrierung;
gemeinsame Weboberflächenhülle;
technische Basiskontrakte.

Diese Richtung ist in der gegenwärtigen Kernarchitektur bereits angelegt. Fachliche Funktionen sollen nicht in den Kern zurückwandern. (gitea@add-ideas.de)

Nicht in den Kern gehören

Benutzerverwaltung;
Mandantenverwaltung;
Rollenverwaltung;
Organisationsmodelle;
Fallmanagement;
Dateiverwaltung;
Workflows;
Richtlinien;
Berichte;
Fachobjekte.

Der Kern darf gemeinsame Datentypen und Verträge bereitstellen, aber nicht die fachliche Bedeutung dieser Objekte besitzen.

Ebene 1: Institutionelle Basis und Berechtigungsordnung

Bestehende Bausteine

govoplan-tenancy
govoplan-identity
govoplan-organizations
govoplan-idm
govoplan-access
govoplan-identity-trust
govoplan-encryption

Zu ergänzen

govoplan-mandates beziehungsweise ein Modul für:
- öffentliche Aufgaben;
- Mandate;
- Zuständigkeiten;
- Befugnisse;
- Verantwortungszuordnungen;
- Jurisdiktionen.

Zweck dieser Ebene

Diese Module beantworten gemeinsam:

Welche Institutionen und Organisationseinheiten existieren?
Welche natürlichen oder juristischen Personen sind bekannt?
Welche Funktionen existieren?
Wer nimmt welche Funktion zu welchem Zeitpunkt wahr?
Welche Aufgabe, Befugnis oder Pflicht ist mit dieser Funktion verbunden?
Über welches Konto handelt die Person?
Welche technischen Rechte ergeben sich daraus?
Wie sicher ist die behauptete Identität?
Für wen handelt die Person möglicherweise vertretungsweise?

Diese Ebene ist das institutionelle Rückgrat von GovOPlaN.

Ebene 2: Governance, Regeln und Rechenschaft

Bestehende Bausteine

govoplan-policy
govoplan-audit
govoplan-risk-compliance
govoplan-admin
govoplan-ops
govoplan-docs
govoplan-views
govoplan-search

Zu ergänzen

govoplan-decisions
später gegebenenfalls ein eigenständiger Ziel- und Wirkungsdienst, zunächst jedoch besser innerhalb von projects, reporting und evaluation

Zweck dieser Ebene

Richtlinien und Regelwerke;
Entscheidungskompetenzen;
Genehmigungsgrenzen;
Aufbewahrungs- und Datenschutzregeln;
Risiko- und Kontrollmodelle;
Prüfpfade;
Nachweise;
formale Entscheidungen;
Maßnahmen und Feststellungen;
Systembetrieb und Administrationsaufsicht;
rollen- und kontextbezogene Projektionen.

govoplan-risk-compliance ist gegenwärtig als fachliches Modul klassifiziert, besitzt aber mit Risiken, Kontrollen, Datenschutz-Folgenabschätzungen, Vorfällen und Maßnahmen überwiegend querschnittliche Funktionen. Die bereits implementierte Sanktionslistenprüfung ist ein erster fachlicher Vertikalschnitt innerhalb dieses allgemeineren Kontrollmodells. (gitea@add-ideas.de)

Deshalb sollte es architektonisch als Governance- und Assurance-Plattformmodul behandelt werden, nicht als gewöhnliches Fachverfahren.

Ebene 3: Menschliche Arbeit und Verfahrensausführung

Bestehende Bausteine

govoplan-forms
govoplan-forms-runtime
govoplan-cases
govoplan-tasks
govoplan-approvals
govoplan-workflow-engine
govoplan-workflow
govoplan-tickets

Zu ergänzen

govoplan-services
govoplan-parties

Zweck dieser Ebene

Leistungen beschreiben;
Anträge und Meldungen erfassen;
Verfahrensbeteiligte verwalten;
Fälle führen;
Aufgaben verteilen;
Freigaben einholen;
Arbeitsschritte koordinieren;
Entscheidungen vorbereiten;
Fristen überwachen;
Verfahrensstände nachvollziehen;
Übergaben an externe Systeme steuern.

Die Trennung zwischen govoplan-workflow-engine und govoplan-workflow ist konzeptionell sinnvoll: Der Engine-Teil besitzt das ausführbare, revisionsfeste Ablaufmodell; das zweite Modul stellt visuelle Modellierung und Inspektion bereit. (gitea@add-ideas.de)

Der Workflow-Engine sollte allerdings nicht zum allgegenwärtigen Unterbau jedes einfachen Moduls werden. Viele Vorgänge benötigen lediglich:

einen Statusautomaten;
Aufgaben;
Fristen;
Freigaben;
Ereignisse.

Die allgemeine Workflow-Engine sollte dort eingesetzt werden, wo:

Abläufe konfigurierbar sein müssen;
mehrere Module beteiligt sind;
längere Ausführungszeiten auftreten;
Wiederaufnahme und Fehlerbehandlung notwendig sind;
Varianten zur Laufzeit ausgewählt werden;
externe Wirkungen orchestriert werden.

Ebene 4: Kommunikations- und Zugangskanäle

Bestehende Bausteine

govoplan-portal
govoplan-postbox
govoplan-notifications
govoplan-mail
govoplan-campaign
govoplan-calendar
govoplan-scheduling
govoplan-booking
govoplan-appointments
govoplan-consultation
govoplan-poll
govoplan-committee
govoplan-addresses
govoplan-dist-lists

Zweck dieser Ebene

Diese Module stellen keine institutionellen Wahrheiten her, sondern ermöglichen Interaktion:

Portale;
sichere Postfächer;
Nachrichten;
Benachrichtigungen;
Serienkommunikation;
Termine;
Ressourcenbuchungen;
Konsultationen;
Abstimmungen;
Gremienarbeit;
Kontakt- und Verteilerverwaltung.

Die konzeptionelle Abgrenzung sollte lauten:

Modul	Besitzt
`mail`	Transportprofile, SMTP/IMAP-Anbindung, Zustellversuche und technische Ausgangswarteschlange
`notifications`	Hinweise, Aufmerksamkeit, Kanalwahl und Zustellkoordination
`postbox`	dauerhaftes institutionelles Ein- und Ausgangspostfach
`campaign`	gesteuerte, nachweisbare Massen- und Zielgruppenkommunikation
`addresses`	normalisierte erreichbare Kontaktziele
`dist-lists`	regelbasierte oder explizite Empfängergruppen
`portal`	externer Zugangskanal und Selbstbedienungsoberfläche

Diese Trennung ist in den bestehenden Modulen bereits weitgehend erkennbar. govoplan-postbox ist ausdrücklich funktionsgebunden und soll Postfächer auch bei Vakanz, Neubesetzung oder Delegation stabil halten. govoplan-mail konzentriert sich dagegen auf Transportprofile und eine dauerhafte Zustellwarteschlange. (gitea@add-ideas.de)

Ebene 5: Inhalte, Dokumente, Akten und Nachweise

Bestehende Bausteine

govoplan-files
govoplan-templates
govoplan-dms
govoplan-records
govoplan-wiki
govoplan-transparency
govoplan-certificates

Empfohlene Abgrenzung

Modul	Kerngegenstand
`files`	Binärobjekte, Dateiablage, Metadaten, Freigaben, Upload und Download
`templates`	Vorlagen, Platzhalter, Rendering und Ausgabevarianten
`dms`	Dokumentidentität, Versionen, Bearbeitungsstatus, Check-in/Check-out, Renditions
`records`	Aktenplan, Vorgangszusammenhang, Aufbewahrung, Aussonderung, Sperre und Archivübergabe
`transparency`	Veröffentlichung, Schwärzung, Auskunft und Offenlegung
`certificates`	ausgestellte, prüfbare Bescheinigungen und Nachweise
`wiki`	kooperativ gepflegtes institutionelles Wissen

Diese Aufteilung sollte erhalten bleiben. Sie bildet unterschiedliche fachliche Verantwortungen ab. govoplan-files ist bereits als generischer Datei- und Metadatendienst ausgelegt, der über Capabilities konsumiert werden soll. (gitea@add-ideas.de)

Ein kleines GovOPlaN-System darf durchaus files, dms und records nativ verwenden. Eine größere Behörde kann stattdessen:

Binärdaten in einem externen Objektspeicher halten;
Dokumente in einem bestehenden DMS führen;
Aufbewahrung und Archivübergabe über ein Records-Management-System steuern;
GovOPlaN nur als Verfahrens-, Zuständigkeits- und Nachweisschicht einsetzen.

Ebene 6: Daten, Berichte und Integration

Bestehende Bausteine

govoplan-connectors
govoplan-datasources
govoplan-dataflow
govoplan-reporting
govoplan-dashboard
govoplan-rest
govoplan-soap
govoplan-xoev
govoplan-xta-osci
govoplan-fit-connect
govoplan-xrechnung
govoplan-erp

Zweck dieser Ebene

externe Systeme katalogisieren;
Verbindungen und technische Erreichbarkeit verwalten;
Datenquellen beschreiben;
Daten beziehen und zwischenspeichern;
Transformationen reproduzierbar ausführen;
Datenherkunft und Versionen erhalten;
analytische Produkte erstellen;
Dashboards und Exporte bereitstellen;
Verwaltungsstandards anbinden.

Die bestehende Abgrenzung von connectors, datasources, dataflow und reporting ist fachlich überzeugend:

Konnektoren besitzen Verbindung, Beschaffung und technischen Zustand;
Datenquellen besitzen Quellenidentität, Staging und Materialisierungszustände;
Datenflüsse besitzen Transformationen, Revisionen und Herkunft;
Reporting besitzt Auswertungsprodukte, Berichte und Exporte;
Workflow besitzt die übergreifende Orchestrierung. (gitea@add-ideas.de)

govoplan-erp sollte dabei nicht als fachliches Domänenmodul, sondern als Konnektorfamilie beziehungsweise Integrationsdienst klassifiziert werden. Fachliche Haushalts- oder Beschaffungssemantik darf nicht vom konkreten ERP-Anbieter abhängen.

Notwendige Erweiterung von `datasources`

govoplan-datasources sollte langfristig nicht nur technische Datenquellen, sondern einen gesteuerten Daten- und Registerkatalog abbilden:

fachliche Bezeichnung;
Datenverantwortung;
maßgebliche Quelle;
Rechtsgrundlage;
Verarbeitungszweck;
Qualitätsregeln;
Aktualität;
Schutzklasse;
Übermittlungsvereinbarung;
semantisches Modell;
Korrekturverfahren;
betroffene Leistungen und Prozesse;
abhängige Berichte und Entscheidungen.

Damit würde aus einer technischen Datenquellenverwaltung ein echter Data-Governance-Baustein.

Ebene 7: Fach- und Betriebsdomänen

Bestehende Bausteine

govoplan-projects
govoplan-procurement
govoplan-contracts
govoplan-grants
govoplan-resources
govoplan-assets
govoplan-facilities
govoplan-learning
govoplan-payments
govoplan-ledger
govoplan-permits
govoplan-inspections
govoplan-evaluation
govoplan-helpdesk

Diese Module setzen die horizontalen Fähigkeiten für bestimmte Aufgabenbereiche zusammen.

Einige sollten echte Fachmodule bleiben. Andere sind eher Produktpakete oder Referenzkonfigurationen:

Bestehender Bereich	Empfehlung
`procurement`	Eigenständiges Fachmodul für Bedarf, Verfahren und Vergabeentscheidung
`contracts`	Eigenständiges Fachmodul für Verpflichtungen, Fristen, Leistungen und Änderungen
`grants`	Eigenständiges Fachmodul für Förderprogramme und Zuwendungsfälle
`permits`	Fachmodul auf Basis von Leistungen, Fällen, Beteiligten und Entscheidungen
`inspections`	Fachmodul für Prüfobjekte, Prüfpläne, Feststellungen und Maßnahmen
`projects`	Zu Portfolio-, Ziel-, Abhängigkeits- und Veränderungssteuerung ausbauen
`evaluation`	Für Wirkungsmodelle, Evaluationsaufträge, Kriterien und Erkenntnisse
`helpdesk`	Eher Produktpaket über `tickets`, `cases`, `tasks`, `postbox` und `notifications`
`appointments`	Zunächst eher Produktpaket über `booking`, `calendar` und `scheduling`
`ledger`	Nur dann eigenständig ausbauen, wenn ein klarer fachlicher Buchungsgegenstand entsteht
`resources`	Gemeinsamer Verfügbarkeits- und Kapazitätsdienst, nicht Personalwirtschaft
`assets` / `facilities`	Getrennt halten, falls Anlagenlebenszyklus und räumlicher Betrieb tatsächlich unabhängig sind

govoplan-ledger und Teile der Formularlandschaft befinden sich gegenwärtig noch auf Scaffold- beziehungsweise Seed-Niveau. Das ist nicht problematisch, sollte aber im Repositorykatalog sichtbar sein; die bloße Existenz eines Repositories darf nicht als Produktreife verstanden werden. (gitea@add-ideas.de)

Ebene 8: Produkt- und Sektorpakete

Diese Ebene sollte nicht aus weiteren Laufzeitmodulen bestehen.

Ein Paket bündelt:

erforderliche Module;
Terminologie;
Rollenmodelle;
Datenmodelle;
Formulare;
Prozessdefinitionen;
Richtlinien;
Ansichten;
Berichte;
Vorlagen;
Konnektorprofile;
Beispieldaten;
Abnahmetests;
Dokumentation;
Migrationsregeln.

Mögliche allgemeine Produktpakete:

Governance-Grundlage
Funktionsgebundene Zusammenarbeit
Gesteuerte Kommunikation
Verwaltungsleistung vom Antrag bis zur Entscheidung
Gremien- und Beschlussmanagement
Akten, Nachweise und Transparenz
Gesteuerte Datenanalyse und Berichtswesen
Beschaffung und Vertragssteuerung
Risiko, Kontrolle und Maßnahmen

Darauf können Sektorpakete aufbauen:

Kommune;
Hochschule und Forschung;
Ministerium;
Regulierungs- und Aufsichtsbehörde;
Fördermittelgeber;
Infrastrukturbetreiber;
öffentliches Gesundheitswesen.

Ein Sektorpaket ist damit eine versionierte Referenzkonfiguration, kein Fork des Plattformkerns.

3. Abgleich mit den zuvor identifizierten Bedarfsfeldern

A. Organisation, Aufgaben und Verantwortung

Bereits vorhanden

organizations
identity
idm
access
tenancy
policy

Lücke

Die Plattform kann Organisationseinheiten, Funktionen, Identitäten, Funktionsbesetzungen und technische Zugriffe abbilden. Es fehlt aber ein eigenständiges Modell dafür:

welche öffentliche Aufgabe existiert;
aufgrund welcher Norm oder Entscheidung sie wahrgenommen wird;
welche Stelle sachlich, örtlich und zeitlich zuständig ist;
welche Funktion entscheidungs- oder zeichnungsbefugt ist;
wer nur mitwirkt und wer rechenschaftspflichtig ist;
welche Zuständigkeit übertragen oder entzogen wurde.

Ableitung

Neues horizontales Modul govoplan-mandates.

B. Leistungs-, Verfahrens- und Fallmanagement

Bereits vorhanden

portal
forms
forms-runtime
cases
tasks
approvals
workflow-engine
permits
postbox
payments

Lücken

kein zentraler Leistungskatalog;
kein allgemeines Beteiligten- und Vertretungsmodell;
kein allgemeines Entscheidungsobjekt;
keine durchgängige Verbindung von Leistung, Fall, Rechtsgrundlage, Entscheidung und Ergebnis.

Ableitung

Ergänzung um:

govoplan-services;
govoplan-parties;
govoplan-decisions.

Danach kann beispielsweise permits einen Genehmigungsfall definieren, ohne selbst erneut:

Antragsteller;
Bevollmächtigte;
Zuständigkeiten;
Formulare;
Aufgaben;
Entscheidungen;
Zustellungen

implementieren zu müssen.

C. Prozesse und Zusammenarbeit

Bereits vorhanden

workflow-engine
workflow
tasks
approvals
cases
views
notifications

Bewertung

Konzeptionell gut abgedeckt.

Notwendige Schärfung

Workflow orchestriert, besitzt aber nicht die Fachsemantik.
Tasks besitzt Arbeitsaufträge, nicht komplette Prozesse.
Approvals besitzt Zustimmungsschritte, nicht die abschließende institutionelle Entscheidung.
Views besitzt Projektionen, ist aber niemals Sicherheitsgrenze.

govoplan-views beschreibt sich bereits entsprechend als gesteuerte, aufgabenbezogene Projektion; Filterung in der Oberfläche darf technische Autorisierung nicht ersetzen. (gitea@add-ideas.de)

D. Entscheidungen, Beschlüsse und Gremien

Bereits vorhanden

committee
poll
consultation
approvals
audit
templates

Lücke

Es fehlt ein allgemeiner, fachübergreifender Entscheidungsgegenstand.

Ein Beschluss ist nicht dasselbe wie:

eine Abstimmung;
eine Freigabe;
ein Protokoll;
ein Workflowstatus;
ein PDF-Dokument.

Ableitung

govoplan-decisions sollte das verbindliche Ergebnis besitzen, einschließlich:

Entscheidungsgegenstand;
Entscheidungskompetenz;
Sachverhalt;
Optionen;
Rechts- und Richtliniengrundlage;
berücksichtigte Nachweise;
Begründung;
entscheidende Person oder entscheidendes Gremium;
Bedingungen und Nebenbestimmungen;
Wirksamkeitszeitpunkt;
resultierende Aufträge;
Veröffentlichung;
Berichtigung, Aufhebung oder Widerruf;
Rechtsbehelf oder interne Überprüfung.

E. Akten, Dokumente und institutionelles Gedächtnis

Bereits vorhanden

files
dms
records
templates
audit
transparency
search
wiki

Bewertung

Die erforderlichen Bausteine sind vorhanden. Entscheidend ist die konsequente Abgrenzung von Datei, Dokument, Akte, Nachweis und Veröffentlichung.

Ergänzung

Jedes Fachobjekt sollte auf Records- und Evidence-Capabilities zugreifen können, ohne selbst Dokumentenmanagement nachzubauen.

F. Daten, Register und Interoperabilität

Bereits vorhanden

connectors
datasources
dataflow
reporting
technische Standardkonnektoren

Lücke

Der technische Datenfluss ist konzeptionell besser ausgearbeitet als die fachliche Daten-Governance.

Ableitung

datasources sollte erweitert werden um:

Register- und Datenkatalog;
Datenverantwortung;
fachliche Begriffe;
Rechtsgrundlage;
Zweckbindung;
Qualitätszusagen;
Berichtigungswege;
semantische Zuordnung;
Abhängigkeiten.

Ein separates neues Repository ist dafür zunächst nicht zwingend erforderlich.

G. Risiko, Compliance, Kontrolle und Prüfung

Bereits vorhanden

risk-compliance
policy
audit
ops
inspections
evaluation

Bewertung

Die horizontale Grundlage ist vorhanden.

Ableitung

Keine Sammlung isolierter Spezialmodule für:

Datenschutz;
Informationssicherheit;
KI-Governance;
Barrierefreiheit;
Notfallmanagement;
Korruptionsprävention.

Stattdessen sollte ein gemeinsames Modell verwendet werden:

Verpflichtung → Schutz- oder Prüfobjekt → Risiko → Kontrolle → Nachweis → Feststellung → Maßnahme → Wirksamkeitsprüfung

Die einzelnen Regelungsbereiche werden als Regel-, Kontroll- und Berichtspakete ausgeliefert.

Nur dort, wo ein eigener fachlicher Lebenszyklus entsteht, ist ein zusätzliches Modul gerechtfertigt.

H. Strategie, Portfolio und Veränderung

Bereits vorhanden

projects
evaluation
reporting
dashboard
resources
contracts
procurement

Lücken

strategische Ziele;
öffentliche Wirkungsziele;
Nutzenhypothesen;
Vorhabensabhängigkeiten;
Veränderungsbetroffenheit;
Kapazitätskonflikte;
Architekturentscheidungen;
Stilllegung von Altsystemen;
Nutzenrealisierung.

Ableitung

govoplan-projects sollte zu einem Portfolio- und Veränderungsmodul ausgebaut werden, statt sofort weitere Repositories für Strategie, Portfolio, Ziele und Change anzulegen.

Benötigte zusätzliche Objekte:

Ziel;
Ergebnis;
Wirkung;
Initiative;
Programm;
Projekt;
Maßnahme;
Meilenstein;
Abhängigkeit;
Annahme;
Fähigkeit;
Ressourcenbedarf;
Veränderungsauswirkung;
Nutzenindikator;
Entscheidungstor.

Erst wenn Ziele und Wirkungen auch ohne Vorhaben von mehreren anderen Modulen intensiv verwendet werden, wäre ein eigenständiges Zielmodul gerechtfertigt.

I. Beschaffung, Verträge und Förderungen

Bereits vorhanden

procurement
contracts
grants
erp
xrechnung
payments
ledger
risk-compliance

Bewertung

Funktional breit abgedeckt.

Zielbild

GovOPlaN sollte nativ insbesondere besitzen:

Bedarf;
Anforderung;
Freigaben;
Bewertungsmatrix;
Entscheidungsnachweise;
Interessenkonflikte;
Vertragspflichten;
Fristen;
Abnahmen;
Änderungen;
Lieferantenrisiken;
Förderziele;
Bewilligungsentscheidungen;
Mittelabrufe und Verwendungsnachweise.

Ein ERP oder eine Vergabeplattform kann weiterhin führen:

Kreditoren;
Haushaltsbuchungen;
Bestellungen;
Rechnungsworkflow;
Zahlungen;
formale elektronische Vergabekommunikation.

J. Finanzen, Personal und Kapazitäten

Bereits vorhanden

erp
payments
ledger
resources
organizations
idm
projects

Lücken

Budgetrahmen;
Mittelbindungen;
Finanzierungsquellen;
Stellen und Kapazitäten;
Qualifikationen;
zeitliche Ressourcenverfügbarkeit;
Verbindung von Haushalt, Aufgabe, Projekt und Wirkung.

Ableitung

GovOPlaN sollte keine vollständige Personalabrechnung oder öffentliche Finanzbuchhaltung nachbauen.

Sinnvoll ist jedoch eine native Governance-Überlagerung für:

Budgetrahmen und verfügbare Mittel;
Finanzierungsquellen;
Mittelverantwortung;
Stellen und organisatorische Kapazität;
Qualifikationsanforderungen;
Projekt- und Aufgabenbelastung;
Freigabe- und Zeichnungsbefugnisse;
Verknüpfung mit Beschlüssen und Vorhaben.

Diese Daten können entweder nativ geführt oder aus ERP- und HR-Systemen bezogen werden.

K. Anlagen, Liegenschaften, Geodaten und Infrastruktur

Bereits vorhanden

assets
facilities
resources
addresses
inspections
projects
contracts

Lücke

Ein gemeinsamer Geobezug und ein standardisierter GIS-Anbietervertrag fehlen.

Ableitung

Zunächst keine vollständige GIS-Plattform entwickeln. Stattdessen einen gemeinsamen Geo-Vertrag definieren:

Punkt;
Adresse;
Gebiet;
Flurstücksreferenz;
Linien- und Netzsegment;
Gebäude- und Raumreferenz;
Koordinatenbezugssystem;
externe Objektkennung;
Karten- und Feature-Service;
räumliche Zuständigkeit.

Ein eigenständiges govoplan-geo sollte erst entstehen, wenn mindestens zwei vollständige Anwendungsfälle – etwa kommunale Leistungen und Anlagenmanagement – denselben fachlichen Geodienst benötigen.

L. Bürger-, Unternehmens- und Beteiligtenkommunikation

Bereits vorhanden

portal
postbox
mail
notifications
campaign
appointments
consultation
poll
transparency
addresses
dist-lists

Bewertung

Dies ist einer der am weitesten ausdifferenzierten Teile der bestehenden Struktur.

Lücke

Es fehlt vor allem das gemeinsame Beteiligten- und Vertretungsmodell.

Ohne dieses Modell wissen die Kommunikationsmodule zwar, wohin etwas gesendet wird, aber nicht ausreichend:

in welcher Verfahrensrolle die Person handelt;
ob sie sich selbst oder eine andere Person vertritt;
aufgrund welcher Vollmacht sie handelt;
ob mehrere Personen gemeinsam Beteiligte sind;
welche Zustellungs- oder Kommunikationsregeln sich daraus ergeben.

M. Leistung, Wirkung und Lernen

Bereits vorhanden

reporting
dashboard
evaluation
dataflow
projects
audit

Lücke

Auswertungen sind noch nicht durchgängig mit:

öffentlichem Auftrag;
Ziel;
Leistung;
Prozess;
Entscheidung;
Ressourceneinsatz;
Ergebnis;
gesellschaftlicher Wirkung

verbunden.

Ableitung

Reporting sollte nicht lediglich Daten visualisieren. Jeder Bericht und Indikator sollte angeben:

welche Fragestellung er beantwortet;
welches Ziel oder welche Verpflichtung betroffen ist;
welche Datenquellen und Transformationen verwendet wurden;
welche Version gilt;
wer für Interpretation und Aktualität verantwortlich ist;
welche Entscheidungen ihn verwendet haben.

4. Die vier noch fehlenden horizontalen Kernmodule

4.1 `govoplan-mandates`: Aufgaben, Mandate, Zuständigkeiten und Verantwortung

Dieses Modul ist für eine öffentliche Governance-Plattform zentral.

Es besitzt

öffentliche und interne Aufgaben;
gesetzliche, satzungsrechtliche oder organisatorische Mandate;
sachliche Zuständigkeiten;
örtliche Zuständigkeiten;
zeitliche Zuständigkeiten;
Entscheidungskompetenzen;
Zeichnungs- und Freigabebefugnisse;
Verantwortlichkeitszuordnungen;
Beteiligungs- und Mitwirkungspflichten;
Rechts- und Organisationsgrundlagen;
Delegation von Befugnissen, soweit diese über bloße Funktionsvertretung hinausgeht;
historische Zuständigkeitsstände.

Es besitzt nicht

Organisationseinheiten selbst;
Personen;
technische Konten;
technische Berechtigungen;
Richtlinieninhalte;
Verfahrensfälle.

Klare Zuständigkeitskette

Frage	Zuständiges Modul
Welche Organisationseinheit oder Funktion existiert?	`organizations`
Welche Identität existiert?	`identity`
Wer besetzt oder vertritt die Funktion?	`idm`
Welche Aufgabe und Befugnis gehört zur Funktion?	`mandates`
Mit welchem Konto wird gehandelt?	`access`
Ist die konkrete Handlung im aktuellen Kontext zulässig?	`policy` und `access`
Wie wurde die Handlung nachgewiesen?	`audit`

Damit wird der wichtige Unterschied zwischen organisatorischer Stellung, fachlicher Zuständigkeit und technischer Berechtigung ausdrücklich modelliert.

4.2 `govoplan-services`: Leistungen und Leistungsversprechen

Dieses Modul beschreibt, was eine Institution gegenüber Bürgern, Unternehmen, anderen Einrichtungen oder internen Nutzern leistet.

Es besitzt

Leistung;
Leistungsvariante;
Zielgruppe;
Zugangsvoraussetzung;
Rechtsgrundlage;
benötigte Nachweise;
Gebühren;
Fristen;
Eingangskanäle;
verantwortliche Organisation und Funktion;
zuständige Gebietseinheit;
Formularbezug;
zu erzeugenden Falltyp;
Prozess- oder Workflowbezug;
mögliche Ergebnisse;
Ausgabedokumente;
Rechtsbehelfsinformationen;
Service- und Qualitätszusagen;
Veröffentlichungsinformationen.

Es besitzt nicht

den konkreten Fall;
den konkreten Antrag;
die beteiligten Personen;
die Entscheidung;
die Portaldarstellung selbst.

Nutzen

Dieses Modul verbindet erstmals:

Leistungskatalog → Portal → Formular → Beteiligte → Fall → Aufgaben → Entscheidung → Zustellung → Wirkung

Es kann Daten aus externen Leistungskatalogen importieren, aber auch nativ Leistungen führen, die nicht in übergreifenden Katalogen enthalten sind, beispielsweise:

universitätsinterne Verwaltungsleistungen;
Gremienservices;
Forschungsservices;
Personal- und IT-Services;
kommunale freiwillige Leistungen.

4.3 `govoplan-parties`: Beteiligte, Beziehungen und Vertretung

identity beantwortet, wer jemand ist. parties beantwortet, in welcher Rolle und Beziehung jemand an einem konkreten Vorgang beteiligt ist.

Es besitzt

Beteiligtenrolle;
Antragsteller;
Adressat;
Begünstigter;
Verpflichteter;
Eigentümer;
Betreiber;
Zeuge;
Gutachter;
Bevollmächtigter;
gesetzlicher Vertreter;
Sorgeberechtigter;
Betreuung;
gemeinsame Antragsteller;
Haushalts- oder Bedarfsgemeinschaft;
Konsortium;
Vertretungsumfang;
Vollmachtsnachweis;
Gültigkeitszeitraum;
Zustellungsbevollmächtigung;
bevorzugte und zulässige Kommunikationswege.

Es besitzt nicht

ein vollständiges Melderegister;
ein Unternehmensregister;
ein Kundenstammsystem;
Authentifizierung;
technische Rechte.

Externe Personen- und Organisationsregister können führend bleiben. GovOPlaN führt nur die für das Verfahren erforderliche Referenz und Beteiligtenbeziehung.

4.4 `govoplan-decisions`: Entscheidungen und ihre Wirkungen

Dieses Modul macht Entscheidungen zu erstklassigen, verknüpfbaren Governance-Objekten.

Es besitzt

Entscheidungsgegenstand;
Entscheidungstyp;
zuständige Funktion oder zuständiges Gremium;
Entscheidungsentwurf;
geprüfte Optionen;
Sachverhaltsstand;
Nachweise;
Rechts- und Richtliniengrundlage;
Begründung;
Tenor beziehungsweise Ergebnis;
Bedingungen;
Wirksamkeit;
Folgeaufträge;
externe Wirkungen;
Zustellung;
Veröffentlichung;
Überprüfung;
Berichtigung;
Rücknahme;
Widerruf;
Aufhebung;
Rechtsbehelfsbezug.

Abgrenzung

Objekt	Bedeutung
`approval`	Eine Person oder Funktion stimmt einem Schritt oder einer Aktion zu.
`poll`	Stimmen oder Meinungsbilder werden erhoben.
`committee`	Ein Gremium und seine Sitzungen werden organisiert.
`workflow`	Arbeitsschritte werden koordiniert.
`decision`	Ein verbindliches institutionelles Ergebnis wird festgestellt und wirksam gemacht.

Ein Gremienbeschluss, eine Vergabeentscheidung, eine Förderbewilligung, eine Genehmigung und eine interne Architekturentscheidung können damit dieselbe Grundstruktur verwenden.

5. Konkrete IDM-Ableitung

Die bestehende Aufteilung ist grundsätzlich tragfähig:

govoplan-identity führt normalisierte Identitäten und deren Verknüpfung mit Plattformkonten;
govoplan-organizations führt Organisationsstrukturen, Einheiten und Funktionen;
govoplan-idm führt Funktionszuordnungen, Delegationen und Synchronisation;
govoplan-access führt Konten, Anmeldung, Sitzungen, API-Schlüssel, Rollen und technische Rechte;
govoplan-tenancy führt den Mandantenlebenszyklus und die Mandantenauflösung. (gitea@add-ideas.de)

Erforderliche Neupositionierung von `govoplan-idm`

govoplan-idm sollte nicht primär als „Konnektor zu externen IDM-Systemen“ beschrieben werden.

Die passendere Definition lautet:

Verwaltung des Identitätslebenszyklus, der institutionellen Funktionszuordnungen, Delegationen und Bereitstellungsprozesse – wahlweise nativ, föderiert oder synchronisiert.

Native Funktionen

Anlegen und Zusammenführen von Identitäten;
Eintritt, Wechsel und Austritt;
Kontenanträge;
Funktionsbesetzung;
zeitliche Zuordnung;
Vertretung;
kommissarische Wahrnehmung;
Delegation;
Funktionsvakanz;
Rollen- und Gruppenabbildung;
Bereitstellungsaufträge;
Genehmigung von Berechtigungsänderungen;
Synchronisationsvorschau;
Konflikterkennung;
Abstimmung und Fehlerkorrektur;
periodische Rezertifizierung;
Entzug bei Fristablauf;
Notfall- und Wiederherstellungsverfahren.

Unterstützte Betriebsweisen

1. Vollständig lokal

Geeignet für kleine Einrichtungen oder einzelne Installationen:

lokale Konten;
lokale Identitäten;
lokale Organisationsfunktionen;
lokale Rollen und Berechtigungen.

2. Externe Anmeldung, lokale Governance

Anmeldung über OIDC oder SAML;
Identitäten werden extern bestätigt;
Funktionen, Delegationen, Mandate und Anwendungsrechte werden lokal geführt.

Das dürfte für viele öffentliche Einrichtungen der wichtigste Modus sein.

3. Externes Verzeichnis mit Synchronisation

LDAP, Active Directory oder SCIM als Quelle;
GovOPlaN übernimmt Identitäten und Konten;
lokale Verantwortungs- und Funktionsdaten werden ergänzt;
Änderungen werden abgeglichen.

4. Externe Stammdaten, GovOPlaN als Governance-Überlagerung

HR-System ist führend für Beschäftigungsverhältnis;
Verzeichnis ist führend für technische Konten;
GovOPlaN ist führend für Funktion, Delegation, Mandat und fachliche Berechtigungsableitung.

5. GovOPlaN als Bereitstellungsdrehscheibe

Freigaben erfolgen in GovOPlaN;
Konten und Gruppen werden extern bereitgestellt;
GovOPlaN verfolgt Soll-, Übermittlungs- und Ist-Zustand;
Abweichungen werden sichtbar gemacht.

Was GovOPlaN nicht selbst entwickeln sollte

Auch bei einem nativen IDM sind folgende Bereiche eher integrationspflichtig:

vollständiger LDAP- oder Active-Directory-Ersatz;
Endgeräteverwaltung;
Mobile-Device-Management;
umfassendes Privileged-Access-Management;
vollständige Public-Key-Infrastruktur;
Zertifizierungsstelle;
Passworttresor;
biometrische Authentifizierung;
hoch spezialisierte Fraud- und Risk-Authentication;
Personalabrechnung.

Der Mehrwert von GovOPlaN liegt nicht in der Nachbildung aller Enterprise-IAM-Funktionen. Er liegt in der institutionellen Bedeutung von Funktionen, Delegationen, Mandaten und daraus abgeleiteten Rechten.

6. Welche Fähigkeiten nativ, hybrid oder überwiegend extern sein sollten

Nativ besonders sinnvoll

Fähigkeit	Begründung
Organisationsstrukturen und Funktionen	Unmittelbarer Bestandteil des Governance-Modells
Aufgaben, Mandate und Zuständigkeiten	In Standardsoftware meist nur unzureichend abgebildet
Funktionsbesetzung und Delegation	Starker öffentlich-institutioneller Bezug
Richtlinien und Entscheidungskompetenzen	Für alle Module erforderlich
Leistungen und Leistungskatalog	Verbindet Portal, Verfahren, Verantwortung und Wirkung
Beteiligten- und Vertretungsmodell	Zentrale Voraussetzung rechtssicherer Verfahren
Fälle, Aufgaben und Freigaben	Allgemeine Arbeitsgrundlage
Entscheidungen	Kern der institutionellen Nachvollziehbarkeit
Funktionspostfächer	Stark an Organisation und Vertretung gebunden
Kampagnen-Governance	Empfängergrundlage, Freigabe und Nachweis sind plattformspezifisch
Risiko, Kontrollen und Maßnahmen	Querschnittlich mit allen GovOPlaN-Objekten verknüpft
Projekt- und Portfoliosteuerung	Benötigt institutionelle Abhängigkeiten und Verantwortung
Vertrags- und Fördersteuerung	Governance-Kontext ist wichtiger als reine Dokumentablage
Akten- und Nachweiskontext	Muss Fachobjekte und Entscheidungen verbinden

Hybrid besonders sinnvoll

Fähigkeit	Nativer Anteil	Externer Anteil
IDM	Funktionen, Delegationen, Freigaben, Sollzustände	Authentifizierung, Verzeichnisse, HR-Stammdaten
DMS	Dokumentkontext, Status, Verknüpfungen	Speicherung, Bearbeitung, Archivsystem
Dateiverwaltung	Metadaten und Berechtigungen	Objekt- oder Cloudspeicher
Kalender	funktionsbezogene Termine und Regeln	Groupwarekalender
Terminvergabe	Leistung, Terminart, Berechtigung	externe Kalender und Videokonferenzsysteme
Beschaffung	Bedarf, Kriterien, Entscheidung, Vertrag	Vergabeplattform und ERP
Finanzsteuerung	Budgetrahmen, Verantwortung, Freigaben	Buchhaltung und Zahlungsverkehr
Personal- und Ressourcenplanung	Funktionen, Kapazität, Qualifikationen	HR- und Abrechnungssystem
Berichtswesen	Herkunft, Transformation und einfache Berichte	spezialisierte BI-Plattform
Anlagenmanagement	Verantwortung, Prüfungen, Maßnahmen	CAFM-, GIS- und technische Systeme
Lernverwaltung	Pflichtqualifikationen und Governance	LMS und Campusmanagement
Fachverfahren	Fallkontext und übergreifende Steuerung	hoch spezialisierte Sachbearbeitung

Überwiegend konnektororientiert

GovOPlaN sollte folgende vollständige Systeme regelmäßig nicht ersetzen:

Finanzbuchhaltung und Haushaltsrechnung;
Entgeltabrechnung;
umfassende Personalwirtschaft;
klinische Systeme;
Campusmanagement;
gerichtliche Fachverfahren;
Steuer- und Zollverfahren;
polizeiliche Einsatz- und Ermittlungssysteme;
vollständige GIS- und CAD-Plattformen;
industrielle Leit- und Betriebstechnik;
E-Mail-Server und vollständige Groupware;
formale Langzeitarchive;
umfassende elektronische Vergabeplattformen.

Auch hier kann GovOPlaN aber Verantwortung, Regeln, Vorhaben, Risiken, Schnittstellen, Entscheidungen und Nachweise führen.

7. Korrekturen an der gegenwärtigen Modulklassifikation

Die Architekturdokumentation unterscheidet bereits:

Plattformmodule;
Dienstmodule;
Fachmodule;
Konnektormodule.

Der maschinenlesbare beziehungsweise tabellarische Repositoryindex verwendet dagegen derzeit im Wesentlichen nur system, module und connector sowie die Unterteilung platform und domain. Dadurch erscheinen wiederverwendbare Dienste und querschnittliche Governance-Funktionen teilweise als Fachdomänen. (gitea@add-ideas.de)

Empfohlene Metadaten

kind: module
module_type: service
layer: communication
maturity: vertical-slice

source_modes:
  - native
  - external
  - mirror
  - synchronized
  - governance-overlay

owns:
  - delivery_profiles
  - delivery_attempts
  - durable_outbox

does_not_own:
  - recipients
  - campaign_semantics
  - institutional_postboxes

capabilities:
  provides:
    - mail.transport
    - mail.delivery_status
  requires:
    - access.actor_context
    - audit.evidence

Sinnvolle Klassifikation

Plattformmodule

tenancy
access
identity
organizations
idm
mandates
policy
audit
risk-compliance
admin
ops
views
search

Wiederverwendbare Dienstmodule

files
templates
mail
notifications
addresses
dist-lists
calendar
booking
resources
dataflow
datasources
reporting

Fach- und Arbeitsmodule

services
parties
cases
tasks
approvals
decisions
campaign
committee
consultation
projects
procurement
contracts
grants
permits
inspections

Konnektoren

ERP
DMS-Anbieter
FIT-Connect
XÖV
XTA/OSCI
REST
SOAP
XRechnung
LDAP
Active Directory
SCIM
OIDC
externe Kalender
GIS
Fachverfahren

ERP sollte daher im Katalog nicht als fachliche Domäne erscheinen. Mail, Files, Templates oder Notifications sollten nicht als gewöhnliche Domainmodule geführt werden.

8. Repositorygrenzen und Konsolidierung

Logische Modularität ist nicht gleich Repositoryzahl

Ein eigener Capability-Vertrag oder ein eigenständiges Fachobjekt verlangt nicht automatisch ein neues Repository.

Ein neues Repository sollte erst entstehen, wenn mindestens die meisten der folgenden Kriterien erfüllt sind:

Eigenständige Datenhoheit: Das Modul besitzt klar definierte Objekte.
Eigenständige Installierbarkeit: Es kann sinnvoll aktiviert oder deaktiviert werden.
Eigene technische Bestandteile: Eigene Migrationen, APIs, Rechte, Hintergrundaufgaben oder Oberflächen.
Eigener Veröffentlichungszyklus: Änderungen müssen unabhängig ausgeliefert werden können.
Eigenständiges Sicherheitsprofil: Das Modul hat besondere Berechtigungs- oder Schutzanforderungen.
Mehrere Verbraucher: Andere Module nutzen seine Capabilities.
Nachgewiesener Referenzprozess: Mindestens ein vollständiger Anwendungsfall funktioniert damit.

Andernfalls sollte die Funktion zunächst entstehen als:

Capability innerhalb eines bestehenden Moduls;
Teilmodul;
Plugin;
Konfigurationspaket;
Profil;
gemeinsamer Datentyp.

Konkrete Fälle

`forms` und `forms-runtime`

Die fachliche Trennung von Definition und Laufzeit ist sinnvoll. Solange der Runtime-Teil jedoch noch keine eigenständige, stabile Lebensdauer besitzt, können beide gemeinsam ausgeliefert werden. Ein separates Repository ist erst zwingend, wenn:

andere Module den Runtime-Dienst unabhängig verwenden;
eigene Skalierung nötig ist;
Submission-Daten getrennt geschützt werden;
unterschiedliche Veröffentlichungszyklen entstehen.

`helpdesk`

Ein Helpdesk benötigt im Wesentlichen:

Tickets;
Fälle;
Aufgaben;
Funktionspostfach;
Benachrichtigungen;
Wissensartikel;
Service-Level-Regeln;
Auswertungen.

Das spricht zunächst für ein Helpdesk-Paket und nicht für eine parallele fachliche Infrastruktur.

`appointments`

Terminverwaltung kann zunächst ein Paket aus:

Leistung;
Terminart;
Kalender;
Verfügbarkeit;
Buchung;
Benachrichtigung;
Beteiligtenbezug

sein. Ein eigenes Fachmodul ist erst erforderlich, wenn Terminserien, Vorprüfungen, Check-in, Wartelisten oder besondere rechtliche Lebenszyklen eigenständige Datenhoheit begründen.

`addresses` und `dist-lists`

Beide dürfen eigenständige Capability-Anbieter bleiben. Sie müssen aber nicht zwingend als separate, für Anwender sichtbare Produktmodule erscheinen.

9. Reifestufen statt bloßer Repositoryexistenz

Die aktuelle Roadmap weist selbst darauf hin, dass die tatsächliche Reife der Module sehr unterschiedlich ist und ein Repositoryname noch keine belastbare Implementierung belegt. (gitea@add-ideas.de)

Deshalb sollte jedes Modul eine explizite Reifestufe tragen:

Reifestufe	Bedeutung
Concept	Domäne und Grenzen sind beschrieben.
Scaffold	Modul ist technisch auffindbar und installierbar, besitzt aber noch keinen vollständigen Ablauf.
Vertical Slice	Ein vollständiger schmaler Anwendungsfall funktioniert.
Reference Ready	Das Modul funktioniert in einem dokumentierten Referenzpaket.
Supported	Migrationen, Tests, Betrieb, Dokumentation und Upgradepfad sind zugesichert.
LTS	Langfristige Kompatibilität und Sicherheitswartung sind definiert.

Zusätzlich sollte erfasst werden:

Referenzpakete;
unterstützte Provider;
bekannte Beschränkungen;
Datenmigrationsstand;
unterstützte Upgradepfade;
Sicherheitsklassifikation;
Betriebsanforderungen.

Das verhindert, dass eine Liste von 72 Repositories äußerlich wie ein fertiges Gesamtprodukt wirkt, obwohl ein Teil bewusst nur als Architekturplatzhalter existiert.

10. Verbindliche querschnittliche Verträge

Bestimmte Anforderungen sollten nicht in jedem Modul neu erfunden werden.

10.1 Zeit und Historisierung

Jedes wesentliche Governance-Objekt benötigt:

fachlich gültig ab;
fachlich gültig bis;
im System erfasst am;
im System ersetzt am;
Version;
Änderungsgrund.

Damit lässt sich unterscheiden zwischen:

dem damaligen institutionellen Zustand;
dem heutigen Wissensstand über diesen Zustand.

10.2 Handelnde und vertretene Identität

Jede relevante Handlung muss unterscheiden:

technisches Konto;
natürliche handelnde Person;
wahrgenommene Funktion;
vertretene Person oder Organisation;
Delegation oder Vollmacht;
zugrunde liegendes Mandat.

10.3 institutioneller Kontext

Eine Handlung sollte, soweit einschlägig, referenzieren:

Mandant;
Organisationseinheit;
Funktion;
Aufgabe;
Mandat;
Zuständigkeitsbereich;
Fall;
Entscheidung.

10.4 Rechts- und Richtliniengrundlage

Nicht jedes Modul muss juristische Dokumente verwalten. Es muss aber auf die maßgebliche Grundlage verweisen können:

Rechtsnorm;
Satzung;
Dienstanweisung;
Richtlinie;
Beschluss;
Vertrag;
Einwilligung.

10.5 Beabsichtigte und tatsächliche Wirkung

Bei externen oder asynchronen Operationen sind mindestens getrennt zu speichern:

Anforderung;
Freigabe;
Ausführungsabsicht;
Übermittlungsversuch;
Rückmeldung;
beobachtete Wirkung;
Abstimmungszustand.

10.6 Nachweis und Herkunft

Jede wichtige Aussage benötigt:

Quelle;
Erfassungsweg;
Version;
Ersteller;
Zeitpunkt;
Vertrauensniveau;
zugehörige Nachweise.

10.7 Klassifikation, Zweck und Aufbewahrung

Gemeinsame Metadaten:

Schutzklasse;
Verarbeitungszweck;
Zugriffsgrund;
Aufbewahrungsregel;
Löschsperre;
Veröffentlichungsklasse;
Schwärzungsbedarf.

10.8 Externe Quelle und Synchronisationszustand

Bei übernommenen Daten:

externes System;
externe Kennung;
letzte erfolgreiche Synchronisation;
Revisionskennung;
Aktualitätszustand;
Konfliktzustand;
lokale Änderungen;
verantwortlicher Provider.

10.9 Barrierefreiheit, Sprache und Darstellung

Formulare, Vorlagen, Portalinhalte und Benachrichtigungen benötigen gemeinsame Verträge für:

Sprache;
leichte beziehungsweise einfache Sprache;
alternative Darstellungen;
barrierefreie Bezeichnungen;
maschinenlesbare Fehler;
kanalabhängige Ausgabe.

Diese Verträge sollten im Kern oder in kleinen gemeinsamen Spezifikationspaketen definiert werden. Ihre fachliche Auslegung bleibt beim jeweils zuständigen Modul.

11. Empfohlene Produktpakete

Paket 1: Governance-Grundlage

tenancy
identity
organizations
mandates
idm
access
policy
audit
admin
docs
views

Ergebnis:

nachvollziehbare Organisation;
Funktionen und Besetzungen;
Zuständigkeiten;
Delegationen;
technische Rechte;
institutioneller Prüfpfad.

Paket 2: Gesteuerte Kommunikation

campaign
addresses
dist-lists
mail
notifications
templates
files
approvals
audit
reporting

Ergebnis:

freigegebene Empfängergrundlage;
nachvollziehbare Serienkommunikation;
belastbare Zustellnachweise;
revisionsfähige Auswertung.

Paket 3: Funktionsgebundene Zusammenarbeit

postbox
organizations
identity
idm
mandates
access
mail
notifications
tasks
views

Ergebnis:

institutionelle Postfächer statt persönlicher Schattenablagen;
stabile Zuständigkeit bei Wechsel und Vakanz;
Delegation und Vertretung;
aufgabenbezogene Sichten.

Paket 4: Leistung vom Eingang bis zur Entscheidung

services
parties
portal
forms
forms-runtime
cases
tasks
approvals
decisions
postbox
templates
files
records
payments
audit

Ergebnis:

veröffentlichte Leistung;
Antrag oder Meldung;
Beteiligten- und Vertretungsmodell;
Fallbearbeitung;
Entscheidung;
Zustellung;
Akten- und Nachweiszusammenhang.

Paket 5: Beschaffung und Vertragssteuerung

procurement
contracts
parties
decisions
approvals
risk-compliance
files
records
ERP- und XRechnung-Konnektoren
reporting

Paket 6: Gesteuerte Datenanalyse

datasources
connectors
dataflow
reporting
dashboard
policy
audit
organizations
mandates

Ergebnis:

verantwortete Datenquellen;
reproduzierbare Transformationen;
nachvollziehbare Berichte;
institutionell zugeordnete Kennzahlen.

12. Sektorspezifische Pakete

Kommunalverwaltung

Zusätzlich zu den horizontalen Grundlagen:

services
parties
forms-runtime
cases
permits
appointments
payments
records
transparency
Geo-Provider
Register- und Fachverfahrenskonnektoren

Hochschule und Forschung

organizations
mandates
identity
idm
committee
projects
grants
learning
certificates
risk-compliance
reporting
HIS-, Campus-, Forschungs- und HR-Konnektoren

Besonders relevant:

akademische Funktionen;
Gremienmitgliedschaften;
zeitlich begrenzte Projektrollen;
Drittmittelverantwortung;
Exportkontrolle;
Berufungs- und Prüfungsverfahren.

Ministerium und Programmverwaltung

mandates
projects
decisions
committee
consultation
grants
contracts
reporting
evaluation
records
transparency

Aufsichts- und Regulierungsbehörde

parties
services
permits
inspections
cases
decisions
risk-compliance
reporting
records
transparency

13. Abgleich mit der bestehenden Roadmap

Die gegenwärtige Roadmap priorisiert im Wesentlichen:

Campaign als belastbaren Referenzpfad;
funktionsgebundene Postfächer;
Vorlagen und Reporting;
Hochschul-BI;
kollaborativen Dokumentenlebenszyklus;
eine bewusst begrenzte und optionale Workflow-Entwicklung. (gitea@add-ideas.de)

Diese Reihenfolge sollte nicht verworfen, sondern um die fehlenden Governance-Grundobjekte ergänzt werden.

Phase 0: Architektur- und Portfoliobereinigung

Repositorybeschreibungen korrigieren;
Modulklassen vereinheitlichen;
Datenhoheit je Modul dokumentieren;
Reifestufen einführen;
Provider- und Betriebsmodelle standardisieren;
direkte Modulimporte durch Capability-Verträge ersetzen;
Referenzpakete maschinenlesbar beschreiben.

Konkrete Korrekturen:

tenancy nicht mehr mit Organisationsstrukturen beschreiben;
organizations nicht mehr als Eigentümer der Funktionsbesetzung darstellen;
identity und access sprachlich klar trennen;
idm als Lifecycle-, Assignment- und Provisioning-Modul positionieren;
risk-compliance als querschnittliches Governance-Modul einordnen;
erp als Konnektorfamilie klassifizieren.

Phase 1: Campaign-Referenzpaket abschließen

Keine neue Breite erzeugen, sondern den vorhandenen End-to-End-Pfad belastbar machen:

Empfängerherkunft;
Vorschau;
Freigabe;
dauerhafte Ausführungsabsicht;
Versand;
unklare Zustände;
Abstimmung;
Nachweise;
Reporting;
Wiederherstellung.

Dieser Pfad liefert Muster für alle späteren externen Wirkungen.

Phase 2: Institutionelle Identitäts- und Funktionsbasis

Zusammenführen und stabilisieren:

identity;
organizations;
idm;
access;
tenancy;
postbox.

Parallel ein minimales mandates einführen:

Aufgabe;
Zuständigkeit;
verantwortliche Funktion;
rechtliche oder organisatorische Grundlage;
Gültigkeitszeitraum.

Damit kann das Postbox-Paket bereits auf echten institutionellen Zuständigkeiten aufbauen.

Phase 3: Entscheidung und Nachweis

decisions als schmalen Vertikalschnitt einführen;
templates und reporting stabilisieren;
Beschluss, Freigabe und externe Wirkung verbinden;
Entscheidungskontext in Campaign, Committee und Procurement erproben.

Phase 4: Hochschul-BI und Data Governance

datasources;
connectors;
dataflow;
reporting;
dashboard.

Ergänzen um:

Datenverantwortung;
Rechtsgrundlage;
Qualitätsstatus;
Herkunft;
Version;
Verwendung in Berichten und Entscheidungen.

Phase 5: Dokumenten- und Aktenlebenszyklus

files;
dms;
records;
templates;
transparency;
search.

Nicht nur gemeinsame Dokumentbearbeitung umsetzen, sondern den gesamten Zusammenhang von:

Fachobjekt → Dokument → Version → Nachweis → Akte → Aufbewahrung → Veröffentlichung

abbilden.

Phase 6: Erste allgemeine Verwaltungsleistung

Dann erst die fehlenden Bausteine gemeinsam vertikal implementieren:

services;
parties;
forms-runtime;
cases;
tasks;
approvals;
decisions;
portal;
postbox;
records.

Als Referenzfall sollte ein überschaubares, aber vollständiges Verfahren gewählt werden, beispielsweise:

interne Genehmigung;
Förderantrag;
Veranstaltungs- oder Raumnutzungsantrag;
einfache kommunale Erlaubnis;
universitäre Serviceleistung.

Damit wird nicht nur ein weiteres Modul demonstriert, sondern erstmals die allgemeine Plattformthese.

14. Zusammengeführtes Zielbild

GovOPlaN sollte selbst besitzen:

die institutionelle Struktur;
Aufgaben, Mandate und Zuständigkeiten;
Funktionen, Besetzungen und Delegationen;
Leistungen;
Beteiligtenbeziehungen;
Fälle und Aufgaben;
Entscheidungen;
Richtlinien und Kontrollen;
Vorhaben und Abhängigkeiten;
Nachweis- und Aktenkontext;
Herkunft und Wirkung externer Operationen.

GovOPlaN sollte optional nativ ausführen:

Identitäts- und Berechtigungsverwaltung;
einfache Datei- und Dokumentenverwaltung;
Formulare;
Fallbearbeitung;
Workflows;
Funktionspostfächer;
Kommunikation;
Termine und Buchungen;
Projekt-, Vertrags- und Fördersteuerung;
einfache Berichte;
einfache Ressourcen- und Budgetrahmenverwaltung.

GovOPlaN sollte regelmäßig anbinden:

ERP;
Personalwirtschaft;
Verzeichnisdienste;
DMS und Archive;
Groupware;
GIS;
BI-Systeme;
Fachverfahren;
Zahlungsdienste;
Campus-, Klinik-, Justiz- und Infrastruktursysteme.

Die entscheidende Produktgrenze verläuft damit nicht zwischen „in GovOPlaN“ und „außerhalb von GovOPlaN“, sondern zwischen:

institutioneller Governance, die GovOPlaN verstehen und erhalten muss, und spezialisierter Ausführung, die GovOPlaN wahlweise selbst erbringt oder gesteuert an andere Systeme übergibt.

Für die unmittelbare Architekturarbeit würde ich daher vier neue fachliche Kernkontexte priorisieren – mandates, services, parties und decisions – und gleichzeitig die vorhandenen 72 Repositories über ein einheitliches Schema für Datenhoheit, Modultyp, Reifegrad und Betriebsmodus neu ordnen. Das schließt die entscheidenden semantischen Lücken, ohne die Plattform durch weitere unverbundene Funktionsmodule auszudehnen.

Ableitung einer Zielarchitektur für govoplan

Ergebnis vorab

1. Das grundlegende Architekturprinzip: nicht „integriert oder angebunden“, sondern unterschiedliche Betriebsmodelle

Gemeinsamer Vertrag für austauschbare Anbieter

2. Empfohlene Zielarchitektur

Ebene 0: System, Laufzeit und Modulverwaltung

Bestehende Bausteine

Zuständigkeit

Nicht in den Kern gehören

Ebene 1: Institutionelle Basis und Berechtigungsordnung

Bestehende Bausteine

Zu ergänzen

Zweck dieser Ebene

Ebene 2: Governance, Regeln und Rechenschaft

Bestehende Bausteine

Zu ergänzen

Zweck dieser Ebene

Ebene 3: Menschliche Arbeit und Verfahrensausführung

Bestehende Bausteine

Zu ergänzen

Zweck dieser Ebene

Ebene 4: Kommunikations- und Zugangskanäle

Bestehende Bausteine

Zweck dieser Ebene

Ebene 5: Inhalte, Dokumente, Akten und Nachweise

Bestehende Bausteine

Empfohlene Abgrenzung

Ebene 6: Daten, Berichte und Integration

Bestehende Bausteine

Zweck dieser Ebene

Notwendige Erweiterung von datasources

Ebene 7: Fach- und Betriebsdomänen

Bestehende Bausteine

Ebene 8: Produkt- und Sektorpakete

3. Abgleich mit den zuvor identifizierten Bedarfsfeldern

A. Organisation, Aufgaben und Verantwortung

Bereits vorhanden

Lücke

Ableitung

B. Leistungs-, Verfahrens- und Fallmanagement

Bereits vorhanden

Lücken

Ableitung

C. Prozesse und Zusammenarbeit

Bereits vorhanden

Bewertung

Notwendige Schärfung

D. Entscheidungen, Beschlüsse und Gremien

Bereits vorhanden

Lücke

Ableitung

E. Akten, Dokumente und institutionelles Gedächtnis

Bereits vorhanden

Bewertung

Ergänzung

F. Daten, Register und Interoperabilität

Bereits vorhanden

Lücke

Ableitung

G. Risiko, Compliance, Kontrolle und Prüfung

Bereits vorhanden

Bewertung

Ableitung

H. Strategie, Portfolio und Veränderung

Bereits vorhanden

Lücken

Ableitung

I. Beschaffung, Verträge und Förderungen

Bereits vorhanden

Bewertung

Zielbild

J. Finanzen, Personal und Kapazitäten

Bereits vorhanden

Lücken

Ableitung

K. Anlagen, Liegenschaften, Geodaten und Infrastruktur

Bereits vorhanden

Lücke

Ableitung

L. Bürger-, Unternehmens- und Beteiligtenkommunikation

Notwendige Erweiterung von `datasources`

4.1 `govoplan-mandates`: Aufgaben, Mandate, Zuständigkeiten und Verantwortung

4.2 `govoplan-services`: Leistungen und Leistungsversprechen

4.3 `govoplan-parties`: Beteiligte, Beziehungen und Vertretung

4.4 `govoplan-decisions`: Entscheidungen und ihre Wirkungen

Erforderliche Neupositionierung von `govoplan-idm`

`forms` und `forms-runtime`

`helpdesk`

`appointments`

`addresses` und `dist-lists`