Referenzarchitekturen

Wie verschiedene Arten von Organisationen Atlas einrichten können, von einer Unternehmenswebsite bis zu einer Multi-Brand-Gruppe oder einer Agentur.

Diese Seite wurde aus dem Englischen übersetzt. Bei Abweichungen gilt die englische Version. Auf Englisch lesen

Dies sind empfohlene Setups, keine Kundengeschichten. Wählen Sie das Muster, das Ihrem am nächsten kommt, und passen Sie es an.

1. Multi-Brand-Gruppe

Eine Holding mit mehreren Marken-Websites, jede mit eigenem Team.

Organization: Group
├── Site: brand-a   (Development, Production)   editors: Brand A team
├── Site: brand-b   (Development, Production)   editors: Brand B team
└── Site: brand-c   (Development, Production)   editors: Brand C team
Approvers: group digital team (organization admins) + one reviewer per brand

Eine Organisation, eine Site pro Marke. Inhalte, Medien, Tokens und Personen werden nie zwischen Sites geteilt.
Jede Marke behält ihren eigenen Website-Code und Contract, mit eigenen Komponenten und Design-Tokens. Atlas erzwingt nie ein gemeinsames Design.
Redakteure der Marken erhalten Rollen nur auf ihrer Site. Das digitale Team der Gruppe gibt Production-Releases frei.
Jede Website hat eigene Delivery-Tokens und Webhooks, sodass das Deployment oder ein Ausfall einer Marke die anderen nicht beeinträchtigt.

2. Regulierte oder freigabeintensive Unternehmen

Teams aus Finanzwesen, Gesundheitswesen, Energie oder behördennahen Bereichen, in denen jede öffentliche Änderung eine Abnahme braucht.

Redakteure und Marketer entwerfen; ein Reviewer/Publisher veröffentlicht in Development; eine kleinere Gruppe gibt Production-Releases frei.
Aktivieren Sie die Freigabe per Telefon für sensible Aktionen.
Jedes Release wird geprüft (Contract synchron, keine Veröffentlichungsprobleme, Site-Gesundheit, aktuelles Backup) und signiert. Ein Rollback ist eine einzige Aktion.
Exportieren Sie das Audit-Log für Ihre Compliance-Unterlagen.
Legen Sie die Regeln zur Lead-Aufbewahrung vor dem Go-live fest und beachten Sie, dass Aufbewahrung und CRM-Push heute nur Development-Leads abdecken.
Klären Sie Hosting-Standort und Datenaufbewahrung vor der Vertragsunterzeichnung mit uns (siehe Sicherheit).

3. Agentur, die Kunden-Websites betreibt

Eine Agentur baut und pflegt Sites für mehrere Kunden.

Bevorzugen Sie eine Organisation pro Kunde, damit jeder Kunde seine Daten, Personen und seinen Tarif besitzt. Agenturmitarbeitende werden als Mitglieder eingeladen.
Bauen Sie eine Bibliothek eigener Komponenten im Code und verwenden Sie sie über Kunden-Contracts hinweg wieder, mit kundenspezifischen Design-Tokens.
Nutzen Sie einen KI-Coding-Agenten über MCP für die Inhaltsmigration; der Reviewer des Kunden veröffentlicht.
Die Übergabe ist sicher: Die Redakteure des Kunden können nur typisierte Felder ändern, nie den Code.

4. Einzelne Unternehmenswebsite

Eine Unternehmenswebsite, ein kleines Marketing-Team und ein externer Entwickler.

Eine Organisation, eine Site. Der Entwickler bindet die Website an und schreibt den Contract einmalig.
Das Marketing bearbeitet Seiten, News und Übersetzungen; die Marketingleitung gibt Production-Releases frei.
Der Entwickler wird nur für neue Komponenten oder Seitentypen gebraucht.

Was alle Muster gemeinsam haben

Code, Hosting und Deployments Ihrer Website bleiben bei Ihnen.
Zuerst Development; Production nur über ein freigegebenes Release.
Ein integrierter Fallback, damit die Site online bleibt, wenn Atlas nicht erreichbar ist.
Delivery-Tokens auf dem Server, vor Ablauf rotiert.