Onboarding: Deine Anwendung auf die Plattform bringen

Das ist der typische Weg von der Idee zu einem Produktions-Spoke. Die genauen Schritte, Formulare und Genehmiger legt deine Organisation fest. Der folgende Weg verbindet die technischen Schritte der Plattform mit den Governance-Schritten, die Organisationen üblicherweise ergänzen. Frag dein Plattform-Team nach dem Onboarding-Formular und dem Eingangskanal.

flowchart LR
    A["1. Registrieren"] --> B["2. Technisches Onboarding<br/>(dev-Spoke)"]
    B --> C["3. Datenschutz- und Datenprüfung"]
    C --> D["4. Design"]
    D --> E["5. Security-Prüfung"]
    E --> F["6. Produktions-Spoke<br/>und Go-live"]

Schritt	Was du tust	Was du bekommst
1. Registrieren	Beschreibe, was du bauen oder migrieren willst. Benenne einen Product Owner (Endverantwortlicher) und einen technischen Ansprechpartner. Lies die Verantwortlichkeiten und Einschränkungen und stimme ihnen zu. Stelle sicher, dass die Personen, die deployen, ein verwaltetes Gerät und Netzwerkzugang (zum Beispiel VPN) haben, um private Ressourcen zu erreichen.	Ein Gespräch mit dem Plattform-Team über Eignung und nächste Schritte
2. Technisches Onboarding	Fülle den technischen Teil des Formulars aus: Workload-Kurzname (max. 6 Zeichen), Umgebungen, Subscription, Größe des Adressbereichs, Subnets, Team-Gruppe, Tags, Datenklassifizierung, Budget und jede Registrierung, die deine Organisation verlangt (zum Beispiel ein CMDB-Eintrag). Siehe So stellst du eine Anfrage.	Ein dev-Spoke, in dem du mit dem Bauen beginnen kannst
3. Datenschutz- und Datenprüfung	Entscheide, ob deine Anwendung personenbezogene Daten verarbeitet. Falls ja, führe die Datenschutzbewertung durch (zum Beispiel eine DPIA) und sprich mit dem Data Management. Daraus ergibt sich der Tag pii.	Ein dokumentiertes Datenschutzergebnis
4. Design	Zeichne die Architektur: Azure-Ressourcen, Verbindungen zu anderen Systemen, das Zugriffsmodell (Entra ID Gruppen), besondere Anforderungen. Ergänze die Ressourcen, die die Baseline bereits mitbringt (siehe Was du bekommst), und die, die deine Anwendung braucht. Berücksichtige die Verfügbarkeit und Wiederherstellung jeder Komponente. Bitte um ein Design-Review.	Ein genehmigtes Design
5. Security-Prüfung	Liefere die Klassifizierung (Vertraulichkeit, Integrität, Verfügbarkeit). Prüfe die Risikoanalyse. Möglicherweise sind zusätzliche Maßnahmen nötig, etwa ein Penetrationstest oder Design-Änderungen.	Eine Security-Freigabe oder eine Liste von Auflagen
6. Go-live	Frage den Produktions-Spoke an. Deploye über deine Pipelines. Nutze deine Checkliste. Bei wesentlichen späteren Änderungen (neue Datenarten, viele zusätzliche Nutzer, neue Funktionalität) sprich mit dem Plattform-Team: Möglicherweise ist ein erneutes Review nötig.	Ein prd-Spoke

Parallel arbeiten

Mit dem dev-Spoke aus Schritt 2 kannst du mit dem Bauen beginnen, während die Schritte 3 bis 5 laufen. Nur der Produktions-Spoke wartet auf die Genehmigungen.

Das solltest du bereithalten

Eine Anfrage wird am schnellsten bearbeitet, wenn du diese Fragen von vornherein beantworten kannst.

Punkt	Warum er nötig ist
Team-Gruppe	Eine bestehende Entra ID Gruppe mit deinem Team. Die Spoke-Gruppen werden mit dieser Gruppe als Mitglied erstellt, sie muss also existieren, bevor der Spoke erstellt wird. Siehe Zugriff, Gruppen und PIM.
Adressbereich und Subnet-Plan	Das Plattform-Team vergibt den Bereich aus dem zentralen IP-Plan. Nenne, wie viele Adressen und Subnets du brauchst, und lass Raum für Wachstum. Siehe IP-Bereich und Subnets.
Tags	Owner, Abteilung, Workload, Kostenstelle und ob du personenbezogene Daten verarbeitest. Siehe Namensgebung und Tags.
Genehmigungen, die deine Organisation verlangt	Viele Organisationen verlangen die Genehmigung des Product Owners sowie von Architektur und Security, bevor ein Workload erstellt wird, und eine Registrierung in einem Asset Register (CMDB). Das Plattform-Team kann diese Schritte nicht überspringen.
Internet-Exposition	Ob der Workload ins Internet veröffentlicht wird. Das bestimmt die management group und ob du das Application Gateway brauchst.
Ein Weg zu privaten Ressourcen	Ein verwaltetes Gerät und ein Netzwerkpfad (zum Beispiel VPN) für die Personen, die deployen.

Einen bestehenden Workload verschieben

Wenn der Workload bereits woanders läuft (on-premises, in einer anderen landing zone oder in einer anderen Cloud), folge den Phasen unter Einen Workload auf die Plattform migrieren. Die obigen Onboarding-Schritte sind der erste Teil dieses Weges.

Hinweise zum Betriebsmodell

• Managed (XMMS): Die Genehmigungen in den Schritten 4 und 5 liegen bei deiner Organisation (Design Authority, Security Officer). XMMS bereitet die Spokes vor und setzt sie um.
• Eigenbetrieb (self-managed): Dein Plattform-Team übernimmt zusätzlich die Rolle von Intake und Umsetzung. Ob die Schritte 3 bis 5 gelten, entscheidet deine Organisation.

Siehe Betriebsmodelle.