Open Enterprise Architecture – Open-Source-Werkzeug für versionierte EA-Disziplin
OEA macht die Architektur einer Organisation zur gemeinsamen, versionierten Wahrheit – für Architekten als Pflegewerkzeug, für Fachbereiche als Inventar, für Compliance als Asset-Quelle, für automatisierte Pipelines als prüfbares Artefakt.
Enterprise Architecture als versionierte, modulare und werkzeugoffene Open-Source-Disziplin – konzeptionell so rigoros wie nötig, pragmatisch so niederschwellig wie möglich.
Drei bewusste Designprinzipien prägen OEA:
- Offene, textbasierte Repräsentation statt proprietärer Formate, weil Architektur-Wissen den Hersteller überleben muss
- Progressive Disclosure statt erzwungener Modellierungs-Tiefe, weil unterschiedliche Rollen unterschiedliche Sichten brauchen
- Modulare, schnittstellen-orientierte Architektur statt Monolith, weil das Tool nicht alles selbst können muss
Mehr Details: business-analysis/vision.md
Pre-Alpha – Requirements Engineering abgeschlossen, Walking Skeleton in Vorbereitung.
| Artefakt | Anzahl |
|---|---|
| Stakeholder-Profile | 9 |
| Use Cases | 21 |
| Requirements | 155 |
| User Stories | 142 |
| ADRs | 29 |
| Business Objects | 22 |
Konzept: v0.17 · Letzter Update: 2026-06-30
Nächster Schritt: Walking Skeleton auf Basis von UC-06 (Katalog-Browser).
- Konzept: vollständig (24 Kapitel + Changelog, v0.17), siehe
concept/ - Requirements: abgeschlossen – alle 21 UCs, 142 REQs, 136 USs, 21 ADRs definiert
- Tech-Stack: entschieden (Java 21 / Vue 3 / PostgreSQL 15 / Tauri)
- Code: noch nicht begonnen
- v1.0-Release: TBD
OEA ist noch nicht produktiv einsetzbar. Wenn du mitwirken willst: CONTRIBUTING.md.
| Was | Wo |
|---|---|
| Konzeptpapier | concept/README.md |
| Vision und Stakeholder | business-analysis/ |
| Business Objects / Datenmodell | business-objects/ · docs/data-model.puml |
| Anforderungen | requirements/ |
| Architekturentscheidungen | adrs/ |
| Wireframes / Screens | docs/screens/ |
| Workflow-Beispiel | docs/workflow-example.md |
| Quick Reference | docs/quick-reference.md |
| Anti-Patterns | docs/anti-patterns.md |
| Templates | templates/ |
| Beitragen | CONTRIBUTING.md |
| Sicherheit | SECURITY.md |
9 Persona-Profile sind ausgearbeitet (siehe business-analysis/stakeholders/):
- SH-01 Franz – Junior Domain Architekt im Konzern
- SH-02 Lukas – Senior Data Architekt im Mittelstand
- SH-03 Kurt – Lead Enterprise Architekt im KMU
- SH-04 Michael – Solution Architekt im Mittelstand
- SH-05 CIO – Konzern mit gemischtem OEA-Stack
- SH-06 Max – Operator im regulierten KMU
- SH-07 Sabine – Senior Business Engineer im Globalkonzern
- SH-08 Anna – Business Analyst im Mittelstand
- SH-09 Rigobert – Produkt Owner und Repository-Inhaber
| ADR | Entscheidung | Status |
|---|---|---|
| ADR-001 | URN-Schema und Stabilitäts-Garantien | accepted |
| ADR-002 | Enterprise Continuum – Ein Repository oder zwei? | accepted |
| ADR-003 | Product vs. Project – Koexistenz oder Trennung? | accepted |
| ADR-004 | Reifikations-Details (Max-Tiefe, Adressierung, UI) | accepted |
| ADR-005 | Application-vs-Technology-Klassifikations-Prinzip (Default) | accepted |
| ADR-006 | Auth-Stack-Wahl (Identity-Provider-Integrationen) | accepted |
| ADR-007 | Canvas-Bibliothek für interaktive Diagramm-Editierung | accepted |
| ADR-008 | GUI-Architektur – Client App + Web Portal (Dual-Track-Delivery) | accepted |
| ADR-009 | Client-App-Framework – Electron vs. Tauri | accepted |
| ADR-010 | Modellierung der DataFlow↔DataObject-Beziehung (n-Connection vs. Property-String) | accepted |
| ADR-011 | Frontend-Framework – Vue 3 + TypeScript | accepted |
| ADR-012 | Backend-Stack – Java 21 + Spring Boot 3 + Hibernate | accepted |
| ADR-013 | API-Stil – REST + OpenAPI 3.x | accepted |
| ADR-014 | Frontend-Komponentenbibliothek und WYSIWYG-Editor | accepted |
| ADR-015 | Datenbank-Migrations-Tool – Flyway | accepted |
| ADR-016 | Persistenz-Strategie – PostgreSQL 15 + JSONB | accepted |
| ADR-017 | Architektur-Layer-Strategie – Fully Open in v1.0 | accepted |
| ADR-018 | Business-Rule-Engine – CEL mit GUI-Abstraktionsschicht | accepted |
| ADR-019 | Soft-Delete-Strategie für Entities und Connections | accepted |
| ADR-020 | Explorer-Browser-Navigationsmodell im Native Client | proposed |
| ADR-021 | Implizite Parent-Child-Verbindung bei Component-Verschachtelung | proposed |
| ADR-022 | Strukturiertes Property-Modell mit Kategorie, temporalem Mapping und Delta-Versionierung | accepted |
| ADR-023 | Multi-DB-Strategie — Datenbankabstraktion via JPA/Hibernate | accepted |
| ADR-024 | Audit-Datenhaltung — separates Schema, konfigurierbar als externe Datenbank | accepted |
| ADR-025 | I18N-Strategie — Zweischichtig mit ETag-Caching und SSE-Invalidierung | accepted |
| ADR-026 | Externe System-Integration — Schreibzugriff via API (optional) | accepted |
| ADR-027 | Projekt-Setup — Mono-Repo, Maven-Struktur, Package-Naming, Docker Compose | accepted |
| ADR-028 | Backend-Schichtenarchitektur — API / Application / Core | accepted |
| ADR-029 | Testframework für BDD-Systemtests — Cucumber JVM | accepted |
Wir freuen uns über Beiträge jeder Größe:
- Bug Reports: Issue mit Template Bug Report
- Feature Requests: Issue mit Template Feature Request
- Code, Doku, Konzept: Pull Request, siehe CONTRIBUTING.md
- Sicherheitslücken: Bitte NICHT öffentlich, siehe SECURITY.md
Erste Schritte: Suche nach Issues mit Label good first issue.
Drei realistische Fragen vor einem Test:
- Bist du in einer regulierten Branche? Dann lies SECURITY.md und die GRC/DSGVO/ISMS-Integration. Audit-Trail und Compliance sind Pflicht-Features, aber v1.0 wird sie erstmalig vollständig liefern.
- Migrierst du aus Sparx, Avolution, LeanIX? Migration-Adapter sind in Planung, aber pre-v1.0 noch nicht produktiv. Lies die Persona-Profile für realistische Erwartungen.
- Brauchst du Vendor-Support? OEA ist OSS ohne kommerzielle Anbietersicherung. Community-Support ist da, SLAs nicht.
OEA ist dual-lizenziert:
| Edition | Lizenz | Nutzung |
|---|---|---|
| Community | AGPL-3.0 | kostenlos, Quellcode-Offenlegungspflicht |
| Enterprise | proprietär | kostenpflichtig, keine Offenlegungspflicht |
Für Beiträge gilt das Contributor License Agreement (CLA). Copyright 2026 Lukas Mathis – siehe NOTICE.
OEA baut auf etablierten Standards auf:
- TOGAF Content Metamodel (The Open Group)
- ArchiMate (The Open Group)
- BPMN 2.0 (OMG)
- arc42 (Gernot Starke, Peter Hruschka)
- ISO 42010 (Architecture Description)
- ISO 27005 (Risk Management)
- BIAN (für Business Object Modeling)
- Konzeptionelle Fragen: GitHub Discussions
- Sicherheits-Meldungen: siehe SECURITY.md
- Verhaltenskodex-Verstöße:
conduct@oea.org(TBD)