Seed vs Node Operating Model

Klare Antwort auf die Kernfrage: Ja, IIO ist der Seed/Template-Kern. Tenant-Projekte wie Intelego sind Nodes und tragen das projektspezifische Betriebswissen.

1. Kurzantwort (entscheidend)

Frage	Antwort
Soll IIO template-basiert sein?	Ja. IIO ist Seed/Referenztemplate fuer alle Nodes.
Soll der Tenant (z. B. Intelego) das projektspezifische enthalten?	Ja. Node enthaelt lokale Struktur, Teams, Kundenbetrieb, lokale Konfiguration.
Soll man IIO jedes Mal neu generieren?	Nein. Normalerweise werden neue Nodes/Clients aus dem Seed projiziert.

IIO = Seed Intelego = Node Node-spezifisches nicht in Seed kippen

1.1 Wording-Regel: IT/CS-Fachsprache zuerst, IIO als Mapping

Ja, fuer Schulung und Einfuehrung ist diese Regel sinnvoll: primaer standardisierte Informatik- und IT-Begriffe (z. B. Tenant, Instanz, Betriebsplattform), dazu IIO-Mapping in Klammern (Node, Seed, Projection). Team- und Business-Sprache wird anschliessend als Uebersetzungsstil aus diesen Kernbegriffen abgeleitet.

IT/CS-Fachbegriff (bevorzugt)	IIO-Begriff	Verwendung im Manual
Referenztemplate / Kernmodell	Seed	Architektur- und Governance-Kapitel
Tenant-Instanz / Kundeninstanz	Node (tenant)	Betrieb, Delivery, Kundensteuerung
Ableitung / Initialisierung	Projection	Einfuehrungs- und Migrationspfad
Betriebsfreigabe	GO/NO-GO Gate	Review-, Release- und Audit-Kapitel

Lesbar fuer Fachseite Eindeutig fuer Architekturseite Keine ungemappten Spezialbegriffe

2. Architekturformel

Node = Seed + local_context + classification_map + configuration

Damit ist die Trennung sauber: Seed liefert universelle Regeln und Rails, Node liefert konkrete Ausfuehrung.

3. Was gehoert wohin?

Inhalt	Seed (iio)	Node/Tenant (z. B. intelego)
Governance-Prinzipien, Premises, Gates	Ja	Nur Anwendung/Konfiguration
Layer-Modelle und Referenzmethoden	Ja	Nein
Kundenspezifische Prozesse und Teamstruktur	Nein	Ja
Kundenobjekte, Projekte, lokale Runbooks	Nein	Ja
Universell wiederverwendbare Verbesserung aus Betrieb	Ja (nach Review)	Quelle aus Node

Schreibregel: In operativen Handbuechern zuerst IT/CS-Fachbegriff nutzen, danach einmalig das IIO-Mapping nennen, z. B. "Tenant-Instanz (Node)". Fuer Management/Fachseite koennen darauf aufbauend Stilvarianten eingesetzt werden.

4. Generierungsstrategie bei mehreren Clients

Wenn weitere Clients dazukommen, erzeugt ihr pro Client eine eigene Node aus dem Seed. Das Seed bleibt zentral, Nodes werden vervielfaeltigt.

clients/
  intelego/      # Node A
  client-b/      # Node B
  client-c/      # Node C

seed/
  iio/           # zentrales Referenztemplate

Operation	Empfehlung
Neuen Client starten	Neue Node aus Seed projizieren
Seed verbessern	Kleine reviewbare Aenderung im Seed, danach kontrolliert in Nodes uebernehmen
Kundenspezifische Ausnahme	In Node halten, nicht im Seed verallgemeinern

5. Was soll man generieren?

Fall	Generieren	Nicht generieren
Neuer Kunde / neuer Tenant	Node/Client-Projekt	Kein neues Seed
Neue universelle Governance-Regel	Seed-Aenderung (nach Gate)	Kein ad-hoc Patch in allen Nodes
Lokaler Kundenprozess	Nur Node-Inhalt	Nicht in Seed verankern

6. Betriebsregel fuer eure Zukunft

Mit mehreren Clients gilt immer dieselbe Reihenfolge:

Neuen Client als neue Node aufsetzen.
Node lokal betreiben und klassifizieren (local-only vs seed-relevant).
Nur seed-relevante Erkenntnisse zurueck in den Seed heben.
Seed-Aenderungen kontrolliert in Nodes ueberfuehren.

Seed stabil halten Nodes schnell bewegen Keine Vermischung

7. Verknuepfte Kapitel

8. Kommunikationsregel fuer externe Partner

Bei Austausch mit anderen IT-Teams, Hochschulen oder Auditoren gilt:

Fachbegriff zuerst nutzen (z. B. Tenant, Instanz, Baseline).
IIO-Mapping in Klammern einmalig ergaenzen (Node, Projection, Seed).
Ab dann konsistent bei einer Bezeichnungsfamilie bleiben.

So bleibt die Kommunikation modern, aber standardnah und fuer externe Fachcommunity direkt nachvollziehbar.