State of the Art — Systeme, Literatur, Positionierung
Für Kapitel 2 der Projektarbeit. Betreuer-Vorgaben: betreuer-vorgaben (nüchtern, kein Ich, Systembeschreibung statt Tagebuch; Zitierstil frei, aber konsistent). Gesprächsergebnis 2026-08-03: anschreiben-prof-schneider. Stand: 2026-08-03.
⚠ Strategiewechsel (2026-08-03)
Die frühere Festlegung „wissenschaftliche Arbeiten, keine Marktprodukte” und „Systembeschreibung, kein Vergleich, keine Rechtfertigungs-Diskussion” ist hinfällig. Prof. Schneider verlangt ausdrücklich das Gegenteil:
- Kriterien für das eigene System zuerst festlegen, dann Systeme daran prüfen
- Drei Systeme am Markt vergleichen
- Selbst positionieren: was ist gut und wird übernommen, was ist schlecht
- Stringent begründen, warum eine Eigenentwicklung notwendig war
Sein Merkblatt sagt ohnehin wörtlich „≥ 2 ähnliche Arbeiten**/Systeme**” — die frühere Notiz hatte das zu eng auf wissenschaftliche Arbeiten verengt.
Motivation / Ausgangslage
- Herkunft (real): Anforderung eines Franchise-Unternehmens aus WordPress-Single-Site; mit IT-Erfahrung ein Lösungsvorschlag entwickelt. Kommerzielle Absicht (Verkauf) — privater Antrieb, nicht in den Text.
- Akademische Motivation (in den Text): Warum das Thema wichtig ist — Franchise-Ketten brauchen viele Standort-Sites mit einheitlichem Marken-Design; Single-Site-Werkzeuge (WordPress) skalieren dafür schlecht (Duplizierung, Inkonsistenz, Pflegeaufwand). Der WP-Single-Site-Ausgangspunkt = konkrete Problemstellung (Kap. 1) und Abgrenzung für „Verwandte Arbeiten”.
Auswahlprinzip (neu, ab 2026-08-03)
Auswahlachse ist wie „ein Design, viele Sites” gelöst wird, nicht Marktanteil und nicht Paradigmen-Nähe. Systeme und Arbeiten werden entlang desselben Kriterienrasters beschrieben, damit Vergleich und eigener Entwurf dieselbe Sprache sprechen.
Bewertung bleibt nüchtern: verworfene Ansätze werden als anderer Einsatzschwerpunkt eingeordnet, nicht als Mangel. Kein Produktbashing — die Systeme sind für ihren Zweck richtig gebaut, der Franchise-Fall ist ein anderer.
Kriterienraster (vor der Systemprüfung festzulegen)
Leitet sich aus den Anforderungen des Themenvorschlags ab:
- 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
Achse 7 trägt die Kernaussage: Der Pflegeaufwand soll nicht mehr mit der Zahl der Sites wachsen.
Systemkandidaten (drei, dokumentationsbasiert)
- WordPress Multisite — Kopieransatz, Massenverbreitung, im Exposé als Ausgangsproblem benannt. Theme geteilt, Inhalte dupliziert, Override unkontrolliert (alles oder nichts).
- Adobe Experience Manager, Multi Site Manager — Blueprint-Site, daraus Live Copies mit feldweiser, gezielt brechbarer Vererbung. Nächster Verwandter und wichtigster Vergleichspartner: belegt, dass „Abweichung ohne Fork” ein industriell anerkanntes Problem ist. Löst es aber über Kopie plus Rollout, nicht über Laufzeitreferenz.
- Dritter Kandidat, noch zu wählen:
- Headless-CMS mit Multi-Space (Storyblok, Contentful) — Inhalt strikt getrennt, Design liegt im Frontendcode, Designänderung ist ein Deployment
- oder Standortseiten-Plattform (Duda, Uberall) — näher am Franchise-Fall, Anschluss an das Indexierbarkeitsthema
(Keine Installation, kein Praxistest, keine Messung — dokumentationsbasiert, sonst
frisst der Vergleich die Arbeit. Aus technischer Dokumentation zitieren, nicht aus
Marketingmaterial. Produktdoku = Webquelle mit exakter URL und Abrufdatum; mehrere
Seiten gleicher URL und gleichen Datums mit a/b unterscheiden.)
Kandidaten (wissenschaftliche Arbeiten)
Feld: Software-Produktlinien für Web-Anwendungen (am direktesten)
BDP+05Balzerani, Di Ruscio, Pierantonio, De Angelis (2005): A product line architecture for web applications. Proc. ACM SAC 2005, S. 1689–1693. → „Koriandol”: Produktlinien-Architektur für Web-App-Familien mit eingebauter, sogar nach Deployment rekonfigurierbarer Variabilität. Kern.WebSPL24WebSPL: A Software Product Line for Web Applications. arXiv:2404.03061 (2024). → aktuelle, gleichnamige SPL für Web-Apps. (Preprint — publizierte Version prüfen.)
Feld: Multi-Tenancy / Per-Tenant-Variabilität
KJ11Kabbedijk, Jansen (2011): Variability in Multi-tenant Environments: Architectural Design Patterns from Industry. Springer, DOI 10.1007/978-3-642-24574-9_20. → 3 Muster (Customizable Data Views, Module Dependent Menu, Pre/Post Update Hooks) für Abweichung je Mandant ohne Fork. Kern (deckt deinen Franchise-Override).BZ10Bezemer, Zaidman (2010): Multi-tenant SaaS applications: maintenance dream or nightmare? Proc. EVOL/IWPSE, ACM DOI 10.1145/1862372.1862393. → Grundlagen/Herausforderungen der Multi-Tenancy.KBJ+15Kabbedijk, Bezemer, Jansen, Zaidman (2015): Defining multi-tenancy: A systematic mapping study … (Zitation/Venue prüfen — vermutl. JSS 2015). → Definition/Abgrenzung Multi-Tenancy.
Feld: Model-Driven Web Engineering — nur als Grundlagen-Beleg, NICHT als Gegen-Ansatz (sonst „warum nicht MDE?”-Diskussion). Dient als Beleg für Separation of Concerns (Design/Struktur/Inhalt trennen):
KKK07Kraus, Knapp, Koch (2007): Model-Driven Generation of Web Applications in UWE. → UWE trennt Content/Navigation/Präsentation.CFB00Ceri, Fraternali, Bongio (2000): WebML. (Zitation prüfen: WWW9 / Computer Networks 33.) → seminales daten-intensives Web-Modell.- Diese formalen MDE-Wege sind ein anderer methodischer Schwerpunkt als die pragmatische Runtime-Engine → nur knapp/neutral einordnen.
In Tiefe beschreiben (Schneiders „≥ 2 wörtlich”)
BDP+05 (Web-Produktlinie) und KJ11 (Multi-Tenant-Variabilitätsmuster) —
zusammen decken sie „ein Design → viele Sites” + „Abweichung ohne Fork” exakt ab.
Optional als drittes das aktuelle WebSPL24.
Positionierung (Kap. 2.6)
Was gut ist und übernommen wird
- AEM Multi Site Manager: feldweise Vererbung mit kontrolliertem Bruch — das Konzept ist richtig, der Mechanismus über Kopie ist es nicht
- Kabbedijk/Jansen: Variabilitätsmuster für Abweichung ohne Fork
- Balzerani et al.: Variabilität als Architektureigenschaft, Rekonfigurierbarkeit auch nach dem Ausrollen
- Headless-Systeme: strikte Trennung von Inhalt und Darstellung
- WordPress: Bedienmodell und redaktionelle Ergonomie für Endnutzer
Was verworfen wird (mit Begründung, ohne Abwertung)
- Kopie als Vererbungsmechanismus — erzeugt Artefakte, die auseinanderdriften, und macht die Wirkung von einem Rolloutschritt abhängig
- Rollout als expliziter Vorgang — widerspricht der Anforderung sofortiger Wirksamkeit
- Design im Frontendcode — verlagert jede Designänderung in ein Deployment
- Freie Gestaltung ohne Typkatalog — verhindert Markenkonsistenz und Wirkungsanalyse, also genau das, was der Franchisegeber braucht
Die Lücke
Zwischen kopiebasierter Vererbung mit Rollout (AEM) und codebasiertem Design ohne Laufzeitkopplung (Headless) fehlt der Ansatz, der die Designquelle zur Laufzeit referenziert und Abweichung über den Blocktyp deklarativ begrenzt, bedienbar durch Endnutzer ohne Entwicklerbeteiligung.
Wichtig: nicht behaupten, es gäbe nichts Vergleichbares. Formulieren, dass für diese Kombination von Anforderungen kein Ansatz existiert. Die Lücke muss aus der Vergleichstabelle folgen, nicht behauptet werden — eine leere Spalte ist ein Argument, ein Satz ist keins.
Warum eine Eigenentwicklung notwendig war
Zentrale Argumentationslast laut Betreuer. Stringent aus den sieben Kriterien herleiten, nicht behaupten.
Caveats
WebSPL24ist Preprint;KBJ+15/CFB00Zitationen final prüfen.- Alles Journals/Proceedings = gültige Primärquellen (kein Wikipedia).
- Literaturumfang steigt durch die drei Systeme auf realistisch 8–10 Einträge.
- Recherchestruktur (Themenfelder, Suchbegriffe, Datenbanken) wird vorab gemeinsam festgelegt — die Recherche muss später verteidigt werden können.