xinionos/docs/decisions/ADR-0001-eigenes-betriebssystem.md
Thomas Reitz d9ed1bc2ff XinionOS als eigenes Erzeugnis herausgeloest
Die Geraeteschicht — Abbild, zwei Wurzeln, Selbstprueflauf, Ruecksprung —
verlaesst die Ablage der ersten Appliance und wird ein eigenes Erzeugnis
mit eigenem Takt und eigenem Nachweis.

Drei Gruende, nach Gewicht: Der Cyber Resilience Act verpflichtet fuer das
gesamte Produkt einschliesslich der Betriebssystemschicht — vier gewachsene
Basissysteme waeren vier Stuecklisten und vier Schwachstellenprozesse, eine
gemeinsame Basis ist ein Dossier. Der Ruecksprung wird nur einmal richtig
gebaut, weil er nur geprueft wird wenn ihn jemand braucht. Und eine
abgegrenzte Aufgabe laesst sich ausschreiben, was unmittelbar auf das
groesste benannte Risiko des Hauses einzahlt.

Der Einwand der Vertraeglichkeitsmatrix wird durch den Nutzlast-Vertrag
entkraeftet statt weggeredet: Die Nutzlast liegt in der Wurzel und wird mit
ihr getauscht. Eine Fassung, ein Rueckweg, keine Matrix.

Das OS kennt kein Produkt — Regel 1. Alle Namen sind entkoppelt, die
Statusseite ist auf die Standardbibliothek umgestellt, weil jede
Abhaengigkeit im Grund-OS eine Verpflichtung ueber die Produktlebensdauer
ist.

Nichts davon ist gelaufen. Der Inhalt gilt als Bauplan.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 08:02:55 +02:00

54 lines
2.7 KiB
Markdown

# ADR-0001 — Das Betriebssystem wird ein eigenes Erzeugnis
**Stand:** Angenommen, 20.08.2026 · **Entscheidet:** CIO Thomas Reitz
---
## Worum es geht
Die Geräteschicht — Abbild, zwei Wurzeln, Selbstprüflauf, Rücksprung — war Teil der ersten
Appliance, für die sie gebraucht wurde. Inzwischen ist absehbar, dass mehrere Erzeugnisse des
Hauses auf Blech beim Kunden stehen sollen: eine Fach-Appliance, eine Proxy-Appliance, die
Verkaufsvariante der Anwendungsplattform.
Diese Entscheidung trennt die Geräteschicht heraus.
## Die Entscheidung
**XinionOS ist ein eigenes Erzeugnis mit eigener Ablage, eigenem Takt und eigenem Nachweis.** Es
kennt kein Produkt; jede Fachlichkeit kommt über den Nutzlast-Vertrag.
## Warum, in der Reihenfolge des Gewichts
**Der Cyber Resilience Act.** Für mehrere Erzeugnisse des Hauses liegen bereits
CRA-Konformitätsdossiers. Die Verordnung verpflichtet den Hersteller, Schwachstellen zu behandeln
und Sicherheitsaktualisierungen zu liefern — **für das gesamte Produkt einschließlich der
Betriebssystemschicht.** Vier gewachsene Basissysteme sind vier Stücklisten, vier
Schwachstellenprozesse, vier Aktualisierungswege. Eine gemeinsame Basis ist **ein Dossier, auf das
jedes Produkt verweist.**
**Der Rücksprung wird nur einmal richtig gebaut.** Er wird ausschließlich dann geprüft, wenn ihn
jemand braucht — eine zweite handgebaute Umsetzung wäre eine zweite ungeprüfte.
**Und er lässt sich besetzen.** Eine abgegrenzte Aufgabe „Betriebssystem für Appliances" ist eine
Stelle, die man ausschreiben kann. „Jemand, der alles kann" ist keine. Das zahlt unmittelbar auf
das größte benannte Risiko des Hauses ein: die Abhängigkeit von einer einzelnen Person.
## Was dagegen sprach
**Verfrühte Verallgemeinerung.** Eine Plattform aus einem einzigen Fall abzuleiten geht meistens
schief; die richtige Abstraktion zeigt sich am zweiten. Der Einwand trägt hier nicht mehr — die
Verkaufsvariante der Anwendungsplattform ist gebaut und läuft.
**Die Verträglichkeitsmatrix.** Zwei getrennt versionierte Erzeugnisse müssen zueinander passen.
Dieser Einwand ist ernst und wird durch den Nutzlast-Vertrag entkräftet, nicht weggeredet: **Die
Nutzlast liegt in der Wurzel und wird mit ihr getauscht** — eine Fassung, ein Rückweg, keine Matrix.
## Was daraus folgt
Die Geräteschicht verlässt die Ablage der ersten Appliance. Dort bleibt ein Verweis und die
Feststellung, dass die Appliance künftig eine **Nutzlast** ist.
Der Name ist vorläufig. Sobald er auf einem Datenblatt oder in einem CRA-Dossier steht, ist er
marktgerichtet und braucht eine Markenrecherche — und ein Betriebssystem, das den Hausnamen trägt,
steht auf jedem Kundengerät. Eine spätere Umbenennung wäre entsprechend teuer.