Gliederung (Arbeitsstand)
Folgt Schneiders Beispielgliederung (betreuer-vorgaben). Verbindliche Vorgaben: kein Ich, nüchtern, Systembeschreibung statt Tagebuch. Zitierstil frei wählbar, aber durchgehend konsistent (Betreuer, 2026-08-03). Grundlage: verwandte-arbeiten, anschreiben-prof-schneider.
Betreuer-Vorgabe vom 2026-08-03 (prägt Kapitel 2): Kriterien für das eigene System zuerst festlegen, dann drei Marktsysteme daran prüfen, dann selbst positionieren (was ist gut und wird übernommen, was ist schlecht, wo ist die Lücke). Zentrale Argumentationslast: stringent begründen, warum eine Eigenentwicklung notwendig war.
Die Kriterien entstehen vor der Systemprüfung. Andernfalls werden sie unbewusst so gewählt, dass das eigene System gewinnt, und die Begründung verliert ihren Wert.
Kurzfassung (DE) · Abstract (EN)
1. Einleitung
1.1 Motivation
Wichtigkeit des Themas (nicht die eigene): Franchise-Ketten brauchen viele Standort-Websites mit einheitlichem Marken-Design; Single-Site-Werkzeuge (WordPress) skalieren dafür schlecht — Duplizierung, Inkonsistenz, Pflegeaufwand. (Ausgangspunkt WordPress-Single-Site = konkrete Problemstellung.)
1.2 Ziele der Arbeit
Eine Rendering-Engine, die aus einer festen, zentral gepflegten Designquelle viele mandantenspezifische Websites erzeugt: zentrale Design-Single-Source, Mandanten-Datenbindung, dynamisches Rendering, Mandantenisolation, begrenzter Override ohne Design-Fork.
2. State of the Art
(„Herzstück” laut Betreuer; Richtwert 4–6 Seiten — verwandte-arbeiten)
2.1 Vorgehen und Auswahlkriterien
Warum diese Systeme, warum diese Vergleichsachsen. Auswahlachse ist wie „ein Design, viele Sites” gelöst wird, nicht Marktanteil.
2.2 Kriterienraster
(entsteht vor der Systemprüfung; leitet sich aus den Anforderungen in Kap. 4.1 ab, sodass Vergleich und eigener Entwurf dieselbe Sprache sprechen)
- Wie wird das Design geteilt — Kopie mit Vererbungsverweis, Laufzeitreferenz, Themedatei
- Wirkung einer zentralen Designänderung — sofort, nach Rollout, manuell nachzuziehen
- Abweichung je Standort — möglich, Granularität, mit oder ohne Fork
- Mandantentrennung — geteilte oder getrennte Datenhaltung
- Erzeugungszeitpunkt — Build oder Laufzeit
- Wer bearbeitet — Entwickler oder Endnutzer
- Aufwand je zusätzlichem Standort — konstant oder wachsend
2.3 Wissenschaftliche Arbeiten
- Balzerani et al. (Produktlinien-Architektur für Web-Anwendungen) — beschreiben
- Kabbedijk & Jansen (Multi-Tenant-Variabilitätsmuster) — beschreiben
- (Multi-Tenancy-Grundlagen: Bezemer/Zaidman)
2.4 Systeme am Markt
(drei, dokumentationsbasiert, jeweils entlang desselben Rasters; keine Installation, kein Praxistest — sonst frisst es die Arbeit)
- Kandidat 1: WordPress Multisite — Kopieransatz, Massenverbreitung, Ausgangsproblem
- Kandidat 2: Adobe Experience Manager, Multi Site Manager — Blueprint und Live Copy mit feldweiser, brechbarer Vererbung; nächster Verwandter, aber kopiebasiert mit Rollout
- Kandidat 3: Headless-CMS mit Multi-Space (Storyblok/Contentful) oder eine Standortseiten-Plattform (Duda/Uberall) — Design im Frontendcode statt in den Daten
2.5 Vergleich
Tabelle Systeme × Kriterien. Die Lücke muss aus der Tabelle folgen, nicht behauptet werden.
2.6 Positionierung
- Was gut ist und übernommen wird: feldweise Vererbung mit kontrolliertem Bruch (AEM), Variabilitätsmuster (Kabbedijk/Jansen), Variabilität als Architektureigenschaft und Rekonfigurierbarkeit nach dem Ausrollen (Balzerani), strikte Trennung von Inhalt und Darstellung (Headless), redaktionelle Ergonomie für Endnutzer (WordPress)
- Was verworfen wird (als anderer Einsatzschwerpunkt, nicht als Mangel): Kopie als Vererbungsmechanismus, Rollout als expliziter Vorgang, Design im Frontendcode, freie Gestaltung ohne Typkatalog
- Die Lücke: Zwischen kopiebasierter Vererbung mit Rollout und codebasiertem Design ohne Laufzeitkopplung fehlt der Ansatz, der die Designquelle zur Laufzeit referenziert und Abweichung über den Blocktyp deklarativ begrenzt, bedienbar durch Endnutzer ohne Entwicklerbeteiligung. (Nicht behaupten, es gäbe nichts Vergleichbares — sagen, dass für diese Kombination von Anforderungen kein Ansatz existiert.)
- Warum eine Eigenentwicklung notwendig war — stringent aus den Kriterien hergeleitet, nicht behauptet
3. Grundlagen
(etablierte Konzepte = Vokabular; je Konzept eine Quelle)
3.1 Multi-Tenancy
3.2 Software-Produktlinien & Variabilität
3.3 Trennung von Design, Struktur und Inhalt (Separation of Concerns; UWE als Beispiel)
3.4 Web-Rendering: Build-Zeit vs. Runtime
3.5 Eingesetzte Technologien (Stack: PHP, Templating, Datenbank …)
4. Konzept
(hohes Abstraktionsniveau: Blockbild, ggf. Pseudocode/Formeln)
4.1 Anforderungen
(Quelle des Kriterienrasters aus 2.2 — beide müssen deckungsgleich sein) Ergänzend zu den sechs Anforderungen des Themenvorschlags: Indexierbarkeit — die Vereinheitlichung erzeugt ein Auffindbarkeitsproblem, weil Standortseiten einander zu stark ähneln. Bestimmte Felder sind daher nicht optional, sondern zwingend lokal zu überschreiben. Damit ist der Override-Mechanismus nicht nur Komfort, sondern technische Notwendigkeit.
4.2 Architektur im Überblick (Blockbild)
4.3 Design-Single-Source (systemweite Layout-Schicht + Marken-Tokens)
4.4 Vier-Schichten-Designmodell (Layout · Variante · Bindung · Marken-Skin)
4.5 Baukastenprinzip: Typ und Instanz
Fest gestaltete Sectionblöcke → endliche, beschreibbare Freiheitsgrade. Der Blocktyp gehört zur Designquelle (zentral, fest, definiertes Feldschema), die Blockinstanz zum Mandanten (variabel in Menge, Reihenfolge, Werten). Die Freigabe für Abweichungen ist Eigenschaft des Typs, nicht der Instanz.
4.6 Datenhaltung: schemastark gegen schemaflexibel
Drei Zonen mit begründeter Grenzziehung:
| Zone | Inhalt | Begründung |
|---|---|---|
| relational, fest | Mandant, Standort, Domain, Seitenbaum, Slots, Bindung, Typkatalog | routbar, rechteprüfbar, auswertbar; Isolation braucht Constraints |
| Dokument | Blockinstanzen je Slot: Menge, Reihenfolge, Feldwerte, Entwurfsstand | schemaflexibel, atomar versionierbar, mergefähig |
| Code oder Datei | Markup und CSS der Blocktypen | offener Zielkonflikt, siehe unten |
Sechs Kriterien der Grenzziehung: Kardinalität · Abfragebedarf · Integritätsbedarf · Änderungseinheit · Urheber und Frequenz · Schemastabilität. Verworfene Alternativen benennen: durchgehend relational · Templatedateien je Site · durchgehend dokumentenorientiert. Nachteile offenlegen: keine referenzielle Integrität im Dokument, teure Auswertungen über den Bestand, Schemaprüfung in der Anwendung statt in der Datenbank. Offener Zielkonflikt: Designquelle als Code (versionierbar, prüfbar, aber Änderung = Deployment) gegen Designquelle als Daten (unmittelbar wirksam, aber ohne Versionskontrolle und Review).
4.7 Vererbung/Override ohne Fork (freigegebene Felder, CSS-Varianten)
4.8 Entscheidung Runtime-Rendering (positiv begründet: sofortige Konsistenz)
4.9 Zwischenspeicherung
Die Zugriffszahl wächst mit Slotzahl × gebundenen Komponenten und multipliziert sich über die Mandanten. Zwischenspeicherung ist damit die Bedingung, unter der Laufzeitrendering trägt — und zugleich Auffindbarkeitsfrage, weil die Antwortzeit auf die Indexierung durchschlägt. Zielkonflikt: Das Kernversprechen ist sofortige Wirksamkeit zentraler Designänderungen, ein Zwischenspeicher ist dessen Gegenteil. Die Entwurfsfrage lautet nicht „welcher Cache”, sondern entlang welcher Achse geschnitten wird, sodass eine zentrale Änderung nicht den gesamten Bestand invalidiert. Das Vier-Schichten-Modell liefert die Schnittkanten: oben zentral und selten, unten lokal und häufig. Achsen: Granularität (Vollseite / Fragment je Slot / Rohdaten) · Invalidierung (aktiv gegen implizit über Versionsstempel im Schlüssel) · Schichtung.
4.10 Mandantenisolation (Domain-Routing, Scoping)
5. Realisierung
5.1 Render-Pipeline (Aufruf → Zuordnung → Renderer → fertige Seite)
5.2 Datenmodell (Design geteilt · Struktur/Inhalt je Mandant · Bindung)
5.3 Redaktion & Auslieferung (Entwurf→Live, Zwischenspeicherung/Read-Replica)
6. Implementierung
(kann mit 5 zusammenfallen; wenig Code, max. 2/3 Seite, immer mit Erklärung)
- ausgewählte Kernmechanik (z. B. Slot-Bindung + Inhalts-Merge) knapp gezeigt.
7. Beispiel
(Drehbuch mit Bildschirmabzügen) — zentrale Designänderung wirkt auf alle Sites; ein Mandant ändert ein freigegebenes Feld; gerenderte Standort-Sites + Editor.
8. Anwendungsszenarien
Weitere Multi-Location-Marken (Handelsketten, Hotelgruppen, Verbände), White-Label-Portale, Mandanten-Websites allgemein.
9. Resümee und Ausblick
Ziele aus 1.2 wieder aufgreifen + wie realisiert (Management-Summary); Ausblick (z. B. Theme-Marketplace, weitere Cache-Ebenen).
10. Literaturverzeichnis
(nur zitierte Quellen; alphabetisch; Stil frei, aber durchgehend konsistent — Produktdokumentation als Webquelle mit Abrufdatum)
Anhang
(lange Tabellen, Quellcode-Auszüge)
Offene Struktur-Entscheidungen (vor der Outline-Besprechung zu klären)
- Evaluationskapitel? Schneiders Beispielgliederung sieht keines vor, er hat sich am 2026-08-03 nicht dazu geäußert. Die Zwischenspeicherung wäre messbar (Renderzeit und Zugriffszahl mit und ohne Cache, Skalierung über die Mandantenzahl, Verzögerung bis eine zentrale Designänderung sichtbar ist). Klein, machbar, hebt die Arbeit über eine reine Systembeschreibung. Ihm als Ergänzung anbieten.
- Fallen 5 und 6 zusammen? Realisierung und Implementierung dürfen laut Vorgabe ein Kapitel bilden.
- Ersetzen die drei Systeme die wissenschaftlichen Arbeiten in Kap. 2, oder kommen sie hinzu? Aktuell als „hinzu” geplant.
- Reicht ein dokumentationsbasierter Systemvergleich, oder wird ein praktischer Test erwartet? Nur Ersteres ist im Umfang realistisch.