nexarch/USP.md

NEXARCH 2.0 – USP (Unique Selling Proposition)

Stand: 2026-08-26. Quellen: nexarch-state.json, PRODUKTARCHITEKTUR.md. Jede Aussage unten ist gegen die Quelldateien geprüft, nicht erfunden.

Kernaussage

Bei NEXARCH landen E-Mail und Dokument in derselben Akte — nicht in zwei Systemen, die sich nicht kennen.

Wer heute archiviert, kennt das: die E-Mail liegt im Mailarchiv, das dazugehörige Dokument im DMS, und niemand sieht beides zusammen, ohne zwei Programme zu öffnen. NEXARCH macht daraus einen Vorgang. Und weil Sicherheit kein Feature ist, das man pro Modul neu erfindet, existiert der heikle Code — Verschlüsselung, Aufbewahrungsfristen, Löschsperren — genau einmal im ganzen System, nicht sechsmal mit sechsmal Fehlerpotenzial. Betrieben wird das Ganze im eigenen Haus, mit KI, die die Daten nicht verlässt.

Warum das trägt

1. Eine Akte, kein Silo-Hopping. Ein Dokument und die dazugehörige E-Mail gehören für den Nutzer zusammen — bei NEXARCH auch technisch. Die Akte lebt an einem Ort, DMS und Mail zeigen sie nur an, keiner kopiert sie. (Workflow-Epic VOR, DMS DOC-13, Mail UX-09.) Ehrlich gesagt: diese Rückkopplung war nicht von Anfang an klar — sie fiel erst im Gespräch auf, weil eine reine Einbahnstraßen-Architektur die Akte für die Anwender unsichtbar gemacht hätte. Jetzt ist sie geschlossen, inklusive sauberer Mandantentrennung.

2. Sicherheitskritischer Code wird nicht sechsmal geschrieben. Das ist kein Zufall, sondern Prinzip: Aufbewahrung, WORM und eDiscovery wurden aus zwei Modulen in eines gezogen, mit der ausdrücklichen Begründung, dass Compliance-Code "einmal richtig existieren sollte statt zweimal". Dieselbe Logik traf die Verschlüsselung — der Master-Key wurde zentralisiert, weil doppelt gepflegter Krypto-Code das größte Fehlerrisiko im ganzen Projekt ist. Vier solcher Konsolidierungen sind dokumentiert, keine Einzelaktion.

3. KI, die zu Hause bleibt. Klassifizierung und Zusammenfassung laufen standardmäßig über ein lokal gehostetes Modell, nicht über eine fremde Cloud. Ein externer Anbieter lässt sich anschließen, wenn jemand das will — aber niemand muss. Und wer KI gar nicht braucht, lässt sie einfach aus.

4. Schlank installiert statt schwer aufgesetzt. Ein Dienst pro Modul, native Installation als Normalfall — kein Cluster, kein Orchestrierungs-Unterbau, den man erst verstehen muss, bevor man loslegen kann.

5. Aus echten Fehlern gelernt, nicht am Reißbrett erfunden. Beide Vorgängersysteme liefen produktiv, mit echten Bugs. Das Dokumentenmodul wird komplett neu gebaut, weil bekannte Fehler nicht mitwandern sollen. Das Mail-Modul übernimmt bewährten Protokollcode (IMAP/SMTP ist zu komplex, um ihn leichtfertig wegzuwerfen) — aber jeder der 13 bekannten Fehler daraus ist als Korrekturpflicht vermerkt, nicht als Fußnote. Einer davon (ein Mandanten-Leck durch falsch platzierten Filter) wurde später bei einem ganz anderen Feature erneut geprüft und geschlossen — das ist gelebte, keine behauptete Sorgfalt.

6. Ein System für klein und groß. Vom Einzelserver bis zur dedizierten Instanz für Großkunden — derselbe Stack, kein Cloud-Sonderweg, der nachträglich On-Premise-tauglich gemacht werden musste. Wachstum ist ein Skalierungsschritt, kein Systemwechsel.

7. Ein Datenleck durch einen Programmierfehler ist strukturell ausgeschlossen, nicht nur unwahrscheinlich. Jeder Mandant sitzt in einer eigenen Datenbank, nicht in einer gemeinsamen mit Filterzeile. Ein vergessener Filter in einer Query kann damit technisch keine fremden Daten mehr zurückliefern — es gibt in dieser Datenbank schlicht keine. Derselbe Schnitt hat einen zweiten Vorteil: eine Mandanten-Datenbank lässt sich als Ganzes von On-Premise zu SaaS verschieben und zurück, ohne die Anwendung umzubauen. (Core TEN-01/TEN-06/TEN-07.)

Wogegen wir NICHT antreten

Ein Alleinstellungsmerkmal wird erst glaubwürdig, wenn man auch sagt, wofür man nicht die richtige Wahl ist:

• Für den Einzelnutzer mit einem Ordner voller PDFs ist NEXARCH überdimensioniert — paperless-ngx oder Docspell sind dafür schneller aufgesetzt. NEXARCH lohnt sich erst, wo mehrere Mandanten oder Abteilungen aufeinandertreffen.
• Für vollwertige BPMN-Prozessorchestrierung ist NEXARCH nicht gebaut — die Workflow-Engine orientiert sich an schlanken Vorbildern, nicht an Camunda-Umfang.
• Für frei definierbare attributbasierte Rechte (ABAC) ist NEXARCH nicht gebaut — das Rechtemodell ist bewusst rollenbasiert (RBAC), nicht auf beliebige Attribut-Policies wie bei Casbin ausgelegt. Wer Rechte nach beliebigen Laufzeit-Attributen statt nach Rollen vergeben will, bekommt das hier nicht.
• Für Kunden ohne eigene Infrastruktur ist On-Premise-first kein Vorteil, sondern zusätzliche Arbeit — dann ist ein reiner Cloud-Anbieter die bessere Wahl.
• Eine feste Preisliste gibt es noch nicht — das Lizenzmodell ist ein Entwurf, keine Zusage.

Wer das kaufen sollte

Organisationen, die heute E-Mail- und Dokumentenarchiv getrennt betreiben und spüren, dass das nicht mehr zusammenpasst. Die unter deutscher Aufbewahrungspflicht stehen — zehn Jahre Audit-Log, WORM, eDiscovery sind bei NEXARCH keine Zusatzoption, sondern Grundhaltung. Die ihre Infrastruktur selbst verantworten wollen, nicht einem fremden Rechenzentrum vertrauen müssen. Und die als Mittelstand mit mehreren Mandanten oder Abteilungen groß genug sind, dass sich Struktur lohnt, aber klein genug, dass eine geteilte Datenbank mit sauberer Filterung reicht — nicht ein Großkonzern mit tausend Mandanten und Isolationspflicht ab Tag 1.

Kurz: wer zwei Alt-Systeme ablösen will, selbst betreiben muss, und keine Cloud-Pflicht will.