Eine anonymisierte Fallstudie zu mehreren eigenständigen Nextcloud-Anwendungen für Organisationsprozesse. Die Anwendungen werden öffentlich unter der Produktmarke Filzmann eingeordnet. Sie teilen nur klar abgegrenzte technische Grundlagen, bleiben fachlich getrennt und setzen ihre Zugriffsrechte serverseitig selbst durch.
Praxisfeld: Persönliche Assistenz und soziale Organisationen
Kontext: eigene Beobachtungen und Anforderungen realer Organisationsprozesse in einem Assistenzbetrieb in Berlin
Entstehung: Konzeption und Entwicklung in Eigeninitiative; keine Beauftragung durch den Assistenzbetrieb
Status: In Entwicklung
Erprobung: kontrolliertes Staging
Produktiver Einsatz: noch nicht
Ausgangsproblem und Ziel
Organisationsprozesse wie Dienst- und Terminplanung, Urlaubsverwaltung, Raumbuchung und Recruiting haben unterschiedliche fachliche Regeln, greifen aber teilweise auf dieselben Rollen, Organisationsdaten und Navigationsstrukturen zurück. Eine einzige große Anwendung würde diese Bereiche unnötig koppeln; vollständig getrennte Lösungen würden gemeinsame Grundlagen mehrfach implementieren.
Ziel der Architektur ist deshalb eine Trennung zwischen gemeinsam genutzter technischer Infrastruktur und eigenständigen Fachanwendungen. Jede Fachanwendung bleibt klar abgrenzbar und kann ohne optionale Integrationen mit einem reduzierten beziehungsweise manuellen Fachweg weiterarbeiten.
Zielgruppen und Rollen
- Beschäftigte, die eigene fachliche Vorgänge nutzen oder bearbeiten
- koordinierende Rollen mit erweiterten fachlichen Aufgaben
- administrierende Rollen für Organisationskonfiguration und technische Verwaltung
Die konkreten betrieblichen Rollen- und Gruppennamen werden auf dieser Website bewusst nicht veröffentlicht. Technische Administration führt nicht automatisch zu fachlichen Lese- oder Schreibrechten.
Architektur in vereinfachter Form
Das Diagramm ist bewusst abstrahiert. Es zeigt die technische Trennung, ohne interne Domains, reale Gruppenstrukturen oder produktive Systemdetails offenzulegen.
Nextcloud-Plattform
Benutzer · Gruppen · Dateien · vorhandene Plattformfunktionen
Gemeinsame technische Grundlagen
Organisationskonfiguration · Navigation · kleine wiederverwendbare Verträge
Dienst- und Terminprozesse
Planung, Urlaub und Räume
Recruiting und weitere Fachprozesse
Serverseitige Fachberechtigungen je Anwendung
Navigation, gemeinsame Infrastruktur und technische Administration erweitern keine fachlichen Rechte
Funktionsumfang
- Wochen- und Monatsplanung für Dienste und Termine einschließlich wiederkehrender Termine, Personen- und Gruppenfilter sowie Planungshilfen
- monatliche Wunschdienstplanung mit kontrolliertem Planstatus und Sperre genehmigter Pläne gegen unbeabsichtigte Änderungen
- Urlaubs- und Raumbuchungsprozesse als eigene Fachbereiche mit klaren Zuständigkeiten
- strukturierter Recruiting-Ausschnitt mit Stellen, Personen, Bewerbungen, versionierten Interviewvorlagen und kontrollierten Statusübergängen
- separate Entwicklungsprototypen für Qualifizierungsplanung sowie die nachvollziehbare Vermittlung kurzfristig offener Schichtabschnitte; keine Freigabe für den produktiven Betrieb
- gemeinsame Organisationsdefinition und Navigation ohne Übertragung fachlicher Schreib- oder Leserechte
- optionale Integrationen über kleine, klar abgegrenzte Verträge statt direkter Zugriffe auf fremde Fachapp-Interna
Berechtigungen, Security und Datenschutz
Navigation ist ausdrücklich keine Berechtigung. Lesen, Schreiben, Administration und konkrete Zielobjekte werden serverseitig in den Fachanwendungen geprüft. Fachliche Daten bleiben in der jeweils zuständigen Anwendung; optionale Integrationen werden so weit wie möglich read-only und datensparsam gehalten.
Das Berechtigungsmodell folgt dem Least-Privilege-Prinzip: Auch administrierende Rollen erhalten nur die fachlichen Rechte, die für ihre Aufgabe tatsächlich erforderlich sind. Dadurch können einzelne Verwaltungswege restriktiver sein als in Systemen mit allmächtigen Administrationsrollen.
Security by Design ist in Architektur, Prüfpfade und Rechtefälle eingebunden. Datenschutz by Design wird parallel weiter systematisiert; dazu gehören unter anderem Datenminimierung und strukturierte Angaben zu Zweck und Speicherfristen dort, wo sie für den jeweiligen Fachprozess benötigt werden. Noch nicht implementierte Teile werden nicht als vorhanden dargestellt.
Qualitätssicherung und Release Evidence
Der Prüfpfad kombiniert schnelle PHP- und JavaScript-Prüfungen, Metadaten- und Vertragschecks, reproduzierbaren Paketbau mit Prüfsummen, Containerprüfungen, authentifizierte HTTP-Smokes sowie Rechtematrizen für typische Allow-/Deny-Fälle. Ergänzend werden Prüfberichte und weitere Nachweise einem konkreten Entwicklungs- oder Releasezustand zugeordnet.
Release Evidence macht sichtbar, welche Nachweise vorhanden, fehlgeschlagen, nicht ausgeführt oder für einen geänderten Stand nicht mehr aktuell sind. Evidence ersetzt weder den Test selbst noch eine fachliche, datenschutzbezogene oder sicherheitsbezogene Freigabe.
Der Prüfprozess soll unnötige Wiederholungen vermeiden: Ein noch gültiger Nachweis für unveränderte Bestandteile kann weiterverwendet werden. Geänderte, sicherheitskritische oder anderweitig betroffene Pfade werden neu geprüft. Damit bleibt die Aussagekraft erhalten, ohne identische Prüfungen ohne Anlass mehrfach auszuführen.
Für einzelne Prüfkriterien werden Anforderungen aus dem BSI IT-Grundschutz als Referenz herangezogen. Dies ist keine BSI-Zertifizierung, keine Prüfung durch das BSI und keine Aussage, ein einzelnes Plugin sei nach IT-Grundschutz zertifiziert.
Status, Version und Kompatibilität
Status: In Entwicklung
Erprobung: kontrolliertes Staging
Produktiver Einsatz: noch nicht
Entwicklungs- und Prüfumgebungen: je nach Fachmodul Nextcloud 34 beziehungsweise 35; eine dokumentierte Nextcloud-35.0.1-Prüfung einzelner Apps ist keine Gesamtfreigabe der Produktfamilie. PHP-Anforderung je Modul prüfen
Version: kein einzelner Versionswert für die Fallstudie, da mehrere eigenständig versionierte Anwendungen zusammengefasst werden
In der aktuellen Entwicklungsphase kann die Testumgebung kontrolliert neu installiert werden. Ein stabiler öffentlicher Release wird erst dann als solcher bezeichnet, wenn Version, Zielumgebung, Nachweise, bekannte Grenzen und Freigabe zusammenpassen.
Technischer Entwicklungsstand am 6. November 2026
Die Fachanwendungen werden unabhängig versioniert. Der Repository-Stand umfasst unter anderem die Dienst- und Terminplanung (0.15.0-rc.2), Wunschdienstplanung (0.7.0-rc.2), Urlaubsplanung (0.7.0-rc.2), Raumbuchung (0.13.0-rc.1), Recruiting (0.11.0-rc.20), Basisqualifizierungsplanung (0.5.0-dev.3) und einen frühen Prototyp für die kurzfristige Schichtvermittlung (0.1.0-dev.1). Diese Versionsangaben sind Entwicklungsstände aus den jeweiligen App-Metadaten, keine gemeinsame veröffentlichte Suite-Version und keine Aussage über produktive Nutzung.
Neu hinzugekommen sind unter anderem optionale, versionierte Schnittstellen für datensparsame Auskunfts- und Verarbeitungsmetadaten sowie kontrollierte, zeitlich begrenzte fachliche Administrationsfreigaben. Diese Mechanismen bleiben von den eigentlichen Nextcloud-Gruppenrechten getrennt. Fehlende oder inkompatible Datenprovider dürfen nicht zu angenommenen Freigaben führen. Rechtliche Speicher- und Löschentscheidungen sind dadurch nicht automatisch geklärt.
Die aus September 2026 verlinkten Product- und Release-Evidence-PDFs sind separate Dokumentausgaben. Sie werden erst nach einem eigenen Inhaltsabgleich als aktuelle Nachweise bezeichnet.
Dokumentation und Repositories
Die technische Dokumentation wird in den jeweiligen Repositories geführt. Dazu gehören je nach Anwendung Architektur, Installation, Betrieb und Rückbau, Tests, Delivery-Gates, bekannte Grenzen und Release-Nachweise. Einen direkten Repository-Link setze ich auf dieser anonymisierten Portfolioseite derzeit nicht: Repository- und frühere Projektbezeichnungen enthalten internen Kontext, der nicht automatisch als öffentliche Produktbezeichnung übernommen wird.
Eigener Anteil und KI-Einsatz
Konzeption und Entwicklung der hier beschriebenen Anwendungskomponenten erfolgten in Eigeninitiative. Mein Anteil umfasst insbesondere die Trennung gemeinsamer Infrastruktur von Fachlogik, Rollen- und Berechtigungsmodelle, technische Umsetzung, Tests, Dokumentation und Delivery-Struktur. Der Assistenzbetrieb ist Kontext der Anforderungen, nicht automatisch Auftraggeber, Partner oder Referenzkunde.
KI-Werkzeuge nutze ich zur Strukturierung von Anforderungen, Codeanalyse, Fehlersuche, Vorbereitung von Tests und Reviews sowie zur Prüfung von Dokumentation. Freigaben, Datenschutz- und Sicherheitsbewertung und die Behauptung erfolgreicher Tests bleiben davon getrennte menschliche Entscheidungen.
Nächste Schritte zu einem stabilen Release
- einen konkreten Releasezustand und eine definierte Zielumgebung festlegen
- Installation beziehungsweise Neuinstallation sowie Rückbau für diesen Stand verifizieren
- Release Evidence auf Aktualität und Vollständigkeit für die betroffenen Pfade prüfen
- Datenschutz- und Sicherheitsprüfung für den konkreten Releasezustand abschließen
- bekannte Grenzen und Kompatibilität dokumentieren und erst anschließend über einen stabilen öffentlichen Release entscheiden
Screenshots und Veröffentlichung
Aktuell veröffentliche ich hier bewusst keine produktiven Screenshots. Für spätere UI-Beispiele werden ausschließlich synthetische Demonstrationsdaten verwendet. Interne Organisationsnamen, reale Benutzer- und Gruppenstrukturen sowie Produktivdaten bleiben außerhalb dieser Darstellung.