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 abgestuften Rollen- und Rechtekonzept.
- Auftraggeber
- VIVAORA Entertainment UG
- Projekt
- Scotschy
- Branche
- Musik, Entertainment & Kreativwirtschaft
- Art
- Digitales Betriebssystem · Musik · Buchung · Verwaltung
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.
- Die tragende Schicht: Anmeldung, ein abgestuftes Rollen- und Rechtekonzept und die Nachvollziehbarkeit sicherheitsrelevanter Vorgänge.
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 Rechtekonzepts – daraus entstand ein abgestufter Schutz für vertrauliche Inhalte.
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 die Plattform.
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 einer gemeinsamen Grundlage. Sie teilen Anmeldung, Rechte und Protokoll, statt jeweils eigene mitzubringen.
Rechte als Grundprinzip
Zugriffsrechte sind ein Grundprinzip der Plattform und nicht nur eine Eigenschaft der Oberfläche.
Eine Grundlage, die wachsen darf
Die Plattform ist modular aufgebaut. Neue Geschäftsbereiche lassen sich aufnehmen, ohne die bestehende Anwendung neu zu entwickeln.
Nachvollziehbarkeit bleibt erhalten
Sicherheitsrelevante Vorgänge werden so festgehalten, dass die Spur auch bei späteren Änderungen erhalten bleibt.
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
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, Protokollierung.
Daten
Gemeinsame Datengrundlage, durch automatisierte Tests abgesichert.
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
- Gesonderter Zugriff auf vertrauliche Dokumente
Verwaltung und Auswertung
- Redaktionssystem für Inhalte, Medien und Seiten
- Verwaltungsübersicht
- Auswertung
- Konfiguration der Plattform
Zugriff und Nachvollziehbarkeit
- Anmeldung
- Rollen- und Rechtekonzept
- Schutz vertraulicher Daten
- Protokollierung sicherheitsrelevanter Vorgänge
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 als Grundprinzip
Zugriffsrechte werden zentral gesteuert und gelten unabhängig von der Oberfläche.
Schutz vertraulicher Inhalte
Vertrauliche Dokumente sind durch ein gesondert vergebenes Recht geschützt und nicht Teil der allgemeinen Verwaltungsrolle.
Unveränderliche Belege
Ausgestellte Belege sind nachträglich nicht mehr änderbar. Korrekturen entstehen als eigener Vorgang, statt den ursprünglichen zu überschreiben.
Nachvollziehbarkeit
Sicherheitsrelevante Vorgänge werden protokolliert.
Woran sich die Umsetzung orientiert
- Secure by Design – Rechte, Protokollierung und Unveränderlichkeit sind Teil des Konzepts, nicht nachgerüstet
- Least Privilege – vertrauliche Inhalte nur mit gesondert vergebenem Recht
- Defense in Depth – mehrere voneinander unabhängige Schutzebenen
- Orientierung an OWASP-Grundsätzen für Anwendungssicherheit
- Orientierung an anerkannten Referenzrahmen (BSI IT-Grundschutz ORP.4, ISO/IEC 27001 und 27002, OWASP ASVS) – keine Zertifizierung
Diese Grundsätze beschreiben die Arbeitsweise. Sie sind keine Zertifizierung und werden hier auch nicht als solche dargestellt.
Was geprüft wurde
- Die Berechtigungslogik ist Bestandteil automatisierter Tests.
- 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.
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.