ePPM Nexus — Softwarearchitekturkonzept (Arc42)

1

Einführung und fachliche Ziele

Problemstellung, Geschäftskontext und Qualitätsanforderungen

In Konzernumgebungen und Großunternehmen erfordert die Führung hunderter zeitgleicher Großvorhaben eine lückenlose Governance bei minimalem bürokratischem Mehraufwand für die Projektleiter. Herkömmliche Enterprise-Tools scheitern oft an überladener Komplexität, langen Latenzzeiten und unklaren Phasenübergängen.

ePPM Nexus standardisiert das Multiprojektmanagement durch eine intuitive, hochperformante Web-Plattform mit drei klaren Phasen und verbindlichen Meilensteinen:

PHASE 1

PreSales (G0 & G1)

Projektinitiierung (G0) und formale Angebotseinreichung / Submittal (G1). Steuerung von Auftragswert (TCV) und Presales-Investitionen.

PHASE 2

PostSales (G2 bis G6)

Vertragsabschluss (G2) leitet die Umsetzungsphase ein. Architektur (G3), Rollout (G4), Fertigstellung (G5) bis zur Endabnahme (G6).

PHASE 3

Closed (Archiviert)

Vollständige Betriebsübergabe an Operations / Service Management, Gewährleistungsphase und Lessons-Learned-Archivierung.

Kern-Qualitätsziele (ISO/IEC 25010)

Qualitätsziel	Architektonische Maßnahme	Messbares Kriterium
Datenschutz & DSGVO	100% On-Premise Ausführung ohne externe Web-APIs oder Cloud-LLM-Pipelines.	0 Byte externer Datenabfluss
Verlässlichkeit (0% Halluzination)	Deterministische regelbasierte Inferenz-Engine für wöchentliche Statusberichte.	100% faktenbasiert & auditierbar
Echtzeit-Performance	Kompakter Async-ASGI-Stack (FastAPI) und DOM-Caching ohne schwere Virtual-DOM-Layers.	Latenz < 50 ms
Revisionssicherheit	Automatisierte Gate-Kaskadierung und unveränderbare Wochenbericht-Archive.	Lückenloser Nachweis

2

Randbedingungen & rechtliche Vorgaben

Betriebsratskonformität, DSGVO und Infrastrukturvorgaben

gavel Betriebsrat & Mitarbeiterdatenschutz

In Konzernen unterliegt die Leistungskontrolle von Einzelpersonen strikten Mitbestimmungsrechten (§ 87 Abs. 1 Nr. 6 BetrVG). Das Ressourcenmodul in ePPM Nexus erfasst daher ausschließlich rollenbasierte FTE-Kontingente (z. B. "50% FTE Rolle Lead Architect in Periode 2026-Q4") ohne minutengenaue Zeiterfassung oder personenbezogene Überwachung.

security Air-Gapped & Offline Tauglichkeit

Das gesamte System läuft vollständig isoliert in abgeschirmten Sicherheitsnetzwerken (Air-Gapped DMZ). Es werden zu keinem Zeitpunkt externe Bibliotheken, Schriften oder Cloud-APIs aus dem öffentlichen Internet nachgeladen.

3

Kontextabgrenzung & Schnittstellen

Einbettung in die bestehende IT- und Unternehmenslandschaft

Das folgende Diagramm visualisiert die Systemgrenze von ePPM Nexus und die Kommunikationskanäle zu Anwendern, Controlling-Tools und Konzernsystemen:

REST API (JSON) Volle CRUD-Endpunkte für Vorhaben, Meilensteine, Risiken, Tasks und Wochenberichte.

Excel-Austausch (XLSX) Import & Export mit intelligenter Schema-Erkennung für Controlling und PMO-Reporting.

1-Pager Druckberichte CSS Paged Media für pixelgenaue PDF-Exporte von Einzel-PSR und Gesamtwochenberichten.

4

Lösungsstrategie & Architekturentscheidungen (ADR)

Verbindliche Architecture Decision Records mit Begründung und Konsequenzen

ADR-01: Wahl von FastAPI als ASGI Core Akzeptiert

Kontext: Das Backend benötigt höchste Lese- und Schreib-Performance bei minimalem Speicherbedarf und automatischer Validierung aller Eingabeparameter.
Entscheidung: Einsatz von FastAPI auf Basis von Starlette und Pydantic anstelle schwergewichtiger Frameworks (Django, Java Spring Boot).
Konsequenz: Durchsatz von $> 10.000$ Requests/Sekunde, automatische interaktive OpenAPI-Dokumentation (`/docs`), geringster Speicherbedarf ($< 60\,\text{MB}$).

ADR-02: SQLite WAL Mode mit ORM-Abstraktion (Postgres-Ready) Akzeptiert

Kontext: Das System soll ohne aufwendige Datenbank-Cluster auf Einzelsystemen und in Containern laufen, aber bei Bedarf nahtlos auf Enterprise-PostgreSQL umschaltbar sein.
Entscheidung: Verwendung von SQLite mit aktiviertem Write-Ahead-Logging (`PRAGMA journal_mode=WAL`), vollständig gekapselt über SQLAlchemy ORM.
Konsequenz: Null Konfigurationsaufwand für lokale Instanzen; paralleles Lesen ohne Schreibblockaden. Die Umschaltung auf PostgreSQL erfordert ausschließlich das Ändern der `DATABASE_URL`.

ADR-03: Reactive Vanilla ES6+ Single Page Architecture (Zero Node-Runtime) Akzeptiert

Kontext: Node.js-Buildketten (Webpack, Vite) führen in Konzern-Pipelines häufig zu Sicherheitswarnungen (CVEs in Unter-Abhängigkeiten) und Wartungsbrüchen.
Entscheidung: Das Frontend wird als native ES6+ Single-Page Application ohne vorgelagerten Node.js-Buildprozess implementiert.
Konsequenz: Ladezeiten im Millisekundenbereich, null Build-Abhängigkeiten, extreme Langzeitstabilität über viele Jahre hinweg.

ADR-04: Deterministische Heuristik-KI statt stochastischer Cloud-LLMs Akzeptiert

Kontext: Externe Cloud-LLMs bergen das Risiko von Halluzinationen (erfundene Meilensteine), Datenschutzrisiken (Übertragung von Finanzzahlen) und hohe API-Kosten.
Entscheidung: Für wöchentliche Statusberichte und KPI-Synthesen kommt ein regelbasiertes deterministisches Expertensystem zum Einsatz.
Konsequenz: 100% verlässliche Zahlen, 0 € laufende Kosten, Antwortzeit < 10 ms, volle Revisionssicherheit für Wirtschaftsprüfer.

ADR-05: RBAC mit Header-basierter Trust-Integration (SSO-Ready) Akzeptiert

Kontext: Die Authentifizierung muss nahtlos mit Enterprise-IAM-Systemen (Azure AD, Keycloak, OAuth2-Proxy) harmonieren, ohne die Anwendungslogik an einen spezifischen Provider zu koppeln.
Entscheidung: Autorisierung erfolgt über standardisierte HTTP-Header (X-User-Role, X-Project-Manager), die vom Reverse Proxy vertrauensvoll injiziert werden.
Konsequenz: Perfekte Entkopplung von IdP und Fachlogik; rollenbasierte Datenfilterung (PL sieht nur eigene Projekte, PMO hat Vollzugriff) direkt im Backend.

ADR-06: Deterministische Zero-Cloud Übersetzungs-Engine (Option A) Akzeptiert

Kontext: Großunternehmen verlangen simultane Zweisprachigkeit (DE/EN) für internationale Steuerungsgremien. Cloud-Übersetzer (DeepL, Google Translate) verletzen DSGVO und Vertraulichkeitsauflagen für vertrauliche Projektdaten.
Entscheidung: Realisierung einer internen, lexikonbasierten Übersetzungs-Engine (app/translator.py) mit bidirektionaler Phrasen- und Begriffs-Transformation.
Konsequenz: 100% Offline-Fähigkeit, Ausführung in < 1 ms im Hauptspeicher, 0 € Schnittstellenkosten, absolut null Datenabfluss nach extern.

5

Bausteinsicht (Building Block View)

Hierarchische Zerlegung des Systems in Schichten und Module

hub Gesamtarchitektur-Blueprint: ePPM Nexus (Alle Schichten & Features)

Arc42 V2.5 High-Resolution

Schichtenarchitektur & Modulstruktur

1. Präsentationsschicht (Client SPA): State Container • Table Filter & Sort • Modal Bus • Gate Timeline

Browser

2. API- & Routing-Schicht: FastAPI Endpoints • Pydantic DTOs • Template Rendering • Auth Middleware

ASGI

3. Fach- & Domänenlogik: GateSequencer • Heuristic AI Engine • Excel Helper • RBAC Enforcement

Domain

4. Persistenz & Datenhaltung: SQLAlchemy ORM Models • SQLite WAL / PostgreSQL Connection Pool

Data

Kernkomponenten im Codebase

app/main.py

Zentraler App-Router, Dependency Injection für DB-Sessions, REST-Endpunkte, Gate-Kaskadierungslogik und Druckvorlagen.

app/models.py & schemas.py

Relationales Datenmodell (6 Tabellen) und strikte Pydantic Validierungsschemas für Ein- und Ausgaben mit dynamischer Übersetzung.

app/translator.py

Deterministische Zero-Cloud Translation Engine mit bidirektionalem Fachlexikon für Phasen, Gates, Risiken, Changes und PSR-Berichte.

app/excel_helper.py

Hochrobuste Im- und Export-Pipeline mit Zellstilen, Zahlenformatierungen, Excel-Vorlagen und Spalten-Alias-Normalisierung.

app/templates/index.html

Reaktive Single-Page Application mit zweisprachiger DE/EN Engine, responsivem Mobile Header, Spaltenfiltern und Cockpit-Tabs.

app/templates/*_print.html

Druckoptimierte CSS Paged Media Templates (1-Pager PSR und Portfolio-Wochenbericht) mit bilingualer Textsynthese.

6

Laufzeitsicht (Runtime Scenarios)

Dynamisches Verhalten bei zentralen Anwendungsfällen

A Ablauf: EDRA Gate-Integrität & automatische Kaskadierung (G0 → G6)

Ein zentrales Architekturmerkmal ist die strikte chronologische Sequenzlogik (G0 → G6). Wenn ein Anwender beispielsweise Gate 3 (Solution Design) als erreicht markiert, prüft das System serverseitig in enforce_gate_sequence_and_phases() den Status der Vorgänger und synchronisiert die Phase:

// Auszug aus enforce_gate_sequence_and_phases() in app/main.py

if p.g3_actual_date:

if not p.g0_actual_date: p.g0_actual_date = p.g3_actual_date # Auto-Fill Vorgänger

if not p.g1_actual_date: p.g1_actual_date = p.g3_actual_date

if not p.g2_actual_date: p.g2_actual_date = p.g3_actual_date

p.project_phase = "PostSales" # G2..G5 garantiert PostSales (Umsetzung)

Wird hingegen ein Gate geleert (z. B. G2 auf offen zurückgesetzt), werden alle nachfolgenden Gates (G3 bis G6) atomar zurückgesetzt und die Phase auf PreSales de-eskaliert. Dadurch ist ein inkonsistenter Datenbestand mathematisch ausgeschlossen.

B Ablauf: Zero-Cloud Bilingual Translation Engine (Option A)

Die Übersetzung erfolgt vollständig deterministisch und im Hauptspeicher ohne Latenz oder Cloud-APIs:

// Auszug aus translate_project_dict() in app/translator.py

def translate_project_dict(p: dict, target_lang: str = "en") -> dict:

res = dict(p)

res["project_phase_display"] = translate_text(p.get("project_phase"), target_lang)

# Übersetze Gates, Status, Risiken, Changes & Reports

return res # Bereit für JSON-Streaming in < 0.5 ms

C Ablauf: Mehrstufiger Change Request Genehmigungsworkflow

Änderungen an Budget, Terminplan oder Scope durchlaufen eine Schwellenwert-basierte Freigabekaskade:

Stufe 1 (Operativ): Budget-Auswirkung ≤ 50.000 € und Terminverschiebung ≤ 4 Wochen erfordern die Freigabe durch das PMO.
Stufe 2 (Executive): Größere Änderungen (> 50.000 € oder > 4 Wochen) eskalieren automatisch an das Executive Board / Steering Committee zur finalen Freigabe.

7

Verteilungssicht & Deployment

Containerisierung, Reverse Proxy und Hochverfügbarkeit

ePPM Nexus wird als leichtgewichtiger OCI-Container (Docker / Podman) bereitgestellt:

view_in_ar Docker / Podman Container

Unprivilegierter Container auf Python:3.11-slim Basis mit persistent gemountetem Volume für die Datenbankdatei.

alt_route Reverse Proxy / TLS

Nginx, Envoy oder Corporate F5 Load Balancer mit TLS 1.3 Terminierung und automatischer Header-Injektion.

backup Zero-Downtime Backup

Dank SQLite WAL-Modus kann die Datenbank im laufenden Betrieb ohne Locking als konsistente Datei gesichert werden.

8

Querschnittliche Konzepte & Security

Rollen, Sicherheit, Theme Engine und Accessibility

Rollen- und Berechtigungskonzept (RBAC Matrix)

Rolle	Projekte anlegen / löschen	Gates & Status pflegen	Wöchentlicher PSR	Change Requests	Ressourcen & FTE
PMO (Governance)	Vollzugriff	Vollzugriff	Vollzugriff	Freigabe Stufe 1 & 2	Vollzugriff
Projektleiter (PL)	–	Eigene Vorhaben	Eigene Vorhaben	Nur Beantragen	–
Executive / Board	Nur Lesen	Nur Lesen	Nur Lesen	Freigabe Stufe 2	Nur Lesen
Ressourcen-Manager	–	Nur Lesen	Nur Lesen	–	Vollzugriff (BR-konform)

9

Architektur-Bewertung & Zukunftsfähigkeit

Risikoanalyse und strategische Integrations-Roadmap

Geplante Meilensteine der Integrations-Roadmap

Phase 1 (Abgeschlossen)

FastAPI Core, Reactive SPA, EDRA Gate Systematik, Deterministisches KI-Expertensystem, Excel-Engine.

Phase 2 (In Vorbereitung)

PostgreSQL / MSSQL Cluster-Treiber, OIDC / SAML2 Single-Sign-On Adapter für Azure Active Directory.

Phase 3 (Ökosystem)

SAP FI/CO Budget-Synchronisation, Jira / Azure DevOps Konnektoren und Microsoft Teams Webhook-Dispatcher.

ePPM Nexus Architecture Arc42 V2.5

Softwarearchitekturkonzept: ePPM Nexus