Musik, Entertainment & Kreativwirtschaft
Ein Künstlerprojekt ist ein Unternehmen
Für die VIVAORA Entertainment UG ist mehr entstanden als eine Künstlerwebsite: eine Plattform, die Veröffentlichungen, Verteilseiten, Buchungsanfragen, Angebote, Belege, Dokumente, Kontakte und Inhalte in einem System führt – mit einem Rollen- und Rechtemodell, das serverseitig aus der Datenbank durchgesetzt wird.
- Auftraggeber
- VIVAORA Entertainment UG
- Projekt
- Scotschy
- Branche
- Musik, Entertainment & Kreativwirtschaft
- Art
- Digitales Betriebssystem · Musik · Buchung · Verwaltung
94 Tabellen im Datenmodell
42 versionierte Migrationen
288 Tests im Backend
Die Angaben auf dieser Seite sind am Projektregelwerk, an einem datierten Prüfstand der Module und an der ausgelieferten Anwendung geprüft.
Ausgangslage
Worum es geht
Wer Musik veröffentlicht, führt nebenbei ein Unternehmen. Termine werden angefragt, Angebote geschrieben, Belege gestellt, Verträge abgelegt, Inhalte gepflegt, Veröffentlichungen vorbereitet und verteilt. Üblicherweise verteilt sich das auf ein Tabellenblatt, ein Postfach, einen Linkdienst, einen Webbaukasten und mehrere Portale.
Jedes dieser Werkzeuge kennt nur seinen Ausschnitt. Eine Anfrage aus dem Postfach weiß nichts vom Angebot, das Angebot nichts vom Beleg, der Beleg nichts vom Kontakt. Was fehlt, ist keine weitere Anwendung, sondern eine gemeinsame Grundlage.
Dazu kommt die Zugriffsfrage. Eine Agentur, ein Management und der Künstler selbst arbeiten an denselben Vorgängen, brauchen aber nicht dieselbe Sicht – und schon gar nicht dieselben Rechte auf Verträge und Belege.
Was XINOO umgesetzt hat
- Den öffentlichen Auftritt: Künstlerwebsite, Veröffentlichungen und Verteilseiten mit eigener Kurzadresse, Entwurfs- und Freigabestand.
- Den Geschäftsteil: Anfrage- und Buchungsstrecke mit Angeboten und Positionen, Notizen, Aufgaben und Verlauf, dazu Belegwesen mit Zahlungen, Zuordnung und gestalteter PDF-Ausgabe.
- Die Verwaltung: Redaktionssystem für Inhalte, Medien und Seiten, Dokumentenverwaltung mit Kategorien und Zugriffsschutz, Kontakt- und Interessentenverwaltung sowie Auswertung von Ereignisdaten.
- Die tragende Schicht: Anmeldung, serverseitig durchgesetztes Rollen- und Rechtemodell, Schutz schreibender Zugriffe und ein Protokoll, das ein hartes Löschen übersteht.
Vorgehen
Was vor der ersten Zeile Code stand
Die teuersten Fehler entstehen nicht beim Programmieren, sondern davor – wenn niemand geklärt hat, welche Vorgänge das System eigentlich abbilden soll.
Den Vorgang verfolgen, nicht die Seiten zählen
Ausgangspunkt war der Weg einer Buchungsanfrage: von der ersten Nachricht über das Angebot bis zum Beleg. Wo dieser Weg heute abreißt und in ein anderes Werkzeug wechselt, entstand später eine Funktion.
Zwei Öffentlichkeiten
Die Plattform bedient zwei sehr verschiedene Gruppen: Fans, die Musik hören und Termine sehen wollen, und Geschäftspartner, die anfragen, verhandeln und abrechnen. Beide Wege wurden getrennt entworfen und liegen dennoch auf demselben Datenbestand.
Was gehört geschützt
Verträge, Belege und Kontaktdaten unterliegen anderen Anforderungen als ein Veröffentlichungstermin. Die Einstufung stand vor dem Entwurf des Rechtemodells – daraus entstand unter anderem eine eigene Berechtigung für vertrauliche Dokumente.
Was ein Beleg aushalten muss
Belege dürfen sich nach dem Ausstellen nicht mehr ändern. Diese Anforderung wurde vor der Umsetzung festgehalten und prägt das Datenmodell: Ausgestellte Belege sind unveränderlich.
Gestaltung
Die Handschrift des Kunden, nicht die der Agentur
Die Bühne gehört dem Künstler
Der öffentliche Auftritt folgt der Bildsprache des Projekts, nicht einer Agenturhandschrift. Musik, Veröffentlichungen und Termine stehen vorn; die Plattform dahinter tritt nicht in Erscheinung.
Verwaltung darf nüchtern sein
Der Verwaltungsbereich ist bewusst anders gestaltet als die Künstlerseite: dichte Listen, klare Zustände, wenig Bewegung. Wer dort täglich arbeitet, braucht Übersicht, keine Inszenierung.
Zustände sichtbar machen
Entwurf, freigegeben, ausgestellt, bezahlt – die Plattform führt viele Vorgänge mit Zwischenzuständen. Diese Zustände sind durchgängig gleich dargestellt, damit man den Stand einer Sache erkennt, ohne sie zu öffnen.
Verteilseiten als eigenes Format
Die Verteilseiten zu Veröffentlichungen sind kein Unterpunkt der Website, sondern ein eigenes, auf das Telefon hin entworfenes Format mit eigener Kurzadresse.
Architektur
Die Entscheidungen dahinter
Nicht der Funktionsumfang entscheidet, ob ein System trägt, sondern wie es geschnitten ist.
Eine Plattform, viele Fachbereiche
Veröffentlichungen, Buchung, Belege, Dokumente, Inhalte und Kontakte sind eigene Fachbereiche auf einem gemeinsamen Datenmodell. Sie teilen Anmeldung, Rechte und Protokoll, statt jeweils eigene mitzubringen.
Rechte im Server, nicht in der Oberfläche
Die Rechteprüfung liegt in der API und liest aus der Datenbank. Eine ausgeblendete Schaltfläche ist eine Bequemlichkeit für Nutzende, kein Schutz – der Schutz greift dahinter.
Ein Datenmodell, das wachsen darf
Das Modell ist modular aufgebaut und über versionierte Migrationen gepflegt. Neue Geschäftsbereiche lassen sich aufnehmen, ohne die bestehende Anwendung neu zu entwickeln.
Ein Protokoll, das Löschen übersteht
Das Vorgangsprotokoll ist bewusst ohne Fremdschlüssel auf die Fachdaten angelegt. Wird ein Datensatz endgültig gelöscht, bleibt der Protokolleintrag bestehen – sonst verschwände genau die Spur, die man später sucht.
Systemaufbau
Von außen nach innen
Die Ebenen des Systems in der Reihenfolge, in der eine Anfrage sie durchläuft.
Fans und Geschäftspartner
Öffentliche Künstlerwebsite, Veröffentlichungen und Verteilseiten mit eigener Kurzadresse.
Anwendung
React-Oberfläche für den öffentlichen Auftritt und einen getrennt gestalteten Verwaltungsbereich.
Fachdienste
Veröffentlichungen, Buchung und Angebote, Belegwesen, Dokumente, Redaktionssystem, Kontakte und Auswertung.
Zugriffsschicht
Anmeldung, Rollen und Rechte aus der Datenbank, Schutz schreibender Zugriffe, Protokollierung.
Daten
94 Tabellen, über 42 versionierte Migrationen gepflegt, abgesichert durch 288 Tests im Backend.
Funktionen
Was das System kann
Gruppiert nach Bereichen. Die Aufstellung ist die Antwort auf die Frage, wie groß das Vorhaben tatsächlich war.
Öffentlicher Auftritt
- Künstlerwebsite
- Veröffentlichungen mit Detailseiten
- Verteilseiten zu Veröffentlichungen
- Eigene Kurzadresse für Weiterleitungen
- Entwurfs- und Freigabestand je Seite
- Redaktionell pflegbare Inhalte und Medien
Buchung und Anfragen
- Öffentliche Anfrageerfassung
- Verwaltung der Anfragen
- Angebote mit Einzelpositionen
- Notizen und Aufgaben am Vorgang
- Verlauf je Anfrage
- Kontakte, Agenturen und Interessenten
Kaufmännisches
- Belege mit Einzelpositionen
- Zahlungen und deren Zuordnung
- Gestaltete PDF-Ausgabe
- Unveränderlichkeit ausgestellter Belege
- Dokumentenverwaltung mit Kategorien
- Eigene Berechtigung für vertrauliche Dokumente
Verwaltung und Auswertung
- Redaktionssystem für Inhalte, Medien und Seiten
- Verwaltungsübersicht
- Auswertung von Ereignisdaten
- Konfiguration der Plattform
- Versionierte Datenbankmigrationen
Zugriff und Nachvollziehbarkeit
- Anmeldung mit Sitzungsverwaltung
- Rollen- und Rechtemodell in eigenen Tabellen
- Serverseitige Durchsetzung der Rechte
- Schutz aller schreibenden Verwaltungszugriffe
- Protokoll mit stabilen Aktionsschlüsseln
- Trennung öffentlicher und vertraulicher Daten
Technik
Womit es gebaut ist
Oberfläche
Anwendungsschicht
Daten
Qualitätssicherung
Integration
Was angebunden ist – und was nicht
Die Plattform ist als eigenständiges System entworfen: Veröffentlichungen, Buchung, Belege und Inhalte laufen ohne Fremdsystem. Angebunden sind die Streamingdienste als Ziele der Verteilseiten. Für den Verkaufsbereich ist eine Anbindung an eine Handelsplattform vorgesehen; sie ist noch nicht umgesetzt.
Sicherheit & Zugriff
Sicherheit ist Teil des Entwurfs
Wer Zugriffsrechte nachträglich einzieht, baut Ausnahmen. Wer sie vorher entwirft, baut eine Struktur.
Rechte serverseitig aus der Datenbank
Benutzer, Rollen, Rechte, Sitzungen und deren Verknüpfungen liegen als eigene Tabellen vor. Die Prüfung erfolgt in der API gegen diesen Bestand – nicht in der Oberfläche.
Schreibende Zugriffe abgesichert
Alle schreibenden Wege im Verwaltungsbereich sind gegen die Ausführung aus fremdem Kontext abgesichert. Ein Formular, das anderswo nachgebaut wird, greift dadurch nicht.
Vertrauliche Dokumente getrennt
Für den Zugriff auf vertrauliche Dokumente existiert eine eigene Berechtigung. Sie ist nicht Teil der allgemeinen Verwaltungsrolle, sondern wird gesondert vergeben.
Unveränderliche Belege
Ausgestellte Belege sind nachträglich nicht mehr änderbar. Korrekturen entstehen als eigener Vorgang, statt den ursprünglichen zu überschreiben.
Protokoll ohne Abhängigkeit von den Fachdaten
Das Protokoll führt stabile Aktionsschlüssel und ist bewusst nicht über Fremdschlüssel an die Fachdaten gebunden. Es überlebt damit auch ein endgültiges Löschen des betroffenen Datensatzes.
Woran sich die Umsetzung orientiert
- Secure by Design – Rechte, Protokoll und Unveränderlichkeit sind Teil des Datenmodells, nicht nachgerüstet
- Least Privilege – vertrauliche Dokumente verlangen eine eigene, gesondert vergebene Berechtigung
- Defense in Depth – Anmeldung, serverseitige Rechteprüfung, Schutz schreibender Zugriffe und Protokoll greifen unabhängig
- An OWASP-Grundsätzen orientierte Anwendungssicherheit bei Authentifizierung, Sitzungsführung und Zugriffskontrolle
Diese Grundsätze beschreiben die Arbeitsweise. Sie sind keine Zertifizierung und werden hier auch nicht als solche dargestellt.
Was geprüft wurde
- 288 Tests im Backend und 18 Rauchtests auf dem ausgelieferten Stand, dokumentiert in einem datierten Prüfstand des Projekts.
- Die Rechteprüfung ist Bestandteil der Testabdeckung des Backends.
- Eine formale Zertifizierung ist damit nicht verbunden und wird nicht behauptet.
Stand
Was läuft, was noch nicht
Ein Projekt ist selten an einem Stichtag fertig. Der Stand steht hier, weil er zur Sache gehört.
Die Plattform ist entwickelt und unter eigener Adresse live: öffentlicher Auftritt, Veröffentlichungen, Verteilseiten, Buchungsstrecke, Belegwesen, Dokumente, Redaktionssystem, Kontakte und Auswertung.
Ein Verkaufsbereich wird derzeit aufgebaut. Kaufweg, Bestellabfrage und Retouren sind bis dahin bewusst abgeriegelt und werden nicht als Funktion geführt.
Das Rechtemodell wird um produktive Rollenkonten erweitert. Die Trennung ist entwickelt und getestet; im laufenden Betrieb ist sie noch nicht mit mehreren Rollen belegt.
Eine öffentliche Presseseite und eine regelbasierte Automatisierung sind vorgesehen. Beide sind noch nicht in Betrieb.
Öffentlich erreichbar unter scotschy.com (öffnet in neuem Tab).
Verwandte Themen
Weiterlesen
Ein vergleichbares Vorhaben?
Schildern Sie die Ausgangslage. Wir ordnen ein, welche Ebene zuerst dran ist und ob dafür ein Produkt, eine Integration oder eine Entwicklung das richtige Mittel ist.