Plan-Phase¶
Die Plan-Phase macht aus einem vereinbarten Umfang ein Design, eine Liste von Stakeholdern und einen Zeitplan. Wenn sie abgeschlossen ist, weiß das Plattform-Team, was zu bauen ist, und der Kunde weiß, was er organisieren muss, bevor die Vorbereitung beginnt.
flowchart LR
a["Agreed scope<br/>(contract or project approval)"] --> b["Kick-off"] --> c["Workshop"] --> d["Design document<br/>or discovery sheet"] --> e["Gap analysis<br/>(if needed)"] --> f["Plan and prerequisites<br/>confirmed"]Schritte¶
| # | Schritt | Ergebnis |
|---|---|---|
| 1 | Bestätige, dass der Umfang vereinbart ist. Beginne im Managed-Modell erst, wenn der Vertrag unterschrieben ist. | Ein Startdatum |
| 2 | Plane Kick-off und Workshop und verschicke die Einladungen. | Termine in den Kalendern |
| 3 | Halte den Kick-off. | Gemeinsames Verständnis von Prozess, Personen, Zeitplan und Abhängigkeiten |
| 4 | Halte den Workshop. | Design-Entscheidungen, dokumentiert |
| 5 | Schreibe das Design-Dokument oder fülle das Discovery-Sheet aus. | Input für das Deployment |
| 6 | Kläre jede Lücke zwischen dem Design und der Standard-Plattform. | Eine Entscheidung pro Lücke: bauen oder weglassen |
| 7 | Bestätige die Voraussetzungen mit dem Kunden. | Eine datierte Liste, wer was organisiert |
Kick-off¶
Im Kick-off gehen das Plattform-Team und der Kunde den Prozess durch, die Personen, die für jede Aktivität nötig sind, die Antworten auf den Intake-Fragebogen, den Zeitplan und die Abhängigkeiten. Das Meeting wird meist vom Hauptimplementierer und vom Delivery Lead (dem Engagement Lead) gehalten.
Lade diese Rollen auf Kundenseite ein:
- Azure-Architekt
- Netzwerk-Spezialist oder -Engineer
- DevOps-Spezialist oder -Engineer
- Azure-Spezialist oder -Engineer
- Security-Spezialist
- Projekt- oder Delivery-Manager
Workshop: Design oder Discovery¶
Zwei Formen sind üblich. Wähle die, die zur Größe und Komplexität des Kunden passt.
| Form | Verwende sie, wenn | Ergebnis |
|---|---|---|
| Design-Workshop (High-Level Design, HLD) | Der Kunde ein vollständiges Design mit einem Dokument braucht, das ihm danach gehört | Ein Design-Dokument |
| Discovery-Workshop | Die Plattform standardmäßig geliefert wird und die Entscheidungen ein fester Satz von Fragen sind | Ein ausgefülltes Discovery-Sheet, das direkt auf Deployment-Werte abgebildet wird (Mapping) |
Ein Design-Workshop dauert je nach Komplexität meist etwa zwei Tage mit zwei oder mehr erfahrenen Azure-Architekten. Das Design-Dokument folgt innerhalb weniger Wochen. Nachdem der Kunde es akzeptiert hat, gehört ihm das Dokument, und er hält es aktuell.
Themen, die du entscheiden musst, egal welche Form du verwendest:
- welche Azure-Regionen verwendet werden und ob die Plattform single-region oder multi-region ist
- die Firewall-SKU und wie Ingress-Traffic behandelt wird (Application Gateway und WAF, oder nicht)
- Konnektivität zu anderen Netzwerken: Site-to-site-VPN, Point-to-site-VPN, ExpressRoute, BGP
- DDoS-Schutz, Bastion und andere optionale Features (feature flags)
- Azure DevOps oder GitHub für Repositorys und pipelines
- die management-group-Struktur und die subscriptions (siehe Voraussetzungen)
- der IP-Plan für den hub, das Job-runner-Netzwerk und die spokes
- Log-Aufbewahrung, Alert-Empfänger und der Security Contact
- wer Produktions-Deployments genehmigt und das PIM-Modell für das Plattform-Team
- das Betriebsmodell und die geltenden Service Levels
Lücken¶
Manchmal braucht der Kunde einen Dienst oder eine Konfiguration, die die Standard-Plattform nicht bietet. Führe eine Gap-Analyse durch und schätze den Aufwand. Lass den Kunden entscheiden, ob er in die Lücke investieren will. Wenn ja, plane sie als eigenes Item und beschreibe sie im Design-Dokument als Abweichung vom Standard. Siehe Neue Funktionalität bauen, wie neue Features ins Code-Repository kommen.
Halte dein Workshop-Template aktuell
Aktualisiere das Template nach jedem Workshop (Fragen, Standardantworten, neu gefundene Lücken), damit der nächste mit dem neuesten Wissen startet. Prüfe das Template regelmäßig mit den Personen, denen das Produkt gehört.
Meetings während der Implementierung¶
| Meeting | Zweck | Häufigkeit |
|---|---|---|
| Kick-off | Abstimmung zu Prozess, Personen, Planung | Einmal |
| Workshop | Die Design-Entscheidungen treffen | Einmal oder in Teilen |
| Stand-up | Plattform-Team und Projektleiter des Kunden prüfen Fortschritt und Hindernisse | Täglich oder jeden zweiten Tag |
| Steering Committee | Der Verantwortliche des Kunden und der Delivery Lead besprechen Risiken, Issues und Entscheidungen. Verwende das Report-Template. | Im Plan festgelegter Zeitraum |
| Technische Übergabe | Das Ergebnis zeigen und das Projekt abschließen | Einmal, am Ende (Übergabe) |
Ergebnis der Plan-Phase¶
Bevor du die Prepare-Phase startest, prüfe, dass du Folgendes hast:
- [ ] das Design-Dokument oder Discovery-Sheet, vom Kunden akzeptiert
- [ ] das ausgefüllte Mapping für die ersten hub-Werte
- [ ] die Liste der Stakeholder und ihrer Rollen
- [ ] Entscheidungen zu jeder Lücke, mit einer Schätzung für die, die gebaut werden
- [ ] Bestätigung jedes Punkts in den Voraussetzungen, mit Verantwortlichem und Datum
- [ ] den IP-Plan für den hub und für das Job-runner-Netzwerk
- [ ] einen Zeitplan für Vorbereitung, Deployment (inklusive Wartungsfenster, wenn der Kunde bestehenden Traffic hat), Validierung und Übergabe