{
  "source": {
    "repository": "https://github.com/APIOpsCycles/apiops-cycles-method-data",
    "commit": "7b08b3f320130e8707a245b3e0d4dc2499781792"
  },
  "locales": [
    "en",
    "fi",
    "fr",
    "de",
    "pt"
  ],
  "defaultLocale": "en",
  "translations": {
    "de": [
      {
        "id": "capability-productization-cycle:question-template-markdown",
        "cycleId": "capability-productization-cycle",
        "kind": "questions",
        "format": "markdown",
        "title": "Capability-Produktisierungszyklus question template Markdown",
        "body": "# Capability-Produktisierungszyklus question template\n\nEin Zyklus zum Definieren und Produktisieren wiederverwendbarer digitaler Fähigkeiten, ohne den Implementierungsstil im Voraus anzunehmen.\n\nUse this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.\n\n## 1. Capability-Strategie\n\nBeginnen Sie mit Customer Journey, Fähigkeitswert und Tragfähigkeitsnachweisen und validieren Sie dann, ob die vorgeschlagene wiederverwendbare digitale Fähigkeit weiterverfolgt werden soll.\n\n### Canvas questions\n#### Customer-Journey-Canvas\nWelche Journey erlebt der am weitesten außen liegende sinnvolle Kunde, und was sollte verbessert werden?\n- **Personas**: Wer ist der typische Kunde oder Nutzer, der diese Reise erlebt?\n- **Kunde erkennt Bedarf**: Wie erkennt der Kunde oder Nutzer ein Bedürfnis oder Problem?\n- **Kundenbedarf wird erfüllt**: Wie wird der Bedarf des Kunden oder Nutzers letztlich erfüllt?\n- **Customer Journey Schritte**: Welche Schritte durchläuft der Kunde bei der Reise?\n- **Probleme**: Welche Probleme oder Pain Points erlebt der Kunde oder Nutzer?\n- **Nutzen**: Welchen Gewinn oder Nutzen hat der Kunde?\n- **Eingaben & Ausgaben**: Was sind die Inputs und Outputs bei jedem Schritt?\n- **Interaktions- und Verarbeitungsregeln**: Wie lauten die Interaktions- und Verarbeitungsregeln bei jedem Schritt?\n- **Verbesserungsmöglichkeiten**: Welche Journey-Schritte zeigen, dass eine zugrunde liegende Capability oder ein Prozess geschaffen, verbessert, automatisiert oder entfernt werden sollte?\n\n#### Fähigkeits-Wertversprechen-Canvas\nWelche wiederverwendbare Capability würde Nutzern Wert liefern, ohne bereits zu entscheiden, ob sie als API, Event, Datei, Stream, Datenprodukt oder ein anderer Implementierungsstil bereitgestellt werden soll?\n- **Nutzeraufgaben und Ergebnisse**: Was möchten Nutzer, Partner, Systeme oder Teams erreichen?\n- **Nutzenstiftende Capability-Funktionen**: Welche Capability-Funktionen helfen Nutzern, bessere Ergebnisse, Geschwindigkeit, Automatisierung, Erkenntnisse, Reichweite oder Compliance zu erreichen?\n- **Pain-Point-reduzierende Capability-Funktionen**: Welche Capability-Funktionen reduzieren Reibung, manuelle Arbeit, Fehler, Verzögerungen, Risiken oder Unsicherheit für Nutzer?\n- **Wiederverwendbare Capabilities**: Welche wiederverwendbaren Geschäfts- oder Daten-Capabilities könnten diese Aufgaben, Nutzen und Pain Points über mehr als einen Nutzer oder Use Case hinweg unterstützen?\n\n#### Fähigkeits-Geschäftsmodell-Canvas\nWie tragfähig, wiederverwendbar, finanziert, verantwortet, unterstützt und auffindbar soll diese Fähigkeit sein?\n- **Wertversprechen der Capability**: Welchen Wert liefert diese wiederverwendbare Capability für Nutzer und für die Organisation oder das Ökosystem?\n- **Nutzersegmente der Capability**: Wer sind die aktuellen und potenziellen Nutzer der Capability, einschließlich Teams, Partnern, Systemen, Produkten oder Datennutzern?\n- **Nutzerinteraktion**: Wie werden Nutzer die Capability entdecken, bewerten, anfordern, onboarden, Unterstützung erhalten und Feedback geben?\n- **Kanäle**: Über welche Kataloge, Portale, Marktplätze, Dokumentationsseiten, Support-Wege oder Governance-Prozesse interagieren Nutzer mit der Capability?\n- **Schlüsselressourcen**: Welche Systeme, Datenbestände, Plattformen, Personen, Standards, Finanzierungen und operativen Fähigkeiten werden benötigt?\n- **Schlüsselaktivitäten**: Was müssen Capability Owner und Produzenten tun, um die Capability zu gestalten, bereitzustellen, zu steuern, zu unterstützen und zu verbessern?\n- **Schlüsselpartner**: Welche Partner aus Business, Technologie, Daten, Sicherheit, Recht, Plattform oder externen Organisationen werden benötigt, damit die Capability funktioniert?\n- **Nutzen**: Welcher geschäftliche, operative, ökologische, wiederverwendungsbezogene, Compliance- oder Kostennutzen rechtfertigt die Capability?\n- **Kosten**: Welche wesentlichen Kosten entstehen durch Aufbau, Betrieb, Governance, Support und Weiterentwicklung der Capability?\n\n#### Canvas zur Fähigkeitsvalidierung\nValidieren Sie, ob eine vorgeschlagene wiederverwendbare digitale Fähigkeit weiterverfolgt werden sollte.\n- **Zu validierende Fähigkeit**: Welche vorgeschlagene Fähigkeit und welcher Wiederverwendungsumfang werden geprüft?\n- **Wiederverwendete Nachweise**: Welche früheren Canvas-Ergebnisse stützen den Vorschlag?\n- **Kritische Annahmen**: Was könnte Wert, Wiederverwendung, Ownership, Nachhaltigkeit oder Akzeptanz ungültig machen?\n- **Minimalvalidierung**: Was ist die kleinste sinnvolle Validierung und welcher Erfolgsschwellenwert gilt?\n- **Entscheidung**: Fortfahren, eingrenzen, überarbeiten und erneut testen oder stoppen?\n\n### Before this station\n- [ ] Die Geschäftsziele sind definiert.\n- [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\n### Ready to leave when\n- [ ] Relevante Marktsignale, Feedback oder operative Erkenntnisse liegen vor, um diese Capability-Möglichkeit zu bewerten.\n- [ ] Die Geschäftsziele sind definiert.\n- [ ] Die Marktrecherche identifiziert relevante Capability-Möglichkeiten.\n- [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\n## 2. Verpflichtungen von Nutzern und Produzenten\n\nVereinbaren Sie gegenseitige Verpflichtungen von Owner, Produzenten und Nutzern für Zugriff, Service, Support, Änderungen und Lebenszyklus.\n\n### Canvas questions\n#### Canvas für Verpflichtungen von Fähigkeitsnutzern und -produzenten\nVereinbaren Sie gegenseitige Verpflichtungen für Bereitstellung und Nutzung einer wiederverwendbaren Fähigkeit.\n- **Ausgewählte Nutzer und Anwendungsfälle**: Welche Nutzer und Nutzungskontexte sind abgedeckt?\n- **Owner- und Produzentenverpflichtungen**: Was werden Owner und Produzenten bereitstellen, warten, überwachen und unterstützen?\n- **Nutzerverantwortlichkeiten**: Was müssen Nutzer für angemessene Nutzung, Zugriff, Tests und Feedback tun?\n- **Zugriff und Onboarding**: Welcher Discovery-, Genehmigungs-, Test- und Onboarding-Pfad ist vereinbart?\n- **Service und Lebenszyklus**: Welche Service-, Änderungs-, Deprecation- und Stilllegungsverpflichtungen sind vereinbart?\n- **Offene Verpflichtungen**: Was bleibt vor Architektur oder Lieferung ungeklärt?\n\n### Before this station\n- [ ] Relevante Marktsignale, Feedback oder operative Erkenntnisse liegen vor, um diese Capability-Möglichkeit zu bewerten.\n- [ ] Die Geschäftsziele sind definiert.\n- [ ] Die Marktrecherche identifiziert relevante Capability-Möglichkeiten.\n- [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\n### Ready to leave when\n- [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n- [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n- [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\n### Other related resources\n- **Leitfaden für Capability Consumer Onboarding**: Leitfaden für Capability Consumer Onboarding unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n- **Leitfaden für Serviceerwartungen wiederverwendbarer Fähigkeiten**: Leitfaden für Serviceerwartungen wiederverwendbarer Fähigkeiten unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n- **Leitfaden für Capability Ownership und Producer-Verantwortlichkeiten**: Leitfaden für Capability Ownership und Producer-Verantwortlichkeiten unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n\n## 3. Entscheidungen zu Fähigkeitsarchitektur und Plattform\n\nCapability Architecture & Platform Decisions: Führt die Definition wiederverwendbarer Fähigkeiten von Hypothese und Consumer-/Producer-Anforderungen über Architektur, Lösungsdesign, Lieferung, Readiness, Veröffentlichung und kontinuierliche Verbesserung.\n\n### Canvas questions\n#### Geschäftsauswirkungs-Canvas\nWelcher Wert, welches Risiko sowie welche betrieblichen, finanziellen, kunden-, mitarbeiter-, compliance- und strategischen Auswirkungen werden erwartet oder stehen auf dem Spiel?\n- **Erwartete Vorteile**: Welche geschäftlichen, kundenbezogenen, mitarbeiterbezogenen, qualitäts-, geschwindigkeits-, risiko-, compliance- oder strategischen Vorteile werden erwartet?\n- **Auswirkung auf die operative Effizienz**: Wie könnten Arbeitsaufwand, Wartezeit, Nacharbeit, Durchsatz, Zuverlässigkeit, Supportbelastung oder Betriebskosten sich verändern?\n- **Auswirkung auf Kunden und Mitarbeitende**: Wie werden Kunden, Mitarbeitende, Partner, Betreiber oder Supportteams die Veränderung erleben?\n- **Finanzielle Auswirkung**: Welche Auswirkungen auf Umsatz, Kosten, Investitionen, Einsparungen, vermiedene Verluste oder Finanzierung werden erwartet?\n- **Compliance- und strategische Auswirkung**: Welche regulatorischen, vertraglichen, richtlinienbezogenen, reputations-, markt-, ökosystem- oder strategischen Konsequenzen sind relevant?\n- **Auswirkung des Nicht-Fortfahrens**: Was geschieht, wenn die Capability, Automatisierung, Integration oder der Service nicht verbessert oder geliefert wird?\n- **Risiken und Kritikalität**: Welche Verfügbarkeits-, Sicherheits-, Daten-, Safety-, Prozess-, Akzeptanz- oder Business-Continuity-Risiken könnten das Ergebnis beeinflussen?\n- **Gegenmaßnahmen und Entscheidungsauswirkung**: Welche Gegenmaßnahmen, Einschränkungen, Kompromisse oder Restrisiken sollten Priorisierung, Architektur, Rollout oder Readiness-Entscheidungen beeinflussen?\n\n#### Standort-Canvas\nWelche geopolitischen, regulatorischen, Netzwerk- und Vertrauensgrenzen betreffen diese Capability oder Schnittstelle?\n- **Standort-/Vertrauensgruppen**: Welche geopolitischen, regulatorischen, netzwerkbezogenen oder vertrauensbezogenen Gruppen sind relevant?\n- **Gruppenmerkmale**: Was sind die Merkmale dieser Gruppen, wie z. B. Standort, Vertrauensstufe oder Netzwerkexposition?\n- **Relevante Standorte / Zonen**: Was sind die relevanten Standorte, Zonen oder Umgebungen innerhalb jeder Gruppe?\n- **Standort-/Zonenmerkmale**: Was sind die Merkmale dieser Standorte oder Zonen, wie z. B. Eigentumsverhältnisse, Region oder Exposition?\n- **Netzwerk- / Regulierungsentfernungen**: Welche Latenz-, Vertrauens-, Regulierungs- oder Konnektivitätsentfernungen bestehen zwischen den Standorten?\n- **Entfernungsmerkmale**: Was sind die Merkmale dieser Entfernungen, wie z. B. Latenzempfindlichkeit, Aufenthaltsbeschränkungen oder Vertrauensgrenzen?\n- **Konnektivitätsendpunkte**: Welche Konnektivitätsendpunkte oder Schnittstellen sind mit den Standorten verbunden?\n- **Endpunktzugriffseigenschaften**: Welche Eigenschaften weisen diese Endpunkte auf, wie z. B. Sichtbarkeit, Protokoll, Sicherheit oder Zugriffsbeschränkungen?\n\n#### Kapazitäts-Canvas\nWie viel Nachfrage, Last, Timing und Skalierungskapazität müssen für Fähigkeit, Automatisierung, Integration oder Service verstanden werden?\n- **Aktuelles Geschäftsvolumen**: Wie hoch sind das aktuelle Geschäftsvolumen und die Transaktionsraten?\n- **Zukünftige Konsumtrends**: Was sind die erwarteten künftigen Konsumtrends?\n- **Spitzenlast- und Verfügbarkeitsanforderungen**: Was sind die Spitzenlast- und Verfügbarkeitsanforderungen?\n- **Caching-Strategien**: Welche Caching-Strategien können zur Performanceoptimierung eingesetzt werden?\n- **Strategien zur Ratenbegrenzung**: Welche Strategien zur Ratenbegrenzung können genutzt werden, um die Nutzung zu steuern?\n- **Strategien zur Skalierung**: Welche Strategien zur Skalierung können eingesetzt werden, um das Wachstum zu unterstützen?\n\n#### Canvas für Fähigkeitsarchitektur-Entscheidung\nWählen Sie anhand bereits gesammelter Nachweise, wie die Fähigkeit geliefert wird.\n- **Wiederverwendete Eingaben**: Welche früheren Entscheidungen und Einschränkungen prägen die Umsetzungswahl?\n- **Tragfähige Optionen**: Welche API-, Event-, Workflow-, Anwendungs-, Datenprodukt-, Shared-Service-, menschlichen Service- oder hybriden Optionen bleiben tragfähig?\n- **Ausgewählter Ansatz**: Welcher Umsetzungsstil und welche unterstützende Plattform werden ausgewählt?\n- **Entscheidungsbegründung**: Warum passt der ausgewählte Ansatz am besten?\n- **Abgelehnte Alternativen**: Welche ernsthaften Alternativen wurden abgelehnt, und warum?\n- **Offene Risiken**: Was muss vor Lieferung oder Release noch validiert werden?\n\n### Before this station\n- [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n- [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n- [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\n### Ready to leave when\n- [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n- [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\n## 4. Fähigkeitslösungs- und Interaktionsdesign\n\nCapability Solution & Interaction Design: Führt die Definition wiederverwendbarer Fähigkeiten von Hypothese und Consumer-/Producer-Anforderungen über Architektur, Lösungsdesign, Lieferung, Readiness, Veröffentlichung und kontinuierliche Verbesserung.\n\n### Canvas questions\n#### Domänen-Canvas\nWelche wesentlichen Entitäten, Begriffe und Fachregeln muss die Capability oder Schnittstelle respektieren?\n- **Ausgewählte Customer Journey Schritte**: Welche Customer Journey Schritte sind für diese Domäne relevant?\n- **Grundlegende Entitäten & geschäftliche Bedeutung**: Welches sind die wesentlichen Entitäten und ihre Bedeutung für das Geschäft?\n- **Attribute & geschäftliche Wichtigkeit**: Welches sind die Schlüsselattribute der einzelnen Entitäten und ihre geschäftliche Wichtigkeit?\n- **Beziehungen zwischen Entitäten**: Welche Beziehungen bestehen zwischen den Entitäten?\n- **Fachregeln, Compliance und Integrität**: Welche Fachregeln sowie Compliance- und Integritätsanforderungen beziehen sich auf die Entitäten?\n- **Überlegungen zu Sicherheit und Datenschutz**: Welche Überlegungen zur Sicherheit und zum Datenschutz gibt es im Zusammenhang mit den Entitäten?\n\n#### Canvas für Fähigkeitslösungsdesign\nVerfeinern Sie den ausgewählten Umsetzungsstil zu einem klaren, nutzerorientierten Fähigkeitsdesign.\n- **Ausgewählte Eingaben**: Welche früheren Journey-, Wert-, Domänen-, Verpflichtungs- und Architekturentscheidungen werden wiederverwendet?\n- **Grenze und Interaktion**: Was gehört in die Fähigkeit, und wie nutzen Nutzer sie?\n- **Vertrag, Regeln und Ergebnisse**: Welches Verhalten, welche Verantwortlichkeiten, Eingaben, Ausgaben und Ergebnisse werden zugesagt?\n- **Fehler und Sicherheit**: Wie werden Ausnahmen, Zugriff, Datenschutz und Vertrauen behandelt?\n- **Lebenszyklus und Support**: Wie funktionieren Änderungen, Versionierung, Support, Deprecation und Stilllegung?\n- **Beobachtbarkeit**: Welche Health-, Nutzungs-, Qualitäts-, Wert- und Nutzersignale müssen sichtbar sein?\n\n#### Interaktions-Canvas\nWelche Arten von Interaktionen muss diese Capability oder Schnittstelle unterstützen, bevor ein konkretes Protokolldesign gewählt wird?\n- **CRUD Interaktionen**: Sind hier Interaktionen im CRUD-Stil erforderlich?\n- **CRUD Input- & Output-Modelle**: Was sind die Eingabe- und Ausgabemodelle für die CRUD-Interaktionen, falls dieser Stil benötigt wird?\n- **CRUD Verarbeitung & Validierung**: Was sind die Verarbeitungs- und Validierungsregeln für die CRUD-Interaktionen, falls dieser Stil benötigt wird?\n- **Abfragegesteuerte Interaktionen**: Welche Lese- oder Abfrageinteraktionen sind erforderlich, um Nutzerfragen zu beantworten?\n- **Abfragegesteuerte Input- & Output-Modelle**: Was sind die Eingabe- und Ausgabemodelle für die abfragegesteuerten Interaktionen?\n- **Abfragegesteuerte Verarbeitung & Validierung**: Was sind die Verarbeitungs- und Validierungsregeln für die abfragegesteuerten Interaktionen?\n- **Befehlsgesteuerte Interaktionen**: Welche Befehle zur Zustandsänderung sind gegebenenfalls erforderlich?\n- **Befehlsgesteuerte Input- & Output-Modelle**: Was sind die Eingabe- und Ausgabemodelle für die befehlsgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n- **Befehlsgesteuerte Verarbeitung & Validierung**: Was sind die Verarbeitungs- und Validierungsregeln für die befehlsgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n- **Eventgesteuerte Interaktionen**: Welche Ereignisse müssen gegebenenfalls veröffentlicht oder verarbeitet werden?\n- **Eventgesteuerte Input- & Output-Modelle**: Was sind die Eingabe- und Ausgabemodelle für die ereignisgesteuerten Interaktionen, falls dieser Stil erforderlich ist?\n- **Eventgesteuerte Verarbeitung & Validierung**: Was sind die Verarbeitungs- und Validierungsregeln für die ereignisgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n\n### Before this station\n- [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n- [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\n### Ready to leave when\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\n### Other related resources\n- **Contract-First Integration Design**: Guidance for validating integration contracts before delivery, including OpenAPI, AsyncAPI, event schemas, message schemas, file schemas, data contracts, and interface specifications.\n\n## 5. Bereitstellung und Betrieb der Fähigkeit\n\nCapability Delivery & Operations: Führt die Definition wiederverwendbarer Fähigkeiten von Hypothese und Consumer-/Producer-Anforderungen über Architektur, Lösungsdesign, Lieferung, Readiness, Veröffentlichung und kontinuierliche Verbesserung.\n\n### Canvas questions\n#### Canvas für Fähigkeitsbereitschaft und Betrieb\nBereiten Sie die minimal erforderlichen Betriebsnachweise vor der Fähigkeits-Readiness-Prüfung vor.\n- **Verantwortlichkeit**: Wer verantwortet Wert, Fähigkeitslebenszyklus, Produktion, Betrieb, Support und Änderungen?\n- **Umgebungen und Zugriff**: Sind erforderliche Umgebungen, Zugriffe, Berechtigungen und Credentials bereit?\n- **Testnachweise**: Was belegt Ergebnisse, Qualität, Sicherheit, Kompatibilität, Resilienz und Nutzerfreundlichkeit?\n- **Monitoring und Support**: Wie werden Health, Nutzung, Wert, Incidents, Nutzer und Betreiber unterstützt?\n- **Kontinuität und Wiederherstellung**: Wie läuft der Service weiter, degradiert sicher, wird wiederhergestellt oder fällt zurück?\n- **Readiness-Status**: Sind Service-Definitionen, Runbooks, Risiken, Bedingungen und blockierende Lücken klar?\n\n### Before this station\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\n### Ready to leave when\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\n### Other related resources\n- **Leitfaden zur Fähigkeitsbereitstellung**: Capability Delivery Guide unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n- **Leitfaden für Capability Testing und Validierung**: Leitfaden für Capability Testing und Validierung unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n- **Leitfaden für Capability CI/CD und Release**: Leitfaden für Capability CI/CD und Release unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n- **Leitfaden für operative Capability Ownership**: Leitfaden für operative Capability Ownership unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n- **Leitfaden für Capability Security und Zugriff**: Leitfaden für Capability Security und Zugriff unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n- **Leitfaden für Capability Support und Lifecycle**: Leitfaden für Capability Support und Lifecycle unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n\n## 6. Sicherstellung der Fähigkeitsbereitschaft\n\nCapability Readiness Assurance: Führt die Definition wiederverwendbarer Fähigkeiten von Hypothese und Consumer-/Producer-Anforderungen über Architektur, Lösungsdesign, Lieferung, Readiness, Veröffentlichung und kontinuierliche Verbesserung.\n\n### Station questions\n- Prüfen Sie abgeschlossenes Design, Testnachweise, Betriebsmodell, Berechtigungen, Credentials, Monitoring, Support, Fallback und Rollback.\n- Verifizieren Sie, dass bekannte Risiken, Ausnahmen, unsichere Aktionen, menschliche Aufsicht, Compliance-Anforderungen und offene Annahmen adressiert oder ausdrücklich akzeptiert sind.\n- Dokumentieren Sie blockierende Befunde, akzeptierte Restrisiken, Freigabebedingungen und erforderliche Remediation-Maßnahmen.\n- Entscheiden Sie, ob die Freigabe bereit, bedingt bereit, remediation-pflichtig oder nicht genehmigt ist.\n- Dokumentieren Sie Entscheidungsverantwortliche, Entscheidungsdatum und verwendete Nachweise.\n- Bestätigen Sie, dass nichts ohne klare fachliche und betriebliche Ownership freigegeben wird.\n- Nutzen Sie Bereitschaftsnachweise, um vor der Produktionsnutzung eine ausdrückliche Go-, bedingte Go- oder No-go-Entscheidung zu treffen.\n- Eine formale Bereitschaftsentscheidung verhindert, dass Automatisierungslösungen ohne klare Nachweise, akzeptierte Risiken, Remediation-Maßnahmen sowie fachliche und betriebliche Ownership freigegeben werden.\n\n### Before this station\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\n### Ready to leave when\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Die Schnittstelle und ihre Capabilities sind ausreichend klar für Review, Auditierung und Onboarding dokumentiert.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n- [ ] Der Schnittstellenvertrag wurde validiert und gegen funktionale und nicht-funktionale Anforderungen getestet.\n\n### Other related resources\n- **Checkliste zur Fähigkeitsbereitschaft**: Capability Readiness Checklist unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n- **Leitfaden für Capability Compliance und Governance**: Leitfaden für Capability Compliance und Governance unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n- **Checkliste für Capability Servicequalität**: Checkliste für Capability Servicequalität unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n\n## 7. Veröffentlichung und Befähigung der Fähigkeit\n\nCapability Publishing & Enablement: Führt die Definition wiederverwendbarer Fähigkeiten von Hypothese und Consumer-/Producer-Anforderungen über Architektur, Lösungsdesign, Lieferung, Readiness, Veröffentlichung und kontinuierliche Verbesserung.\n\n### Station questions\n- Betroffene Personen und geänderte Arbeit: Wer wird die Freigabe nutzen, betreiben, unterstützen, genehmigen, konsumieren oder davon betroffen sein, und welche Verantwortlichkeiten, Entscheidungen, Übergaben oder Arbeitsweisen ändern sich?\n- Aktivierungs- und Rollout-Ansatz: Wie werden Zugriff, Berechtigungen, Pilotnutzung, phasenweiser Rollout, eingeschränkte Gruppen, Parallelbetrieb und Rollout-Erweiterung gesteuert?\n- Enablement und Support: Welche Kommunikation, Schulung, Betriebsanweisungen und Supportpfade sind erforderlich?\n- Feedback und Kontrolle: Wie werden Adoption, Vertrauen, tatsächliche Nutzung, Probleme und unerwartetes Verhalten überwacht, und welche Bedingungen lösen Pause, Rollback oder Rückkehr zum manuellen Betrieb aus?\n- Planen Sie Rollout, Befähigung, Support, Feedback und Rollback, damit freigegebene Lösungen sicher eingeführt werden können.\n- Automatisierungslösungen schaffen erst nach dem Rollout Wert, wenn betroffene Personen und konsumierende Systeme verstehen, was sich ändert, wie Zugriff und Betrieb funktionieren, wo Unterstützung verfügbar ist und wann der Rollout pausiert, erweitert oder zurückgerollt werden muss.\n\n### Before this station\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Die Schnittstelle und ihre Capabilities sind ausreichend klar für Review, Auditierung und Onboarding dokumentiert.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n- [ ] Der Schnittstellenvertrag wurde validiert und gegen funktionale und nicht-funktionale Anforderungen getestet.\n\n### Ready to leave when\n- [ ] Die Lösung besteht Qualitäts-, Sicherheits-, Compliance- und Bereitschaftsprüfungen.\n- [ ] Audit-Ergebnisse und Maßnahmenentscheidungen wurden mit den relevanten Stakeholdern geteilt.\n- [ ] Die Capability ist bereit, über den gewählten Bereitstellungsmechanismus veröffentlicht oder ausgeliefert zu werden.\n- [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n\n### Other related resources\n- **Leitfaden für Capability Publishing und Discovery**: Leitfaden für Capability Publishing und Discovery unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n- **Leitfaden für Capability Consumer Onboarding**: Leitfaden für Capability Consumer Onboarding unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n- **Vorlage für Fähigkeits-Servicevereinbarung**: Capability Service Agreement Template unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n- **Leitfaden für Capability Versioning und Lifecycle**: Leitfaden für Capability Versioning und Lifecycle unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n\n## 8. Monitoring und Verbesserung der Fähigkeit\n\nCapability Monitoring & Improvement: Führt die Definition wiederverwendbarer Fähigkeiten von Hypothese und Consumer-/Producer-Anforderungen über Architektur, Lösungsdesign, Lieferung, Readiness, Veröffentlichung und kontinuierliche Verbesserung.\n\n### Station questions\n- Ergebnisse und Wert: Werden die erwarteten Prozess-, Nutzer- und Geschäftsergebnisse erreicht?\n- Betriebsleistung: Was zeigen erfolgreiche Läufe, Fehler, Teilabschlüsse, Ausnahmen, Wiederholungen, Timeouts, Interventionen, Verarbeitungszeit, Wartezeit und Kosten?\n- Nutzer-, Risiko- und Wiederherstellungssignale: Welche Fehler, Korrekturen, unsicheren Aktionen, Umgehungen, Misstrauen, Supportbedarfe, Fallback-Ereignisse oder Wiederherstellungsfehler treten auf?\n- Lernen und Lifecycle-Entscheidung: Welche Hypothesenannahmen wurden bestätigt oder verworfen, und sollte die Lösung verbessert, erweitert, eingeschränkt, neu gestaltet, pausiert oder stillgelegt werden?\n- Nutzen Sie operative, Nutzer-, Risiko- und Wertnachweise, um zu entscheiden, was verbessert, erweitert, eingeschränkt, pausiert oder stillgelegt werden soll.\n- Freigegebene Lösungen benötigen Nachweise, ob erwartete Ergebnisse erreicht werden, wo manuelle Intervention oder Wiederherstellung noch nötig ist und welche Lifecycle-Entscheidung als Nächstes getroffen werden sollte.\n\n### Before this station\n- [ ] Die Lösung besteht Qualitäts-, Sicherheits-, Compliance- und Bereitschaftsprüfungen.\n- [ ] Audit-Ergebnisse und Maßnahmenentscheidungen wurden mit den relevanten Stakeholdern geteilt.\n- [ ] Die Capability ist bereit, über den gewählten Bereitstellungsmechanismus veröffentlicht oder ausgeliefert zu werden.\n- [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n\n### Ready to leave when\n- [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n- [ ] Onboarding-, Support- und Kommunikationsprozesse für Nutzer sind bereit.\n- [ ] Rechtliche, Datenschutz- und Compliance-Anforderungen für Veröffentlichung oder Release sind definiert und verstanden.\n\n### Other related resources\n- **Capability Monitoring und Wertmetriken**: Capability Monitoring und Wertmetriken unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n- **Leitfaden für Capability Adoption und Wiederverwendung**: Leitfaden für Capability Adoption und Wiederverwendung unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n- **Leitfaden für Capability Consumer Feedback**: Leitfaden für Capability Consumer Feedback unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n- **Leitfaden für Capability Lifecycle Management**: Leitfaden für Capability Lifecycle Management unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten."
      },
      {
        "id": "capability-productization-cycle:question-template-confluence-wiki",
        "cycleId": "capability-productization-cycle",
        "kind": "questions",
        "format": "confluence-wiki",
        "title": "Capability-Produktisierungszyklus question template Confluence wiki",
        "body": "h1. Capability-Produktisierungszyklus question template\n\nEin Zyklus zum Definieren und Produktisieren wiederverwendbarer digitaler Fähigkeiten, ohne den Implementierungsstil im Voraus anzunehmen.\n\nUse this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.\n\nh2. 1. Capability-Strategie\n\nBeginnen Sie mit Customer Journey, Fähigkeitswert und Tragfähigkeitsnachweisen und validieren Sie dann, ob die vorgeschlagene wiederverwendbare digitale Fähigkeit weiterverfolgt werden soll.\n\nh3. Canvas questions\nh4. Customer-Journey-Canvas\nWelche Journey erlebt der am weitesten außen liegende sinnvolle Kunde, und was sollte verbessert werden?\n* *Personas*: Wer ist der typische Kunde oder Nutzer, der diese Reise erlebt?\n* *Kunde erkennt Bedarf*: Wie erkennt der Kunde oder Nutzer ein Bedürfnis oder Problem?\n* *Kundenbedarf wird erfüllt*: Wie wird der Bedarf des Kunden oder Nutzers letztlich erfüllt?\n* *Customer Journey Schritte*: Welche Schritte durchläuft der Kunde bei der Reise?\n* *Probleme*: Welche Probleme oder Pain Points erlebt der Kunde oder Nutzer?\n* *Nutzen*: Welchen Gewinn oder Nutzen hat der Kunde?\n* *Eingaben & Ausgaben*: Was sind die Inputs und Outputs bei jedem Schritt?\n* *Interaktions- und Verarbeitungsregeln*: Wie lauten die Interaktions- und Verarbeitungsregeln bei jedem Schritt?\n* *Verbesserungsmöglichkeiten*: Welche Journey-Schritte zeigen, dass eine zugrunde liegende Capability oder ein Prozess geschaffen, verbessert, automatisiert oder entfernt werden sollte?\n\nh4. Fähigkeits-Wertversprechen-Canvas\nWelche wiederverwendbare Capability würde Nutzern Wert liefern, ohne bereits zu entscheiden, ob sie als API, Event, Datei, Stream, Datenprodukt oder ein anderer Implementierungsstil bereitgestellt werden soll?\n* *Nutzeraufgaben und Ergebnisse*: Was möchten Nutzer, Partner, Systeme oder Teams erreichen?\n* *Nutzenstiftende Capability-Funktionen*: Welche Capability-Funktionen helfen Nutzern, bessere Ergebnisse, Geschwindigkeit, Automatisierung, Erkenntnisse, Reichweite oder Compliance zu erreichen?\n* *Pain-Point-reduzierende Capability-Funktionen*: Welche Capability-Funktionen reduzieren Reibung, manuelle Arbeit, Fehler, Verzögerungen, Risiken oder Unsicherheit für Nutzer?\n* *Wiederverwendbare Capabilities*: Welche wiederverwendbaren Geschäfts- oder Daten-Capabilities könnten diese Aufgaben, Nutzen und Pain Points über mehr als einen Nutzer oder Use Case hinweg unterstützen?\n\nh4. Fähigkeits-Geschäftsmodell-Canvas\nWie tragfähig, wiederverwendbar, finanziert, verantwortet, unterstützt und auffindbar soll diese Fähigkeit sein?\n* *Wertversprechen der Capability*: Welchen Wert liefert diese wiederverwendbare Capability für Nutzer und für die Organisation oder das Ökosystem?\n* *Nutzersegmente der Capability*: Wer sind die aktuellen und potenziellen Nutzer der Capability, einschließlich Teams, Partnern, Systemen, Produkten oder Datennutzern?\n* *Nutzerinteraktion*: Wie werden Nutzer die Capability entdecken, bewerten, anfordern, onboarden, Unterstützung erhalten und Feedback geben?\n* *Kanäle*: Über welche Kataloge, Portale, Marktplätze, Dokumentationsseiten, Support-Wege oder Governance-Prozesse interagieren Nutzer mit der Capability?\n* *Schlüsselressourcen*: Welche Systeme, Datenbestände, Plattformen, Personen, Standards, Finanzierungen und operativen Fähigkeiten werden benötigt?\n* *Schlüsselaktivitäten*: Was müssen Capability Owner und Produzenten tun, um die Capability zu gestalten, bereitzustellen, zu steuern, zu unterstützen und zu verbessern?\n* *Schlüsselpartner*: Welche Partner aus Business, Technologie, Daten, Sicherheit, Recht, Plattform oder externen Organisationen werden benötigt, damit die Capability funktioniert?\n* *Nutzen*: Welcher geschäftliche, operative, ökologische, wiederverwendungsbezogene, Compliance- oder Kostennutzen rechtfertigt die Capability?\n* *Kosten*: Welche wesentlichen Kosten entstehen durch Aufbau, Betrieb, Governance, Support und Weiterentwicklung der Capability?\n\nh4. Canvas zur Fähigkeitsvalidierung\nValidieren Sie, ob eine vorgeschlagene wiederverwendbare digitale Fähigkeit weiterverfolgt werden sollte.\n* *Zu validierende Fähigkeit*: Welche vorgeschlagene Fähigkeit und welcher Wiederverwendungsumfang werden geprüft?\n* *Wiederverwendete Nachweise*: Welche früheren Canvas-Ergebnisse stützen den Vorschlag?\n* *Kritische Annahmen*: Was könnte Wert, Wiederverwendung, Ownership, Nachhaltigkeit oder Akzeptanz ungültig machen?\n* *Minimalvalidierung*: Was ist die kleinste sinnvolle Validierung und welcher Erfolgsschwellenwert gilt?\n* *Entscheidung*: Fortfahren, eingrenzen, überarbeiten und erneut testen oder stoppen?\n\nh3. Before this station\n* [ ] Die Geschäftsziele sind definiert.\n* [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\nh3. Ready to leave when\n* [ ] Relevante Marktsignale, Feedback oder operative Erkenntnisse liegen vor, um diese Capability-Möglichkeit zu bewerten.\n* [ ] Die Geschäftsziele sind definiert.\n* [ ] Die Marktrecherche identifiziert relevante Capability-Möglichkeiten.\n* [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\nh2. 2. Verpflichtungen von Nutzern und Produzenten\n\nVereinbaren Sie gegenseitige Verpflichtungen von Owner, Produzenten und Nutzern für Zugriff, Service, Support, Änderungen und Lebenszyklus.\n\nh3. Canvas questions\nh4. Canvas für Verpflichtungen von Fähigkeitsnutzern und -produzenten\nVereinbaren Sie gegenseitige Verpflichtungen für Bereitstellung und Nutzung einer wiederverwendbaren Fähigkeit.\n* *Ausgewählte Nutzer und Anwendungsfälle*: Welche Nutzer und Nutzungskontexte sind abgedeckt?\n* *Owner- und Produzentenverpflichtungen*: Was werden Owner und Produzenten bereitstellen, warten, überwachen und unterstützen?\n* *Nutzerverantwortlichkeiten*: Was müssen Nutzer für angemessene Nutzung, Zugriff, Tests und Feedback tun?\n* *Zugriff und Onboarding*: Welcher Discovery-, Genehmigungs-, Test- und Onboarding-Pfad ist vereinbart?\n* *Service und Lebenszyklus*: Welche Service-, Änderungs-, Deprecation- und Stilllegungsverpflichtungen sind vereinbart?\n* *Offene Verpflichtungen*: Was bleibt vor Architektur oder Lieferung ungeklärt?\n\nh3. Before this station\n* [ ] Relevante Marktsignale, Feedback oder operative Erkenntnisse liegen vor, um diese Capability-Möglichkeit zu bewerten.\n* [ ] Die Geschäftsziele sind definiert.\n* [ ] Die Marktrecherche identifiziert relevante Capability-Möglichkeiten.\n* [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\nh3. Ready to leave when\n* [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n* [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n* [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\nh3. Other related resources\n* *Leitfaden für Capability Consumer Onboarding*: Leitfaden für Capability Consumer Onboarding unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n* *Leitfaden für Serviceerwartungen wiederverwendbarer Fähigkeiten*: Leitfaden für Serviceerwartungen wiederverwendbarer Fähigkeiten unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n* *Leitfaden für Capability Ownership und Producer-Verantwortlichkeiten*: Leitfaden für Capability Ownership und Producer-Verantwortlichkeiten unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n\nh2. 3. Entscheidungen zu Fähigkeitsarchitektur und Plattform\n\nCapability Architecture & Platform Decisions: Führt die Definition wiederverwendbarer Fähigkeiten von Hypothese und Consumer-/Producer-Anforderungen über Architektur, Lösungsdesign, Lieferung, Readiness, Veröffentlichung und kontinuierliche Verbesserung.\n\nh3. Canvas questions\nh4. Geschäftsauswirkungs-Canvas\nWelcher Wert, welches Risiko sowie welche betrieblichen, finanziellen, kunden-, mitarbeiter-, compliance- und strategischen Auswirkungen werden erwartet oder stehen auf dem Spiel?\n* *Erwartete Vorteile*: Welche geschäftlichen, kundenbezogenen, mitarbeiterbezogenen, qualitäts-, geschwindigkeits-, risiko-, compliance- oder strategischen Vorteile werden erwartet?\n* *Auswirkung auf die operative Effizienz*: Wie könnten Arbeitsaufwand, Wartezeit, Nacharbeit, Durchsatz, Zuverlässigkeit, Supportbelastung oder Betriebskosten sich verändern?\n* *Auswirkung auf Kunden und Mitarbeitende*: Wie werden Kunden, Mitarbeitende, Partner, Betreiber oder Supportteams die Veränderung erleben?\n* *Finanzielle Auswirkung*: Welche Auswirkungen auf Umsatz, Kosten, Investitionen, Einsparungen, vermiedene Verluste oder Finanzierung werden erwartet?\n* *Compliance- und strategische Auswirkung*: Welche regulatorischen, vertraglichen, richtlinienbezogenen, reputations-, markt-, ökosystem- oder strategischen Konsequenzen sind relevant?\n* *Auswirkung des Nicht-Fortfahrens*: Was geschieht, wenn die Capability, Automatisierung, Integration oder der Service nicht verbessert oder geliefert wird?\n* *Risiken und Kritikalität*: Welche Verfügbarkeits-, Sicherheits-, Daten-, Safety-, Prozess-, Akzeptanz- oder Business-Continuity-Risiken könnten das Ergebnis beeinflussen?\n* *Gegenmaßnahmen und Entscheidungsauswirkung*: Welche Gegenmaßnahmen, Einschränkungen, Kompromisse oder Restrisiken sollten Priorisierung, Architektur, Rollout oder Readiness-Entscheidungen beeinflussen?\n\nh4. Standort-Canvas\nWelche geopolitischen, regulatorischen, Netzwerk- und Vertrauensgrenzen betreffen diese Capability oder Schnittstelle?\n* *Standort-/Vertrauensgruppen*: Welche geopolitischen, regulatorischen, netzwerkbezogenen oder vertrauensbezogenen Gruppen sind relevant?\n* *Gruppenmerkmale*: Was sind die Merkmale dieser Gruppen, wie z. B. Standort, Vertrauensstufe oder Netzwerkexposition?\n* *Relevante Standorte / Zonen*: Was sind die relevanten Standorte, Zonen oder Umgebungen innerhalb jeder Gruppe?\n* *Standort-/Zonenmerkmale*: Was sind die Merkmale dieser Standorte oder Zonen, wie z. B. Eigentumsverhältnisse, Region oder Exposition?\n* *Netzwerk- / Regulierungsentfernungen*: Welche Latenz-, Vertrauens-, Regulierungs- oder Konnektivitätsentfernungen bestehen zwischen den Standorten?\n* *Entfernungsmerkmale*: Was sind die Merkmale dieser Entfernungen, wie z. B. Latenzempfindlichkeit, Aufenthaltsbeschränkungen oder Vertrauensgrenzen?\n* *Konnektivitätsendpunkte*: Welche Konnektivitätsendpunkte oder Schnittstellen sind mit den Standorten verbunden?\n* *Endpunktzugriffseigenschaften*: Welche Eigenschaften weisen diese Endpunkte auf, wie z. B. Sichtbarkeit, Protokoll, Sicherheit oder Zugriffsbeschränkungen?\n\nh4. Kapazitäts-Canvas\nWie viel Nachfrage, Last, Timing und Skalierungskapazität müssen für Fähigkeit, Automatisierung, Integration oder Service verstanden werden?\n* *Aktuelles Geschäftsvolumen*: Wie hoch sind das aktuelle Geschäftsvolumen und die Transaktionsraten?\n* *Zukünftige Konsumtrends*: Was sind die erwarteten künftigen Konsumtrends?\n* *Spitzenlast- und Verfügbarkeitsanforderungen*: Was sind die Spitzenlast- und Verfügbarkeitsanforderungen?\n* *Caching-Strategien*: Welche Caching-Strategien können zur Performanceoptimierung eingesetzt werden?\n* *Strategien zur Ratenbegrenzung*: Welche Strategien zur Ratenbegrenzung können genutzt werden, um die Nutzung zu steuern?\n* *Strategien zur Skalierung*: Welche Strategien zur Skalierung können eingesetzt werden, um das Wachstum zu unterstützen?\n\nh4. Canvas für Fähigkeitsarchitektur-Entscheidung\nWählen Sie anhand bereits gesammelter Nachweise, wie die Fähigkeit geliefert wird.\n* *Wiederverwendete Eingaben*: Welche früheren Entscheidungen und Einschränkungen prägen die Umsetzungswahl?\n* *Tragfähige Optionen*: Welche API-, Event-, Workflow-, Anwendungs-, Datenprodukt-, Shared-Service-, menschlichen Service- oder hybriden Optionen bleiben tragfähig?\n* *Ausgewählter Ansatz*: Welcher Umsetzungsstil und welche unterstützende Plattform werden ausgewählt?\n* *Entscheidungsbegründung*: Warum passt der ausgewählte Ansatz am besten?\n* *Abgelehnte Alternativen*: Welche ernsthaften Alternativen wurden abgelehnt, und warum?\n* *Offene Risiken*: Was muss vor Lieferung oder Release noch validiert werden?\n\nh3. Before this station\n* [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n* [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n* [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\nh3. Ready to leave when\n* [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n* [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\nh2. 4. Fähigkeitslösungs- und Interaktionsdesign\n\nCapability Solution & Interaction Design: Führt die Definition wiederverwendbarer Fähigkeiten von Hypothese und Consumer-/Producer-Anforderungen über Architektur, Lösungsdesign, Lieferung, Readiness, Veröffentlichung und kontinuierliche Verbesserung.\n\nh3. Canvas questions\nh4. Domänen-Canvas\nWelche wesentlichen Entitäten, Begriffe und Fachregeln muss die Capability oder Schnittstelle respektieren?\n* *Ausgewählte Customer Journey Schritte*: Welche Customer Journey Schritte sind für diese Domäne relevant?\n* *Grundlegende Entitäten & geschäftliche Bedeutung*: Welches sind die wesentlichen Entitäten und ihre Bedeutung für das Geschäft?\n* *Attribute & geschäftliche Wichtigkeit*: Welches sind die Schlüsselattribute der einzelnen Entitäten und ihre geschäftliche Wichtigkeit?\n* *Beziehungen zwischen Entitäten*: Welche Beziehungen bestehen zwischen den Entitäten?\n* *Fachregeln, Compliance und Integrität*: Welche Fachregeln sowie Compliance- und Integritätsanforderungen beziehen sich auf die Entitäten?\n* *Überlegungen zu Sicherheit und Datenschutz*: Welche Überlegungen zur Sicherheit und zum Datenschutz gibt es im Zusammenhang mit den Entitäten?\n\nh4. Canvas für Fähigkeitslösungsdesign\nVerfeinern Sie den ausgewählten Umsetzungsstil zu einem klaren, nutzerorientierten Fähigkeitsdesign.\n* *Ausgewählte Eingaben*: Welche früheren Journey-, Wert-, Domänen-, Verpflichtungs- und Architekturentscheidungen werden wiederverwendet?\n* *Grenze und Interaktion*: Was gehört in die Fähigkeit, und wie nutzen Nutzer sie?\n* *Vertrag, Regeln und Ergebnisse*: Welches Verhalten, welche Verantwortlichkeiten, Eingaben, Ausgaben und Ergebnisse werden zugesagt?\n* *Fehler und Sicherheit*: Wie werden Ausnahmen, Zugriff, Datenschutz und Vertrauen behandelt?\n* *Lebenszyklus und Support*: Wie funktionieren Änderungen, Versionierung, Support, Deprecation und Stilllegung?\n* *Beobachtbarkeit*: Welche Health-, Nutzungs-, Qualitäts-, Wert- und Nutzersignale müssen sichtbar sein?\n\nh4. Interaktions-Canvas\nWelche Arten von Interaktionen muss diese Capability oder Schnittstelle unterstützen, bevor ein konkretes Protokolldesign gewählt wird?\n* *CRUD Interaktionen*: Sind hier Interaktionen im CRUD-Stil erforderlich?\n* *CRUD Input- & Output-Modelle*: Was sind die Eingabe- und Ausgabemodelle für die CRUD-Interaktionen, falls dieser Stil benötigt wird?\n* *CRUD Verarbeitung & Validierung*: Was sind die Verarbeitungs- und Validierungsregeln für die CRUD-Interaktionen, falls dieser Stil benötigt wird?\n* *Abfragegesteuerte Interaktionen*: Welche Lese- oder Abfrageinteraktionen sind erforderlich, um Nutzerfragen zu beantworten?\n* *Abfragegesteuerte Input- & Output-Modelle*: Was sind die Eingabe- und Ausgabemodelle für die abfragegesteuerten Interaktionen?\n* *Abfragegesteuerte Verarbeitung & Validierung*: Was sind die Verarbeitungs- und Validierungsregeln für die abfragegesteuerten Interaktionen?\n* *Befehlsgesteuerte Interaktionen*: Welche Befehle zur Zustandsänderung sind gegebenenfalls erforderlich?\n* *Befehlsgesteuerte Input- & Output-Modelle*: Was sind die Eingabe- und Ausgabemodelle für die befehlsgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n* *Befehlsgesteuerte Verarbeitung & Validierung*: Was sind die Verarbeitungs- und Validierungsregeln für die befehlsgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n* *Eventgesteuerte Interaktionen*: Welche Ereignisse müssen gegebenenfalls veröffentlicht oder verarbeitet werden?\n* *Eventgesteuerte Input- & Output-Modelle*: Was sind die Eingabe- und Ausgabemodelle für die ereignisgesteuerten Interaktionen, falls dieser Stil erforderlich ist?\n* *Eventgesteuerte Verarbeitung & Validierung*: Was sind die Verarbeitungs- und Validierungsregeln für die ereignisgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n\nh3. Before this station\n* [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n* [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\nh3. Ready to leave when\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\nh3. Other related resources\n* *Contract-First Integration Design*: Guidance for validating integration contracts before delivery, including OpenAPI, AsyncAPI, event schemas, message schemas, file schemas, data contracts, and interface specifications.\n\nh2. 5. Bereitstellung und Betrieb der Fähigkeit\n\nCapability Delivery & Operations: Führt die Definition wiederverwendbarer Fähigkeiten von Hypothese und Consumer-/Producer-Anforderungen über Architektur, Lösungsdesign, Lieferung, Readiness, Veröffentlichung und kontinuierliche Verbesserung.\n\nh3. Canvas questions\nh4. Canvas für Fähigkeitsbereitschaft und Betrieb\nBereiten Sie die minimal erforderlichen Betriebsnachweise vor der Fähigkeits-Readiness-Prüfung vor.\n* *Verantwortlichkeit*: Wer verantwortet Wert, Fähigkeitslebenszyklus, Produktion, Betrieb, Support und Änderungen?\n* *Umgebungen und Zugriff*: Sind erforderliche Umgebungen, Zugriffe, Berechtigungen und Credentials bereit?\n* *Testnachweise*: Was belegt Ergebnisse, Qualität, Sicherheit, Kompatibilität, Resilienz und Nutzerfreundlichkeit?\n* *Monitoring und Support*: Wie werden Health, Nutzung, Wert, Incidents, Nutzer und Betreiber unterstützt?\n* *Kontinuität und Wiederherstellung*: Wie läuft der Service weiter, degradiert sicher, wird wiederhergestellt oder fällt zurück?\n* *Readiness-Status*: Sind Service-Definitionen, Runbooks, Risiken, Bedingungen und blockierende Lücken klar?\n\nh3. Before this station\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\nh3. Ready to leave when\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\nh3. Other related resources\n* *Leitfaden zur Fähigkeitsbereitstellung*: Capability Delivery Guide unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n* *Leitfaden für Capability Testing und Validierung*: Leitfaden für Capability Testing und Validierung unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n* *Leitfaden für Capability CI/CD und Release*: Leitfaden für Capability CI/CD und Release unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n* *Leitfaden für operative Capability Ownership*: Leitfaden für operative Capability Ownership unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n* *Leitfaden für Capability Security und Zugriff*: Leitfaden für Capability Security und Zugriff unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n* *Leitfaden für Capability Support und Lifecycle*: Leitfaden für Capability Support und Lifecycle unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n\nh2. 6. Sicherstellung der Fähigkeitsbereitschaft\n\nCapability Readiness Assurance: Führt die Definition wiederverwendbarer Fähigkeiten von Hypothese und Consumer-/Producer-Anforderungen über Architektur, Lösungsdesign, Lieferung, Readiness, Veröffentlichung und kontinuierliche Verbesserung.\n\nh3. Station questions\n* Prüfen Sie abgeschlossenes Design, Testnachweise, Betriebsmodell, Berechtigungen, Credentials, Monitoring, Support, Fallback und Rollback.\n* Verifizieren Sie, dass bekannte Risiken, Ausnahmen, unsichere Aktionen, menschliche Aufsicht, Compliance-Anforderungen und offene Annahmen adressiert oder ausdrücklich akzeptiert sind.\n* Dokumentieren Sie blockierende Befunde, akzeptierte Restrisiken, Freigabebedingungen und erforderliche Remediation-Maßnahmen.\n* Entscheiden Sie, ob die Freigabe bereit, bedingt bereit, remediation-pflichtig oder nicht genehmigt ist.\n* Dokumentieren Sie Entscheidungsverantwortliche, Entscheidungsdatum und verwendete Nachweise.\n* Bestätigen Sie, dass nichts ohne klare fachliche und betriebliche Ownership freigegeben wird.\n* Nutzen Sie Bereitschaftsnachweise, um vor der Produktionsnutzung eine ausdrückliche Go-, bedingte Go- oder No-go-Entscheidung zu treffen.\n* Eine formale Bereitschaftsentscheidung verhindert, dass Automatisierungslösungen ohne klare Nachweise, akzeptierte Risiken, Remediation-Maßnahmen sowie fachliche und betriebliche Ownership freigegeben werden.\n\nh3. Before this station\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\nh3. Ready to leave when\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Die Schnittstelle und ihre Capabilities sind ausreichend klar für Review, Auditierung und Onboarding dokumentiert.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n* [ ] Der Schnittstellenvertrag wurde validiert und gegen funktionale und nicht-funktionale Anforderungen getestet.\n\nh3. Other related resources\n* *Checkliste zur Fähigkeitsbereitschaft*: Capability Readiness Checklist unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n* *Leitfaden für Capability Compliance und Governance*: Leitfaden für Capability Compliance und Governance unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n* *Checkliste für Capability Servicequalität*: Checkliste für Capability Servicequalität unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n\nh2. 7. Veröffentlichung und Befähigung der Fähigkeit\n\nCapability Publishing & Enablement: Führt die Definition wiederverwendbarer Fähigkeiten von Hypothese und Consumer-/Producer-Anforderungen über Architektur, Lösungsdesign, Lieferung, Readiness, Veröffentlichung und kontinuierliche Verbesserung.\n\nh3. Station questions\n* Betroffene Personen und geänderte Arbeit: Wer wird die Freigabe nutzen, betreiben, unterstützen, genehmigen, konsumieren oder davon betroffen sein, und welche Verantwortlichkeiten, Entscheidungen, Übergaben oder Arbeitsweisen ändern sich?\n* Aktivierungs- und Rollout-Ansatz: Wie werden Zugriff, Berechtigungen, Pilotnutzung, phasenweiser Rollout, eingeschränkte Gruppen, Parallelbetrieb und Rollout-Erweiterung gesteuert?\n* Enablement und Support: Welche Kommunikation, Schulung, Betriebsanweisungen und Supportpfade sind erforderlich?\n* Feedback und Kontrolle: Wie werden Adoption, Vertrauen, tatsächliche Nutzung, Probleme und unerwartetes Verhalten überwacht, und welche Bedingungen lösen Pause, Rollback oder Rückkehr zum manuellen Betrieb aus?\n* Planen Sie Rollout, Befähigung, Support, Feedback und Rollback, damit freigegebene Lösungen sicher eingeführt werden können.\n* Automatisierungslösungen schaffen erst nach dem Rollout Wert, wenn betroffene Personen und konsumierende Systeme verstehen, was sich ändert, wie Zugriff und Betrieb funktionieren, wo Unterstützung verfügbar ist und wann der Rollout pausiert, erweitert oder zurückgerollt werden muss.\n\nh3. Before this station\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Die Schnittstelle und ihre Capabilities sind ausreichend klar für Review, Auditierung und Onboarding dokumentiert.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n* [ ] Der Schnittstellenvertrag wurde validiert und gegen funktionale und nicht-funktionale Anforderungen getestet.\n\nh3. Ready to leave when\n* [ ] Die Lösung besteht Qualitäts-, Sicherheits-, Compliance- und Bereitschaftsprüfungen.\n* [ ] Audit-Ergebnisse und Maßnahmenentscheidungen wurden mit den relevanten Stakeholdern geteilt.\n* [ ] Die Capability ist bereit, über den gewählten Bereitstellungsmechanismus veröffentlicht oder ausgeliefert zu werden.\n* [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n\nh3. Other related resources\n* *Leitfaden für Capability Publishing und Discovery*: Leitfaden für Capability Publishing und Discovery unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n* *Leitfaden für Capability Consumer Onboarding*: Leitfaden für Capability Consumer Onboarding unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n* *Vorlage für Fähigkeits-Servicevereinbarung*: Capability Service Agreement Template unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n* *Leitfaden für Capability Versioning und Lifecycle*: Leitfaden für Capability Versioning und Lifecycle unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n\nh2. 8. Monitoring und Verbesserung der Fähigkeit\n\nCapability Monitoring & Improvement: Führt die Definition wiederverwendbarer Fähigkeiten von Hypothese und Consumer-/Producer-Anforderungen über Architektur, Lösungsdesign, Lieferung, Readiness, Veröffentlichung und kontinuierliche Verbesserung.\n\nh3. Station questions\n* Ergebnisse und Wert: Werden die erwarteten Prozess-, Nutzer- und Geschäftsergebnisse erreicht?\n* Betriebsleistung: Was zeigen erfolgreiche Läufe, Fehler, Teilabschlüsse, Ausnahmen, Wiederholungen, Timeouts, Interventionen, Verarbeitungszeit, Wartezeit und Kosten?\n* Nutzer-, Risiko- und Wiederherstellungssignale: Welche Fehler, Korrekturen, unsicheren Aktionen, Umgehungen, Misstrauen, Supportbedarfe, Fallback-Ereignisse oder Wiederherstellungsfehler treten auf?\n* Lernen und Lifecycle-Entscheidung: Welche Hypothesenannahmen wurden bestätigt oder verworfen, und sollte die Lösung verbessert, erweitert, eingeschränkt, neu gestaltet, pausiert oder stillgelegt werden?\n* Nutzen Sie operative, Nutzer-, Risiko- und Wertnachweise, um zu entscheiden, was verbessert, erweitert, eingeschränkt, pausiert oder stillgelegt werden soll.\n* Freigegebene Lösungen benötigen Nachweise, ob erwartete Ergebnisse erreicht werden, wo manuelle Intervention oder Wiederherstellung noch nötig ist und welche Lifecycle-Entscheidung als Nächstes getroffen werden sollte.\n\nh3. Before this station\n* [ ] Die Lösung besteht Qualitäts-, Sicherheits-, Compliance- und Bereitschaftsprüfungen.\n* [ ] Audit-Ergebnisse und Maßnahmenentscheidungen wurden mit den relevanten Stakeholdern geteilt.\n* [ ] Die Capability ist bereit, über den gewählten Bereitstellungsmechanismus veröffentlicht oder ausgeliefert zu werden.\n* [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n\nh3. Ready to leave when\n* [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n* [ ] Onboarding-, Support- und Kommunikationsprozesse für Nutzer sind bereit.\n* [ ] Rechtliche, Datenschutz- und Compliance-Anforderungen für Veröffentlichung oder Release sind definiert und verstanden.\n\nh3. Other related resources\n* *Capability Monitoring und Wertmetriken*: Capability Monitoring und Wertmetriken unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n* *Leitfaden für Capability Adoption und Wiederverwendung*: Leitfaden für Capability Adoption und Wiederverwendung unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n* *Leitfaden für Capability Consumer Feedback*: Leitfaden für Capability Consumer Feedback unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten.\n* *Leitfaden für Capability Lifecycle Management*: Leitfaden für Capability Lifecycle Management unterstützt den jeweiligen Capability-Schritt mit spezifischen Entscheidungen, Nachweisen, Verantwortlichkeiten, Risiken und nächsten Schritten."
      },
      {
        "id": "api-productization-cycle:question-template-markdown",
        "cycleId": "api-productization-cycle",
        "kind": "questions",
        "format": "markdown",
        "title": "API-Produktisierungszyklus question template Markdown",
        "body": "# API-Produktisierungszyklus question template\n\nDie API-fokussierte APIOps-Cycles-Journey für Produktisierung, Design, Bereitstellung, Veröffentlichung und Verbesserung von APIs.\n\nUse this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.\n\n## 1. API-Produktstrategie\n\nBevor Sie etwas bauen, sollten Sie von Anfang an den Wert, die Benutzer und die Geschäftsziele Ihrer API definieren.\n\n### Canvas questions\n#### Customer-Journey-Canvas\nWelche Journey erlebt der am weitesten außen liegende sinnvolle Kunde, und was sollte verbessert werden?\n- **Personas**: Wer ist der typische Kunde oder Nutzer, der diese Reise erlebt?\n- **Kunde erkennt Bedarf**: Wie erkennt der Kunde oder Nutzer ein Bedürfnis oder Problem?\n- **Kundenbedarf wird erfüllt**: Wie wird der Bedarf des Kunden oder Nutzers letztlich erfüllt?\n- **Customer Journey Schritte**: Welche Schritte durchläuft der Kunde bei der Reise?\n- **Probleme**: Welche Probleme oder Pain Points erlebt der Kunde oder Nutzer?\n- **Nutzen**: Welchen Gewinn oder Nutzen hat der Kunde?\n- **Eingaben & Ausgaben**: Was sind die Inputs und Outputs bei jedem Schritt?\n- **Interaktions- und Verarbeitungsregeln**: Wie lauten die Interaktions- und Verarbeitungsregeln bei jedem Schritt?\n- **Verbesserungsmöglichkeiten**: Welche Journey-Schritte zeigen, dass eine zugrunde liegende Capability oder ein Prozess geschaffen, verbessert, automatisiert oder entfernt werden sollte?\n\n#### Domänen-Canvas\nWelche wesentlichen Entitäten, Begriffe und Fachregeln muss die Capability oder Schnittstelle respektieren?\n- **Ausgewählte Customer Journey Schritte**: Welche Customer Journey Schritte sind für diese Domäne relevant?\n- **Grundlegende Entitäten & geschäftliche Bedeutung**: Welches sind die wesentlichen Entitäten und ihre Bedeutung für das Geschäft?\n- **Attribute & geschäftliche Wichtigkeit**: Welches sind die Schlüsselattribute der einzelnen Entitäten und ihre geschäftliche Wichtigkeit?\n- **Beziehungen zwischen Entitäten**: Welche Beziehungen bestehen zwischen den Entitäten?\n- **Fachregeln, Compliance und Integrität**: Welche Fachregeln sowie Compliance- und Integritätsanforderungen beziehen sich auf die Entitäten?\n- **Überlegungen zu Sicherheit und Datenschutz**: Welche Überlegungen zur Sicherheit und zum Datenschutz gibt es im Zusammenhang mit den Entitäten?\n\n#### API-Wertversprechen-Canvas\nWie hängt die Customer Journey mit APIs zusammen? Welche Pain Points und Nutzen von Endnutzern und API-Nutzern müssen adressiert werden?\n- **Aufgaben**: Was möchten Kunden oder Endnutzer erreichen?\n- **Nutzenstiftende Funktionen**: Welche Funktionen helfen Endnutzern und API-Nutzern, den gewünschten Nutzen zu erreichen?\n- **Funktionen zur Reduktion von Pain Points**: Welche Funktionen helfen Endnutzern und API-Nutzern, Pain Points zu reduzieren?\n- **API-Produkte**: Welche API-Produkte und -Features eigenen sich für diese Aufgaben, Probleme und Bedürfnisse?\n\n#### API-Geschäftsmodell-Canvas\nWie praktikabel und wiederverwendbar wird diese API sein? Haben wir einen Business Case aus Kosten-Nutzen-Sicht?\n- **Wertversprechen der API**: Beginnen Sie mit einem Haftzettel, auf dem Sie die API oder die API-Familie benennen, und erfassen Sie dann, welchen Nutzen die API den API-Nutzern bietet.\n- **API-Nutzersegmente**: Wer sind die Zielgruppen für die API?\n- **Developer-Relations**: Wie erreicht und unterstützt der API-Anbieter die API-Nutzer?\n- **Kanäle**: Über welche Mechanismen interagieren API-Nutzer mit der API?\n- **Schlüsselressourcen**: Welche strategischen Ressourcen muss der API-Anbieter beschaffen oder aufbauen?\n- **Schlüsselaktivitäten**: Welche wichtigsten Aktivitäten muss der API-Anbieter ausführen, damit die API erfolgreich betrieben werden kann?\n- **Schlüsselpartner**: Wer sind die wichtigsten beteiligten Stakeholder?\n- **Vorteile**: Was sind die wesentlichen Vorteile oder Einnahmequellen, die durch die API generiert werden?\n- **Kosten**: Welche wesentlichen Kosten entstehen durch Aufbau, Bereitstellung und Betrieb der API?\n\n### Before this station\n- [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n\n### Ready to leave when\n- [ ] Relevante Marktsignale, Feedback oder operative Erkenntnisse liegen vor, um diese Capability-Möglichkeit zu bewerten.\n- [ ] Die Geschäftsziele sind definiert.\n- [ ] Die Marktrecherche identifiziert relevante Capability-Möglichkeiten.\n- [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\n## 2. API-Nutzererlebnis\n\nStellen Sie sicher, dass Ihre API auffindbar, verständlich und nutzbar ist - vor und nach der Einführung.\n\n### Canvas questions\n#### API-Wertversprechen-Canvas\nWie hängt die Customer Journey mit APIs zusammen? Welche Pain Points und Nutzen von Endnutzern und API-Nutzern müssen adressiert werden?\n- **Aufgaben**: Was möchten Kunden oder Endnutzer erreichen?\n- **Nutzenstiftende Funktionen**: Welche Funktionen helfen Endnutzern und API-Nutzern, den gewünschten Nutzen zu erreichen?\n- **Funktionen zur Reduktion von Pain Points**: Welche Funktionen helfen Endnutzern und API-Nutzern, Pain Points zu reduzieren?\n- **API-Produkte**: Welche API-Produkte und -Features eigenen sich für diese Aufgaben, Probleme und Bedürfnisse?\n\n#### Customer-Journey-Canvas\nWelche Journey erlebt der am weitesten außen liegende sinnvolle Kunde, und was sollte verbessert werden?\n- **Personas**: Wer ist der typische Kunde oder Nutzer, der diese Reise erlebt?\n- **Kunde erkennt Bedarf**: Wie erkennt der Kunde oder Nutzer ein Bedürfnis oder Problem?\n- **Kundenbedarf wird erfüllt**: Wie wird der Bedarf des Kunden oder Nutzers letztlich erfüllt?\n- **Customer Journey Schritte**: Welche Schritte durchläuft der Kunde bei der Reise?\n- **Probleme**: Welche Probleme oder Pain Points erlebt der Kunde oder Nutzer?\n- **Nutzen**: Welchen Gewinn oder Nutzen hat der Kunde?\n- **Eingaben & Ausgaben**: Was sind die Inputs und Outputs bei jedem Schritt?\n- **Interaktions- und Verarbeitungsregeln**: Wie lauten die Interaktions- und Verarbeitungsregeln bei jedem Schritt?\n- **Verbesserungsmöglichkeiten**: Welche Journey-Schritte zeigen, dass eine zugrunde liegende Capability oder ein Prozess geschaffen, verbessert, automatisiert oder entfernt werden sollte?\n\n### Before this station\n- [ ] Relevante Marktsignale, Feedback oder operative Erkenntnisse liegen vor, um diese Capability-Möglichkeit zu bewerten.\n- [ ] Die Geschäftsziele sind definiert.\n- [ ] Die Marktrecherche identifiziert relevante Capability-Möglichkeiten.\n- [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\n### Ready to leave when\n- [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n- [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n- [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\n### Other related resources\n- **Bewährte Praktiken beim API-Onboarding**: Bewährte Praktiken zur Optimierung des Onboarding-Prozesses für API-Kunden mit schrittweiser Anleitung zur Registrierung, Erkundung und zum ersten Anruf.\n\n## 3. API-Plattformarchitektur\n\nGewährleisten Sie Skalierbarkeit, Wiederverwendung und Governance für Ihre API- und Plattformkomponenten.\n\n### Canvas questions\n#### Geschäftsauswirkungs-Canvas\nWelcher Wert, welches Risiko sowie welche betrieblichen, finanziellen, kunden-, mitarbeiter-, compliance- und strategischen Auswirkungen werden erwartet oder stehen auf dem Spiel?\n- **Erwartete Vorteile**: Welche geschäftlichen, kundenbezogenen, mitarbeiterbezogenen, qualitäts-, geschwindigkeits-, risiko-, compliance- oder strategischen Vorteile werden erwartet?\n- **Auswirkung auf die operative Effizienz**: Wie könnten Arbeitsaufwand, Wartezeit, Nacharbeit, Durchsatz, Zuverlässigkeit, Supportbelastung oder Betriebskosten sich verändern?\n- **Auswirkung auf Kunden und Mitarbeitende**: Wie werden Kunden, Mitarbeitende, Partner, Betreiber oder Supportteams die Veränderung erleben?\n- **Finanzielle Auswirkung**: Welche Auswirkungen auf Umsatz, Kosten, Investitionen, Einsparungen, vermiedene Verluste oder Finanzierung werden erwartet?\n- **Compliance- und strategische Auswirkung**: Welche regulatorischen, vertraglichen, richtlinienbezogenen, reputations-, markt-, ökosystem- oder strategischen Konsequenzen sind relevant?\n- **Auswirkung des Nicht-Fortfahrens**: Was geschieht, wenn die Capability, Automatisierung, Integration oder der Service nicht verbessert oder geliefert wird?\n- **Risiken und Kritikalität**: Welche Verfügbarkeits-, Sicherheits-, Daten-, Safety-, Prozess-, Akzeptanz- oder Business-Continuity-Risiken könnten das Ergebnis beeinflussen?\n- **Gegenmaßnahmen und Entscheidungsauswirkung**: Welche Gegenmaßnahmen, Einschränkungen, Kompromisse oder Restrisiken sollten Priorisierung, Architektur, Rollout oder Readiness-Entscheidungen beeinflussen?\n\n#### Standort-Canvas\nWelche geopolitischen, regulatorischen, Netzwerk- und Vertrauensgrenzen betreffen diese Capability oder Schnittstelle?\n- **Standort-/Vertrauensgruppen**: Welche geopolitischen, regulatorischen, netzwerkbezogenen oder vertrauensbezogenen Gruppen sind relevant?\n- **Gruppenmerkmale**: Was sind die Merkmale dieser Gruppen, wie z. B. Standort, Vertrauensstufe oder Netzwerkexposition?\n- **Relevante Standorte / Zonen**: Was sind die relevanten Standorte, Zonen oder Umgebungen innerhalb jeder Gruppe?\n- **Standort-/Zonenmerkmale**: Was sind die Merkmale dieser Standorte oder Zonen, wie z. B. Eigentumsverhältnisse, Region oder Exposition?\n- **Netzwerk- / Regulierungsentfernungen**: Welche Latenz-, Vertrauens-, Regulierungs- oder Konnektivitätsentfernungen bestehen zwischen den Standorten?\n- **Entfernungsmerkmale**: Was sind die Merkmale dieser Entfernungen, wie z. B. Latenzempfindlichkeit, Aufenthaltsbeschränkungen oder Vertrauensgrenzen?\n- **Konnektivitätsendpunkte**: Welche Konnektivitätsendpunkte oder Schnittstellen sind mit den Standorten verbunden?\n- **Endpunktzugriffseigenschaften**: Welche Eigenschaften weisen diese Endpunkte auf, wie z. B. Sichtbarkeit, Protokoll, Sicherheit oder Zugriffsbeschränkungen?\n\n#### Kapazitäts-Canvas\nWie viel Nachfrage, Last, Timing und Skalierungskapazität müssen für Fähigkeit, Automatisierung, Integration oder Service verstanden werden?\n- **Aktuelles Geschäftsvolumen**: Wie hoch sind das aktuelle Geschäftsvolumen und die Transaktionsraten?\n- **Zukünftige Konsumtrends**: Was sind die erwarteten künftigen Konsumtrends?\n- **Spitzenlast- und Verfügbarkeitsanforderungen**: Was sind die Spitzenlast- und Verfügbarkeitsanforderungen?\n- **Caching-Strategien**: Welche Caching-Strategien können zur Performanceoptimierung eingesetzt werden?\n- **Strategien zur Ratenbegrenzung**: Welche Strategien zur Ratenbegrenzung können genutzt werden, um die Nutzung zu steuern?\n- **Strategien zur Skalierung**: Welche Strategien zur Skalierung können eingesetzt werden, um das Wachstum zu unterstützen?\n\n### Before this station\n- [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n- [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n- [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\n### Ready to leave when\n- [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n- [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\n### Other related resources\n- **API-Metriken und -Analysen**: Eine Ressource zum Definieren, Sammeln und Analysieren von API-Leistungs- und -Nutzungsdaten, um technische KPIs mit den Geschäftsergebnissen in Einklang zu bringen.\n\n## 4. API-Design\n\nErstellen Sie API-Designs, die konsistent, wiederverwendbar und auf Geschäftszielen und gemeinsamen Standards basieren.\n\n### Canvas questions\n#### Domänen-Canvas\nWelche wesentlichen Entitäten, Begriffe und Fachregeln muss die Capability oder Schnittstelle respektieren?\n- **Ausgewählte Customer Journey Schritte**: Welche Customer Journey Schritte sind für diese Domäne relevant?\n- **Grundlegende Entitäten & geschäftliche Bedeutung**: Welches sind die wesentlichen Entitäten und ihre Bedeutung für das Geschäft?\n- **Attribute & geschäftliche Wichtigkeit**: Welches sind die Schlüsselattribute der einzelnen Entitäten und ihre geschäftliche Wichtigkeit?\n- **Beziehungen zwischen Entitäten**: Welche Beziehungen bestehen zwischen den Entitäten?\n- **Fachregeln, Compliance und Integrität**: Welche Fachregeln sowie Compliance- und Integritätsanforderungen beziehen sich auf die Entitäten?\n- **Überlegungen zu Sicherheit und Datenschutz**: Welche Überlegungen zur Sicherheit und zum Datenschutz gibt es im Zusammenhang mit den Entitäten?\n\n#### Interaktions-Canvas\nWelche Arten von Interaktionen muss diese Capability oder Schnittstelle unterstützen, bevor ein konkretes Protokolldesign gewählt wird?\n- **CRUD Interaktionen**: Sind hier Interaktionen im CRUD-Stil erforderlich?\n- **CRUD Input- & Output-Modelle**: Was sind die Eingabe- und Ausgabemodelle für die CRUD-Interaktionen, falls dieser Stil benötigt wird?\n- **CRUD Verarbeitung & Validierung**: Was sind die Verarbeitungs- und Validierungsregeln für die CRUD-Interaktionen, falls dieser Stil benötigt wird?\n- **Abfragegesteuerte Interaktionen**: Welche Lese- oder Abfrageinteraktionen sind erforderlich, um Nutzerfragen zu beantworten?\n- **Abfragegesteuerte Input- & Output-Modelle**: Was sind die Eingabe- und Ausgabemodelle für die abfragegesteuerten Interaktionen?\n- **Abfragegesteuerte Verarbeitung & Validierung**: Was sind die Verarbeitungs- und Validierungsregeln für die abfragegesteuerten Interaktionen?\n- **Befehlsgesteuerte Interaktionen**: Welche Befehle zur Zustandsänderung sind gegebenenfalls erforderlich?\n- **Befehlsgesteuerte Input- & Output-Modelle**: Was sind die Eingabe- und Ausgabemodelle für die befehlsgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n- **Befehlsgesteuerte Verarbeitung & Validierung**: Was sind die Verarbeitungs- und Validierungsregeln für die befehlsgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n- **Eventgesteuerte Interaktionen**: Welche Ereignisse müssen gegebenenfalls veröffentlicht oder verarbeitet werden?\n- **Eventgesteuerte Input- & Output-Modelle**: Was sind die Eingabe- und Ausgabemodelle für die ereignisgesteuerten Interaktionen, falls dieser Stil erforderlich ist?\n- **Eventgesteuerte Verarbeitung & Validierung**: Was sind die Verarbeitungs- und Validierungsregeln für die ereignisgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n\n#### REST-Canvas\nWie kann die API nach RESTful-Prinzipien gestaltet werden?\n- **API-Ressourcen**: Was sind die Schlüsselressourcen, die von der API bereitgestellt werden?\n- **API-Ressourcenmodell**: Wie sieht die Struktur des API-Ressourcenmodells aus?\n- **HTTP-Methoden der API**: Welche HTTP-Methoden werden für die Interaktion mit den API-Ressourcen verwendet?\n- **HTTP-Methoden-Beispiel**: Geben Sie für jede HTTP-Methode ein Beispiel für eine API-Anfrage und -Antwort an.\n\n#### Event-Canvas\nWelche Ereignisse sind für die Capability oder Schnittstelle relevant und wie werden sie verarbeitet?\n- **Nutzeraufgabe / Auslöser**: Welche Nutzeraktion oder welches Systemereignis löst diese Ereignisoperation aus?\n- **Input / Event-Payload**: Welche Daten sind in der eingehenden Event-Payload enthalten? Geben Sie die Schlüsselattribute an.\n- **Verarbeitung / Logik**: Beschreiben Sie die Verarbeitungslogik der Backend-Systeme, einschließlich Validierungen, Transformationen oder Routing-Entscheidungen.\n- **Output / Event-Ergebnis**: Welches Event oder welche Bestätigungsmeldung wird erzeugt? Geben Sie die Attribute des Output-Payloads an.\n\n#### GraphQL-Canvas\nWie kann die API nach GraphQL-Prinzipien gestaltet werden?\n- **API-Name**: Wie lautet der Name der GraphQL-API oder des Endpunkts?\n- **Ziele der API-Nutzer**: Welche Probleme versuchen API-Nutzer zu lösen? Welche Daten benötigen sie?\n- **Schlüsseltypen**: Welche zentralen Typen werden bereitgestellt (z. B. Nutzer, Bestellung, Produkt)?\n- **Beziehungen**: Wie stehen die Typen in verschachtelten Abfragen zueinander?\n- **Abfragen**: Welche typischen Abfragen sollten unterstützt werden?\n- **Mutationen**: Welche Operationen verändern Daten (z.B. erstellen, aktualisieren, löschen)?\n- **Abonnements**: Gibt es Echtzeit-Updates oder Ereignisse, die Nutzer abonnieren können?\n- **Autorisierungsregeln**: Wer darf auf welche Felder oder Typen zugreifen?\n- **Einschränkungen für Nutzer**: Gibt es Paginierungs-, Filter- oder Ratenbegrenzungen?\n- **Notizen / Offene Fragen**: Gibt es noch offene Entscheidungen oder Integrationsüberlegungen?\n\n### Before this station\n- [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n- [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\n### Ready to leave when\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\n### Other related resources\n- **API Design Prinzipien**: Ein prägnanter Leitfaden zu API-Benutzerfreundlichkeit, Auffindbarkeit und Konsistenz, der auf gemeinsamen Designregeln und echten Kundenbedürfnissen basiert.\n- **Contract-First Integration Design**: Guidance for validating integration contracts before delivery, including OpenAPI, AsyncAPI, event schemas, message schemas, file schemas, data contracts, and interface specifications.\n\n## 5. API-Bereitstellung\n\nErstellen, Testen und Freigeben von APIs unter Verwendung moderner Bereitstellungspipelines und bewährter technischer Verfahren.\n\n### Station questions\n- Verwenden Sie Best Practices für die API-Entwicklung als Leitfaden für die Implementierung des validierten Schnittstellenvertrags mit etablierten Frameworks und Bibliotheken, um sicherzustellen, dass das Ergebnis wiederverwendbar und wartbar ist.\n- Erstellen Sie die API-Implementierung auf Basis des validierten Schnittstellenvertrags unter Verwendung etablierter Frameworks, Bibliotheken und Teamstandards.\n- Testen Sie APIs auf Funktionalität, Sicherheit und Leistung mit automatisierten Testwerkzeugen.\n- Verwenden Sie CI/CD-Pipelines, um Build-, Test- und Bereitstellungsprozesse zu automatisieren und so konsistente Qualität und Nachvollziehbarkeit zu gewährleisten.\n- Stellen Sie sicher, dass APIs die Sicherheits- und Compliance-Anforderungen durch automatische Prüfungen und Audits erfüllen.\n- Verwenden Sie die API-Audit-Checkliste, um sicherzustellen, dass die API die funktionalen und nicht-funktionalen Anforderungen erfüllt, einschließlich Sicherheit, Leistung und Compliance.\n- Bereitstellung von Frameworks, Bibliotheken und Standards für die API-Implementierung. Implementierung von CI/CD-Pipelines, Qualitätssicherungs-Frameworks und Tools zur Automatisierung der Bereitstellung.\n- Selbst die besten API-Designs scheitern, wenn die Bereitstellung uneinheitlich ist. Diese Station stellt sicher, dass Ihre APIs qualitativ hochwertig erstellt, gründlich getestet und zuverlässig bereitgestellt werden - für schnellere Iterationen und mehr Vertrauen.\n\n### Before this station\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\n### Ready to leave when\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\n### Other related resources\n- **Bewährte Praktiken der API-Entwicklung**: Implementierungsleitfaden zur Umsetzung eines validierten API-Vertrags in eine konsistente, wartbare API-Codebasis unter Verwendung von Standardbibliotheken, wiederverwendbaren Mustern und aufeinander abgestimmten Entwicklungsabläufen.\n- **Bewährte Praktiken für API-Tests**: Richtlinien für die Implementierung automatisierter Funktions-, Leistungs- und Sicherheitstests während des gesamten API-Lebenszyklus.\n- **APIOps CI/CD für APIs**: Bereitstellungsleitfaden, der die Aufgaben des API-Lebenszyklus - Entwurf, Tests, Governance - in die Pipelines für die kontinuierliche Integration und Bereitstellung integriert.\n- **Bewährte Praktiken für die API-Sicherheit**: Eine Reihe praktikabler Kontrollen zur Sicherung von APIs, einschließlich Authentifizierung, Autorisierung, Verschlüsselung, Ratenbegrenzung und Konformitätsprüfungen auf Pipeline-Ebene.\n\n## 6. API-Audit\n\nStellen Sie sicher, dass APIs vor der Veröffentlichung und Bereitstellung den geschäftlichen, gestalterischen und betrieblichen Standards entsprechen.\n\n### Station questions\n- Führen Sie Audits durch, um sicherzustellen, dass APIs vor der Veröffentlichung organisatorische, technische und rechtliche Standards erfüllen.\n- Verwenden Sie Checklisten, Linters und Testwerkzeuge, um die Konsistenz und Compliance mit den Standards zu überprüfen.\n- Zusammenarbeit mit Governance-Teams und Domänenexperten, um sicherzustellen, dass APIs für die Produktion bereit sind.\n- Richten Sie einen konsistenten Audit-Prozess ein, der die API-Bereitschaft über alle Lebenszyklusphasen hinweg anhand definierter Kriterien, Nachweise und Standards bewertet. Stellen Sie sicher, dass Lücken frühzeitig erkannt und vor der Veröffentlichung behoben werden.\n- APIs sind langlebige Produkte und müssen den Erwartungen hinsichtlich Qualität, Konsistenz und Compliance entsprechen. Das Audit verbindet Designentscheidungen, Implementierung und Betriebsbereitschaft mit definierten Standards und reduziert so Risiken vor der Bereitstellung.\n\n### Before this station\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\n### Ready to leave when\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Die Schnittstelle und ihre Capabilities sind ausreichend klar für Review, Auditierung und Onboarding dokumentiert.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n- [ ] Der Schnittstellenvertrag wurde validiert und gegen funktionale und nicht-funktionale Anforderungen getestet.\n\n### Other related resources\n- **API Audit Checkliste**: Eine lebenszyklusbasierte Checkliste zur Überprüfung der API-Bereitschaft in den Bereichen Design, Bereitstellung, Veröffentlichung und Compliance anhand definierter Audit-Kriterien und Nachweise.\n- **Bewährte Praktiken zur API-Einhaltung**: Sicherstellen, dass APIs durch Dokumentation, Kontrollen und automatisierte Validierungen die rechtlichen, regulatorischen und internen Anforderungen erfüllen.\n\n## 7. API-Veröffentlichung\n\nStellen Sie APIs mit der richtigen Dokumentation und den richtigen Prozessen sicher und klar für die richtige Zielgruppe bereit.\n\n### Station questions\n- Veröffentlichen Sie APIs in den entsprechenden Gateways und Umgebungen, um die Wiederverwendbarkeit für mehrere Nutzer zu unterstützen.\n- Dokumentieren Sie, wie die Nutzer die API finden und nutzen, einschließlich Onboarding-Prozesse und Registrierung.\n- Stellen Sie sicher, dass die Sicherheitsmodelle, die Gateway-Konfiguration und die rechtlichen Bestimmungen für die Nutzer klar und verständlich sind.\n- Ermöglichung der Veröffentlichung von APIs in der jeweiligen Umgebung mit klaren Registrierungs- und Zugriffsmechanismen (z. B. API-Schlüssel, OAuth, Abonnementpläne) je nach den Nutzersegmenten und den Sicherheits- und Compliance-Anforderungen.\n- Bei der Veröffentlichung geht es nicht nur um die Bereitstellung, sondern auch um die Auffindbarkeit, den Zugang und die Unterstützung. Wenn APIs nicht korrekt veröffentlicht werden, können sie nicht verwendet, wiederverwendet oder effektiv gesichert werden.\n\n### Before this station\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Die Schnittstelle und ihre Capabilities sind ausreichend klar für Review, Auditierung und Onboarding dokumentiert.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n- [ ] Der Schnittstellenvertrag wurde validiert und gegen funktionale und nicht-funktionale Anforderungen getestet.\n\n### Ready to leave when\n- [ ] Die Lösung besteht Qualitäts-, Sicherheits-, Compliance- und Bereitschaftsprüfungen.\n- [ ] Audit-Ergebnisse und Maßnahmenentscheidungen wurden mit den relevanten Stakeholdern geteilt.\n- [ ] Die Capability ist bereit, über den gewählten Bereitstellungsmechanismus veröffentlicht oder ausgeliefert zu werden.\n- [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n\n### Other related resources\n- **APIOps CI/CD für APIs**: Bereitstellungsleitfaden, der die Aufgaben des API-Lebenszyklus - Entwurf, Tests, Governance - in die Pipelines für die kontinuierliche Integration und Bereitstellung integriert.\n- **Bewährte Praktiken beim API-Onboarding**: Bewährte Praktiken zur Optimierung des Onboarding-Prozesses für API-Kunden mit schrittweiser Anleitung zur Registrierung, Erkundung und zum ersten Anruf.\n- **API Audit Checkliste**: Eine lebenszyklusbasierte Checkliste zur Überprüfung der API-Bereitschaft in den Bereichen Design, Bereitstellung, Veröffentlichung und Compliance anhand definierter Audit-Kriterien und Nachweise.\n\n## 8. API-Monitoring & Verbesserung\n\nNutzen Sie Messgrößen und Feedback, um die API-Leistung zu verfolgen und kontinuierliche Verbesserungen voranzutreiben.\n\n### Station questions\n- Überwachen Sie Leistungsmetriken (z. B. API-Aufrufe, Latenz, Fehlerraten) und Akzeptanzmetriken (z. B. NPS).\n- Analysieren Sie API-Nutzungsmetriken und integrieren Sie Benutzerfeedback in API-Iterationen.\n- Machen Sie es sich zur Gewohnheit, die Messwerte zu überprüfen und kontinuierliche Verbesserungsmaßnahmen zu planen.\n- Einrichtung von Analyserahmen zur Verfolgung von Leistung und Engagement. Entwickeln Sie Feedbackschleifen, Analysetools und Engagementstrategien für APIs.\n- Die API-Bereitstellung endet nicht mit dem Start. Ohne Überwachung können Teams weder die Akzeptanz noch die Leistung oder den ROI verbessern. Diese Station stellt sicher, dass APIs nützlich und sicher bleiben und sich mit den Geschäftsanforderungen weiterentwickeln.\n\n### Before this station\n- [ ] Die Lösung besteht Qualitäts-, Sicherheits-, Compliance- und Bereitschaftsprüfungen.\n- [ ] Audit-Ergebnisse und Maßnahmenentscheidungen wurden mit den relevanten Stakeholdern geteilt.\n- [ ] Die Capability ist bereit, über den gewählten Bereitstellungsmechanismus veröffentlicht oder ausgeliefert zu werden.\n- [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n\n### Ready to leave when\n- [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n- [ ] Onboarding-, Support- und Kommunikationsprozesse für Nutzer sind bereit.\n- [ ] Rechtliche, Datenschutz- und Compliance-Anforderungen für Veröffentlichung oder Release sind definiert und verstanden.\n\n### Other related resources\n- **API-Metriken und -Analysen**: Eine Ressource zum Definieren, Sammeln und Analysieren von API-Leistungs- und -Nutzungsdaten, um technische KPIs mit den Geschäftsergebnissen in Einklang zu bringen.\n- **Strategien für das Engagement der API-Gemeinschaft**: Ein Leitfaden für die Förderung der API-Annahme durch die Pflege von Gemeinschaften durch Inhalte, Support-Kanäle, Feedback-Schleifen und Strategien für soziales Engagement."
      },
      {
        "id": "api-productization-cycle:question-template-confluence-wiki",
        "cycleId": "api-productization-cycle",
        "kind": "questions",
        "format": "confluence-wiki",
        "title": "API-Produktisierungszyklus question template Confluence wiki",
        "body": "h1. API-Produktisierungszyklus question template\n\nDie API-fokussierte APIOps-Cycles-Journey für Produktisierung, Design, Bereitstellung, Veröffentlichung und Verbesserung von APIs.\n\nUse this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.\n\nh2. 1. API-Produktstrategie\n\nBevor Sie etwas bauen, sollten Sie von Anfang an den Wert, die Benutzer und die Geschäftsziele Ihrer API definieren.\n\nh3. Canvas questions\nh4. Customer-Journey-Canvas\nWelche Journey erlebt der am weitesten außen liegende sinnvolle Kunde, und was sollte verbessert werden?\n* *Personas*: Wer ist der typische Kunde oder Nutzer, der diese Reise erlebt?\n* *Kunde erkennt Bedarf*: Wie erkennt der Kunde oder Nutzer ein Bedürfnis oder Problem?\n* *Kundenbedarf wird erfüllt*: Wie wird der Bedarf des Kunden oder Nutzers letztlich erfüllt?\n* *Customer Journey Schritte*: Welche Schritte durchläuft der Kunde bei der Reise?\n* *Probleme*: Welche Probleme oder Pain Points erlebt der Kunde oder Nutzer?\n* *Nutzen*: Welchen Gewinn oder Nutzen hat der Kunde?\n* *Eingaben & Ausgaben*: Was sind die Inputs und Outputs bei jedem Schritt?\n* *Interaktions- und Verarbeitungsregeln*: Wie lauten die Interaktions- und Verarbeitungsregeln bei jedem Schritt?\n* *Verbesserungsmöglichkeiten*: Welche Journey-Schritte zeigen, dass eine zugrunde liegende Capability oder ein Prozess geschaffen, verbessert, automatisiert oder entfernt werden sollte?\n\nh4. Domänen-Canvas\nWelche wesentlichen Entitäten, Begriffe und Fachregeln muss die Capability oder Schnittstelle respektieren?\n* *Ausgewählte Customer Journey Schritte*: Welche Customer Journey Schritte sind für diese Domäne relevant?\n* *Grundlegende Entitäten & geschäftliche Bedeutung*: Welches sind die wesentlichen Entitäten und ihre Bedeutung für das Geschäft?\n* *Attribute & geschäftliche Wichtigkeit*: Welches sind die Schlüsselattribute der einzelnen Entitäten und ihre geschäftliche Wichtigkeit?\n* *Beziehungen zwischen Entitäten*: Welche Beziehungen bestehen zwischen den Entitäten?\n* *Fachregeln, Compliance und Integrität*: Welche Fachregeln sowie Compliance- und Integritätsanforderungen beziehen sich auf die Entitäten?\n* *Überlegungen zu Sicherheit und Datenschutz*: Welche Überlegungen zur Sicherheit und zum Datenschutz gibt es im Zusammenhang mit den Entitäten?\n\nh4. API-Wertversprechen-Canvas\nWie hängt die Customer Journey mit APIs zusammen? Welche Pain Points und Nutzen von Endnutzern und API-Nutzern müssen adressiert werden?\n* *Aufgaben*: Was möchten Kunden oder Endnutzer erreichen?\n* *Nutzenstiftende Funktionen*: Welche Funktionen helfen Endnutzern und API-Nutzern, den gewünschten Nutzen zu erreichen?\n* *Funktionen zur Reduktion von Pain Points*: Welche Funktionen helfen Endnutzern und API-Nutzern, Pain Points zu reduzieren?\n* *API-Produkte*: Welche API-Produkte und -Features eigenen sich für diese Aufgaben, Probleme und Bedürfnisse?\n\nh4. API-Geschäftsmodell-Canvas\nWie praktikabel und wiederverwendbar wird diese API sein? Haben wir einen Business Case aus Kosten-Nutzen-Sicht?\n* *Wertversprechen der API*: Beginnen Sie mit einem Haftzettel, auf dem Sie die API oder die API-Familie benennen, und erfassen Sie dann, welchen Nutzen die API den API-Nutzern bietet.\n* *API-Nutzersegmente*: Wer sind die Zielgruppen für die API?\n* *Developer-Relations*: Wie erreicht und unterstützt der API-Anbieter die API-Nutzer?\n* *Kanäle*: Über welche Mechanismen interagieren API-Nutzer mit der API?\n* *Schlüsselressourcen*: Welche strategischen Ressourcen muss der API-Anbieter beschaffen oder aufbauen?\n* *Schlüsselaktivitäten*: Welche wichtigsten Aktivitäten muss der API-Anbieter ausführen, damit die API erfolgreich betrieben werden kann?\n* *Schlüsselpartner*: Wer sind die wichtigsten beteiligten Stakeholder?\n* *Vorteile*: Was sind die wesentlichen Vorteile oder Einnahmequellen, die durch die API generiert werden?\n* *Kosten*: Welche wesentlichen Kosten entstehen durch Aufbau, Bereitstellung und Betrieb der API?\n\nh3. Before this station\n* [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n\nh3. Ready to leave when\n* [ ] Relevante Marktsignale, Feedback oder operative Erkenntnisse liegen vor, um diese Capability-Möglichkeit zu bewerten.\n* [ ] Die Geschäftsziele sind definiert.\n* [ ] Die Marktrecherche identifiziert relevante Capability-Möglichkeiten.\n* [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\nh2. 2. API-Nutzererlebnis\n\nStellen Sie sicher, dass Ihre API auffindbar, verständlich und nutzbar ist - vor und nach der Einführung.\n\nh3. Canvas questions\nh4. API-Wertversprechen-Canvas\nWie hängt die Customer Journey mit APIs zusammen? Welche Pain Points und Nutzen von Endnutzern und API-Nutzern müssen adressiert werden?\n* *Aufgaben*: Was möchten Kunden oder Endnutzer erreichen?\n* *Nutzenstiftende Funktionen*: Welche Funktionen helfen Endnutzern und API-Nutzern, den gewünschten Nutzen zu erreichen?\n* *Funktionen zur Reduktion von Pain Points*: Welche Funktionen helfen Endnutzern und API-Nutzern, Pain Points zu reduzieren?\n* *API-Produkte*: Welche API-Produkte und -Features eigenen sich für diese Aufgaben, Probleme und Bedürfnisse?\n\nh4. Customer-Journey-Canvas\nWelche Journey erlebt der am weitesten außen liegende sinnvolle Kunde, und was sollte verbessert werden?\n* *Personas*: Wer ist der typische Kunde oder Nutzer, der diese Reise erlebt?\n* *Kunde erkennt Bedarf*: Wie erkennt der Kunde oder Nutzer ein Bedürfnis oder Problem?\n* *Kundenbedarf wird erfüllt*: Wie wird der Bedarf des Kunden oder Nutzers letztlich erfüllt?\n* *Customer Journey Schritte*: Welche Schritte durchläuft der Kunde bei der Reise?\n* *Probleme*: Welche Probleme oder Pain Points erlebt der Kunde oder Nutzer?\n* *Nutzen*: Welchen Gewinn oder Nutzen hat der Kunde?\n* *Eingaben & Ausgaben*: Was sind die Inputs und Outputs bei jedem Schritt?\n* *Interaktions- und Verarbeitungsregeln*: Wie lauten die Interaktions- und Verarbeitungsregeln bei jedem Schritt?\n* *Verbesserungsmöglichkeiten*: Welche Journey-Schritte zeigen, dass eine zugrunde liegende Capability oder ein Prozess geschaffen, verbessert, automatisiert oder entfernt werden sollte?\n\nh3. Before this station\n* [ ] Relevante Marktsignale, Feedback oder operative Erkenntnisse liegen vor, um diese Capability-Möglichkeit zu bewerten.\n* [ ] Die Geschäftsziele sind definiert.\n* [ ] Die Marktrecherche identifiziert relevante Capability-Möglichkeiten.\n* [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\nh3. Ready to leave when\n* [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n* [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n* [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\nh3. Other related resources\n* *Bewährte Praktiken beim API-Onboarding*: Bewährte Praktiken zur Optimierung des Onboarding-Prozesses für API-Kunden mit schrittweiser Anleitung zur Registrierung, Erkundung und zum ersten Anruf.\n\nh2. 3. API-Plattformarchitektur\n\nGewährleisten Sie Skalierbarkeit, Wiederverwendung und Governance für Ihre API- und Plattformkomponenten.\n\nh3. Canvas questions\nh4. Geschäftsauswirkungs-Canvas\nWelcher Wert, welches Risiko sowie welche betrieblichen, finanziellen, kunden-, mitarbeiter-, compliance- und strategischen Auswirkungen werden erwartet oder stehen auf dem Spiel?\n* *Erwartete Vorteile*: Welche geschäftlichen, kundenbezogenen, mitarbeiterbezogenen, qualitäts-, geschwindigkeits-, risiko-, compliance- oder strategischen Vorteile werden erwartet?\n* *Auswirkung auf die operative Effizienz*: Wie könnten Arbeitsaufwand, Wartezeit, Nacharbeit, Durchsatz, Zuverlässigkeit, Supportbelastung oder Betriebskosten sich verändern?\n* *Auswirkung auf Kunden und Mitarbeitende*: Wie werden Kunden, Mitarbeitende, Partner, Betreiber oder Supportteams die Veränderung erleben?\n* *Finanzielle Auswirkung*: Welche Auswirkungen auf Umsatz, Kosten, Investitionen, Einsparungen, vermiedene Verluste oder Finanzierung werden erwartet?\n* *Compliance- und strategische Auswirkung*: Welche regulatorischen, vertraglichen, richtlinienbezogenen, reputations-, markt-, ökosystem- oder strategischen Konsequenzen sind relevant?\n* *Auswirkung des Nicht-Fortfahrens*: Was geschieht, wenn die Capability, Automatisierung, Integration oder der Service nicht verbessert oder geliefert wird?\n* *Risiken und Kritikalität*: Welche Verfügbarkeits-, Sicherheits-, Daten-, Safety-, Prozess-, Akzeptanz- oder Business-Continuity-Risiken könnten das Ergebnis beeinflussen?\n* *Gegenmaßnahmen und Entscheidungsauswirkung*: Welche Gegenmaßnahmen, Einschränkungen, Kompromisse oder Restrisiken sollten Priorisierung, Architektur, Rollout oder Readiness-Entscheidungen beeinflussen?\n\nh4. Standort-Canvas\nWelche geopolitischen, regulatorischen, Netzwerk- und Vertrauensgrenzen betreffen diese Capability oder Schnittstelle?\n* *Standort-/Vertrauensgruppen*: Welche geopolitischen, regulatorischen, netzwerkbezogenen oder vertrauensbezogenen Gruppen sind relevant?\n* *Gruppenmerkmale*: Was sind die Merkmale dieser Gruppen, wie z. B. Standort, Vertrauensstufe oder Netzwerkexposition?\n* *Relevante Standorte / Zonen*: Was sind die relevanten Standorte, Zonen oder Umgebungen innerhalb jeder Gruppe?\n* *Standort-/Zonenmerkmale*: Was sind die Merkmale dieser Standorte oder Zonen, wie z. B. Eigentumsverhältnisse, Region oder Exposition?\n* *Netzwerk- / Regulierungsentfernungen*: Welche Latenz-, Vertrauens-, Regulierungs- oder Konnektivitätsentfernungen bestehen zwischen den Standorten?\n* *Entfernungsmerkmale*: Was sind die Merkmale dieser Entfernungen, wie z. B. Latenzempfindlichkeit, Aufenthaltsbeschränkungen oder Vertrauensgrenzen?\n* *Konnektivitätsendpunkte*: Welche Konnektivitätsendpunkte oder Schnittstellen sind mit den Standorten verbunden?\n* *Endpunktzugriffseigenschaften*: Welche Eigenschaften weisen diese Endpunkte auf, wie z. B. Sichtbarkeit, Protokoll, Sicherheit oder Zugriffsbeschränkungen?\n\nh4. Kapazitäts-Canvas\nWie viel Nachfrage, Last, Timing und Skalierungskapazität müssen für Fähigkeit, Automatisierung, Integration oder Service verstanden werden?\n* *Aktuelles Geschäftsvolumen*: Wie hoch sind das aktuelle Geschäftsvolumen und die Transaktionsraten?\n* *Zukünftige Konsumtrends*: Was sind die erwarteten künftigen Konsumtrends?\n* *Spitzenlast- und Verfügbarkeitsanforderungen*: Was sind die Spitzenlast- und Verfügbarkeitsanforderungen?\n* *Caching-Strategien*: Welche Caching-Strategien können zur Performanceoptimierung eingesetzt werden?\n* *Strategien zur Ratenbegrenzung*: Welche Strategien zur Ratenbegrenzung können genutzt werden, um die Nutzung zu steuern?\n* *Strategien zur Skalierung*: Welche Strategien zur Skalierung können eingesetzt werden, um das Wachstum zu unterstützen?\n\nh3. Before this station\n* [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n* [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n* [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\nh3. Ready to leave when\n* [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n* [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\nh3. Other related resources\n* *API-Metriken und -Analysen*: Eine Ressource zum Definieren, Sammeln und Analysieren von API-Leistungs- und -Nutzungsdaten, um technische KPIs mit den Geschäftsergebnissen in Einklang zu bringen.\n\nh2. 4. API-Design\n\nErstellen Sie API-Designs, die konsistent, wiederverwendbar und auf Geschäftszielen und gemeinsamen Standards basieren.\n\nh3. Canvas questions\nh4. Domänen-Canvas\nWelche wesentlichen Entitäten, Begriffe und Fachregeln muss die Capability oder Schnittstelle respektieren?\n* *Ausgewählte Customer Journey Schritte*: Welche Customer Journey Schritte sind für diese Domäne relevant?\n* *Grundlegende Entitäten & geschäftliche Bedeutung*: Welches sind die wesentlichen Entitäten und ihre Bedeutung für das Geschäft?\n* *Attribute & geschäftliche Wichtigkeit*: Welches sind die Schlüsselattribute der einzelnen Entitäten und ihre geschäftliche Wichtigkeit?\n* *Beziehungen zwischen Entitäten*: Welche Beziehungen bestehen zwischen den Entitäten?\n* *Fachregeln, Compliance und Integrität*: Welche Fachregeln sowie Compliance- und Integritätsanforderungen beziehen sich auf die Entitäten?\n* *Überlegungen zu Sicherheit und Datenschutz*: Welche Überlegungen zur Sicherheit und zum Datenschutz gibt es im Zusammenhang mit den Entitäten?\n\nh4. Interaktions-Canvas\nWelche Arten von Interaktionen muss diese Capability oder Schnittstelle unterstützen, bevor ein konkretes Protokolldesign gewählt wird?\n* *CRUD Interaktionen*: Sind hier Interaktionen im CRUD-Stil erforderlich?\n* *CRUD Input- & Output-Modelle*: Was sind die Eingabe- und Ausgabemodelle für die CRUD-Interaktionen, falls dieser Stil benötigt wird?\n* *CRUD Verarbeitung & Validierung*: Was sind die Verarbeitungs- und Validierungsregeln für die CRUD-Interaktionen, falls dieser Stil benötigt wird?\n* *Abfragegesteuerte Interaktionen*: Welche Lese- oder Abfrageinteraktionen sind erforderlich, um Nutzerfragen zu beantworten?\n* *Abfragegesteuerte Input- & Output-Modelle*: Was sind die Eingabe- und Ausgabemodelle für die abfragegesteuerten Interaktionen?\n* *Abfragegesteuerte Verarbeitung & Validierung*: Was sind die Verarbeitungs- und Validierungsregeln für die abfragegesteuerten Interaktionen?\n* *Befehlsgesteuerte Interaktionen*: Welche Befehle zur Zustandsänderung sind gegebenenfalls erforderlich?\n* *Befehlsgesteuerte Input- & Output-Modelle*: Was sind die Eingabe- und Ausgabemodelle für die befehlsgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n* *Befehlsgesteuerte Verarbeitung & Validierung*: Was sind die Verarbeitungs- und Validierungsregeln für die befehlsgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n* *Eventgesteuerte Interaktionen*: Welche Ereignisse müssen gegebenenfalls veröffentlicht oder verarbeitet werden?\n* *Eventgesteuerte Input- & Output-Modelle*: Was sind die Eingabe- und Ausgabemodelle für die ereignisgesteuerten Interaktionen, falls dieser Stil erforderlich ist?\n* *Eventgesteuerte Verarbeitung & Validierung*: Was sind die Verarbeitungs- und Validierungsregeln für die ereignisgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n\nh4. REST-Canvas\nWie kann die API nach RESTful-Prinzipien gestaltet werden?\n* *API-Ressourcen*: Was sind die Schlüsselressourcen, die von der API bereitgestellt werden?\n* *API-Ressourcenmodell*: Wie sieht die Struktur des API-Ressourcenmodells aus?\n* *HTTP-Methoden der API*: Welche HTTP-Methoden werden für die Interaktion mit den API-Ressourcen verwendet?\n* *HTTP-Methoden-Beispiel*: Geben Sie für jede HTTP-Methode ein Beispiel für eine API-Anfrage und -Antwort an.\n\nh4. Event-Canvas\nWelche Ereignisse sind für die Capability oder Schnittstelle relevant und wie werden sie verarbeitet?\n* *Nutzeraufgabe / Auslöser*: Welche Nutzeraktion oder welches Systemereignis löst diese Ereignisoperation aus?\n* *Input / Event-Payload*: Welche Daten sind in der eingehenden Event-Payload enthalten? Geben Sie die Schlüsselattribute an.\n* *Verarbeitung / Logik*: Beschreiben Sie die Verarbeitungslogik der Backend-Systeme, einschließlich Validierungen, Transformationen oder Routing-Entscheidungen.\n* *Output / Event-Ergebnis*: Welches Event oder welche Bestätigungsmeldung wird erzeugt? Geben Sie die Attribute des Output-Payloads an.\n\nh4. GraphQL-Canvas\nWie kann die API nach GraphQL-Prinzipien gestaltet werden?\n* *API-Name*: Wie lautet der Name der GraphQL-API oder des Endpunkts?\n* *Ziele der API-Nutzer*: Welche Probleme versuchen API-Nutzer zu lösen? Welche Daten benötigen sie?\n* *Schlüsseltypen*: Welche zentralen Typen werden bereitgestellt (z. B. Nutzer, Bestellung, Produkt)?\n* *Beziehungen*: Wie stehen die Typen in verschachtelten Abfragen zueinander?\n* *Abfragen*: Welche typischen Abfragen sollten unterstützt werden?\n* *Mutationen*: Welche Operationen verändern Daten (z.B. erstellen, aktualisieren, löschen)?\n* *Abonnements*: Gibt es Echtzeit-Updates oder Ereignisse, die Nutzer abonnieren können?\n* *Autorisierungsregeln*: Wer darf auf welche Felder oder Typen zugreifen?\n* *Einschränkungen für Nutzer*: Gibt es Paginierungs-, Filter- oder Ratenbegrenzungen?\n* *Notizen / Offene Fragen*: Gibt es noch offene Entscheidungen oder Integrationsüberlegungen?\n\nh3. Before this station\n* [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n* [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\nh3. Ready to leave when\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\nh3. Other related resources\n* *API Design Prinzipien*: Ein prägnanter Leitfaden zu API-Benutzerfreundlichkeit, Auffindbarkeit und Konsistenz, der auf gemeinsamen Designregeln und echten Kundenbedürfnissen basiert.\n* *Contract-First Integration Design*: Guidance for validating integration contracts before delivery, including OpenAPI, AsyncAPI, event schemas, message schemas, file schemas, data contracts, and interface specifications.\n\nh2. 5. API-Bereitstellung\n\nErstellen, Testen und Freigeben von APIs unter Verwendung moderner Bereitstellungspipelines und bewährter technischer Verfahren.\n\nh3. Station questions\n* Verwenden Sie Best Practices für die API-Entwicklung als Leitfaden für die Implementierung des validierten Schnittstellenvertrags mit etablierten Frameworks und Bibliotheken, um sicherzustellen, dass das Ergebnis wiederverwendbar und wartbar ist.\n* Erstellen Sie die API-Implementierung auf Basis des validierten Schnittstellenvertrags unter Verwendung etablierter Frameworks, Bibliotheken und Teamstandards.\n* Testen Sie APIs auf Funktionalität, Sicherheit und Leistung mit automatisierten Testwerkzeugen.\n* Verwenden Sie CI/CD-Pipelines, um Build-, Test- und Bereitstellungsprozesse zu automatisieren und so konsistente Qualität und Nachvollziehbarkeit zu gewährleisten.\n* Stellen Sie sicher, dass APIs die Sicherheits- und Compliance-Anforderungen durch automatische Prüfungen und Audits erfüllen.\n* Verwenden Sie die API-Audit-Checkliste, um sicherzustellen, dass die API die funktionalen und nicht-funktionalen Anforderungen erfüllt, einschließlich Sicherheit, Leistung und Compliance.\n* Bereitstellung von Frameworks, Bibliotheken und Standards für die API-Implementierung. Implementierung von CI/CD-Pipelines, Qualitätssicherungs-Frameworks und Tools zur Automatisierung der Bereitstellung.\n* Selbst die besten API-Designs scheitern, wenn die Bereitstellung uneinheitlich ist. Diese Station stellt sicher, dass Ihre APIs qualitativ hochwertig erstellt, gründlich getestet und zuverlässig bereitgestellt werden - für schnellere Iterationen und mehr Vertrauen.\n\nh3. Before this station\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\nh3. Ready to leave when\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\nh3. Other related resources\n* *Bewährte Praktiken der API-Entwicklung*: Implementierungsleitfaden zur Umsetzung eines validierten API-Vertrags in eine konsistente, wartbare API-Codebasis unter Verwendung von Standardbibliotheken, wiederverwendbaren Mustern und aufeinander abgestimmten Entwicklungsabläufen.\n* *Bewährte Praktiken für API-Tests*: Richtlinien für die Implementierung automatisierter Funktions-, Leistungs- und Sicherheitstests während des gesamten API-Lebenszyklus.\n* *APIOps CI/CD für APIs*: Bereitstellungsleitfaden, der die Aufgaben des API-Lebenszyklus - Entwurf, Tests, Governance - in die Pipelines für die kontinuierliche Integration und Bereitstellung integriert.\n* *Bewährte Praktiken für die API-Sicherheit*: Eine Reihe praktikabler Kontrollen zur Sicherung von APIs, einschließlich Authentifizierung, Autorisierung, Verschlüsselung, Ratenbegrenzung und Konformitätsprüfungen auf Pipeline-Ebene.\n\nh2. 6. API-Audit\n\nStellen Sie sicher, dass APIs vor der Veröffentlichung und Bereitstellung den geschäftlichen, gestalterischen und betrieblichen Standards entsprechen.\n\nh3. Station questions\n* Führen Sie Audits durch, um sicherzustellen, dass APIs vor der Veröffentlichung organisatorische, technische und rechtliche Standards erfüllen.\n* Verwenden Sie Checklisten, Linters und Testwerkzeuge, um die Konsistenz und Compliance mit den Standards zu überprüfen.\n* Zusammenarbeit mit Governance-Teams und Domänenexperten, um sicherzustellen, dass APIs für die Produktion bereit sind.\n* Richten Sie einen konsistenten Audit-Prozess ein, der die API-Bereitschaft über alle Lebenszyklusphasen hinweg anhand definierter Kriterien, Nachweise und Standards bewertet. Stellen Sie sicher, dass Lücken frühzeitig erkannt und vor der Veröffentlichung behoben werden.\n* APIs sind langlebige Produkte und müssen den Erwartungen hinsichtlich Qualität, Konsistenz und Compliance entsprechen. Das Audit verbindet Designentscheidungen, Implementierung und Betriebsbereitschaft mit definierten Standards und reduziert so Risiken vor der Bereitstellung.\n\nh3. Before this station\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\nh3. Ready to leave when\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Die Schnittstelle und ihre Capabilities sind ausreichend klar für Review, Auditierung und Onboarding dokumentiert.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n* [ ] Der Schnittstellenvertrag wurde validiert und gegen funktionale und nicht-funktionale Anforderungen getestet.\n\nh3. Other related resources\n* *API Audit Checkliste*: Eine lebenszyklusbasierte Checkliste zur Überprüfung der API-Bereitschaft in den Bereichen Design, Bereitstellung, Veröffentlichung und Compliance anhand definierter Audit-Kriterien und Nachweise.\n* *Bewährte Praktiken zur API-Einhaltung*: Sicherstellen, dass APIs durch Dokumentation, Kontrollen und automatisierte Validierungen die rechtlichen, regulatorischen und internen Anforderungen erfüllen.\n\nh2. 7. API-Veröffentlichung\n\nStellen Sie APIs mit der richtigen Dokumentation und den richtigen Prozessen sicher und klar für die richtige Zielgruppe bereit.\n\nh3. Station questions\n* Veröffentlichen Sie APIs in den entsprechenden Gateways und Umgebungen, um die Wiederverwendbarkeit für mehrere Nutzer zu unterstützen.\n* Dokumentieren Sie, wie die Nutzer die API finden und nutzen, einschließlich Onboarding-Prozesse und Registrierung.\n* Stellen Sie sicher, dass die Sicherheitsmodelle, die Gateway-Konfiguration und die rechtlichen Bestimmungen für die Nutzer klar und verständlich sind.\n* Ermöglichung der Veröffentlichung von APIs in der jeweiligen Umgebung mit klaren Registrierungs- und Zugriffsmechanismen (z. B. API-Schlüssel, OAuth, Abonnementpläne) je nach den Nutzersegmenten und den Sicherheits- und Compliance-Anforderungen.\n* Bei der Veröffentlichung geht es nicht nur um die Bereitstellung, sondern auch um die Auffindbarkeit, den Zugang und die Unterstützung. Wenn APIs nicht korrekt veröffentlicht werden, können sie nicht verwendet, wiederverwendet oder effektiv gesichert werden.\n\nh3. Before this station\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Die Schnittstelle und ihre Capabilities sind ausreichend klar für Review, Auditierung und Onboarding dokumentiert.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n* [ ] Der Schnittstellenvertrag wurde validiert und gegen funktionale und nicht-funktionale Anforderungen getestet.\n\nh3. Ready to leave when\n* [ ] Die Lösung besteht Qualitäts-, Sicherheits-, Compliance- und Bereitschaftsprüfungen.\n* [ ] Audit-Ergebnisse und Maßnahmenentscheidungen wurden mit den relevanten Stakeholdern geteilt.\n* [ ] Die Capability ist bereit, über den gewählten Bereitstellungsmechanismus veröffentlicht oder ausgeliefert zu werden.\n* [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n\nh3. Other related resources\n* *APIOps CI/CD für APIs*: Bereitstellungsleitfaden, der die Aufgaben des API-Lebenszyklus - Entwurf, Tests, Governance - in die Pipelines für die kontinuierliche Integration und Bereitstellung integriert.\n* *Bewährte Praktiken beim API-Onboarding*: Bewährte Praktiken zur Optimierung des Onboarding-Prozesses für API-Kunden mit schrittweiser Anleitung zur Registrierung, Erkundung und zum ersten Anruf.\n* *API Audit Checkliste*: Eine lebenszyklusbasierte Checkliste zur Überprüfung der API-Bereitschaft in den Bereichen Design, Bereitstellung, Veröffentlichung und Compliance anhand definierter Audit-Kriterien und Nachweise.\n\nh2. 8. API-Monitoring & Verbesserung\n\nNutzen Sie Messgrößen und Feedback, um die API-Leistung zu verfolgen und kontinuierliche Verbesserungen voranzutreiben.\n\nh3. Station questions\n* Überwachen Sie Leistungsmetriken (z. B. API-Aufrufe, Latenz, Fehlerraten) und Akzeptanzmetriken (z. B. NPS).\n* Analysieren Sie API-Nutzungsmetriken und integrieren Sie Benutzerfeedback in API-Iterationen.\n* Machen Sie es sich zur Gewohnheit, die Messwerte zu überprüfen und kontinuierliche Verbesserungsmaßnahmen zu planen.\n* Einrichtung von Analyserahmen zur Verfolgung von Leistung und Engagement. Entwickeln Sie Feedbackschleifen, Analysetools und Engagementstrategien für APIs.\n* Die API-Bereitstellung endet nicht mit dem Start. Ohne Überwachung können Teams weder die Akzeptanz noch die Leistung oder den ROI verbessern. Diese Station stellt sicher, dass APIs nützlich und sicher bleiben und sich mit den Geschäftsanforderungen weiterentwickeln.\n\nh3. Before this station\n* [ ] Die Lösung besteht Qualitäts-, Sicherheits-, Compliance- und Bereitschaftsprüfungen.\n* [ ] Audit-Ergebnisse und Maßnahmenentscheidungen wurden mit den relevanten Stakeholdern geteilt.\n* [ ] Die Capability ist bereit, über den gewählten Bereitstellungsmechanismus veröffentlicht oder ausgeliefert zu werden.\n* [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n\nh3. Ready to leave when\n* [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n* [ ] Onboarding-, Support- und Kommunikationsprozesse für Nutzer sind bereit.\n* [ ] Rechtliche, Datenschutz- und Compliance-Anforderungen für Veröffentlichung oder Release sind definiert und verstanden.\n\nh3. Other related resources\n* *API-Metriken und -Analysen*: Eine Ressource zum Definieren, Sammeln und Analysieren von API-Leistungs- und -Nutzungsdaten, um technische KPIs mit den Geschäftsergebnissen in Einklang zu bringen.\n* *Strategien für das Engagement der API-Gemeinschaft*: Ein Leitfaden für die Förderung der API-Annahme durch die Pflege von Gemeinschaften durch Inhalte, Support-Kanäle, Feedback-Schleifen und Strategien für soziales Engagement."
      },
      {
        "id": "integration-productization-cycle:question-template-markdown",
        "cycleId": "integration-productization-cycle",
        "kind": "questions",
        "format": "markdown",
        "title": "Integrationszyklus question template Markdown",
        "body": "# Integrationszyklus question template\n\nEin Zyklus zum Definieren und Produktisieren wiederverwendbarer Integrationsfähigkeiten, ohne den Implementierungsstil im Voraus anzunehmen.\n\nUse this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.\n\n## 1. Integrations-Capability-Strategie\n\nBeginnen Sie mit Customer Journey, Fähigkeitswert und Tragfähigkeitsnachweisen und validieren Sie dann, ob die vorgeschlagene wiederverwendbare Integrationsfähigkeit weiterverfolgt werden soll.\n\n### Canvas questions\n#### Customer-Journey-Canvas\nWelche Journey erlebt der am weitesten außen liegende sinnvolle Kunde, und was sollte verbessert werden?\n- **Personas**: Wer ist der typische Kunde oder Nutzer, der diese Reise erlebt?\n- **Kunde erkennt Bedarf**: Wie erkennt der Kunde oder Nutzer ein Bedürfnis oder Problem?\n- **Kundenbedarf wird erfüllt**: Wie wird der Bedarf des Kunden oder Nutzers letztlich erfüllt?\n- **Customer Journey Schritte**: Welche Schritte durchläuft der Kunde bei der Reise?\n- **Probleme**: Welche Probleme oder Pain Points erlebt der Kunde oder Nutzer?\n- **Nutzen**: Welchen Gewinn oder Nutzen hat der Kunde?\n- **Eingaben & Ausgaben**: Was sind die Inputs und Outputs bei jedem Schritt?\n- **Interaktions- und Verarbeitungsregeln**: Wie lauten die Interaktions- und Verarbeitungsregeln bei jedem Schritt?\n- **Verbesserungsmöglichkeiten**: Welche Journey-Schritte zeigen, dass eine zugrunde liegende Capability oder ein Prozess geschaffen, verbessert, automatisiert oder entfernt werden sollte?\n\n#### Fähigkeits-Wertversprechen-Canvas\nWelche wiederverwendbare Capability würde Nutzern Wert liefern, ohne bereits zu entscheiden, ob sie als API, Event, Datei, Stream, Datenprodukt oder ein anderer Implementierungsstil bereitgestellt werden soll?\n- **Nutzeraufgaben und Ergebnisse**: Was möchten Nutzer, Partner, Systeme oder Teams erreichen?\n- **Nutzenstiftende Capability-Funktionen**: Welche Capability-Funktionen helfen Nutzern, bessere Ergebnisse, Geschwindigkeit, Automatisierung, Erkenntnisse, Reichweite oder Compliance zu erreichen?\n- **Pain-Point-reduzierende Capability-Funktionen**: Welche Capability-Funktionen reduzieren Reibung, manuelle Arbeit, Fehler, Verzögerungen, Risiken oder Unsicherheit für Nutzer?\n- **Wiederverwendbare Capabilities**: Welche wiederverwendbaren Geschäfts- oder Daten-Capabilities könnten diese Aufgaben, Nutzen und Pain Points über mehr als einen Nutzer oder Use Case hinweg unterstützen?\n\n#### Fähigkeits-Geschäftsmodell-Canvas\nWie tragfähig, wiederverwendbar, finanziert, verantwortet, unterstützt und auffindbar soll diese Fähigkeit sein?\n- **Wertversprechen der Capability**: Welchen Wert liefert diese wiederverwendbare Capability für Nutzer und für die Organisation oder das Ökosystem?\n- **Nutzersegmente der Capability**: Wer sind die aktuellen und potenziellen Nutzer der Capability, einschließlich Teams, Partnern, Systemen, Produkten oder Datennutzern?\n- **Nutzerinteraktion**: Wie werden Nutzer die Capability entdecken, bewerten, anfordern, onboarden, Unterstützung erhalten und Feedback geben?\n- **Kanäle**: Über welche Kataloge, Portale, Marktplätze, Dokumentationsseiten, Support-Wege oder Governance-Prozesse interagieren Nutzer mit der Capability?\n- **Schlüsselressourcen**: Welche Systeme, Datenbestände, Plattformen, Personen, Standards, Finanzierungen und operativen Fähigkeiten werden benötigt?\n- **Schlüsselaktivitäten**: Was müssen Capability Owner und Produzenten tun, um die Capability zu gestalten, bereitzustellen, zu steuern, zu unterstützen und zu verbessern?\n- **Schlüsselpartner**: Welche Partner aus Business, Technologie, Daten, Sicherheit, Recht, Plattform oder externen Organisationen werden benötigt, damit die Capability funktioniert?\n- **Nutzen**: Welcher geschäftliche, operative, ökologische, wiederverwendungsbezogene, Compliance- oder Kostennutzen rechtfertigt die Capability?\n- **Kosten**: Welche wesentlichen Kosten entstehen durch Aufbau, Betrieb, Governance, Support und Weiterentwicklung der Capability?\n\n#### Canvas zur Validierung der Integrationsfähigkeit\nValidieren Sie, ob eine vorgeschlagene wiederverwendbare Integrationsfähigkeit weiterverfolgt werden sollte.\n- **Zu validierende Fähigkeit**: Welche vorgeschlagene Integrationsfähigkeit und welcher Wiederverwendungsumfang werden geprüft?\n- **Wiederverwendete Nachweise**: Welche früheren Canvas-Ergebnisse stützen den Vorschlag?\n- **Kritische Annahmen**: Was könnte Wert, Wiederverwendung, Ownership, Machbarkeit oder Akzeptanz ungültig machen?\n- **Validierungsschritt**: Was ist die kleinste sinnvolle Validierung und welcher Erfolgsschwellenwert gilt?\n- **Entscheidung**: Fortfahren, eingrenzen, überarbeiten und erneut testen oder stoppen?\n\n### Before this station\n- [ ] Die Geschäftsziele sind definiert.\n- [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n\n### Ready to leave when\n- [ ] Relevante Marktsignale, Feedback oder operative Erkenntnisse liegen vor, um diese Capability-Möglichkeit zu bewerten.\n- [ ] Die Geschäftsziele sind definiert.\n- [ ] Die Marktrecherche identifiziert relevante Capability-Möglichkeiten.\n- [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\n## 2. Verpflichtungen von Integrationsnutzern und -anbietern\n\nVereinbaren Sie Anbieter- und Nutzerverpflichtungen für Zugriff, Validierung, Service, Fehlerbehandlung, Wiederherstellung, Kompatibilität und Lebenszyklus.\n\n### Canvas questions\n#### Canvas für Verpflichtungen von Integrationsnutzern und -anbietern\nVereinbaren Sie die Verantwortlichkeiten, die zur Nutzung und Bereitstellung einer wiederverwendbaren Integrationsfähigkeit erforderlich sind.\n- **Ausgewählte Parteien und Anwendungsfälle**: Welche Produzenten, Anbieter, Nutzer und Anwendungsfälle sind abgedeckt?\n- **Anbieterverpflichtungen**: Was werden Anbieter liefern, warten, überwachen und unterstützen?\n- **Nutzerverpflichtungen**: Was müssen Nutzer testen, schützen, betreiben und kommunizieren?\n- **Zugriff und Validierung**: Wie werden Zugriff, Umgebungen, Credentials und Konformität gehandhabt?\n- **Fehler und Wiederherstellung**: Wer behandelt Fehler, Replay, Duplikate, Abstimmung und Wiederherstellung?\n- **Änderung und Lebenszyklus**: Wie funktionieren Kompatibilität, Migration, Benachrichtigung, Deprecation und Stilllegung?\n\n### Before this station\n- [ ] Relevante Marktsignale, Feedback oder operative Erkenntnisse liegen vor, um diese Capability-Möglichkeit zu bewerten.\n- [ ] Die Geschäftsziele sind definiert.\n- [ ] Die Marktrecherche identifiziert relevante Capability-Möglichkeiten.\n- [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\n### Ready to leave when\n- [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n- [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n- [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\n### Other related resources\n- **Leitfaden für Integrations-Consumer-Onboarding**: Leitfaden für Integrations-Consumer-Onboarding unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n- **Checkliste für Integrationszugriff und Umgebungen**: Checkliste für Integrationszugriff und Umgebungen unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n\n## 3. Integrationsarchitektur & Plattformentscheidungen\n\nWählen Sie Integrationsarchitektur, Implementierungsstil und Plattformfähigkeiten unter Berücksichtigung von Randbedingungen und Governance.\n\n### Canvas questions\n#### Geschäftsauswirkungs-Canvas\nWelcher Wert, welches Risiko sowie welche betrieblichen, finanziellen, kunden-, mitarbeiter-, compliance- und strategischen Auswirkungen werden erwartet oder stehen auf dem Spiel?\n- **Erwartete Vorteile**: Welche geschäftlichen, kundenbezogenen, mitarbeiterbezogenen, qualitäts-, geschwindigkeits-, risiko-, compliance- oder strategischen Vorteile werden erwartet?\n- **Auswirkung auf die operative Effizienz**: Wie könnten Arbeitsaufwand, Wartezeit, Nacharbeit, Durchsatz, Zuverlässigkeit, Supportbelastung oder Betriebskosten sich verändern?\n- **Auswirkung auf Kunden und Mitarbeitende**: Wie werden Kunden, Mitarbeitende, Partner, Betreiber oder Supportteams die Veränderung erleben?\n- **Finanzielle Auswirkung**: Welche Auswirkungen auf Umsatz, Kosten, Investitionen, Einsparungen, vermiedene Verluste oder Finanzierung werden erwartet?\n- **Compliance- und strategische Auswirkung**: Welche regulatorischen, vertraglichen, richtlinienbezogenen, reputations-, markt-, ökosystem- oder strategischen Konsequenzen sind relevant?\n- **Auswirkung des Nicht-Fortfahrens**: Was geschieht, wenn die Capability, Automatisierung, Integration oder der Service nicht verbessert oder geliefert wird?\n- **Risiken und Kritikalität**: Welche Verfügbarkeits-, Sicherheits-, Daten-, Safety-, Prozess-, Akzeptanz- oder Business-Continuity-Risiken könnten das Ergebnis beeinflussen?\n- **Gegenmaßnahmen und Entscheidungsauswirkung**: Welche Gegenmaßnahmen, Einschränkungen, Kompromisse oder Restrisiken sollten Priorisierung, Architektur, Rollout oder Readiness-Entscheidungen beeinflussen?\n\n#### Standort-Canvas\nWelche geopolitischen, regulatorischen, Netzwerk- und Vertrauensgrenzen betreffen diese Capability oder Schnittstelle?\n- **Standort-/Vertrauensgruppen**: Welche geopolitischen, regulatorischen, netzwerkbezogenen oder vertrauensbezogenen Gruppen sind relevant?\n- **Gruppenmerkmale**: Was sind die Merkmale dieser Gruppen, wie z. B. Standort, Vertrauensstufe oder Netzwerkexposition?\n- **Relevante Standorte / Zonen**: Was sind die relevanten Standorte, Zonen oder Umgebungen innerhalb jeder Gruppe?\n- **Standort-/Zonenmerkmale**: Was sind die Merkmale dieser Standorte oder Zonen, wie z. B. Eigentumsverhältnisse, Region oder Exposition?\n- **Netzwerk- / Regulierungsentfernungen**: Welche Latenz-, Vertrauens-, Regulierungs- oder Konnektivitätsentfernungen bestehen zwischen den Standorten?\n- **Entfernungsmerkmale**: Was sind die Merkmale dieser Entfernungen, wie z. B. Latenzempfindlichkeit, Aufenthaltsbeschränkungen oder Vertrauensgrenzen?\n- **Konnektivitätsendpunkte**: Welche Konnektivitätsendpunkte oder Schnittstellen sind mit den Standorten verbunden?\n- **Endpunktzugriffseigenschaften**: Welche Eigenschaften weisen diese Endpunkte auf, wie z. B. Sichtbarkeit, Protokoll, Sicherheit oder Zugriffsbeschränkungen?\n\n#### Kapazitäts-Canvas\nWie viel Nachfrage, Last, Timing und Skalierungskapazität müssen für Fähigkeit, Automatisierung, Integration oder Service verstanden werden?\n- **Aktuelles Geschäftsvolumen**: Wie hoch sind das aktuelle Geschäftsvolumen und die Transaktionsraten?\n- **Zukünftige Konsumtrends**: Was sind die erwarteten künftigen Konsumtrends?\n- **Spitzenlast- und Verfügbarkeitsanforderungen**: Was sind die Spitzenlast- und Verfügbarkeitsanforderungen?\n- **Caching-Strategien**: Welche Caching-Strategien können zur Performanceoptimierung eingesetzt werden?\n- **Strategien zur Ratenbegrenzung**: Welche Strategien zur Ratenbegrenzung können genutzt werden, um die Nutzung zu steuern?\n- **Strategien zur Skalierung**: Welche Strategien zur Skalierung können eingesetzt werden, um das Wachstum zu unterstützen?\n\n#### Canvas für Integrationsarchitektur-Entscheidung\nWählen Sie Integrationsstil und Plattform anhand bereits gesammelter Nachweise.\n- **Wiederverwendete Eingaben**: Welche Verpflichtungen sowie Kapazitäts-, Standort-, Auswirkungs- und Domänenentscheidungen begrenzen die Auswahl?\n- **Tragfähige Optionen**: Welche API-, Event-, Messaging-, Datei-, Stream-, Daten-, Konnektor-, Plattform- oder individuellen Optionen bleiben tragfähig?\n- **Ausgewählter Ansatz**: Welcher Integrationsstil, welche Plattform oder welcher hybride Ansatz wird ausgewählt?\n- **Entscheidungsbegründung**: Warum passt der ausgewählte Ansatz am besten?\n- **Abgelehnte Alternativen**: Welche ernsthaften Alternativen wurden abgelehnt, und warum?\n- **Offene Risiken**: Was muss vor Lieferung oder Release noch validiert werden?\n\n### Before this station\n- [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n- [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n- [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\n### Ready to leave when\n- [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n- [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\n## 4. Integrationsdesign\n\nEntwerfen Sie Integrationslösung, Verträge, Schemas, Datenstrukturen, Mappings sowie Interaktions- oder Liefermuster für den ausgewählten Stil.\n\n### Canvas questions\n#### Domänen-Canvas\nWelche wesentlichen Entitäten, Begriffe und Fachregeln muss die Capability oder Schnittstelle respektieren?\n- **Ausgewählte Customer Journey Schritte**: Welche Customer Journey Schritte sind für diese Domäne relevant?\n- **Grundlegende Entitäten & geschäftliche Bedeutung**: Welches sind die wesentlichen Entitäten und ihre Bedeutung für das Geschäft?\n- **Attribute & geschäftliche Wichtigkeit**: Welches sind die Schlüsselattribute der einzelnen Entitäten und ihre geschäftliche Wichtigkeit?\n- **Beziehungen zwischen Entitäten**: Welche Beziehungen bestehen zwischen den Entitäten?\n- **Fachregeln, Compliance und Integrität**: Welche Fachregeln sowie Compliance- und Integritätsanforderungen beziehen sich auf die Entitäten?\n- **Überlegungen zu Sicherheit und Datenschutz**: Welche Überlegungen zur Sicherheit und zum Datenschutz gibt es im Zusammenhang mit den Entitäten?\n\n#### Canvas für Integrationslösungsdesign\nVerfeinern Sie die ausgewählte Architektur zu einem umsetzbaren Integrationsdesign.\n- **Ausgewählte Eingaben**: Welche Architektur-, Domänen-, Interaktions- und Verpflichtungsentscheidungen werden wiederverwendet?\n- **Vertrag und Modell**: Welcher Vertrag, welches Schema, Datenmodell und welche Version definieren die Integration?\n- **Mapping und Lieferung**: Welche Transformationen, Liefermuster und Metadaten sind erforderlich?\n- **Fehler und Wiederherstellung**: Wie werden Fehler, Retries, Replay, Duplikate und Abstimmung behandelt?\n- **Sicherheit und Vertrauen**: Welche Identitäts-, Zugriffs-, Datenschutz- und Vertrauenskontrollen gelten?\n- **Observability und Weiterentwicklung**: Wie wird die Integration überwacht, geändert, migriert und als deprecated markiert?\n\n#### Interaktions-Canvas\nWelche Arten von Interaktionen muss diese Capability oder Schnittstelle unterstützen, bevor ein konkretes Protokolldesign gewählt wird?\n- **CRUD Interaktionen**: Sind hier Interaktionen im CRUD-Stil erforderlich?\n- **CRUD Input- & Output-Modelle**: Was sind die Eingabe- und Ausgabemodelle für die CRUD-Interaktionen, falls dieser Stil benötigt wird?\n- **CRUD Verarbeitung & Validierung**: Was sind die Verarbeitungs- und Validierungsregeln für die CRUD-Interaktionen, falls dieser Stil benötigt wird?\n- **Abfragegesteuerte Interaktionen**: Welche Lese- oder Abfrageinteraktionen sind erforderlich, um Nutzerfragen zu beantworten?\n- **Abfragegesteuerte Input- & Output-Modelle**: Was sind die Eingabe- und Ausgabemodelle für die abfragegesteuerten Interaktionen?\n- **Abfragegesteuerte Verarbeitung & Validierung**: Was sind die Verarbeitungs- und Validierungsregeln für die abfragegesteuerten Interaktionen?\n- **Befehlsgesteuerte Interaktionen**: Welche Befehle zur Zustandsänderung sind gegebenenfalls erforderlich?\n- **Befehlsgesteuerte Input- & Output-Modelle**: Was sind die Eingabe- und Ausgabemodelle für die befehlsgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n- **Befehlsgesteuerte Verarbeitung & Validierung**: Was sind die Verarbeitungs- und Validierungsregeln für die befehlsgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n- **Eventgesteuerte Interaktionen**: Welche Ereignisse müssen gegebenenfalls veröffentlicht oder verarbeitet werden?\n- **Eventgesteuerte Input- & Output-Modelle**: Was sind die Eingabe- und Ausgabemodelle für die ereignisgesteuerten Interaktionen, falls dieser Stil erforderlich ist?\n- **Eventgesteuerte Verarbeitung & Validierung**: Was sind die Verarbeitungs- und Validierungsregeln für die ereignisgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n\n### Before this station\n- [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n- [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\n### Ready to leave when\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\n### Other related resources\n- **Contract-First Integration Design**: Guidance for validating integration contracts before delivery, including OpenAPI, AsyncAPI, event schemas, message schemas, file schemas, data contracts, and interface specifications.\n- **Leitfaden für integrationsstilspezifisches Design**: Leitfaden für integrationsstilspezifisches Design unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n\n## 5. Integrationsbereitstellung & Betrieb\n\nBauen, testen, deployen und betreiben Sie die Integrationsfähigkeit mit ausgewähltem Implementierungsstil und validiertem Vertrag.\n\n### Canvas questions\n#### Canvas für Integrationsbereitschaft und Betrieb\nBereiten Sie die minimal erforderlichen Betriebsnachweise vor der Integrations-Readiness-Prüfung vor.\n- **Verantwortlichkeit**: Wer verantwortet Geschäfts-, Integrations-, Produzenten-, Nutzer-, Plattform- und Incident-Aufgaben?\n- **Umgebungen und Zugriff**: Sind Umgebungen, Credentials, Konnektivität, Berechtigungen und Sequenzierung bereit?\n- **Testnachweise**: Was belegt Vertrag, Mapping, Kompatibilität, Qualität, Resilienz und Wiederherstellung?\n- **Monitoring und Support**: Wie werden Produzenten, Nutzer, Plattformen, Incidents und Servicefragen unterstützt?\n- **Fehler und Wiederherstellung**: Wie funktionieren Retry, Replay, Duplikate, Abstimmung, Fallback und Kompensation?\n- **Readiness-Status**: Sind Verträge, Runbooks, Abhängigkeiten, Risiken, Bedingungen und blockierende Lücken klar?\n\n### Before this station\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\n### Ready to leave when\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\n### Other related resources\n- **Best Practices für Integrationsentwicklung**: Best Practices für Integrationsentwicklung unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n- **Leitfaden für Integrationstests**: Leitfaden für Integrationstests unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n- **Leitfaden für Integrations-CI/CD und Deployment**: Leitfaden für Integrations-CI/CD und Deployment unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n- **Leitfaden für Integrationssicherheit**: Leitfaden für Integrationssicherheit unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n- **Leitfaden für Integrationswiederherstellung und Abstimmung**: Leitfaden für Integrationswiederherstellung und Abstimmung unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n\n## 6. Integrationsbereitschaftssicherung\n\nSichern Sie Integrations-Readiness, Governance, Qualität, Security, Compliance und operative Nachweise vor der Freigabe ab.\n\n### Station questions\n- Prüfen Sie abgeschlossenes Design, Testnachweise, Betriebsmodell, Berechtigungen, Credentials, Monitoring, Support, Fallback und Rollback.\n- Verifizieren Sie, dass bekannte Risiken, Ausnahmen, unsichere Aktionen, menschliche Aufsicht, Compliance-Anforderungen und offene Annahmen adressiert oder ausdrücklich akzeptiert sind.\n- Dokumentieren Sie blockierende Befunde, akzeptierte Restrisiken, Freigabebedingungen und erforderliche Remediation-Maßnahmen.\n- Entscheiden Sie, ob die Freigabe bereit, bedingt bereit, remediation-pflichtig oder nicht genehmigt ist.\n- Dokumentieren Sie Entscheidungsverantwortliche, Entscheidungsdatum und verwendete Nachweise.\n- Bestätigen Sie, dass nichts ohne klare fachliche und betriebliche Ownership freigegeben wird.\n- Nutzen Sie Bereitschaftsnachweise, um vor der Produktionsnutzung eine ausdrückliche Go-, bedingte Go- oder No-go-Entscheidung zu treffen.\n- Eine formale Bereitschaftsentscheidung verhindert, dass Automatisierungslösungen ohne klare Nachweise, akzeptierte Risiken, Remediation-Maßnahmen sowie fachliche und betriebliche Ownership freigegeben werden.\n\n### Before this station\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\n### Ready to leave when\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Die Schnittstelle und ihre Capabilities sind ausreichend klar für Review, Auditierung und Onboarding dokumentiert.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n- [ ] Der Schnittstellenvertrag wurde validiert und gegen funktionale und nicht-funktionale Anforderungen getestet.\n\n### Other related resources\n- **Checkliste für Integration Readiness**: Checkliste für Integration Readiness unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n- **Leitfaden für Integrations-Compliance und Data Governance**: Leitfaden für Integrations-Compliance und Data Governance unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n\n## 7. Integrationsveroeffentlichung & Enablement\n\nVeröffentlichen Sie die Integrationsfähigkeit, damit Teams sie finden, bewerten, Zugriff beantragen, onboarding durchführen, wiederverwenden und Support erhalten können.\n\n### Station questions\n- Betroffene Personen und geänderte Arbeit: Wer wird die Freigabe nutzen, betreiben, unterstützen, genehmigen, konsumieren oder davon betroffen sein, und welche Verantwortlichkeiten, Entscheidungen, Übergaben oder Arbeitsweisen ändern sich?\n- Aktivierungs- und Rollout-Ansatz: Wie werden Zugriff, Berechtigungen, Pilotnutzung, phasenweiser Rollout, eingeschränkte Gruppen, Parallelbetrieb und Rollout-Erweiterung gesteuert?\n- Enablement und Support: Welche Kommunikation, Schulung, Betriebsanweisungen und Supportpfade sind erforderlich?\n- Feedback und Kontrolle: Wie werden Adoption, Vertrauen, tatsächliche Nutzung, Probleme und unerwartetes Verhalten überwacht, und welche Bedingungen lösen Pause, Rollback oder Rückkehr zum manuellen Betrieb aus?\n- Planen Sie Rollout, Befähigung, Support, Feedback und Rollback, damit freigegebene Lösungen sicher eingeführt werden können.\n- Automatisierungslösungen schaffen erst nach dem Rollout Wert, wenn betroffene Personen und konsumierende Systeme verstehen, was sich ändert, wie Zugriff und Betrieb funktionieren, wo Unterstützung verfügbar ist und wann der Rollout pausiert, erweitert oder zurückgerollt werden muss.\n\n### Before this station\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Die Schnittstelle und ihre Capabilities sind ausreichend klar für Review, Auditierung und Onboarding dokumentiert.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n- [ ] Der Schnittstellenvertrag wurde validiert und gegen funktionale und nicht-funktionale Anforderungen getestet.\n\n### Ready to leave when\n- [ ] Die Lösung besteht Qualitäts-, Sicherheits-, Compliance- und Bereitschaftsprüfungen.\n- [ ] Audit-Ergebnisse und Maßnahmenentscheidungen wurden mit den relevanten Stakeholdern geteilt.\n- [ ] Die Capability ist bereit, über den gewählten Bereitstellungsmechanismus veröffentlicht oder ausgeliefert zu werden.\n- [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n\n### Other related resources\n- **Leitfaden für Integrationsveröffentlichung und Auffindbarkeit**: Leitfaden für Integrationsveröffentlichung und Auffindbarkeit unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n- **Leitfaden für Integrations-Consumer-Onboarding**: Leitfaden für Integrations-Consumer-Onboarding unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n- **Vorlage für Integrations-Servicevereinbarungen**: Vorlage für Integrations-Servicevereinbarungen unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n- **Leitfaden für Integrationsversionierung und Deprecation**: Leitfaden für Integrationsversionierung und Deprecation unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n\n## 8. Integrationsmonitoring & Verbesserung\n\nÜberwachen Sie Integrationszuverlässigkeit, Wiederverwendung, Incidents, Performance, Consumer-Ergebnisse und Verbesserungsbedarf.\n\n### Station questions\n- Ergebnisse und Wert: Werden die erwarteten Prozess-, Nutzer- und Geschäftsergebnisse erreicht?\n- Betriebsleistung: Was zeigen erfolgreiche Läufe, Fehler, Teilabschlüsse, Ausnahmen, Wiederholungen, Timeouts, Interventionen, Verarbeitungszeit, Wartezeit und Kosten?\n- Nutzer-, Risiko- und Wiederherstellungssignale: Welche Fehler, Korrekturen, unsicheren Aktionen, Umgehungen, Misstrauen, Supportbedarfe, Fallback-Ereignisse oder Wiederherstellungsfehler treten auf?\n- Lernen und Lifecycle-Entscheidung: Welche Hypothesenannahmen wurden bestätigt oder verworfen, und sollte die Lösung verbessert, erweitert, eingeschränkt, neu gestaltet, pausiert oder stillgelegt werden?\n- Nutzen Sie operative, Nutzer-, Risiko- und Wertnachweise, um zu entscheiden, was verbessert, erweitert, eingeschränkt, pausiert oder stillgelegt werden soll.\n- Freigegebene Lösungen benötigen Nachweise, ob erwartete Ergebnisse erreicht werden, wo manuelle Intervention oder Wiederherstellung noch nötig ist und welche Lifecycle-Entscheidung als Nächstes getroffen werden sollte.\n\n### Before this station\n- [ ] Die Lösung besteht Qualitäts-, Sicherheits-, Compliance- und Bereitschaftsprüfungen.\n- [ ] Audit-Ergebnisse und Maßnahmenentscheidungen wurden mit den relevanten Stakeholdern geteilt.\n- [ ] Die Capability ist bereit, über den gewählten Bereitstellungsmechanismus veröffentlicht oder ausgeliefert zu werden.\n- [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n\n### Ready to leave when\n- [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n- [ ] Onboarding-, Support- und Kommunikationsprozesse für Nutzer sind bereit.\n- [ ] Rechtliche, Datenschutz- und Compliance-Anforderungen für Veröffentlichung oder Release sind definiert und verstanden.\n\n### Other related resources\n- **Integrationsmonitoring und Wertmetriken**: Integrationsmonitoring und Wertmetriken unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n- **Leitfaden für Integrations-Consumer-Feedback und Adoption**: Leitfaden für Integrations-Consumer-Feedback und Adoption unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n- **Integrationszuverlässigkeit und Datenqualitätsmetriken**: Integrationszuverlässigkeit und Datenqualitätsmetriken unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n- **Leitfaden für Integrations-Lifecycle-Management**: Leitfaden für Integrations-Lifecycle-Management unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit."
      },
      {
        "id": "integration-productization-cycle:question-template-confluence-wiki",
        "cycleId": "integration-productization-cycle",
        "kind": "questions",
        "format": "confluence-wiki",
        "title": "Integrationszyklus question template Confluence wiki",
        "body": "h1. Integrationszyklus question template\n\nEin Zyklus zum Definieren und Produktisieren wiederverwendbarer Integrationsfähigkeiten, ohne den Implementierungsstil im Voraus anzunehmen.\n\nUse this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.\n\nh2. 1. Integrations-Capability-Strategie\n\nBeginnen Sie mit Customer Journey, Fähigkeitswert und Tragfähigkeitsnachweisen und validieren Sie dann, ob die vorgeschlagene wiederverwendbare Integrationsfähigkeit weiterverfolgt werden soll.\n\nh3. Canvas questions\nh4. Customer-Journey-Canvas\nWelche Journey erlebt der am weitesten außen liegende sinnvolle Kunde, und was sollte verbessert werden?\n* *Personas*: Wer ist der typische Kunde oder Nutzer, der diese Reise erlebt?\n* *Kunde erkennt Bedarf*: Wie erkennt der Kunde oder Nutzer ein Bedürfnis oder Problem?\n* *Kundenbedarf wird erfüllt*: Wie wird der Bedarf des Kunden oder Nutzers letztlich erfüllt?\n* *Customer Journey Schritte*: Welche Schritte durchläuft der Kunde bei der Reise?\n* *Probleme*: Welche Probleme oder Pain Points erlebt der Kunde oder Nutzer?\n* *Nutzen*: Welchen Gewinn oder Nutzen hat der Kunde?\n* *Eingaben & Ausgaben*: Was sind die Inputs und Outputs bei jedem Schritt?\n* *Interaktions- und Verarbeitungsregeln*: Wie lauten die Interaktions- und Verarbeitungsregeln bei jedem Schritt?\n* *Verbesserungsmöglichkeiten*: Welche Journey-Schritte zeigen, dass eine zugrunde liegende Capability oder ein Prozess geschaffen, verbessert, automatisiert oder entfernt werden sollte?\n\nh4. Fähigkeits-Wertversprechen-Canvas\nWelche wiederverwendbare Capability würde Nutzern Wert liefern, ohne bereits zu entscheiden, ob sie als API, Event, Datei, Stream, Datenprodukt oder ein anderer Implementierungsstil bereitgestellt werden soll?\n* *Nutzeraufgaben und Ergebnisse*: Was möchten Nutzer, Partner, Systeme oder Teams erreichen?\n* *Nutzenstiftende Capability-Funktionen*: Welche Capability-Funktionen helfen Nutzern, bessere Ergebnisse, Geschwindigkeit, Automatisierung, Erkenntnisse, Reichweite oder Compliance zu erreichen?\n* *Pain-Point-reduzierende Capability-Funktionen*: Welche Capability-Funktionen reduzieren Reibung, manuelle Arbeit, Fehler, Verzögerungen, Risiken oder Unsicherheit für Nutzer?\n* *Wiederverwendbare Capabilities*: Welche wiederverwendbaren Geschäfts- oder Daten-Capabilities könnten diese Aufgaben, Nutzen und Pain Points über mehr als einen Nutzer oder Use Case hinweg unterstützen?\n\nh4. Fähigkeits-Geschäftsmodell-Canvas\nWie tragfähig, wiederverwendbar, finanziert, verantwortet, unterstützt und auffindbar soll diese Fähigkeit sein?\n* *Wertversprechen der Capability*: Welchen Wert liefert diese wiederverwendbare Capability für Nutzer und für die Organisation oder das Ökosystem?\n* *Nutzersegmente der Capability*: Wer sind die aktuellen und potenziellen Nutzer der Capability, einschließlich Teams, Partnern, Systemen, Produkten oder Datennutzern?\n* *Nutzerinteraktion*: Wie werden Nutzer die Capability entdecken, bewerten, anfordern, onboarden, Unterstützung erhalten und Feedback geben?\n* *Kanäle*: Über welche Kataloge, Portale, Marktplätze, Dokumentationsseiten, Support-Wege oder Governance-Prozesse interagieren Nutzer mit der Capability?\n* *Schlüsselressourcen*: Welche Systeme, Datenbestände, Plattformen, Personen, Standards, Finanzierungen und operativen Fähigkeiten werden benötigt?\n* *Schlüsselaktivitäten*: Was müssen Capability Owner und Produzenten tun, um die Capability zu gestalten, bereitzustellen, zu steuern, zu unterstützen und zu verbessern?\n* *Schlüsselpartner*: Welche Partner aus Business, Technologie, Daten, Sicherheit, Recht, Plattform oder externen Organisationen werden benötigt, damit die Capability funktioniert?\n* *Nutzen*: Welcher geschäftliche, operative, ökologische, wiederverwendungsbezogene, Compliance- oder Kostennutzen rechtfertigt die Capability?\n* *Kosten*: Welche wesentlichen Kosten entstehen durch Aufbau, Betrieb, Governance, Support und Weiterentwicklung der Capability?\n\nh4. Canvas zur Validierung der Integrationsfähigkeit\nValidieren Sie, ob eine vorgeschlagene wiederverwendbare Integrationsfähigkeit weiterverfolgt werden sollte.\n* *Zu validierende Fähigkeit*: Welche vorgeschlagene Integrationsfähigkeit und welcher Wiederverwendungsumfang werden geprüft?\n* *Wiederverwendete Nachweise*: Welche früheren Canvas-Ergebnisse stützen den Vorschlag?\n* *Kritische Annahmen*: Was könnte Wert, Wiederverwendung, Ownership, Machbarkeit oder Akzeptanz ungültig machen?\n* *Validierungsschritt*: Was ist die kleinste sinnvolle Validierung und welcher Erfolgsschwellenwert gilt?\n* *Entscheidung*: Fortfahren, eingrenzen, überarbeiten und erneut testen oder stoppen?\n\nh3. Before this station\n* [ ] Die Geschäftsziele sind definiert.\n* [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n\nh3. Ready to leave when\n* [ ] Relevante Marktsignale, Feedback oder operative Erkenntnisse liegen vor, um diese Capability-Möglichkeit zu bewerten.\n* [ ] Die Geschäftsziele sind definiert.\n* [ ] Die Marktrecherche identifiziert relevante Capability-Möglichkeiten.\n* [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\nh2. 2. Verpflichtungen von Integrationsnutzern und -anbietern\n\nVereinbaren Sie Anbieter- und Nutzerverpflichtungen für Zugriff, Validierung, Service, Fehlerbehandlung, Wiederherstellung, Kompatibilität und Lebenszyklus.\n\nh3. Canvas questions\nh4. Canvas für Verpflichtungen von Integrationsnutzern und -anbietern\nVereinbaren Sie die Verantwortlichkeiten, die zur Nutzung und Bereitstellung einer wiederverwendbaren Integrationsfähigkeit erforderlich sind.\n* *Ausgewählte Parteien und Anwendungsfälle*: Welche Produzenten, Anbieter, Nutzer und Anwendungsfälle sind abgedeckt?\n* *Anbieterverpflichtungen*: Was werden Anbieter liefern, warten, überwachen und unterstützen?\n* *Nutzerverpflichtungen*: Was müssen Nutzer testen, schützen, betreiben und kommunizieren?\n* *Zugriff und Validierung*: Wie werden Zugriff, Umgebungen, Credentials und Konformität gehandhabt?\n* *Fehler und Wiederherstellung*: Wer behandelt Fehler, Replay, Duplikate, Abstimmung und Wiederherstellung?\n* *Änderung und Lebenszyklus*: Wie funktionieren Kompatibilität, Migration, Benachrichtigung, Deprecation und Stilllegung?\n\nh3. Before this station\n* [ ] Relevante Marktsignale, Feedback oder operative Erkenntnisse liegen vor, um diese Capability-Möglichkeit zu bewerten.\n* [ ] Die Geschäftsziele sind definiert.\n* [ ] Die Marktrecherche identifiziert relevante Capability-Möglichkeiten.\n* [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\nh3. Ready to leave when\n* [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n* [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n* [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\nh3. Other related resources\n* *Leitfaden für Integrations-Consumer-Onboarding*: Leitfaden für Integrations-Consumer-Onboarding unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n* *Checkliste für Integrationszugriff und Umgebungen*: Checkliste für Integrationszugriff und Umgebungen unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n\nh2. 3. Integrationsarchitektur & Plattformentscheidungen\n\nWählen Sie Integrationsarchitektur, Implementierungsstil und Plattformfähigkeiten unter Berücksichtigung von Randbedingungen und Governance.\n\nh3. Canvas questions\nh4. Geschäftsauswirkungs-Canvas\nWelcher Wert, welches Risiko sowie welche betrieblichen, finanziellen, kunden-, mitarbeiter-, compliance- und strategischen Auswirkungen werden erwartet oder stehen auf dem Spiel?\n* *Erwartete Vorteile*: Welche geschäftlichen, kundenbezogenen, mitarbeiterbezogenen, qualitäts-, geschwindigkeits-, risiko-, compliance- oder strategischen Vorteile werden erwartet?\n* *Auswirkung auf die operative Effizienz*: Wie könnten Arbeitsaufwand, Wartezeit, Nacharbeit, Durchsatz, Zuverlässigkeit, Supportbelastung oder Betriebskosten sich verändern?\n* *Auswirkung auf Kunden und Mitarbeitende*: Wie werden Kunden, Mitarbeitende, Partner, Betreiber oder Supportteams die Veränderung erleben?\n* *Finanzielle Auswirkung*: Welche Auswirkungen auf Umsatz, Kosten, Investitionen, Einsparungen, vermiedene Verluste oder Finanzierung werden erwartet?\n* *Compliance- und strategische Auswirkung*: Welche regulatorischen, vertraglichen, richtlinienbezogenen, reputations-, markt-, ökosystem- oder strategischen Konsequenzen sind relevant?\n* *Auswirkung des Nicht-Fortfahrens*: Was geschieht, wenn die Capability, Automatisierung, Integration oder der Service nicht verbessert oder geliefert wird?\n* *Risiken und Kritikalität*: Welche Verfügbarkeits-, Sicherheits-, Daten-, Safety-, Prozess-, Akzeptanz- oder Business-Continuity-Risiken könnten das Ergebnis beeinflussen?\n* *Gegenmaßnahmen und Entscheidungsauswirkung*: Welche Gegenmaßnahmen, Einschränkungen, Kompromisse oder Restrisiken sollten Priorisierung, Architektur, Rollout oder Readiness-Entscheidungen beeinflussen?\n\nh4. Standort-Canvas\nWelche geopolitischen, regulatorischen, Netzwerk- und Vertrauensgrenzen betreffen diese Capability oder Schnittstelle?\n* *Standort-/Vertrauensgruppen*: Welche geopolitischen, regulatorischen, netzwerkbezogenen oder vertrauensbezogenen Gruppen sind relevant?\n* *Gruppenmerkmale*: Was sind die Merkmale dieser Gruppen, wie z. B. Standort, Vertrauensstufe oder Netzwerkexposition?\n* *Relevante Standorte / Zonen*: Was sind die relevanten Standorte, Zonen oder Umgebungen innerhalb jeder Gruppe?\n* *Standort-/Zonenmerkmale*: Was sind die Merkmale dieser Standorte oder Zonen, wie z. B. Eigentumsverhältnisse, Region oder Exposition?\n* *Netzwerk- / Regulierungsentfernungen*: Welche Latenz-, Vertrauens-, Regulierungs- oder Konnektivitätsentfernungen bestehen zwischen den Standorten?\n* *Entfernungsmerkmale*: Was sind die Merkmale dieser Entfernungen, wie z. B. Latenzempfindlichkeit, Aufenthaltsbeschränkungen oder Vertrauensgrenzen?\n* *Konnektivitätsendpunkte*: Welche Konnektivitätsendpunkte oder Schnittstellen sind mit den Standorten verbunden?\n* *Endpunktzugriffseigenschaften*: Welche Eigenschaften weisen diese Endpunkte auf, wie z. B. Sichtbarkeit, Protokoll, Sicherheit oder Zugriffsbeschränkungen?\n\nh4. Kapazitäts-Canvas\nWie viel Nachfrage, Last, Timing und Skalierungskapazität müssen für Fähigkeit, Automatisierung, Integration oder Service verstanden werden?\n* *Aktuelles Geschäftsvolumen*: Wie hoch sind das aktuelle Geschäftsvolumen und die Transaktionsraten?\n* *Zukünftige Konsumtrends*: Was sind die erwarteten künftigen Konsumtrends?\n* *Spitzenlast- und Verfügbarkeitsanforderungen*: Was sind die Spitzenlast- und Verfügbarkeitsanforderungen?\n* *Caching-Strategien*: Welche Caching-Strategien können zur Performanceoptimierung eingesetzt werden?\n* *Strategien zur Ratenbegrenzung*: Welche Strategien zur Ratenbegrenzung können genutzt werden, um die Nutzung zu steuern?\n* *Strategien zur Skalierung*: Welche Strategien zur Skalierung können eingesetzt werden, um das Wachstum zu unterstützen?\n\nh4. Canvas für Integrationsarchitektur-Entscheidung\nWählen Sie Integrationsstil und Plattform anhand bereits gesammelter Nachweise.\n* *Wiederverwendete Eingaben*: Welche Verpflichtungen sowie Kapazitäts-, Standort-, Auswirkungs- und Domänenentscheidungen begrenzen die Auswahl?\n* *Tragfähige Optionen*: Welche API-, Event-, Messaging-, Datei-, Stream-, Daten-, Konnektor-, Plattform- oder individuellen Optionen bleiben tragfähig?\n* *Ausgewählter Ansatz*: Welcher Integrationsstil, welche Plattform oder welcher hybride Ansatz wird ausgewählt?\n* *Entscheidungsbegründung*: Warum passt der ausgewählte Ansatz am besten?\n* *Abgelehnte Alternativen*: Welche ernsthaften Alternativen wurden abgelehnt, und warum?\n* *Offene Risiken*: Was muss vor Lieferung oder Release noch validiert werden?\n\nh3. Before this station\n* [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n* [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n* [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\nh3. Ready to leave when\n* [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n* [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\nh2. 4. Integrationsdesign\n\nEntwerfen Sie Integrationslösung, Verträge, Schemas, Datenstrukturen, Mappings sowie Interaktions- oder Liefermuster für den ausgewählten Stil.\n\nh3. Canvas questions\nh4. Domänen-Canvas\nWelche wesentlichen Entitäten, Begriffe und Fachregeln muss die Capability oder Schnittstelle respektieren?\n* *Ausgewählte Customer Journey Schritte*: Welche Customer Journey Schritte sind für diese Domäne relevant?\n* *Grundlegende Entitäten & geschäftliche Bedeutung*: Welches sind die wesentlichen Entitäten und ihre Bedeutung für das Geschäft?\n* *Attribute & geschäftliche Wichtigkeit*: Welches sind die Schlüsselattribute der einzelnen Entitäten und ihre geschäftliche Wichtigkeit?\n* *Beziehungen zwischen Entitäten*: Welche Beziehungen bestehen zwischen den Entitäten?\n* *Fachregeln, Compliance und Integrität*: Welche Fachregeln sowie Compliance- und Integritätsanforderungen beziehen sich auf die Entitäten?\n* *Überlegungen zu Sicherheit und Datenschutz*: Welche Überlegungen zur Sicherheit und zum Datenschutz gibt es im Zusammenhang mit den Entitäten?\n\nh4. Canvas für Integrationslösungsdesign\nVerfeinern Sie die ausgewählte Architektur zu einem umsetzbaren Integrationsdesign.\n* *Ausgewählte Eingaben*: Welche Architektur-, Domänen-, Interaktions- und Verpflichtungsentscheidungen werden wiederverwendet?\n* *Vertrag und Modell*: Welcher Vertrag, welches Schema, Datenmodell und welche Version definieren die Integration?\n* *Mapping und Lieferung*: Welche Transformationen, Liefermuster und Metadaten sind erforderlich?\n* *Fehler und Wiederherstellung*: Wie werden Fehler, Retries, Replay, Duplikate und Abstimmung behandelt?\n* *Sicherheit und Vertrauen*: Welche Identitäts-, Zugriffs-, Datenschutz- und Vertrauenskontrollen gelten?\n* *Observability und Weiterentwicklung*: Wie wird die Integration überwacht, geändert, migriert und als deprecated markiert?\n\nh4. Interaktions-Canvas\nWelche Arten von Interaktionen muss diese Capability oder Schnittstelle unterstützen, bevor ein konkretes Protokolldesign gewählt wird?\n* *CRUD Interaktionen*: Sind hier Interaktionen im CRUD-Stil erforderlich?\n* *CRUD Input- & Output-Modelle*: Was sind die Eingabe- und Ausgabemodelle für die CRUD-Interaktionen, falls dieser Stil benötigt wird?\n* *CRUD Verarbeitung & Validierung*: Was sind die Verarbeitungs- und Validierungsregeln für die CRUD-Interaktionen, falls dieser Stil benötigt wird?\n* *Abfragegesteuerte Interaktionen*: Welche Lese- oder Abfrageinteraktionen sind erforderlich, um Nutzerfragen zu beantworten?\n* *Abfragegesteuerte Input- & Output-Modelle*: Was sind die Eingabe- und Ausgabemodelle für die abfragegesteuerten Interaktionen?\n* *Abfragegesteuerte Verarbeitung & Validierung*: Was sind die Verarbeitungs- und Validierungsregeln für die abfragegesteuerten Interaktionen?\n* *Befehlsgesteuerte Interaktionen*: Welche Befehle zur Zustandsänderung sind gegebenenfalls erforderlich?\n* *Befehlsgesteuerte Input- & Output-Modelle*: Was sind die Eingabe- und Ausgabemodelle für die befehlsgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n* *Befehlsgesteuerte Verarbeitung & Validierung*: Was sind die Verarbeitungs- und Validierungsregeln für die befehlsgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n* *Eventgesteuerte Interaktionen*: Welche Ereignisse müssen gegebenenfalls veröffentlicht oder verarbeitet werden?\n* *Eventgesteuerte Input- & Output-Modelle*: Was sind die Eingabe- und Ausgabemodelle für die ereignisgesteuerten Interaktionen, falls dieser Stil erforderlich ist?\n* *Eventgesteuerte Verarbeitung & Validierung*: Was sind die Verarbeitungs- und Validierungsregeln für die ereignisgesteuerten Interaktionen, falls dieser Stil benötigt wird?\n\nh3. Before this station\n* [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n* [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\nh3. Ready to leave when\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\nh3. Other related resources\n* *Contract-First Integration Design*: Guidance for validating integration contracts before delivery, including OpenAPI, AsyncAPI, event schemas, message schemas, file schemas, data contracts, and interface specifications.\n* *Leitfaden für integrationsstilspezifisches Design*: Leitfaden für integrationsstilspezifisches Design unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n\nh2. 5. Integrationsbereitstellung & Betrieb\n\nBauen, testen, deployen und betreiben Sie die Integrationsfähigkeit mit ausgewähltem Implementierungsstil und validiertem Vertrag.\n\nh3. Canvas questions\nh4. Canvas für Integrationsbereitschaft und Betrieb\nBereiten Sie die minimal erforderlichen Betriebsnachweise vor der Integrations-Readiness-Prüfung vor.\n* *Verantwortlichkeit*: Wer verantwortet Geschäfts-, Integrations-, Produzenten-, Nutzer-, Plattform- und Incident-Aufgaben?\n* *Umgebungen und Zugriff*: Sind Umgebungen, Credentials, Konnektivität, Berechtigungen und Sequenzierung bereit?\n* *Testnachweise*: Was belegt Vertrag, Mapping, Kompatibilität, Qualität, Resilienz und Wiederherstellung?\n* *Monitoring und Support*: Wie werden Produzenten, Nutzer, Plattformen, Incidents und Servicefragen unterstützt?\n* *Fehler und Wiederherstellung*: Wie funktionieren Retry, Replay, Duplikate, Abstimmung, Fallback und Kompensation?\n* *Readiness-Status*: Sind Verträge, Runbooks, Abhängigkeiten, Risiken, Bedingungen und blockierende Lücken klar?\n\nh3. Before this station\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\nh3. Ready to leave when\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\nh3. Other related resources\n* *Best Practices für Integrationsentwicklung*: Best Practices für Integrationsentwicklung unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n* *Leitfaden für Integrationstests*: Leitfaden für Integrationstests unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n* *Leitfaden für Integrations-CI/CD und Deployment*: Leitfaden für Integrations-CI/CD und Deployment unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n* *Leitfaden für Integrationssicherheit*: Leitfaden für Integrationssicherheit unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n* *Leitfaden für Integrationswiederherstellung und Abstimmung*: Leitfaden für Integrationswiederherstellung und Abstimmung unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n\nh2. 6. Integrationsbereitschaftssicherung\n\nSichern Sie Integrations-Readiness, Governance, Qualität, Security, Compliance und operative Nachweise vor der Freigabe ab.\n\nh3. Station questions\n* Prüfen Sie abgeschlossenes Design, Testnachweise, Betriebsmodell, Berechtigungen, Credentials, Monitoring, Support, Fallback und Rollback.\n* Verifizieren Sie, dass bekannte Risiken, Ausnahmen, unsichere Aktionen, menschliche Aufsicht, Compliance-Anforderungen und offene Annahmen adressiert oder ausdrücklich akzeptiert sind.\n* Dokumentieren Sie blockierende Befunde, akzeptierte Restrisiken, Freigabebedingungen und erforderliche Remediation-Maßnahmen.\n* Entscheiden Sie, ob die Freigabe bereit, bedingt bereit, remediation-pflichtig oder nicht genehmigt ist.\n* Dokumentieren Sie Entscheidungsverantwortliche, Entscheidungsdatum und verwendete Nachweise.\n* Bestätigen Sie, dass nichts ohne klare fachliche und betriebliche Ownership freigegeben wird.\n* Nutzen Sie Bereitschaftsnachweise, um vor der Produktionsnutzung eine ausdrückliche Go-, bedingte Go- oder No-go-Entscheidung zu treffen.\n* Eine formale Bereitschaftsentscheidung verhindert, dass Automatisierungslösungen ohne klare Nachweise, akzeptierte Risiken, Remediation-Maßnahmen sowie fachliche und betriebliche Ownership freigegeben werden.\n\nh3. Before this station\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\nh3. Ready to leave when\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Die Schnittstelle und ihre Capabilities sind ausreichend klar für Review, Auditierung und Onboarding dokumentiert.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n* [ ] Der Schnittstellenvertrag wurde validiert und gegen funktionale und nicht-funktionale Anforderungen getestet.\n\nh3. Other related resources\n* *Checkliste für Integration Readiness*: Checkliste für Integration Readiness unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n* *Leitfaden für Integrations-Compliance und Data Governance*: Leitfaden für Integrations-Compliance und Data Governance unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n\nh2. 7. Integrationsveroeffentlichung & Enablement\n\nVeröffentlichen Sie die Integrationsfähigkeit, damit Teams sie finden, bewerten, Zugriff beantragen, onboarding durchführen, wiederverwenden und Support erhalten können.\n\nh3. Station questions\n* Betroffene Personen und geänderte Arbeit: Wer wird die Freigabe nutzen, betreiben, unterstützen, genehmigen, konsumieren oder davon betroffen sein, und welche Verantwortlichkeiten, Entscheidungen, Übergaben oder Arbeitsweisen ändern sich?\n* Aktivierungs- und Rollout-Ansatz: Wie werden Zugriff, Berechtigungen, Pilotnutzung, phasenweiser Rollout, eingeschränkte Gruppen, Parallelbetrieb und Rollout-Erweiterung gesteuert?\n* Enablement und Support: Welche Kommunikation, Schulung, Betriebsanweisungen und Supportpfade sind erforderlich?\n* Feedback und Kontrolle: Wie werden Adoption, Vertrauen, tatsächliche Nutzung, Probleme und unerwartetes Verhalten überwacht, und welche Bedingungen lösen Pause, Rollback oder Rückkehr zum manuellen Betrieb aus?\n* Planen Sie Rollout, Befähigung, Support, Feedback und Rollback, damit freigegebene Lösungen sicher eingeführt werden können.\n* Automatisierungslösungen schaffen erst nach dem Rollout Wert, wenn betroffene Personen und konsumierende Systeme verstehen, was sich ändert, wie Zugriff und Betrieb funktionieren, wo Unterstützung verfügbar ist und wann der Rollout pausiert, erweitert oder zurückgerollt werden muss.\n\nh3. Before this station\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Die Schnittstelle und ihre Capabilities sind ausreichend klar für Review, Auditierung und Onboarding dokumentiert.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n* [ ] Der Schnittstellenvertrag wurde validiert und gegen funktionale und nicht-funktionale Anforderungen getestet.\n\nh3. Ready to leave when\n* [ ] Die Lösung besteht Qualitäts-, Sicherheits-, Compliance- und Bereitschaftsprüfungen.\n* [ ] Audit-Ergebnisse und Maßnahmenentscheidungen wurden mit den relevanten Stakeholdern geteilt.\n* [ ] Die Capability ist bereit, über den gewählten Bereitstellungsmechanismus veröffentlicht oder ausgeliefert zu werden.\n* [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n\nh3. Other related resources\n* *Leitfaden für Integrationsveröffentlichung und Auffindbarkeit*: Leitfaden für Integrationsveröffentlichung und Auffindbarkeit unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n* *Leitfaden für Integrations-Consumer-Onboarding*: Leitfaden für Integrations-Consumer-Onboarding unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n* *Vorlage für Integrations-Servicevereinbarungen*: Vorlage für Integrations-Servicevereinbarungen unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n* *Leitfaden für Integrationsversionierung und Deprecation*: Leitfaden für Integrationsversionierung und Deprecation unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n\nh2. 8. Integrationsmonitoring & Verbesserung\n\nÜberwachen Sie Integrationszuverlässigkeit, Wiederverwendung, Incidents, Performance, Consumer-Ergebnisse und Verbesserungsbedarf.\n\nh3. Station questions\n* Ergebnisse und Wert: Werden die erwarteten Prozess-, Nutzer- und Geschäftsergebnisse erreicht?\n* Betriebsleistung: Was zeigen erfolgreiche Läufe, Fehler, Teilabschlüsse, Ausnahmen, Wiederholungen, Timeouts, Interventionen, Verarbeitungszeit, Wartezeit und Kosten?\n* Nutzer-, Risiko- und Wiederherstellungssignale: Welche Fehler, Korrekturen, unsicheren Aktionen, Umgehungen, Misstrauen, Supportbedarfe, Fallback-Ereignisse oder Wiederherstellungsfehler treten auf?\n* Lernen und Lifecycle-Entscheidung: Welche Hypothesenannahmen wurden bestätigt oder verworfen, und sollte die Lösung verbessert, erweitert, eingeschränkt, neu gestaltet, pausiert oder stillgelegt werden?\n* Nutzen Sie operative, Nutzer-, Risiko- und Wertnachweise, um zu entscheiden, was verbessert, erweitert, eingeschränkt, pausiert oder stillgelegt werden soll.\n* Freigegebene Lösungen benötigen Nachweise, ob erwartete Ergebnisse erreicht werden, wo manuelle Intervention oder Wiederherstellung noch nötig ist und welche Lifecycle-Entscheidung als Nächstes getroffen werden sollte.\n\nh3. Before this station\n* [ ] Die Lösung besteht Qualitäts-, Sicherheits-, Compliance- und Bereitschaftsprüfungen.\n* [ ] Audit-Ergebnisse und Maßnahmenentscheidungen wurden mit den relevanten Stakeholdern geteilt.\n* [ ] Die Capability ist bereit, über den gewählten Bereitstellungsmechanismus veröffentlicht oder ausgeliefert zu werden.\n* [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n\nh3. Ready to leave when\n* [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n* [ ] Onboarding-, Support- und Kommunikationsprozesse für Nutzer sind bereit.\n* [ ] Rechtliche, Datenschutz- und Compliance-Anforderungen für Veröffentlichung oder Release sind definiert und verstanden.\n\nh3. Other related resources\n* *Integrationsmonitoring und Wertmetriken*: Integrationsmonitoring und Wertmetriken unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n* *Leitfaden für Integrations-Consumer-Feedback und Adoption*: Leitfaden für Integrations-Consumer-Feedback und Adoption unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n* *Integrationszuverlässigkeit und Datenqualitätsmetriken*: Integrationszuverlässigkeit und Datenqualitätsmetriken unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit.\n* *Leitfaden für Integrations-Lifecycle-Management*: Leitfaden für Integrations-Lifecycle-Management unterstützt die Planung, Entscheidung, Lieferung, Veröffentlichung oder Verbesserung einer wiederverwendbaren Integrationsfähigkeit."
      },
      {
        "id": "automation-cycle:question-template-markdown",
        "cycleId": "automation-cycle",
        "kind": "questions",
        "format": "markdown",
        "title": "Automatisierungszyklus question template Markdown",
        "body": "# Automatisierungszyklus question template\n\nEin Zyklus zum Auswählen, Entwerfen, Bereitstellen, Einführen und Verbessern von Automatisierungslösungen über Menschen, Regeln, Workflows, Agenten, Integrationen, UI-Automatisierung und Betrieb hinweg.\n\nUse this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.\n\n## 1. Automatisierungschance & Strategie\n\nBeginnen Sie mit dem relevantesten externen Kunden. Nutzen Sie Nachweise aus Journey und Fähigkeitswert, um zu validieren, ob eine Automatisierungshypothese weiterverfolgt werden soll.\n\n### Canvas questions\n#### Customer-Journey-Canvas\nWelche Journey erlebt der am weitesten außen liegende sinnvolle Kunde, und was sollte verbessert werden?\n- **Personas**: Wer ist der typische Kunde oder Nutzer, der diese Reise erlebt?\n- **Kunde erkennt Bedarf**: Wie erkennt der Kunde oder Nutzer ein Bedürfnis oder Problem?\n- **Kundenbedarf wird erfüllt**: Wie wird der Bedarf des Kunden oder Nutzers letztlich erfüllt?\n- **Customer Journey Schritte**: Welche Schritte durchläuft der Kunde bei der Reise?\n- **Probleme**: Welche Probleme oder Pain Points erlebt der Kunde oder Nutzer?\n- **Nutzen**: Welchen Gewinn oder Nutzen hat der Kunde?\n- **Eingaben & Ausgaben**: Was sind die Inputs und Outputs bei jedem Schritt?\n- **Interaktions- und Verarbeitungsregeln**: Wie lauten die Interaktions- und Verarbeitungsregeln bei jedem Schritt?\n- **Verbesserungsmöglichkeiten**: Welche Journey-Schritte zeigen, dass eine zugrunde liegende Capability oder ein Prozess geschaffen, verbessert, automatisiert oder entfernt werden sollte?\n\n#### Fähigkeits-Wertversprechen-Canvas\nWelche wiederverwendbare Capability würde Nutzern Wert liefern, ohne bereits zu entscheiden, ob sie als API, Event, Datei, Stream, Datenprodukt oder ein anderer Implementierungsstil bereitgestellt werden soll?\n- **Nutzeraufgaben und Ergebnisse**: Was möchten Nutzer, Partner, Systeme oder Teams erreichen?\n- **Nutzenstiftende Capability-Funktionen**: Welche Capability-Funktionen helfen Nutzern, bessere Ergebnisse, Geschwindigkeit, Automatisierung, Erkenntnisse, Reichweite oder Compliance zu erreichen?\n- **Pain-Point-reduzierende Capability-Funktionen**: Welche Capability-Funktionen reduzieren Reibung, manuelle Arbeit, Fehler, Verzögerungen, Risiken oder Unsicherheit für Nutzer?\n- **Wiederverwendbare Capabilities**: Welche wiederverwendbaren Geschäfts- oder Daten-Capabilities könnten diese Aufgaben, Nutzen und Pain Points über mehr als einen Nutzer oder Use Case hinweg unterstützen?\n\n#### Canvas für Automatisierungshypothese und Validierung\nÜberführen Sie vorhandene Nachweise zu Journey, Wert, Auswirkungen, Domäne und Kapazität in eine prüfbare Automatisierungsentscheidung.\n- **Automatisierungshypothese**: Welche Arbeit sollte aus unserer Sicht automatisiert werden, und welches Ergebnis soll sie erreichen?\n- **Wiederverwendete Nachweise**: Welche früheren Canvas-Ergebnisse stützen die Hypothese?\n- **Kritische Annahmen**: Was könnte die Hypothese falsch, unsicher oder nicht umsetzbar machen?\n- **Validierungsexperiment**: Was ist der kleinste sinnvolle Test, welcher Nachweisschwellenwert gilt, und wann wird gestoppt?\n- **Entscheidung**: Fortfahren, überarbeiten, den Prozess neu gestalten oder stoppen?\n\n### Before this station\n- [ ] Die Automatisierungshypothese verfügt über ausreichend referenzierte Nachweise zum erwarteten Ergebnis, Umfang, zu anfänglichen Umsetzungsannahmen, kritischen Risiken, Validierungsexperiment, Schwellenwerten und zur Entscheidung, um zu bestimmen, ob sie weiterverfolgt werden soll.\n- [ ] Die Verantwortlichkeit für die Automatisierungschance, Prozessentscheidungen, PoC-Validierung, Risiken und Lebenszyklusergebnisse ist geklärt.\n\n### Ready to leave when\n- [ ] Relevante Marktsignale, Feedback oder operative Erkenntnisse liegen vor, um diese Capability-Möglichkeit zu bewerten.\n- [ ] Die Geschäftsziele sind definiert.\n- [ ] Die Marktrecherche identifiziert relevante Capability-Möglichkeiten.\n- [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\n## 2. Prozess- und Erlebnisanforderungen\n\nKlären Sie Prozess-, Erlebnis-, Domänen-, Service- und nichtfunktionale Anforderungen, die der spätere Workflow und die Architektur erfüllen müssen.\n\n### Canvas questions\n#### Canvas für Anforderungen an das Nutzererlebnis\nWelche Erlebnis-, Betriebs- und nichtfunktionalen Anforderungen muss die Lösung für Benutzer, Betreiber, Konsumenten, Genehmigende und Support-Teams erfüllen?\n- **Ziele von Benutzern, Betreibern oder Konsumenten**: Welche Geschäfts-, Workflow-, Entscheidungs-, Automatisierungs-, Support- oder Datennutzungsziele müssen unterstützt werden?\n- **Verfügbarkeits- und Aktualitätsbedarfe**: Wann muss die Lösung verfügbar sein, wie aktuell müssen Informationen sein, und welche Reaktions-, Liefer- oder Abschlussfenster sind wichtig?\n- **Volumen- und Leistungserwartungen**: Welche Benutzer-, Fall-, Transaktions-, Datensatz-, Event-, Datei-, Batch- oder Arbeitsvolumen müssen vor der Kapazitätsplanung verstanden werden?\n- **Bedarfe an Datenqualität und Konsistenz**: Welche Erwartungen an Genauigkeit, Vollständigkeit, Konsistenz, Reihenfolge, Deduplizierung, Abstimmung oder Validierung bestehen?\n- **Sicherheits-, Datenschutz- und Compliance-Randbedingungen**: Welche Anforderungen an Identität, Autorisierung, Vertraulichkeit, Datenresidenz, Einwilligung, Aufbewahrung, Audit oder Regulierung muss die Lösung erfüllen?\n- **Aktivierung und Zugriff**: Wie erhalten Benutzer, Betreiber oder konsumierende Teams Zugriff, starten oder nutzen die Lösung und erhalten notwendige Berechtigungen und Anleitung?\n- **Erwartungen an Änderung und Versionierung**: Welche Änderungstoleranz besteht, und welche Erwartungen an Ankündigung, Kompatibilität, Migration, Schulung oder Versionierung gelten?\n- **Bedarfe an Beobachtbarkeit und Support**: Welche Überwachung, Statusinformationen, Nachverfolgbarkeit, Qualitätsübersicht, Unterstützung, Verantwortung und Incident-Kommunikation benötigen Benutzer und Betreiber?\n- **Bedarfe an Wiederherstellung und Kontinuität**: Welche Erwartungen an Replay, Retry, Abstimmung, Backup, Fallback, Kontinuität oder manuelle Wiederherstellung müssen unterstützt werden?\n- **Randbedingungen für späteres Design**: Welche Anforderungen müssen spätere Architektur-, Workflow-, Kapazitäts-, Integrations- oder Implementierungsentscheidungen erfüllen?\n\n#### Domänen-Canvas\nWelche wesentlichen Entitäten, Begriffe und Fachregeln muss die Capability oder Schnittstelle respektieren?\n- **Ausgewählte Customer Journey Schritte**: Welche Customer Journey Schritte sind für diese Domäne relevant?\n- **Grundlegende Entitäten & geschäftliche Bedeutung**: Welches sind die wesentlichen Entitäten und ihre Bedeutung für das Geschäft?\n- **Attribute & geschäftliche Wichtigkeit**: Welches sind die Schlüsselattribute der einzelnen Entitäten und ihre geschäftliche Wichtigkeit?\n- **Beziehungen zwischen Entitäten**: Welche Beziehungen bestehen zwischen den Entitäten?\n- **Fachregeln, Compliance und Integrität**: Welche Fachregeln sowie Compliance- und Integritätsanforderungen beziehen sich auf die Entitäten?\n- **Überlegungen zu Sicherheit und Datenschutz**: Welche Überlegungen zur Sicherheit und zum Datenschutz gibt es im Zusammenhang mit den Entitäten?\n\n### Before this station\n- [ ] Relevante Marktsignale, Feedback oder operative Erkenntnisse liegen vor, um diese Capability-Möglichkeit zu bewerten.\n- [ ] Die Geschäftsziele sind definiert.\n- [ ] Die Marktrecherche identifiziert relevante Capability-Möglichkeiten.\n- [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\n### Ready to leave when\n- [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n- [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n- [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\n## 3. Entscheidung zu Automatisierungsarchitektur und Plattform\n\nNutzen Sie Auswirkungen, Standort, Kapazität und frühere Anforderungen, um den Umsetzungsansatz für die Automatisierung zu wählen und Begründung sowie verbleibende Risiken festzuhalten.\n\n### Canvas questions\n#### Geschäftsauswirkungs-Canvas\nWelcher Wert, welches Risiko sowie welche betrieblichen, finanziellen, kunden-, mitarbeiter-, compliance- und strategischen Auswirkungen werden erwartet oder stehen auf dem Spiel?\n- **Erwartete Vorteile**: Welche geschäftlichen, kundenbezogenen, mitarbeiterbezogenen, qualitäts-, geschwindigkeits-, risiko-, compliance- oder strategischen Vorteile werden erwartet?\n- **Auswirkung auf die operative Effizienz**: Wie könnten Arbeitsaufwand, Wartezeit, Nacharbeit, Durchsatz, Zuverlässigkeit, Supportbelastung oder Betriebskosten sich verändern?\n- **Auswirkung auf Kunden und Mitarbeitende**: Wie werden Kunden, Mitarbeitende, Partner, Betreiber oder Supportteams die Veränderung erleben?\n- **Finanzielle Auswirkung**: Welche Auswirkungen auf Umsatz, Kosten, Investitionen, Einsparungen, vermiedene Verluste oder Finanzierung werden erwartet?\n- **Compliance- und strategische Auswirkung**: Welche regulatorischen, vertraglichen, richtlinienbezogenen, reputations-, markt-, ökosystem- oder strategischen Konsequenzen sind relevant?\n- **Auswirkung des Nicht-Fortfahrens**: Was geschieht, wenn die Capability, Automatisierung, Integration oder der Service nicht verbessert oder geliefert wird?\n- **Risiken und Kritikalität**: Welche Verfügbarkeits-, Sicherheits-, Daten-, Safety-, Prozess-, Akzeptanz- oder Business-Continuity-Risiken könnten das Ergebnis beeinflussen?\n- **Gegenmaßnahmen und Entscheidungsauswirkung**: Welche Gegenmaßnahmen, Einschränkungen, Kompromisse oder Restrisiken sollten Priorisierung, Architektur, Rollout oder Readiness-Entscheidungen beeinflussen?\n\n#### Standort-Canvas\nWelche geopolitischen, regulatorischen, Netzwerk- und Vertrauensgrenzen betreffen diese Capability oder Schnittstelle?\n- **Standort-/Vertrauensgruppen**: Welche geopolitischen, regulatorischen, netzwerkbezogenen oder vertrauensbezogenen Gruppen sind relevant?\n- **Gruppenmerkmale**: Was sind die Merkmale dieser Gruppen, wie z. B. Standort, Vertrauensstufe oder Netzwerkexposition?\n- **Relevante Standorte / Zonen**: Was sind die relevanten Standorte, Zonen oder Umgebungen innerhalb jeder Gruppe?\n- **Standort-/Zonenmerkmale**: Was sind die Merkmale dieser Standorte oder Zonen, wie z. B. Eigentumsverhältnisse, Region oder Exposition?\n- **Netzwerk- / Regulierungsentfernungen**: Welche Latenz-, Vertrauens-, Regulierungs- oder Konnektivitätsentfernungen bestehen zwischen den Standorten?\n- **Entfernungsmerkmale**: Was sind die Merkmale dieser Entfernungen, wie z. B. Latenzempfindlichkeit, Aufenthaltsbeschränkungen oder Vertrauensgrenzen?\n- **Konnektivitätsendpunkte**: Welche Konnektivitätsendpunkte oder Schnittstellen sind mit den Standorten verbunden?\n- **Endpunktzugriffseigenschaften**: Welche Eigenschaften weisen diese Endpunkte auf, wie z. B. Sichtbarkeit, Protokoll, Sicherheit oder Zugriffsbeschränkungen?\n\n#### Kapazitäts-Canvas\nWie viel Nachfrage, Last, Timing und Skalierungskapazität müssen für Fähigkeit, Automatisierung, Integration oder Service verstanden werden?\n- **Aktuelles Geschäftsvolumen**: Wie hoch sind das aktuelle Geschäftsvolumen und die Transaktionsraten?\n- **Zukünftige Konsumtrends**: Was sind die erwarteten künftigen Konsumtrends?\n- **Spitzenlast- und Verfügbarkeitsanforderungen**: Was sind die Spitzenlast- und Verfügbarkeitsanforderungen?\n- **Caching-Strategien**: Welche Caching-Strategien können zur Performanceoptimierung eingesetzt werden?\n- **Strategien zur Ratenbegrenzung**: Welche Strategien zur Ratenbegrenzung können genutzt werden, um die Nutzung zu steuern?\n- **Strategien zur Skalierung**: Welche Strategien zur Skalierung können eingesetzt werden, um das Wachstum zu unterstützen?\n\n#### Canvas für Automatisierungsarchitektur-Entscheidung\nWählen Sie den Umsetzungsansatz anhand bereits gesammelter Nachweise.\n- **Wiederverwendete Eingaben**: Welche Anforderungen, Kapazitäts-, Standort-, Auswirkungs- und Verantwortlichkeitsentscheidungen begrenzen die Auswahl?\n- **Tragfähige Optionen**: Welche Optionen mit Menschen, Workflows, Regeln, Agenten, APIs, Konnektoren, individuellen Lösungen oder UI-Automatisierung bleiben tragfähig?\n- **Ausgewählter Ansatz**: Welcher Umsetzungsstil oder hybride Ansatz wird ausgewählt?\n- **Entscheidungsbegründung**: Warum passt der ausgewählte Ansatz am besten?\n- **Abgelehnte Alternativen**: Welche ernsthaften Alternativen wurden abgelehnt, und warum?\n- **Offene Risiken**: Was muss vor Lieferung oder Release noch validiert werden?\n\n### Before this station\n- [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n- [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n- [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\n### Ready to leave when\n- [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n- [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\n## 4. Automatisierungs-Workflow-Design\n\nEntwerfen Sie den internen Workflow, der zur Erreichung der ausgewählten Kunden- und Fähigkeitsergebnisse benötigt wird, einschließlich Arbeitsverteilung, Kontrollen, Ausnahmen, Wiederherstellung, Nachweisen und Monitoring.\n\n### Canvas questions\n#### Automatisierungs-Workflow-Canvas\nEntwerfen Sie den internen Workflow, der benötigt wird, um die ausgewählten Kunden- und Capability-Ergebnisse zu liefern.\n- **Ausgewählte Kunden- und Capability-Ergebnisse**: Welche vereinbarten Kunden- und Capability-Ergebnisse muss dieser Workflow liefern?\n- **Interne Workflow-Schritte**: Welche interne Arbeit muss stattfinden, um diese Ergebnisse zu erzeugen?\n- **Arbeitsverteilung und menschliche Kontrolle**: Was bleibt menschlich, was wird automatisiert und wo sind Aufsicht oder Eskalation erforderlich?\n- **Inputs, Outputs und Interaktionen**: Welche Informationen, Systeme und Übergaben werden benötigt?\n- **Entscheidungen, Ausnahmen und Wiederherstellung**: Was verändert den Ablauf, was kann fehlschlagen und wie wird die Arbeit wiederhergestellt?\n- **Nachweise und Monitoring**: Was belegt den korrekten Betrieb und zeigt, ob das beabsichtigte Ergebnis erreicht wurde?\n\n### Before this station\n- [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n- [ ] Die Nutzersegmente sind identifiziert.\n- [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\n### Ready to leave when\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\n## 5. Automatisierungsbereitstellung & Betrieb\n\nBauen, konfigurieren, testen, versionieren und deployen Sie den ausgewählten Automatisierungspfad und bereiten Sie das Betriebsmodell vor, einschließlich Verantwortlichkeit, Umgebungen, Runbooks, Monitoring, Fallback, Rollback, Support und bekannter Risiken.\n\n### Canvas questions\n#### Canvas für Automatisierungsbereitschaft und Betrieb\nBereiten Sie die minimal erforderlichen Betriebsnachweise vor der Readiness-Prüfung vor.\n- **Verantwortlichkeit**: Wer verantwortet Geschäftsergebnisse, Betrieb, Support und Änderungen?\n- **Umgebungen und Zugriff**: Sind Umgebungen, Berechtigungen, Credentials und Identitäten bereit?\n- **Testnachweise**: Was belegt korrektes, sicheres und zuverlässiges Verhalten?\n- **Monitoring und Support**: Wie werden Health, Incidents, Nutzer und Betreiber unterstützt?\n- **Fehler und Wiederherstellung**: Wie funktionieren Ausnahmen, Fallback, Rollback und manuelle Wiederherstellung?\n- **Readiness-Status**: Sind Dokumentation, Risiken, Bedingungen und blockierende Lücken klar?\n\n### Before this station\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\n### Ready to leave when\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\n## 6. Automatisierungsbereitschaftsprüfung\n\nNutzen Sie eine Readiness-Checkliste, um Nachweise zu prüfen und die Freigabeentscheidung festzuhalten: bereit, unter Bedingungen bereit, Nachbesserung erforderlich oder nicht genehmigt.\n\n### Station questions\n- Prüfen Sie abgeschlossenes Design, Testnachweise, Betriebsmodell, Berechtigungen, Credentials, Monitoring, Support, Fallback und Rollback.\n- Verifizieren Sie, dass bekannte Risiken, Ausnahmen, unsichere Aktionen, menschliche Aufsicht, Compliance-Anforderungen und offene Annahmen adressiert oder ausdrücklich akzeptiert sind.\n- Dokumentieren Sie blockierende Befunde, akzeptierte Restrisiken, Freigabebedingungen und erforderliche Remediation-Maßnahmen.\n- Entscheiden Sie, ob die Freigabe bereit, bedingt bereit, remediation-pflichtig oder nicht genehmigt ist.\n- Dokumentieren Sie Entscheidungsverantwortliche, Entscheidungsdatum und verwendete Nachweise.\n- Bestätigen Sie, dass nichts ohne klare fachliche und betriebliche Ownership freigegeben wird.\n- Nutzen Sie Bereitschaftsnachweise, um vor der Produktionsnutzung eine ausdrückliche Go-, bedingte Go- oder No-go-Entscheidung zu treffen.\n- Eine formale Bereitschaftsentscheidung verhindert, dass Automatisierungslösungen ohne klare Nachweise, akzeptierte Risiken, Remediation-Maßnahmen sowie fachliche und betriebliche Ownership freigegeben werden.\n\n### Before this station\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\n### Ready to leave when\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Die Schnittstelle und ihre Capabilities sind ausreichend klar für Review, Auditierung und Onboarding dokumentiert.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n- [ ] Der Schnittstellenvertrag wurde validiert und gegen funktionale und nicht-funktionale Anforderungen getestet.\n\n### Other related resources\n- **Checkliste zur Automatisierungsbereitschaft**: Eine Checkliste zur Prüfung von Automatisierungsnachweisen, blockierenden Befunden, akzeptierten Restrisiken, Freigabebedingungen, Nachbesserungsmaßnahmen, Entscheidungsverantwortung, Entscheidungsdatum und Release Readiness.\n\n## 7. Automatisierungs-Rollout & Enablement\n\nAktivieren und rollen Sie die Automatisierung sicher aus - mit Kommunikation, Schulung, Betriebsanweisungen, Supportwegen, Adoptionsmonitoring, Feedbackkanälen, phasenweisem Rollout sowie Pausen- und Rollback-Bedingungen.\n\n### Station questions\n- Betroffene Personen und geänderte Arbeit: Wer wird die Freigabe nutzen, betreiben, unterstützen, genehmigen, konsumieren oder davon betroffen sein, und welche Verantwortlichkeiten, Entscheidungen, Übergaben oder Arbeitsweisen ändern sich?\n- Aktivierungs- und Rollout-Ansatz: Wie werden Zugriff, Berechtigungen, Pilotnutzung, phasenweiser Rollout, eingeschränkte Gruppen, Parallelbetrieb und Rollout-Erweiterung gesteuert?\n- Enablement und Support: Welche Kommunikation, Schulung, Betriebsanweisungen und Supportpfade sind erforderlich?\n- Feedback und Kontrolle: Wie werden Adoption, Vertrauen, tatsächliche Nutzung, Probleme und unerwartetes Verhalten überwacht, und welche Bedingungen lösen Pause, Rollback oder Rückkehr zum manuellen Betrieb aus?\n- Planen Sie Rollout, Befähigung, Support, Feedback und Rollback, damit freigegebene Lösungen sicher eingeführt werden können.\n- Automatisierungslösungen schaffen erst nach dem Rollout Wert, wenn betroffene Personen und konsumierende Systeme verstehen, was sich ändert, wie Zugriff und Betrieb funktionieren, wo Unterstützung verfügbar ist und wann der Rollout pausiert, erweitert oder zurückgerollt werden muss.\n\n### Before this station\n- [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n- [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n- [ ] Die Schnittstelle und ihre Capabilities sind ausreichend klar für Review, Auditierung und Onboarding dokumentiert.\n- [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n- [ ] Der Schnittstellenvertrag wurde validiert und gegen funktionale und nicht-funktionale Anforderungen getestet.\n\n### Ready to leave when\n- [ ] Die Lösung besteht Qualitäts-, Sicherheits-, Compliance- und Bereitschaftsprüfungen.\n- [ ] Audit-Ergebnisse und Maßnahmenentscheidungen wurden mit den relevanten Stakeholdern geteilt.\n- [ ] Die Capability ist bereit, über den gewählten Bereitstellungsmechanismus veröffentlicht oder ausgeliefert zu werden.\n- [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n\n### Other related resources\n- **Leitfaden für Rollout und Enablement von Automatisierungen**: Anleitung zur Aktivierung und Einführung von Automatisierungen mit Analyse geänderter Arbeit, Rollout-Ansatz, Enablement, Support, Feedback, Adoptionsmonitoring und Kontrollbedingungen.\n\n## 8. Automatisierungsmonitoring & Verbesserung\n\nÜberwachen Sie tatsächliche Automatisierungsergebnisse, erfolgreiche und fehlgeschlagene Läufe, Ausnahmen, Wiederholungen, Eingriffe, Durchlaufzeit, Wartezeit, Kosten, Fehler, unsichere Aktionen, Einführung, Vertrauen, realisierten Nutzen und welche Hypothesenannahmen bestätigt oder verworfen wurden.\n\n### Station questions\n- Ergebnisse und Wert: Werden die erwarteten Prozess-, Nutzer- und Geschäftsergebnisse erreicht?\n- Betriebsleistung: Was zeigen erfolgreiche Läufe, Fehler, Teilabschlüsse, Ausnahmen, Wiederholungen, Timeouts, Interventionen, Verarbeitungszeit, Wartezeit und Kosten?\n- Nutzer-, Risiko- und Wiederherstellungssignale: Welche Fehler, Korrekturen, unsicheren Aktionen, Umgehungen, Misstrauen, Supportbedarfe, Fallback-Ereignisse oder Wiederherstellungsfehler treten auf?\n- Lernen und Lifecycle-Entscheidung: Welche Hypothesenannahmen wurden bestätigt oder verworfen, und sollte die Lösung verbessert, erweitert, eingeschränkt, neu gestaltet, pausiert oder stillgelegt werden?\n- Nutzen Sie operative, Nutzer-, Risiko- und Wertnachweise, um zu entscheiden, was verbessert, erweitert, eingeschränkt, pausiert oder stillgelegt werden soll.\n- Freigegebene Lösungen benötigen Nachweise, ob erwartete Ergebnisse erreicht werden, wo manuelle Intervention oder Wiederherstellung noch nötig ist und welche Lifecycle-Entscheidung als Nächstes getroffen werden sollte.\n\n### Before this station\n- [ ] Die Lösung besteht Qualitäts-, Sicherheits-, Compliance- und Bereitschaftsprüfungen.\n- [ ] Audit-Ergebnisse und Maßnahmenentscheidungen wurden mit den relevanten Stakeholdern geteilt.\n- [ ] Die Capability ist bereit, über den gewählten Bereitstellungsmechanismus veröffentlicht oder ausgeliefert zu werden.\n- [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n\n### Ready to leave when\n- [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n- [ ] Onboarding-, Support- und Kommunikationsprozesse für Nutzer sind bereit.\n- [ ] Rechtliche, Datenschutz- und Compliance-Anforderungen für Veröffentlichung oder Release sind definiert und verstanden.\n\n### Other related resources\n- **Automatisierungsmonitoring und Wertmetriken**: Anleitung zur Messung von Ergebnissen, operativer Leistung, Nutzerverhalten, Risiko, Wiederherstellung, realisiertem Wert, Hypothesenlernen und Lifecycle-Entscheidungen nach dem Rollout."
      },
      {
        "id": "automation-cycle:question-template-confluence-wiki",
        "cycleId": "automation-cycle",
        "kind": "questions",
        "format": "confluence-wiki",
        "title": "Automatisierungszyklus question template Confluence wiki",
        "body": "h1. Automatisierungszyklus question template\n\nEin Zyklus zum Auswählen, Entwerfen, Bereitstellen, Einführen und Verbessern von Automatisierungslösungen über Menschen, Regeln, Workflows, Agenten, Integrationen, UI-Automatisierung und Betrieb hinweg.\n\nUse this template to gather answers and evidence station by station. Canvas section prompts are listed first, followed by other related resources.\n\nh2. 1. Automatisierungschance & Strategie\n\nBeginnen Sie mit dem relevantesten externen Kunden. Nutzen Sie Nachweise aus Journey und Fähigkeitswert, um zu validieren, ob eine Automatisierungshypothese weiterverfolgt werden soll.\n\nh3. Canvas questions\nh4. Customer-Journey-Canvas\nWelche Journey erlebt der am weitesten außen liegende sinnvolle Kunde, und was sollte verbessert werden?\n* *Personas*: Wer ist der typische Kunde oder Nutzer, der diese Reise erlebt?\n* *Kunde erkennt Bedarf*: Wie erkennt der Kunde oder Nutzer ein Bedürfnis oder Problem?\n* *Kundenbedarf wird erfüllt*: Wie wird der Bedarf des Kunden oder Nutzers letztlich erfüllt?\n* *Customer Journey Schritte*: Welche Schritte durchläuft der Kunde bei der Reise?\n* *Probleme*: Welche Probleme oder Pain Points erlebt der Kunde oder Nutzer?\n* *Nutzen*: Welchen Gewinn oder Nutzen hat der Kunde?\n* *Eingaben & Ausgaben*: Was sind die Inputs und Outputs bei jedem Schritt?\n* *Interaktions- und Verarbeitungsregeln*: Wie lauten die Interaktions- und Verarbeitungsregeln bei jedem Schritt?\n* *Verbesserungsmöglichkeiten*: Welche Journey-Schritte zeigen, dass eine zugrunde liegende Capability oder ein Prozess geschaffen, verbessert, automatisiert oder entfernt werden sollte?\n\nh4. Fähigkeits-Wertversprechen-Canvas\nWelche wiederverwendbare Capability würde Nutzern Wert liefern, ohne bereits zu entscheiden, ob sie als API, Event, Datei, Stream, Datenprodukt oder ein anderer Implementierungsstil bereitgestellt werden soll?\n* *Nutzeraufgaben und Ergebnisse*: Was möchten Nutzer, Partner, Systeme oder Teams erreichen?\n* *Nutzenstiftende Capability-Funktionen*: Welche Capability-Funktionen helfen Nutzern, bessere Ergebnisse, Geschwindigkeit, Automatisierung, Erkenntnisse, Reichweite oder Compliance zu erreichen?\n* *Pain-Point-reduzierende Capability-Funktionen*: Welche Capability-Funktionen reduzieren Reibung, manuelle Arbeit, Fehler, Verzögerungen, Risiken oder Unsicherheit für Nutzer?\n* *Wiederverwendbare Capabilities*: Welche wiederverwendbaren Geschäfts- oder Daten-Capabilities könnten diese Aufgaben, Nutzen und Pain Points über mehr als einen Nutzer oder Use Case hinweg unterstützen?\n\nh4. Canvas für Automatisierungshypothese und Validierung\nÜberführen Sie vorhandene Nachweise zu Journey, Wert, Auswirkungen, Domäne und Kapazität in eine prüfbare Automatisierungsentscheidung.\n* *Automatisierungshypothese*: Welche Arbeit sollte aus unserer Sicht automatisiert werden, und welches Ergebnis soll sie erreichen?\n* *Wiederverwendete Nachweise*: Welche früheren Canvas-Ergebnisse stützen die Hypothese?\n* *Kritische Annahmen*: Was könnte die Hypothese falsch, unsicher oder nicht umsetzbar machen?\n* *Validierungsexperiment*: Was ist der kleinste sinnvolle Test, welcher Nachweisschwellenwert gilt, und wann wird gestoppt?\n* *Entscheidung*: Fortfahren, überarbeiten, den Prozess neu gestalten oder stoppen?\n\nh3. Before this station\n* [ ] Die Automatisierungshypothese verfügt über ausreichend referenzierte Nachweise zum erwarteten Ergebnis, Umfang, zu anfänglichen Umsetzungsannahmen, kritischen Risiken, Validierungsexperiment, Schwellenwerten und zur Entscheidung, um zu bestimmen, ob sie weiterverfolgt werden soll.\n* [ ] Die Verantwortlichkeit für die Automatisierungschance, Prozessentscheidungen, PoC-Validierung, Risiken und Lebenszyklusergebnisse ist geklärt.\n\nh3. Ready to leave when\n* [ ] Relevante Marktsignale, Feedback oder operative Erkenntnisse liegen vor, um diese Capability-Möglichkeit zu bewerten.\n* [ ] Die Geschäftsziele sind definiert.\n* [ ] Die Marktrecherche identifiziert relevante Capability-Möglichkeiten.\n* [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\nh2. 2. Prozess- und Erlebnisanforderungen\n\nKlären Sie Prozess-, Erlebnis-, Domänen-, Service- und nichtfunktionale Anforderungen, die der spätere Workflow und die Architektur erfüllen müssen.\n\nh3. Canvas questions\nh4. Canvas für Anforderungen an das Nutzererlebnis\nWelche Erlebnis-, Betriebs- und nichtfunktionalen Anforderungen muss die Lösung für Benutzer, Betreiber, Konsumenten, Genehmigende und Support-Teams erfüllen?\n* *Ziele von Benutzern, Betreibern oder Konsumenten*: Welche Geschäfts-, Workflow-, Entscheidungs-, Automatisierungs-, Support- oder Datennutzungsziele müssen unterstützt werden?\n* *Verfügbarkeits- und Aktualitätsbedarfe*: Wann muss die Lösung verfügbar sein, wie aktuell müssen Informationen sein, und welche Reaktions-, Liefer- oder Abschlussfenster sind wichtig?\n* *Volumen- und Leistungserwartungen*: Welche Benutzer-, Fall-, Transaktions-, Datensatz-, Event-, Datei-, Batch- oder Arbeitsvolumen müssen vor der Kapazitätsplanung verstanden werden?\n* *Bedarfe an Datenqualität und Konsistenz*: Welche Erwartungen an Genauigkeit, Vollständigkeit, Konsistenz, Reihenfolge, Deduplizierung, Abstimmung oder Validierung bestehen?\n* *Sicherheits-, Datenschutz- und Compliance-Randbedingungen*: Welche Anforderungen an Identität, Autorisierung, Vertraulichkeit, Datenresidenz, Einwilligung, Aufbewahrung, Audit oder Regulierung muss die Lösung erfüllen?\n* *Aktivierung und Zugriff*: Wie erhalten Benutzer, Betreiber oder konsumierende Teams Zugriff, starten oder nutzen die Lösung und erhalten notwendige Berechtigungen und Anleitung?\n* *Erwartungen an Änderung und Versionierung*: Welche Änderungstoleranz besteht, und welche Erwartungen an Ankündigung, Kompatibilität, Migration, Schulung oder Versionierung gelten?\n* *Bedarfe an Beobachtbarkeit und Support*: Welche Überwachung, Statusinformationen, Nachverfolgbarkeit, Qualitätsübersicht, Unterstützung, Verantwortung und Incident-Kommunikation benötigen Benutzer und Betreiber?\n* *Bedarfe an Wiederherstellung und Kontinuität*: Welche Erwartungen an Replay, Retry, Abstimmung, Backup, Fallback, Kontinuität oder manuelle Wiederherstellung müssen unterstützt werden?\n* *Randbedingungen für späteres Design*: Welche Anforderungen müssen spätere Architektur-, Workflow-, Kapazitäts-, Integrations- oder Implementierungsentscheidungen erfüllen?\n\nh4. Domänen-Canvas\nWelche wesentlichen Entitäten, Begriffe und Fachregeln muss die Capability oder Schnittstelle respektieren?\n* *Ausgewählte Customer Journey Schritte*: Welche Customer Journey Schritte sind für diese Domäne relevant?\n* *Grundlegende Entitäten & geschäftliche Bedeutung*: Welches sind die wesentlichen Entitäten und ihre Bedeutung für das Geschäft?\n* *Attribute & geschäftliche Wichtigkeit*: Welches sind die Schlüsselattribute der einzelnen Entitäten und ihre geschäftliche Wichtigkeit?\n* *Beziehungen zwischen Entitäten*: Welche Beziehungen bestehen zwischen den Entitäten?\n* *Fachregeln, Compliance und Integrität*: Welche Fachregeln sowie Compliance- und Integritätsanforderungen beziehen sich auf die Entitäten?\n* *Überlegungen zu Sicherheit und Datenschutz*: Welche Überlegungen zur Sicherheit und zum Datenschutz gibt es im Zusammenhang mit den Entitäten?\n\nh3. Before this station\n* [ ] Relevante Marktsignale, Feedback oder operative Erkenntnisse liegen vor, um diese Capability-Möglichkeit zu bewerten.\n* [ ] Die Geschäftsziele sind definiert.\n* [ ] Die Marktrecherche identifiziert relevante Capability-Möglichkeiten.\n* [ ] Die relevanten Stakeholder stimmen zu, dass diese Capability-Möglichkeit weiter untersucht und priorisiert werden sollte.\n\nh3. Ready to leave when\n* [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n* [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n* [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\nh2. 3. Entscheidung zu Automatisierungsarchitektur und Plattform\n\nNutzen Sie Auswirkungen, Standort, Kapazität und frühere Anforderungen, um den Umsetzungsansatz für die Automatisierung zu wählen und Begründung sowie verbleibende Risiken festzuhalten.\n\nh3. Canvas questions\nh4. Geschäftsauswirkungs-Canvas\nWelcher Wert, welches Risiko sowie welche betrieblichen, finanziellen, kunden-, mitarbeiter-, compliance- und strategischen Auswirkungen werden erwartet oder stehen auf dem Spiel?\n* *Erwartete Vorteile*: Welche geschäftlichen, kundenbezogenen, mitarbeiterbezogenen, qualitäts-, geschwindigkeits-, risiko-, compliance- oder strategischen Vorteile werden erwartet?\n* *Auswirkung auf die operative Effizienz*: Wie könnten Arbeitsaufwand, Wartezeit, Nacharbeit, Durchsatz, Zuverlässigkeit, Supportbelastung oder Betriebskosten sich verändern?\n* *Auswirkung auf Kunden und Mitarbeitende*: Wie werden Kunden, Mitarbeitende, Partner, Betreiber oder Supportteams die Veränderung erleben?\n* *Finanzielle Auswirkung*: Welche Auswirkungen auf Umsatz, Kosten, Investitionen, Einsparungen, vermiedene Verluste oder Finanzierung werden erwartet?\n* *Compliance- und strategische Auswirkung*: Welche regulatorischen, vertraglichen, richtlinienbezogenen, reputations-, markt-, ökosystem- oder strategischen Konsequenzen sind relevant?\n* *Auswirkung des Nicht-Fortfahrens*: Was geschieht, wenn die Capability, Automatisierung, Integration oder der Service nicht verbessert oder geliefert wird?\n* *Risiken und Kritikalität*: Welche Verfügbarkeits-, Sicherheits-, Daten-, Safety-, Prozess-, Akzeptanz- oder Business-Continuity-Risiken könnten das Ergebnis beeinflussen?\n* *Gegenmaßnahmen und Entscheidungsauswirkung*: Welche Gegenmaßnahmen, Einschränkungen, Kompromisse oder Restrisiken sollten Priorisierung, Architektur, Rollout oder Readiness-Entscheidungen beeinflussen?\n\nh4. Standort-Canvas\nWelche geopolitischen, regulatorischen, Netzwerk- und Vertrauensgrenzen betreffen diese Capability oder Schnittstelle?\n* *Standort-/Vertrauensgruppen*: Welche geopolitischen, regulatorischen, netzwerkbezogenen oder vertrauensbezogenen Gruppen sind relevant?\n* *Gruppenmerkmale*: Was sind die Merkmale dieser Gruppen, wie z. B. Standort, Vertrauensstufe oder Netzwerkexposition?\n* *Relevante Standorte / Zonen*: Was sind die relevanten Standorte, Zonen oder Umgebungen innerhalb jeder Gruppe?\n* *Standort-/Zonenmerkmale*: Was sind die Merkmale dieser Standorte oder Zonen, wie z. B. Eigentumsverhältnisse, Region oder Exposition?\n* *Netzwerk- / Regulierungsentfernungen*: Welche Latenz-, Vertrauens-, Regulierungs- oder Konnektivitätsentfernungen bestehen zwischen den Standorten?\n* *Entfernungsmerkmale*: Was sind die Merkmale dieser Entfernungen, wie z. B. Latenzempfindlichkeit, Aufenthaltsbeschränkungen oder Vertrauensgrenzen?\n* *Konnektivitätsendpunkte*: Welche Konnektivitätsendpunkte oder Schnittstellen sind mit den Standorten verbunden?\n* *Endpunktzugriffseigenschaften*: Welche Eigenschaften weisen diese Endpunkte auf, wie z. B. Sichtbarkeit, Protokoll, Sicherheit oder Zugriffsbeschränkungen?\n\nh4. Kapazitäts-Canvas\nWie viel Nachfrage, Last, Timing und Skalierungskapazität müssen für Fähigkeit, Automatisierung, Integration oder Service verstanden werden?\n* *Aktuelles Geschäftsvolumen*: Wie hoch sind das aktuelle Geschäftsvolumen und die Transaktionsraten?\n* *Zukünftige Konsumtrends*: Was sind die erwarteten künftigen Konsumtrends?\n* *Spitzenlast- und Verfügbarkeitsanforderungen*: Was sind die Spitzenlast- und Verfügbarkeitsanforderungen?\n* *Caching-Strategien*: Welche Caching-Strategien können zur Performanceoptimierung eingesetzt werden?\n* *Strategien zur Ratenbegrenzung*: Welche Strategien zur Ratenbegrenzung können genutzt werden, um die Nutzung zu steuern?\n* *Strategien zur Skalierung*: Welche Strategien zur Skalierung können eingesetzt werden, um das Wachstum zu unterstützen?\n\nh4. Canvas für Automatisierungsarchitektur-Entscheidung\nWählen Sie den Umsetzungsansatz anhand bereits gesammelter Nachweise.\n* *Wiederverwendete Eingaben*: Welche Anforderungen, Kapazitäts-, Standort-, Auswirkungs- und Verantwortlichkeitsentscheidungen begrenzen die Auswahl?\n* *Tragfähige Optionen*: Welche Optionen mit Menschen, Workflows, Regeln, Agenten, APIs, Konnektoren, individuellen Lösungen oder UI-Automatisierung bleiben tragfähig?\n* *Ausgewählter Ansatz*: Welcher Umsetzungsstil oder hybride Ansatz wird ausgewählt?\n* *Entscheidungsbegründung*: Warum passt der ausgewählte Ansatz am besten?\n* *Abgelehnte Alternativen*: Welche ernsthaften Alternativen wurden abgelehnt, und warum?\n* *Offene Risiken*: Was muss vor Lieferung oder Release noch validiert werden?\n\nh3. Before this station\n* [ ] Die Capability-Möglichkeit wurde identifiziert und dokumentiert.\n* [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n* [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\nh3. Ready to leave when\n* [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n* [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\nh2. 4. Automatisierungs-Workflow-Design\n\nEntwerfen Sie den internen Workflow, der zur Erreichung der ausgewählten Kunden- und Fähigkeitsergebnisse benötigt wird, einschließlich Arbeitsverteilung, Kontrollen, Ausnahmen, Wiederherstellung, Nachweisen und Monitoring.\n\nh3. Canvas questions\nh4. Automatisierungs-Workflow-Canvas\nEntwerfen Sie den internen Workflow, der benötigt wird, um die ausgewählten Kunden- und Capability-Ergebnisse zu liefern.\n* *Ausgewählte Kunden- und Capability-Ergebnisse*: Welche vereinbarten Kunden- und Capability-Ergebnisse muss dieser Workflow liefern?\n* *Interne Workflow-Schritte*: Welche interne Arbeit muss stattfinden, um diese Ergebnisse zu erzeugen?\n* *Arbeitsverteilung und menschliche Kontrolle*: Was bleibt menschlich, was wird automatisiert und wo sind Aufsicht oder Eskalation erforderlich?\n* *Inputs, Outputs und Interaktionen*: Welche Informationen, Systeme und Übergaben werden benötigt?\n* *Entscheidungen, Ausnahmen und Wiederherstellung*: Was verändert den Ablauf, was kann fehlschlagen und wie wird die Arbeit wiederhergestellt?\n* *Nachweise und Monitoring*: Was belegt den korrekten Betrieb und zeigt, ob das beabsichtigte Ergebnis erreicht wurde?\n\nh3. Before this station\n* [ ] Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert.\n* [ ] Die Nutzersegmente sind identifiziert.\n* [ ] Eine übergeordnete Roadmap für die Umsetzung ist definiert.\n\nh3. Ready to leave when\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\nh2. 5. Automatisierungsbereitstellung & Betrieb\n\nBauen, konfigurieren, testen, versionieren und deployen Sie den ausgewählten Automatisierungspfad und bereiten Sie das Betriebsmodell vor, einschließlich Verantwortlichkeit, Umgebungen, Runbooks, Monitoring, Fallback, Rollback, Support und bekannter Risiken.\n\nh3. Canvas questions\nh4. Canvas für Automatisierungsbereitschaft und Betrieb\nBereiten Sie die minimal erforderlichen Betriebsnachweise vor der Readiness-Prüfung vor.\n* *Verantwortlichkeit*: Wer verantwortet Geschäftsergebnisse, Betrieb, Support und Änderungen?\n* *Umgebungen und Zugriff*: Sind Umgebungen, Berechtigungen, Credentials und Identitäten bereit?\n* *Testnachweise*: Was belegt korrektes, sicheres und zuverlässiges Verhalten?\n* *Monitoring und Support*: Wie werden Health, Incidents, Nutzer und Betreiber unterstützt?\n* *Fehler und Wiederherstellung*: Wie funktionieren Ausnahmen, Fallback, Rollback und manuelle Wiederherstellung?\n* *Readiness-Status*: Sind Dokumentation, Risiken, Bedingungen und blockierende Lücken klar?\n\nh3. Before this station\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\nh3. Ready to leave when\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\nh2. 6. Automatisierungsbereitschaftsprüfung\n\nNutzen Sie eine Readiness-Checkliste, um Nachweise zu prüfen und die Freigabeentscheidung festzuhalten: bereit, unter Bedingungen bereit, Nachbesserung erforderlich oder nicht genehmigt.\n\nh3. Station questions\n* Prüfen Sie abgeschlossenes Design, Testnachweise, Betriebsmodell, Berechtigungen, Credentials, Monitoring, Support, Fallback und Rollback.\n* Verifizieren Sie, dass bekannte Risiken, Ausnahmen, unsichere Aktionen, menschliche Aufsicht, Compliance-Anforderungen und offene Annahmen adressiert oder ausdrücklich akzeptiert sind.\n* Dokumentieren Sie blockierende Befunde, akzeptierte Restrisiken, Freigabebedingungen und erforderliche Remediation-Maßnahmen.\n* Entscheiden Sie, ob die Freigabe bereit, bedingt bereit, remediation-pflichtig oder nicht genehmigt ist.\n* Dokumentieren Sie Entscheidungsverantwortliche, Entscheidungsdatum und verwendete Nachweise.\n* Bestätigen Sie, dass nichts ohne klare fachliche und betriebliche Ownership freigegeben wird.\n* Nutzen Sie Bereitschaftsnachweise, um vor der Produktionsnutzung eine ausdrückliche Go-, bedingte Go- oder No-go-Entscheidung zu treffen.\n* Eine formale Bereitschaftsentscheidung verhindert, dass Automatisierungslösungen ohne klare Nachweise, akzeptierte Risiken, Remediation-Maßnahmen sowie fachliche und betriebliche Ownership freigegeben werden.\n\nh3. Before this station\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n\nh3. Ready to leave when\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Die Schnittstelle und ihre Capabilities sind ausreichend klar für Review, Auditierung und Onboarding dokumentiert.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n* [ ] Der Schnittstellenvertrag wurde validiert und gegen funktionale und nicht-funktionale Anforderungen getestet.\n\nh3. Other related resources\n* *Checkliste zur Automatisierungsbereitschaft*: Eine Checkliste zur Prüfung von Automatisierungsnachweisen, blockierenden Befunden, akzeptierten Restrisiken, Freigabebedingungen, Nachbesserungsmaßnahmen, Entscheidungsverantwortung, Entscheidungsdatum und Release Readiness.\n\nh2. 7. Automatisierungs-Rollout & Enablement\n\nAktivieren und rollen Sie die Automatisierung sicher aus - mit Kommunikation, Schulung, Betriebsanweisungen, Supportwegen, Adoptionsmonitoring, Feedbackkanälen, phasenweisem Rollout sowie Pausen- und Rollback-Bedingungen.\n\nh3. Station questions\n* Betroffene Personen und geänderte Arbeit: Wer wird die Freigabe nutzen, betreiben, unterstützen, genehmigen, konsumieren oder davon betroffen sein, und welche Verantwortlichkeiten, Entscheidungen, Übergaben oder Arbeitsweisen ändern sich?\n* Aktivierungs- und Rollout-Ansatz: Wie werden Zugriff, Berechtigungen, Pilotnutzung, phasenweiser Rollout, eingeschränkte Gruppen, Parallelbetrieb und Rollout-Erweiterung gesteuert?\n* Enablement und Support: Welche Kommunikation, Schulung, Betriebsanweisungen und Supportpfade sind erforderlich?\n* Feedback und Kontrolle: Wie werden Adoption, Vertrauen, tatsächliche Nutzung, Probleme und unerwartetes Verhalten überwacht, und welche Bedingungen lösen Pause, Rollback oder Rückkehr zum manuellen Betrieb aus?\n* Planen Sie Rollout, Befähigung, Support, Feedback und Rollback, damit freigegebene Lösungen sicher eingeführt werden können.\n* Automatisierungslösungen schaffen erst nach dem Rollout Wert, wenn betroffene Personen und konsumierende Systeme verstehen, was sich ändert, wie Zugriff und Betrieb funktionieren, wo Unterstützung verfügbar ist und wann der Rollout pausiert, erweitert oder zurückgerollt werden muss.\n\nh3. Before this station\n* [ ] Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.\n* [ ] Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen.\n* [ ] Die Schnittstelle und ihre Capabilities sind ausreichend klar für Review, Auditierung und Onboarding dokumentiert.\n* [ ] Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen.\n* [ ] Der Schnittstellenvertrag wurde validiert und gegen funktionale und nicht-funktionale Anforderungen getestet.\n\nh3. Ready to leave when\n* [ ] Die Lösung besteht Qualitäts-, Sicherheits-, Compliance- und Bereitschaftsprüfungen.\n* [ ] Audit-Ergebnisse und Maßnahmenentscheidungen wurden mit den relevanten Stakeholdern geteilt.\n* [ ] Die Capability ist bereit, über den gewählten Bereitstellungsmechanismus veröffentlicht oder ausgeliefert zu werden.\n* [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n\nh3. Other related resources\n* *Leitfaden für Rollout und Enablement von Automatisierungen*: Anleitung zur Aktivierung und Einführung von Automatisierungen mit Analyse geänderter Arbeit, Rollout-Ansatz, Enablement, Support, Feedback, Adoptionsmonitoring und Kontrollbedingungen.\n\nh2. 8. Automatisierungsmonitoring & Verbesserung\n\nÜberwachen Sie tatsächliche Automatisierungsergebnisse, erfolgreiche und fehlgeschlagene Läufe, Ausnahmen, Wiederholungen, Eingriffe, Durchlaufzeit, Wartezeit, Kosten, Fehler, unsichere Aktionen, Einführung, Vertrauen, realisierten Nutzen und welche Hypothesenannahmen bestätigt oder verworfen wurden.\n\nh3. Station questions\n* Ergebnisse und Wert: Werden die erwarteten Prozess-, Nutzer- und Geschäftsergebnisse erreicht?\n* Betriebsleistung: Was zeigen erfolgreiche Läufe, Fehler, Teilabschlüsse, Ausnahmen, Wiederholungen, Timeouts, Interventionen, Verarbeitungszeit, Wartezeit und Kosten?\n* Nutzer-, Risiko- und Wiederherstellungssignale: Welche Fehler, Korrekturen, unsicheren Aktionen, Umgehungen, Misstrauen, Supportbedarfe, Fallback-Ereignisse oder Wiederherstellungsfehler treten auf?\n* Lernen und Lifecycle-Entscheidung: Welche Hypothesenannahmen wurden bestätigt oder verworfen, und sollte die Lösung verbessert, erweitert, eingeschränkt, neu gestaltet, pausiert oder stillgelegt werden?\n* Nutzen Sie operative, Nutzer-, Risiko- und Wertnachweise, um zu entscheiden, was verbessert, erweitert, eingeschränkt, pausiert oder stillgelegt werden soll.\n* Freigegebene Lösungen benötigen Nachweise, ob erwartete Ergebnisse erreicht werden, wo manuelle Intervention oder Wiederherstellung noch nötig ist und welche Lifecycle-Entscheidung als Nächstes getroffen werden sollte.\n\nh3. Before this station\n* [ ] Die Lösung besteht Qualitäts-, Sicherheits-, Compliance- und Bereitschaftsprüfungen.\n* [ ] Audit-Ergebnisse und Maßnahmenentscheidungen wurden mit den relevanten Stakeholdern geteilt.\n* [ ] Die Capability ist bereit, über den gewählten Bereitstellungsmechanismus veröffentlicht oder ausgeliefert zu werden.\n* [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n\nh3. Ready to leave when\n* [ ] Nutzerorientierte Dokumentation und Onboarding-Materialien sind bereit.\n* [ ] Onboarding-, Support- und Kommunikationsprozesse für Nutzer sind bereit.\n* [ ] Rechtliche, Datenschutz- und Compliance-Anforderungen für Veröffentlichung oder Release sind definiert und verstanden.\n\nh3. Other related resources\n* *Automatisierungsmonitoring und Wertmetriken*: Anleitung zur Messung von Ergebnissen, operativer Leistung, Nutzerverhalten, Risiko, Wiederherstellung, realisiertem Wert, Hypothesenlernen und Lifecycle-Entscheidungen nach dem Rollout."
      }
    ]
  }
}