Verbindliche Ausgangsarchitektur für September 2026

Status: Freigegebene Arbeitsgrundlage

Verbindliche Ausgangsarchitektur für September 2026

Version: 1.0

Verbindliche Ausgangsarchitektur für September 2026

Geltungsbereich: ORLENE Platform und ORLENE Footwear

Verbindliche Ausgangsarchitektur für September 2026

Primäres Ziel: Drei stabile Produktivstandorte für Peter Wagner bis September 2026

1. Zweck des Dokuments

Dieses Dokument legt die erste verbindliche Systemarchitektur der ORLENE Platform fest.

1. Zweck des Dokuments

Es beschreibt:

1. Zweck des Dokuments

- die Trennung zwischen Entwicklung und Produktivbetrieb, - die Beziehung zwischen ORLENE Platform und ORLENE Footwear, - die drei vorgesehenen Peter-Wagner-Installationen, - den grundlegenden Release- und Installationsprozess, - die standortübergreifende Erfassung der Gefundenen Zeit, - sowie die Funktionen, die bewusst erst nach September umgesetzt werden.

1. Zweck des Dokuments

Die Architektur wird später erweitert. Die vorliegende Version konzentriert sich ausschließlich auf die Voraussetzungen für einen stabilen Einsatz an drei Standorten.

2. Architektonisches Ziel

Bis September bestehen vier klar getrennte Umgebungen:

2. Architektonisches Ziel

ORLENE Platform └── ORLENE Development

2. Architektonisches Ziel

ORLENE Footwear ├── PW-WIEN ├── PW-ASTEN └── PW-MESSE-01

2. Architektonisches Ziel

Dabei gilt:

2. Architektonisches Ziel

„Entwicklung und Produktivbetrieb dürfen nicht mehr dieselbe Installation, dieselbe Datenbank oder dieselbe Konfiguration verwenden.“

2. Architektonisches Ziel

Die heutige Notebook-Version wird daher in eine Entwicklungsumgebung und eine eigenständige Produktivinstallation für Wien getrennt.

3. ORLENE Platform

Die ORLENE Platform ist die übergeordnete Entwicklungs-, Wissens-, Prüfungs- und Veröffentlichungsumgebung.

3. ORLENE Platform

Sie ist kein Kundenprodukt und keine operative Verkaufsinstallation.

3. ORLENE Platform

Ihre Aufgabe ist es, ORLENE-Produkte hervorzubringen, weiterzuentwickeln, zu prüfen und kontrolliert auszuliefern.

3.1 Bereiche der ersten Platform-Version

ORLENE Platform ├── Development Space ├── Documentation Space ├── Reading Space ├── Review Workspace ├── Build & Release ├── Installationsverwaltung └── Gefundene Zeit

3.1 Bereiche der ersten Platform-Version

Weitere Spaces und Verwaltungsbereiche können später ergänzt werden.

3.2 Development Space

Im Development Space findet die technische Entwicklung statt.

3.2 Development Space

Dazu gehören:

3.2 Development Space

- Quellcode, - Entwicklungsdaten, - technische Tests, - Prototypen, - experimentelle Funktionen, - Fehleranalyse, - Build-Vorbereitung.

3.2 Development Space

Der Development Space darf nicht für operative Verkäufe, Reservierungen oder echte Produktivvorgänge verwendet werden.

3.3 Documentation Space

Der Documentation Space gehört zur ORLENE Platform.

3.3 Documentation Space

Er bewahrt unter anderem:

3.3 Documentation Space

- Systemarchitektur, - Founding Domains, - Entwicklerbuch, - Funktionsdokumentationen, - Prozessbeschreibungen, - Entscheidungen, - Release-Dokumentationen, - Installationsanleitungen, - spätere Kundendokumentationen.

3.3 Documentation Space

Der Documentation Space ist nicht ausschließlich ORLENE Footwear zugeordnet. Er kann später auch weitere ORLENE-Produkte dokumentieren.

3.4 Reading Space und Review Workspace

Der Reading Space dient der strukturierten Prüfung und dem Lesen von Dokumenten.

3.4 Reading Space und Review Workspace

Der Review Workspace dient der gemeinsamen Prüfung von:

3.4 Reading Space und Review Workspace

- Ideen, - Änderungsvorschlägen, - Dokumenten, - Architekturentscheidungen, - geplanten Funktionen, - später auch Releases und Entwicklungsständen.

3.4 Reading Space und Review Workspace

Prüfung und Umsetzung bleiben getrennte Schritte.

4. ORLENE Footwear

ORLENE Footwear ist das erste operative Produkt der ORLENE Platform.

4. ORLENE Footwear

Es umfasst den vollständigen aktuellen Funktionsstand der Peter-Wagner-Anwendung.

4. ORLENE Footwear

Dazu können unter anderem gehören:

4. ORLENE Footwear

- Artikelsuche, - Etikettendruck, - Preisverwaltung, - Verkauf, - Reservierung, - Lager- und Standortfunktionen, - Scannerfunktionen, - Sortimentplanung, - Inventur, - Berichte, - weitere bereits vorhandene Funktionen.

4. ORLENE Footwear

Bis September findet keine lizenzabhängige Modultrennung statt.

4. ORLENE Footwear

Peter Wagner erhält als Referenzkunde an allen drei Standorten den vollständigen verfügbaren Funktionsumfang.

5. Produktivinstallationen

Bis September werden drei eigenständige Produktivinstallationen eingerichtet.

5.1 PW-WIEN

Produkt: ORLENE Footwear

5.1 PW-WIEN

Organisation: Peter Wagner

5.1 PW-WIEN

Installation-ID: PW-WIEN

5.1 PW-WIEN

Standort: Wien

5.1 PW-WIEN

Umgebung: production

5.1 PW-WIEN

Updatekanal: stable

5.1 PW-WIEN

PW-WIEN ist die zukünftige Produktivinstallation auf dem derzeit verwendeten Notebook beziehungsweise dem für Wien vorgesehenen Gerät.

5.1 PW-WIEN

Die heutige Entwicklungsinstallation darf nicht einfach in PW-WIEN umbenannt werden. Produktivdaten und Entwicklung müssen sauber getrennt werden.

5.2 PW-ASTEN

Produkt: ORLENE Footwear

5.2 PW-ASTEN

Organisation: Peter Wagner

5.2 PW-ASTEN

Installation-ID: PW-ASTEN

5.2 PW-ASTEN

Standort: Zentrale Asten

5.2 PW-ASTEN

Umgebung: production

5.2 PW-ASTEN

Updatekanal: stable

5.2 PW-ASTEN

PW-ASTEN wird als eigenständige Installation eingerichtet und erhält eine eigene Datenbank, Konfiguration und Protokollierung.

5.3 PW-MESSE-01

Produkt: ORLENE Footwear

5.3 PW-MESSE-01

Organisation: Peter Wagner

5.3 PW-MESSE-01

Installation-ID: PW-MESSE-01

5.3 PW-MESSE-01

Standort: Messe unterwegs

5.3 PW-MESSE-01

Umgebung: production

5.3 PW-MESSE-01

Updatekanal: stable

5.3 PW-MESSE-01

PW-MESSE-01 muss vollständig offline funktionsfähig bleiben.

5.3 PW-MESSE-01

Internetverbindungen dürfen für den operativen Messebetrieb keine zwingende Voraussetzung sein.

6. Gemeinsamer Programmstand

Die drei Standorte erhalten grundsätzlich denselben freigegebenen Softwarestand.

6. Gemeinsamer Programmstand

Nicht vorgesehen sind getrennte Quellcodes wie:

6. Gemeinsamer Programmstand

- orlene_wien - orlene_asten - orlene_messe

6. Gemeinsamer Programmstand

Stattdessen gilt:

6. Gemeinsamer Programmstand

eine Entwicklungsquelle ↓ ein freigegebener Build ↓ drei getrennte Installationen

6. Gemeinsamer Programmstand

Die Installationen unterscheiden sich durch:

6. Gemeinsamer Programmstand

- Installation-ID, - Standort, - Daten, - Konfiguration, - lokale Hardware, - lokale Drucker- und Scannerkonfiguration.

6. Gemeinsamer Programmstand

Sie unterscheiden sich nicht durch manuell veränderten Quellcode.

7. Installationsprofil

Jede Installation erhält eine eigene Profildatei.

7. Installationsprofil

Für die erste Version reicht folgende Struktur:

7. Installationsprofil

```json { "profile_version": 1, "product": "ORLENE Footwear", "organisation_id": "PETER_WAGNER", "installation_id": "PW-WIEN", "location_name": "Wien", "environment": "production", "update_channel": "stable", "offline_capable": true, "all_features_enabled": true, "license_mode": "reference_customer_full" } ```

7. Installationsprofil

Für Asten und Messe werden entsprechende Profile mit eigenen IDs und Standortbezeichnungen erstellt.

7. Installationsprofil

Das Installationsprofil darf keine Passwörter oder sonstigen geheimen Zugangsdaten enthalten.

8.1 Verbindliche Regel

„Es wird niemals direkt in einer Produktivinstallation entwickelt.“

8.1 Verbindliche Regel

Das betrifft:

8.1 Verbindliche Regel

- PW-WIEN, - PW-ASTEN, - PW-MESSE-01, - alle späteren Kundeninstallationen.

8.2 Getrennte Datenbereiche

Mindestens folgende Bereiche müssen getrennt werden:

8.2 Getrennte Datenbereiche

Development ├── eigene Datenbank ├── eigene Konfiguration ├── eigene Logs ├── eigene Backups └── eigener Port

8.2 Getrennte Datenbereiche

PW-WIEN ├── eigene Datenbank ├── eigene Konfiguration ├── eigene Logs ├── eigene Backups └── eigener Port

8.2 Getrennte Datenbereiche

Development und PW-WIEN dürfen keine gemeinsame Datenbank verwenden.

8.3 Visuelle Kennzeichnung

Die Entwicklungsumgebung muss dauerhaft klar gekennzeichnet sein:

8.3 Visuelle Kennzeichnung

ORLENE DEVELOPMENT Nicht für Produktivbetrieb

8.3 Visuelle Kennzeichnung

Produktivinstallationen zeigen dagegen:

8.3 Visuelle Kennzeichnung

ORLENE Footwear Standort: Wien Version: 0.9.x

8.3 Visuelle Kennzeichnung

Dadurch soll eine versehentliche Nutzung der falschen Umgebung verhindert werden.

9. Releaseprozess

Jede Produktivänderung durchläuft künftig folgenden Ablauf:

9. Releaseprozess

Entwicklung ↓ technische Prüfung ↓ Funktionsprüfung ↓ Release erstellen ↓ Backup der Produktivinstallation ↓ Update installieren ↓ Funktionstest ↓ Freigabe

9. Releaseprozess

Produktivinstallationen erhalten ausschließlich freigegebene Releases.

9.1 Versionierung

Für ORLENE Footwear wird eine nachvollziehbare Versionierung verwendet:

9.1 Versionierung

- 0.9.0 - 0.9.1 - 0.10.0 - 1.0.0

9.1 Versionierung

Jede Installation muss ihre aktive Version sichtbar anzeigen.

9.2 Releases müssen nachvollziehbar sein

Jedes Release erhält mindestens:

9.2 Releases müssen nachvollziehbar sein

- Versionsnummer, - Erstellungsdatum, - Änderungsübersicht, - Datenbankänderungen, - bekannte Einschränkungen, - Freigabestatus, - Sicherungsinformation.

10.1 Grundverständnis

ORLENE misst nicht lediglich eingesparte Arbeitszeit.

10.1 Grundverständnis

ORLENE macht sichtbar, wie viel zuvor durch Suchen, Wiederholungen, Wartezeiten, Medienbrüche oder unnötige Arbeit gebundene Zeit wieder verfügbar wurde.

10.1 Grundverständnis

Diese Kennzahl heißt verbindlich:

10.1 Grundverständnis

Gefundene Zeit

10.2 Grundsatz

„Gefundene Zeit ist kein Leistungsindikator für Menschen. Sie ist ein Qualitätsindikator für Prozesse.“

10.2 Grundsatz

Die Messung darf nicht dazu verwendet werden:

10.2 Grundsatz

- Mitarbeiter zu überwachen, - Menschen miteinander zu vergleichen, - individuellen Leistungsdruck aufzubauen, - vermeintlich langsame Benutzer zu bewerten.

10.2 Grundsatz

Sie dient dazu:

10.2 Grundsatz

- den Nutzen von ORLENE sichtbar zu machen, - verbesserte Prozesse zu erkennen, - Entwicklungsschwerpunkte zu bestimmen, - den Nutzen gegenüber Kunden und Förderstellen nachvollziehbar zu belegen.

10.3 Standortübergreifende Erfassung

Jede Produktivinstallation muss Gefundene Zeit mit ihrer Installation-ID erfassen.

10.3 Standortübergreifende Erfassung

Beispiel:

10.3 Standortübergreifende Erfassung

```json { "event_type": "FOUND_TIME_RECORDED", "product": "ORLENE Footwear", "organisation_id": "PETER_WAGNER", "installation_id": "PW-WIEN", "function_id": "LABEL_PRINTING", "saved_seconds": 80, "created_at": "2026-07-26T18:00:00+02:00" } ```

10.4 Ermittlung

Für jeden geeigneten Vorgang wird eine nachvollziehbare Referenz definiert.

10.4 Ermittlung

Beispiel Etikettendruck:

10.4 Ermittlung

Früherer Ablauf: 90 Sekunden

10.4 Ermittlung

ORLENE-Ablauf: 10 Sekunden

10.4 Ermittlung

Gefundene Zeit: 80 Sekunden

10.4 Ermittlung

Nach jedem erfolgreich abgeschlossenen Vorgang werden 80 Sekunden Gefundene Zeit erfasst.

10.4 Ermittlung

Die Referenzwerte müssen dokumentiert und später veränderbar sein.

10.5 Auswertung

Die Gefundene Zeit soll mindestens ausgewertet werden können nach:

10.5 Auswertung

- gesamter ORLENE Platform, - Produkt, - Organisation, - Installation, - Standort, - Funktion, - Zeitraum.

10.6 Offline-Erfassung

PW-MESSE-01 muss Gefundene Zeit auch ohne Internet erfassen können.

10.6 Offline-Erfassung

Die Messwerte werden lokal gespeichert und später synchronisiert, sobald eine Verbindung verfügbar ist.

10.6 Offline-Erfassung

Ein bereits übertragener Vorgang darf nicht doppelt gezählt werden. Deshalb benötigt jeder Eintrag eine eindeutige Ereignis-ID.

11. Datensouveränität der Standorte

Jede Produktivinstallation besitzt eine eigene lokale Datenbasis.

11. Datensouveränität der Standorte

Für September ist keine dauerhaft gemeinsame zentrale Datenbank erforderlich.

11. Datensouveränität der Standorte

PW-WIEN └── eigene lokale Datenbank

11. Datensouveränität der Standorte

PW-ASTEN └── eigene lokale Datenbank

11. Datensouveränität der Standorte

PW-MESSE-01 └── eigene lokale Datenbank

11. Datensouveränität der Standorte

Spätere Synchronisationen erfolgen kontrolliert über eindeutige Ereignisse und definierte Datenflüsse, nicht durch unkontrolliertes Überschreiben kompletter Datenbanken.

12. Zentrale Entwicklungsumgebung

Die Entwicklungsumgebung soll später online und geräteunabhängig erreichbar sein.

12. Zentrale Entwicklungsumgebung

Der Entwickler soll künftig von folgenden Geräten auf denselben Entwicklungsstand zugreifen können:

12. Zentrale Entwicklungsumgebung

- PC zu Hause, - privates Notebook, - Firmennotebook, - weitere freigegebene Geräte.

12. Zentrale Entwicklungsumgebung

Die zentrale Entwicklungsumgebung wird später auf einem gesicherten Server eingerichtet.

12. Zentrale Entwicklungsumgebung

Der Serveraufbau ist jedoch nicht Bestandteil der ersten lokalen Trennung. Zuerst wird die vorhandene Anwendung strukturell getrennt und stabilisiert.

13. Nicht Bestandteil der September-Version

Folgende Funktionen werden bewusst verschoben:

13. Nicht Bestandteil der September-Version

- vollständiges Modulsystem, - lizenzabhängige Funktionsauswahl, - Abonnementverwaltung, - Kunden-Selbstinstallation, - selektiver Moduldownload, - Plugin- oder Marketplace-System, - allgemeiner Installer für beliebige Kunden, - vollständig automatisierte Cloud-Auslieferung, - öffentliche Online-Version von ORLENE Footwear.

13. Nicht Bestandteil der September-Version

Diese Bereiche werden später auf Grundlage der stabilen September-Architektur geplant.

14. Vorbereitung für die spätere Modularchitektur

Obwohl bis September alle Funktionen vollständig installiert werden, erhält das Installationsprofil bereits:

14. Vorbereitung für die spätere Modularchitektur

```json { "all_features_enabled": true, "license_mode": "reference_customer_full" } ```

14. Vorbereitung für die spätere Modularchitektur

Zusätzlich kann eine zentrale Funktionsprüfung vorbereitet werden:

14. Vorbereitung für die spätere Modularchitektur

```python def feature_enabled(feature_name: str) -> bool: return True ```

14. Vorbereitung für die spätere Modularchitektur

Für Peter Wagner sind damit alle Funktionen aktiv.

14. Vorbereitung für die spätere Modularchitektur

Später kann diese zentrale Prüfung durch echte Lizenz- und Modulregeln ersetzt werden, ohne sämtliche Programmteile neu strukturieren zu müssen.

15. Sicherheits- und Stabilitätsgrundsätze

Für alle Produktivinstallationen gelten folgende Mindestregeln:

15. Sicherheits- und Stabilitätsgrundsätze

- Debug-Modus ist deaktiviert. - Produktivdaten werden vor jedem Update gesichert. - Updates dürfen bestehende Daten nicht unkontrolliert überschreiben. - Fehler einer Installation dürfen andere Standorte nicht blockieren. - PW-MESSE-01 bleibt offline arbeitsfähig. - Installationsidentitäten dürfen nicht doppelt vergeben werden. - Entwicklung verwendet niemals direkt die Produktivdatenbank. - Jeder produktive Build ist versioniert. - Jede Installation besitzt eigene Logs und Backups.

Development

- Eine getrennte Entwicklungsumgebung besteht. - Sie besitzt eine eigene Datenbank und Konfiguration. - Sie ist sichtbar als Development gekennzeichnet.

PW-WIEN

- Eine eigenständige Produktivinstallation besteht. - Die bisherigen produktiven Daten wurden übernommen. - Etikettendruck, Artikelsuche und bestehende Kernfunktionen funktionieren.

PW-ASTEN

- Eine eigenständige Installation wurde eingerichtet. - Drucker und vorgesehene Arbeitsabläufe wurden getestet. - Die Installation arbeitet unabhängig von PW-WIEN.

PW-MESSE-01

- Die Installation startet vollständig offline. - Die operativen Messefunktionen sind offline nutzbar. - Lokale Vorgänge werden zuverlässig gespeichert.

Releases

- Ein freigegebener Build kann reproduzierbar auf allen drei Installationen eingesetzt werden. - Die aktive Version ist sichtbar. - Vor Updates werden automatisch oder kontrolliert Backups erstellt.

Gefundene Zeit

- Jeder Standort verwendet seine eigene Installation-ID. - Geeignete Vorgänge erfassen Gefundene Zeit. - Offline-Ereignisse können später ohne Doppelzählung zusammengeführt werden. - Eine Gesamtauswertung für alle drei Standorte ist möglich.

17. Verbindliche Architekturgrundsätze

1. ORLENE Platform und ORLENE Footwear sind unterschiedliche Ebenen.

17. Verbindliche Architekturgrundsätze

2. ORLENE Platform entwickelt und veröffentlicht Produkte. ORLENE Footwear wird operativ eingesetzt.

17. Verbindliche Architekturgrundsätze

3. Es wird niemals direkt in einer Produktivinstallation entwickelt.

17. Verbindliche Architekturgrundsätze

4. Alle Standorte verwenden denselben freigegebenen Programmstand und unterscheiden sich durch Identität, Daten und Konfiguration.

17. Verbindliche Architekturgrundsätze

5. Produktivinstallationen müssen auch bei fehlender Internetverbindung arbeitsfähig bleiben, sofern ihr Einsatz dies erfordert.

17. Verbindliche Architekturgrundsätze

6. Gefundene Zeit bewertet Prozesse, nicht Menschen.

17. Verbindliche Architekturgrundsätze

7. Für September hat ein stabiler Referenzbetrieb an drei Standorten Vorrang vor einer vollständigen Modul- und Lizenzarchitektur.

17. Verbindliche Architekturgrundsätze

8. Die ORLENE Platform ist die erste Anwendung ihrer eigenen Arbeits-, Wissens-, Dokumentations- und Review-Prinzipien.

18. Ergebnis der Systemarchitektur 1.0

Mit dieser Architektur ist verbindlich festgelegt:

18. Ergebnis der Systemarchitektur 1.0

ORLENE Platform └── zentrale Entwicklung, Dokumentation, Prüfung und Veröffentlichung

18. Ergebnis der Systemarchitektur 1.0

ORLENE Footwear ├── PW-WIEN ├── PW-ASTEN └── PW-MESSE-01

18. Ergebnis der Systemarchitektur 1.0

Bis September entsteht eine vollständige ORLENE-Footwear-Version für Peter Wagner, die an drei voneinander getrennten Standorten eingesetzt wird.

18. Ergebnis der Systemarchitektur 1.0

Alle drei Standorte:

18. Ergebnis der Systemarchitektur 1.0

- erhalten denselben freigegebenen Build, - besitzen eigene Daten und Installationsprofile, - erfassen ihre Gefundene Zeit, - können später kontrolliert aktualisiert und synchronisiert werden.