Stakeholder Engagement, Lifecycle & GTM

Screen 1: Orientation: what you will be able to do by the end

MODULE · ORIENTATION Orientation: what you will be able to do by the end

Die letzten drei Module haben Sie von einem geschäftlichen Problem zu einer gestalteten, integrierten und verwalteten Claude-Bereitstellung geführt. Sie können eine Anfrage aufschlüsseln, ein Muster auswählen, einen Use Case dimensionieren, Evals als Akzeptanzkriterien erstellen, Observability instrumentieren und eine nachvollziehbare Kontrollgruppe für eine regulierte Workload aufbauen. Was all das nicht gelöst hat, ist der Teil der Arbeit, der in Räumen mit Stakeholdern stattfindet: das Discovery-Gespräch, in dem die echten Anforderungen festgelegt werden, das Genehmigungstreffen, in dem ein Tradeoff gewonnen oder verloren wird, die Übergabe, bei der Ihr Design entweder Ihre Abwesenheit übersteht oder sich leise verschlechtert.

Dieses Modul behandelt diese Arbeit. Am Ende werden Sie in der Lage sein: 1 Ein strukturiertes Discovery-Gespräch mit einem nicht-technischen Stakeholder zu führen und das Gelernte in architektonische Anforderungen und dokumentierte Annahmen zu übersetzen, damit das Design auf den Business Case zurückgeht und nicht auf Ihre eigene technische Vorliebe. 2 Einen architektonischen Tradeoff in Begriffen zu präsentieren, auf die ein Business Stakeholder handeln kann, indem Sie jede Wahl mit Kosten, Risiko und dem Aufwand für eine Umkehrung koppeln, damit Executive- und Procurement-Reviews zu einer Entscheidung führen statt zu stagnieren. 3 Eine Stakeholder-Feedback-Loop über den Bereitstellungslebenszyklus aufbauen und betreiben, die benennt, was eine Überprüfung auslöst, was ein SLA-Verstoß erfordert, und wann iteriert versus neu architekturiert werden soll, mit Governance-Checkpoints, die in die gleiche Loop integriert sind. 4 PARTNER TRACK[Partner-Track Relevant, nicht vom Architect-Examen getestet; für Partner-Track-Lernende beibehalten] Die Rolle des Architects in einer Partner-Go-to-Market-Motion durch Discovery, ein szenariobasiertes Demo, technische Einwandbehandlung und gemeinsame Scoping mit dem Anthropic Applied AI Team führen, damit eine Enterprise-Gelegenheit nicht bei Fragen stagniert, die nur Sie beantworten können. 5 Den Bereitstellungseinstiegspunkt und die Cross-Platform-Strategie für ein Multi-Platform-Produktionssystem auswählen, indem Sie die direkte API, Bedrock, Vertex und Third-Party-Routen auf Latenz, Compliance und Kosten vergleichen, und dann ein Ergebnisdokument erstellen, das den Wert für einen nicht-technischen Sponsor verständlich macht und als Partner-IP wiederverwendbar ist. Die Arbeit ordnet sich den folgenden Abschnitten zu:

Discovery ist der Ort, an dem Sie die Vorliebe eines Stakeholders in eine dokumentierte Einschränkung umwandeln, gegen die die Architektur gestaltet werden kann. Der Schritt ist Übersetzung: Eine Vorliebe signalisiert, dass mehr Fragen erforderlich sind, anstatt als direkte Anforderung zu fungieren. Eine nützliche Anforderung ist testbar und begrenzt. Das kostspielige Versagen ist ein Discovery-Anruf, der in einer Design-Skizze endet, bevor die Übersetzung abgeschlossen ist. Die plausible Skizze ist das, was es gefährlich macht: Ein Stakeholder, der eine selbstbewusste Architektur sieht, nimmt an, dass die Fragen beantwortet wurden.

Tradeoff-Framing und Go-to-Market ist der Ort, an dem Sie eine architektonische Entscheidung in Begriffen präsentieren, auf die ein Stakeholder handeln kann, und wo Sie ein Demo gegen das echte Szenario des Käufers gestalten, anstatt gegen die eigenen Fähigkeiten des Teams. Drei Elemente gehören in jede Tradeoff-Präsentation: was die Wahl gewinnt, was sie aufgibt, und was eine Umkehrung kostet, sobald das System um sie herum gebaut ist. Das dritte Element ist das, das das Treffen verändert, und es ist das, das in den meisten Präsentationen fehlt.

Die Feedback-Loop ist der Ort, an dem Sie die Entscheidungsebene aufbauen, die über dem Observability-Stack sitzt und bestimmt, welche Signale das Verhalten ändern und wessen. Eine Feedback-Loop ist eine Governance-Tabelle, die jedes Signal einem Trigger, einem Eigentümer und einer Aktion zuordnet. In regulierten Bereitstellungen werden einige Überprüfungen nach einem Zeitplan ausgelöst, anstatt bei einem Schwellenwert. Diese Governance-Zeilen müssen vor dem Start vorhanden sein. Wenn es keinen definierten Trigger gibt, wird ein Compliance-Checkpoint nicht auftauchen, bis ein Reviewer nach dem Datensatz sucht.

Dokumentation für Übergabe und Audit ist der Ort, an dem Sie nicht nur die getroffenen Entscheidungen aufzeichnen, sondern auch die abgelehnten Alternativen und den Tradeoff, den jede gelöst hat. Der Vollständigkeitstest ist, ob ein kompetenter Architect, der nicht im Raum war, nach dem Lesen des Dokuments eine sichere Änderung am System vornehmen kann. Ein Diagramm zeigt, was das System ist. Ohne die Begründung für die Entscheidungen kann das Diagramm dem Nachfolger nicht sagen, welche Entscheidungen tragend sind und welche einfach Vorlieben sind. Der Moment, in dem Sie das Engagement verlassen, ist der Moment, in dem diese Begründung weg ist, wenn sie nie dokumentiert wurde.

Entry-Point-Auswahl und das Ergebnisdokument ist der Ort, an dem Sie die richtige Bereitstellungsroute für ein Live-Produktionssystem bestätigen und die Ergebnisse der Bereitstellung in ein Artefakt umwandeln, das das Engagement übersteht. Das Ergebnisdokument macht den Business Case für einen Leser, der nicht Teil des Builds war. Volumen, Latenz und Fehlerrate sagen einem Sponsor, dass das System läuft. Ein Vorher-Nachher bei der Business-Metrik, auf die der Use Case abzielte, unterstützt durch eine nachvollziehbare Kontrolle, sagt einem CFO, was es wert ist zu erweitern.

Diese fünf Themen sind nicht unabhängig, tatsächlich erstreckt sich jedes aus dem letzten. Die Einschränkungsmenge aus Discovery ist das, was die Tradeoff-Präsentation verteidigt. Die Feedback-Loop-Governance-Tabelle hält die im Register erfassten Compliance-Kontrollen aktuell, während die Bereitstellung läuft. Die Dokumentationslogik verhindert, dass die Entscheidungen, die das Register enthält, von einem Nachfolger stillschweigend rückgängig gemacht werden. Das Ergebnisdokument zieht aus jeder Ebene darüber, um den Wert für einen Leser verständlich zu machen, der die Arbeit nie gesehen hat. Die kumulative Aufgabe am Ende fordert Sie auf, eine regulierte Multi-Platform-Bereitstellung vom ersten Satz eines Stakeholders bis zu einem Ergebnisdokument zu führen, das eine Expansion rechtfertigt. Tatsächlich ist dies genau das, wozu dieses Modul Sie ausrüstet, bevor Sie übergeben.

Über diese fünf Themen hinweg verläuft der Projektlebenszyklus selbst: Discovery → Design → Übergabe → Monitoring → Iteration. Discovery und Tradeoff-Framing führen die Discovery-und-Design-Arbeit durch; die Feedback-Loop ist die Monitoring-und-Iterations-Phase; Dokumentation ist die Übergabephase; und Entry-Point-Auswahl mit dem Ergebnisdokument schließt die Loop. Die Identifizierung der Phase, zu der eine Entscheidung gehört, ist das, was es Ihnen ermöglicht, zu beurteilen, wann eine Phase bereit ist, zur nächsten zu wechseln.

DISCLAIMER / NOTICE FOR EDUCATIONAL CONTENT

Wir haben diesen Architect-Kurs Modul 4: Stakeholder Engagement, Lifecycle und Go-to-Market erstellt, um Ihnen zu helfen, echte Arbeit mit Claude zu leisten. Behandeln Sie ihn als Bildungsinhalte. Er stellt keine rechtliche, finanzielle oder andere professionelle Beratung dar, daher sollten Sie das Gelernte an Ihre eigene Situation anpassen. Unsere Produkte und Dienstleistungen entwickeln sich schnell, daher können bestimmte Inhalte Fehler enthalten oder veraltet sein; denken Sie daran, auf der Website oder in der Dokumentation von Anthropic zu überprüfen. Beispiele und Szenarien, die im Kurs verwendet werden, sind illustrativ und oft fiktiv. Wenn der Kursinhalt ein Unternehmen oder Produkt erwähnt, bedeutet dies nicht, dass Anthropic diese unterstützt, sie Anthropic unterstützen oder dass wir verbunden sind. Beachten Sie auch, dass Ihre Nutzung von Anthropic-Produkten und -Dienstleistungen durch unsere Bedingungen, Richtlinien und Dokumentation abgedeckt ist; wenn etwas in diesem Kurs damit in Konflikt steht, haben diese Vorrang.

Screen 2: A discovery call is a structured elicitation, not a conversation

Discovery A discovery call is a structured elicitation, not a conversation Sie wissen, wie Sie das Muster, die Bereitstellungsplattform und die Kontrollposition evaluieren. Discovery zeigt, ob Sie das richtige Problem lösen. Ein Stakeholder wird das Problem normalerweise in geschäftlichen Begriffen beschreiben. Ihre Aufgabe ist es, zuzuhören, was das Unternehmen erreichen möchte, die in dieser Beschreibung verborgenen Einschränkungen zu identifizieren und den Anruf mit einem Datensatz zu verlassen, dem das Design folgen kann.

Discovery stellt die Artefakte auf, auf die das Design angewiesen ist Ein Discovery-Gespräch funktioniert als dreiteiliger Filter: zuhören, übersetzen und aufschreiben.

1Hören Sie zunächst das geschäftliche Ziel in einfacher Sprache und achten Sie auf die Bedeutung hinter dem Wort. Stakeholder beschreiben normalerweise das Ergebnis, das sie wollen, aber nicht die Einschränkung, die Sie zum Gestalten benötigen. 2Übersetzen Sie das zweitens in Anforderungen, Annahmen und ungelöste Einschränkungen. Dies ermöglicht es Ihnen zu sehen, was das Design unterstützen muss, was noch bestätigt werden muss, und was die Lösung später blockieren könnte. 3Schreiben Sie diese Elemente drittens auf, bevor das Gespräch weitergeht. Das Design benötigt einen klaren Datensatz zum Folgen. Ohne diesen Filter erbt das Design Ihre Annahmen. Die Nichtübereinstimmung wird möglicherweise erst viel später offenbart, wenn das Ändern der Richtung langsamer, schwieriger und teurer ist.

Der Kernschritt ist Übersetzung: Eine angegebene Vorliebe verbirgt fast immer eine Einschränkung Die wichtigste Fähigkeit in Discovery ist Übersetzung. Stakeholder sprechen normalerweise in Vorlieben, aber Designentscheidungen werden gegen Einschränkungen getroffen. Stellen Sie sich vor, ein Stakeholder sagt: „Wir möchten, dass sich das nahtlos anfühlt. " Wenn Sie „nahtlos" als Anforderung aufschreiben, haben Sie nicht genug gelernt, um etwas zu gestalten. Sie haben nur die Zusammenfassung des Stakeholders über die Erfahrung, die er möchte. Die echte Arbeit beginnt mit der nächsten Frage: Was würde es sich nicht nahtlos anfühlen lassen? Dort beginnen die verborgenen Einschränkungen zu erscheinen. Vielleicht sollte der Benutzer nie mehr als eine oder zwei Sekunden auf den nächsten Schritt warten. Vielleicht sollten sie keine Informationen erneut eingeben, die bereits vorgelagert vorhanden sind. Vielleicht sollten Ausnahmen leise zu einem menschlichen Reviewer gehen, anstatt einen technischen Fehler zu offenbaren. Vielleicht muss der Workflow in einer Anwendung bleiben, damit der Benutzer nie zwischen Tools wechseln muss. Jede Antwort schärft das Design. Dieser Austausch verwandelt „nahtlos" in Anforderungen, die die Architektur unterstützen muss: ein Latenz-Ziel, eine Integrationsanforderung, eine Handoff-Regel und einen sicheren Fehlerpfad. Der Stakeholder benennt das Ergebnis in geschäftlicher Sprache. Sie verwandeln es in etwas, das das System bauen und messen kann. Die Vorliebe sitzt auf der obersten Ebene, und die Einschränkung sitzt darunter. Wenn ein Stakeholder Ihnen ein Erfahrungswort wie nahtlos, einfach, schnell, simpel oder intuitiv gibt, behandeln Sie es als Signal, dass mehr Discovery erforderlich ist. Fragen Sie, was diese Erfahrung brechen würde, was der Benutzer nie bemerken sollte, was hinter den Kulissen passieren muss, und was noch wahr sein muss, wenn etwas schiefgeht. Diese Antworten sind das, was in den Design-Datensatz gehört. Eine testbare, begrenzte Einschränkung ist das, gegen das das Design gebaut werden kann. Eine Stakeholder-Vorliebe sagt Ihnen, wo Sie untersuchen sollten, während die Folgefragen die Einschränkung selbst produzieren.

Vier Fragen verwandeln Discovery in Anforderungen Discovery funktioniert am besten, wenn Sie eine vage Stakeholder-Aussage in die vier Buckets unten zwingen. Eine Aussage wie „wir möchten, dass sich das nahtlos anfühlt" ist noch nicht etwas, gegen das Sie gestalten können. Sie verbirgt normalerweise eine oder mehrere spezifische Antworten. Untersuchen Sie Folgendes:

1Was das System tun muss. Dies sind die Fähigkeiten, die die Bereitstellung liefern muss, ausgedrückt als geschäftliche Ergebnisse statt als Features. Hier trennen Sie die Arbeit, die Claude besitzt, von der Arbeit, die bei einem bestehenden System oder einem Menschen bleibt. 2Was das System nicht tun darf. Dies sind die Grenzen, verbotenen Aktionen und Fälle, die zu einem Menschen geroutet werden müssen. Stakeholder bieten diese selten freiwillig an, daher müssen Sie explizit danach fragen. 3Was das System kosten muss. Dies ist die Budget-Einschränkung, ausgedrückt in Begriffen, die der Stakeholder kontrolliert. Ein Latenz-Ziel, eine Pro-Interaktions-Kostendeckelung oder eine Volumenprognose sollten alle hier berücksichtigt werden. Diese werden zu entscheidenden Design-Einschränkungen. 4Was das System beweisen muss. Dies ist der Beweis, den die Bereitstellung produzieren muss, um etwas von Wert zu zeigen. In regulierten Workflows sind Beweispflichten Teil der Anforderungsmenge. Sie in Discovery zu identifizieren ist weit billiger als während einer rechtlichen Überprüfung Wochen später.

„Nahtlos" kann wirklich ein Latenz-Budget bedeuten, das der Benutzer nicht bemerken sollte, ein Handoff, das den Fluss nicht unterbrechen sollte, oder ein Fehlerzustand, der System-Interna nicht offenbaren darf. Sobald Sie diese Antworten entdecken, haben Sie Anforderungen, die das Team gestalten, testen und verteidigen kann.

Die Ausgabe von Discovery ist eine Übersetzungstabelle Jedes in Discovery gefundene Element wird zu einer Zeile in einer Übersetzungstabelle. Die Zeile erfasst die Stakeholder-Aussage, wie sie gesagt wurde, die Einschränkung, die sie impliziert, die architektonische Entscheidung, die diese Einschränkung erzwingt, und jede Annahme, die Sie dokumentieren, wenn die Einschränkung noch nicht bestätigt wurde. Eine Zeile pro Element hält die Begründung intakt, während die Arbeit von Discovery in Design übergeht, und hält Annahmen im Fokus.

Stakeholder-AussageImplizierte EinschränkungErforderliche architektonische EntscheidungAnnahme des Dokuments

„Wir möchten, dass sich das nahtlos anfühlt. "Die Erfahrung muss in einem vereinbarten Latenz-Budget bleiben. Fehler dürfen System-Interna nicht offenbaren oder den Fluss nicht unterbrechen. Setzen Sie ein p95-Latenz-Ziel als Design-Einschränkung, dann gestalten Sie einen anmutigen, intern-sicheren Fehlerzustand. Nimmt an, dass „nahtlos" sich auf wahrgenommene Reaktionsfähigkeit und Kontinuität des Flusses bezieht. Bestätigen Sie das Verständnis. „Es muss nur das Formular lesen und es routen. "Das Routing kann eine deterministische Geschäftsregel sein. Halten Sie die Routing-Entscheidung in der Regel-Engine. Claude extrahiert, und das System routet. Nimmt an, dass die Routing-Logik außerhalb des Modells besessen und gepflegt wird. Bestätigen Sie den Eigentümer. „Kliniker werden die Ausgabe ohnehin überprüfen. "Ein lizenzierter Mensch muss die Ausgabe autorisieren, bevor sie Teil eines Datensatzes mit rechtlichen, finanziellen oder klinischen Konsequenzen wird. Bauen Sie einen menschlichen Autorisierungsschritt als obligatorischen Checkpoint. Nimmt an, dass die Überprüfung ein architektonisches Gate ist. Bestätigen Sie die Autorität und das Timing. „Wir sind im Gesundheitswesen, also seien vorsichtig mit Daten. "Der Workflow trägt wahrscheinlich eine Beweispflicht unter einem Gesundheitsdatenschutz-Regime. Behandeln Sie Audit-Trail und Datenbehandlung-Beweis als Kernanforderung von Tag eins. Nimmt an, dass ein abgedeckter Workflow mit einer formalen Verpflichtung vorhanden ist. Bestätigen Sie den Umfang mit Compliance.

Kosten · Komplexität · Risiko

Kosten: Ein Discovery-Anruf, der lange genug läuft, um die echten Einschränkungen zu identifizieren, ist weit billiger als das Umgestalten der Lösung, nachdem eine verborgene Einschränkung während einer rechtlichen oder Compliance-Überprüfung auftaucht. Komplexität: Das Durcharbeiten der vier Fragenkategorien fügt notwendige Struktur hinzu, und das Übersetzen von Vorlieben in Einschränkungen in Echtzeit erfordert bewusste Übung. Risiko: Das kostspielige Versagen ist die unausgesprochene Einschränkung, die den Test übersteht und zu einem Produktions-Review-Blocker wird, wenn die Kosten für das Ändern des Designs am höchsten sind.

Screen 3: The discovery call that turned into a design session

Watch OutDiscovery5 min Der Discovery-Anruf, der sich in eine Design-Sitzung verwandelte

SetupDiscovery ist der Ort, an dem die Arbeit beginnt. Design ist der Ort, an dem sie beschleunigt. Ein guter Architect beginnt, eine Lösung partway durch den Anruf zu bilden. Skizzieren und Visualisieren fühlt sich produktiv an, und der Stakeholder scheint erfreut zu sein, Fortschritt zu sehen. Das ist genau der Moment, in dem die Fragen aufhören.

Ein rekonstruierter Discovery-Anruf, bei dem die Fragen früh aufhörten Im Austausch unten hört der Architect zwei Stakeholder-Aussagen und beginnt, eine Lösung vorzuschlagen. Der Stakeholder bestätigt den anfänglichen Vorschlag, weil er kompetent klingt. Die Einschränkungen, die diese Architektur ausgeschlossen hätten, werden nie identifiziert. Sie tauchen zwei Wochen später während einer Compliance-Überprüfung auf. Dieser Abschnitt zeigt genau, wo die Frage, die jede Einschränkung hätte fangen können, gehörte. Verwenden Sie dieses Beispiel, um das Muster in Ihren eigenen Anrufen zu erkennen.

Rekonstruierter Austausch

Stakeholder: „Wir betreiben ein regionales Krankenhausnetzwerk. Krankenschwestern verbringen ewig damit, Patienteninteraktionen aufzuschreiben. Wir möchten, dass Claude die klinische Notiz aus ihrer Diktation entwirft. " Architect: „Verstanden, das ist nur ein sauberes erweitertes Muster. Claude nimmt die Diktation, entwirft die strukturierte Notiz, dann schreibt sie zurück. Wir können nächste Woche einen Prototyp haben. " Stakeholder: „Das klingt richtig. Es gibt irgendwo einen Überprüfungsschritt, aber es ist nur eine schnelle Überprüfung. " Architect: „Sicher, wir fügen einen Überprüfungsschritt hinzu. Lassen Sie mich mit dem Design beginnen. "

Verschiedene Einschränkungen, die zu spät identifiziert wurden, um eine einfache Reparatur zu sein Die „schnelle Überprüfung" war keine Komfortfunktion. Der Krankenpflege-Workflow erforderte, dass ein lizenzierter Kliniker jede Modellausgabe autorisiert, bevor sie die Patientenakte erreichte. Dies machte die menschliche Autorisierung zu einem erforderlichen architektonischen Gate statt zu einer optionalen Ergänzung. Die Diktation enthielt geschützte Gesundheitsinformationen. Geschützte Gesundheitsinformationen wurden durch das Kontextfenster ohne die erforderliche Behandlung des Workflows bewegt. Das Netzwerk erstreckte sich über zwei Staaten mit unterschiedlichen Aufbewahrungsregeln, und das Single-Region-Design berücksichtigte nie eines davon. Keine dieser Anforderungen waren ungewöhnlich oder schwer zu finden. Jede wäre aus einer direkten Frage in den Must-Prove- und Must-Not-Do-Kategorien hervorgegangen, hätte der Anruf nicht vor diesen Fragen zu Skizzieren gewechselt.

Warum das brach: Ein kompetenter Skizzen-Vorschlag beendete die Fragen, die ein Discovery-Anruf stellen soll Die Skizze war plausibel, und Plausibilität ist das, was das gefährlich macht. Ein Stakeholder, der eine selbstbewusste Architektur hört, nimmt an, dass der Architect die Informationen hat, um sie zu bauen. Der Schritt, der Sie schützt, ist langweilig: Beenden Sie die Vier-Kategorien-Fragenmenge, bevor Sie etwas vorschlagen, und behandeln Sie jedes „es ist nur eine Überprüfung" als Einschränkung zum Verfolgen.

Screen 4: Checkpoint: find the undocumented assumption

Discovery · Checkpoint Checkpoint: Finden Sie die undokumentierte Annahme

Versuchen Sie es jetzt. Unten ist eine Discovery-Anruf-Zusammenfassung und das Anforderungsdokument, das ein Architect daraus erstellt hat. Drei Elemente lassen sich auf etwas zurückführen, das der Stakeholder sagte; eines ist eine Annahme, die der Architect ohne Oberflächeneinschränkung gemacht hat. Wählen Sie das Element, das die undokumentierte Annahme ist, und bestätigen Sie dann, dass keine Stakeholder-Aussage es unterstützt.

Anforderungsdokument

• Claude entwirft die Kunden-E-Mail, aber eine Person sendet sie tatsächlich.
• Antworten müssen innerhalb eines Zwei-Sekunden-Wahrnehmungsbudgets zurückkehren.
• Rückerstattungen über dem Schwellenwert werden zu einem menschlichen Genehmiger geroutet.
• Gesprächstranskripte werden 60 Tage lang für Analysen aufbewahrt.

Was der Stakeholder sagte

„Alles Große erfordert die Zustimmung einer Person. " „Entwurf der Antwort, aber wir senden sie selbst. " „Es muss sich für den Benutzer sofort anfühlen. "

Teil 1: Welches Element ist die undokumentierte Annahme?

AElement 1, E-Mail-Entwurf mit menschlichem Versand BElement 2, Zwei-Sekunden-Latenz-Budget CElement 3, Rückerstattungs-Routing zu menschlichem Genehmiger DElement 4, 60-Tage-Transkript-Aufbewahrung

Teil 2: Welche Stakeholder-Aussage sollte Element 4 zurückführen?

A„Entwurf der Antwort, aber wir senden sie selbst. " B„Es muss sich für den Benutzer sofort anfühlen. " C„Alles Große erfordert die Zustimmung einer Person. " DKeine Stakeholder-Aussage unterstützt dieses Element.

Antwort überprüfen Überspringen

Screen 5: Present a tradeoff so the stakeholder can act on it, and design a demo that adva

Tradeoffs & GTM Präsentieren Sie einen Tradeoff, damit der Stakeholder darauf handeln kann, und gestalten Sie ein Demo, das das Geschäft vorantreibt Discovery hat Ihnen gesagt, was der Käufer braucht. Die Umwandlung dieser Anforderungen in eine Entscheidung, auf die ein Stakeholder handeln kann, ist die nächste Arbeit. Der Architect hilft dem Stakeholder jetzt, den Tradeoff zu verstehen, die geschäftlichen Konsequenzen zu sehen und einen Weg nach vorne mit Vertrauen zu genehmigen.

Ihre Aufgabe ist nicht, den Tradeoff vor dem Treffen zu lösen. Ihre Aufgabe ist es, Entscheidungen möglich zu machen. Ihre Aufgabe ist es, die Optionen klar genug zu beschreiben, damit der Stakeholder eine informierte Wahl treffen kann. Jede bedeutungsvolle Design-Entscheidung hat einen Tradeoff. Eine Option kann Kosten oder Komplexität reduzieren, aber Latenz, Risiko oder Compliance-Belastung erhöhen. Eine andere kann die Benutzererfahrung verbessern oder besser skalieren, erfordert aber mehr Aufwand im Voraus. Wenn Sie nur die Schlussfolgerung präsentieren, kann die Entscheidung klar aussehen, aber sie ist schwach. Wenn die Kehrseite später auftaucht, kann der Stakeholder das Gefühl haben, eine Empfehlung genehmigt zu haben, ohne zu verstehen, was damit kam. Verwenden Sie also einen einfachen Entscheidungsrahmen:

1Was gewinnen wir? 2Was geben wir auf? 3Was passiert, wenn wir das jetzt wählen, aber es später rückgängig machen müssen? 4In regulierten Umgebungen, was macht das mit unserer Compliance-Position?

Diese dritte Frage ist die, die die meisten Menschen überspringen, und sie ist oft die, die das Treffen verändert. Sie verwandelt die Diskussion von „was ist die bessere technische Antwort? " in „was ist die bessere geschäftliche Wahl? " Technische Präzision ist notwendig, aber nicht ausreichend. In Architektur-Reviews ist die Empfehlung oft technisch korrekt, aber immer noch nicht verständlich für die Person, die sie genehmigen muss. Der Architect kann die Optionen in technischem Vokabular erklären (d. h. Latenz, Logging-Tiefe, Kontextgröße, Abrufmuster, Bereitstellungsroute), aber der Executive stellt eine einfachere Frage: „Was passiert mit dem Geschäft, wenn wir die falsche Wahl treffen? " An diesem Punkt braucht der Raum nicht mehr Details, was er braucht, ist Übersetzung in etwas, das eine Person verstehen kann. Wenn Sie das gut machen, hört der Stakeholder nicht nur Ihre Empfehlung. Sie treffen eine informierte Entscheidung, die sie später verteidigen können.

Rahmen Sie die Entscheidung als Paket, nicht als Urteil Präsentieren Sie die Entscheidung als Paket, auf das der Stakeholder handeln kann: die Optionen, die Sie in Betracht gezogen haben, die Kriterien, die Sie gewogen haben, Ihre Empfehlung und die Risiken, die bleiben. Der Stakeholder übernimmt nicht Ihre Architektur; sie akzeptieren eine Entscheidung, die sie ihrer eigenen Führung verteidigen müssen.

Beschreibung ist die Kompetenz, die das Paket landen lässt Beschreibung ist eine der vier AI Fluency-Kompetenzen: effektive Kommunikation mit AI. Auf die Stakeholder-Seite der Arbeit erweitert, bedeutet die gleiche Disziplin, dem Publikum genau das zu sagen, was es braucht, in Begriffen, die es verstehen kann. Angewendet auf Stakeholder-Kommunikation bedeutet Beschreibung, das Verhalten des Systems, seine Grenzen und die Aufsicht darum in den Zielterm des Stakeholders zu rahmen. Der Rahmen sollte ihrer AI-Vertrautheit entsprechen, ohne Genauigkeit zu opfern. Drei Regeln gelten in der Praxis: Führen Sie mit dem geschäftlichen Ergebnis statt mit der Architektur; rahmen Sie Einschränkungen ehrlich, da ein Sicherheits-Stakeholder einem System vertraut, dessen Grenzen klar angegeben sind; und antizipieren Sie die Peer-Proof-Anforderung, da der Stakeholder die Wahl anderen rechtfertigen muss und das Gespräch mit dieser Rechtfertigung verlassen sollte.

Verwenden Sie die Tradeoff-Übersetzungskarte, um von Architektur-Framing zu Stakeholder-Entscheidungssprache zu wechseln.

Architektonische EntscheidungWas Sie gewinnenWas Sie aufgebenWas eine falsche, rückgängig gemachte Wahl kostet

Größeres Kontextfenster pro Anruf versus Abruf über ChunksEinfacheres anfängliches Design, das vollständige Dokument in Sicht, und weniger bewegliche Teile zum frühen Verwalten. Höhere Pro-Anruf-Kosten und langsamere Antwortzeiten, wenn das Produktionsvolumen wächst. Prompt Caching kann einen erheblichen Teil der Eingabekosten für statische Inhalte wie Richtliniendokumente, die über Anrufe im Kontext gehalten werden, zurückgewinnen, daher evaluieren Sie Caching, bevor Sie Pro-Anruf-Kosten als fest behandeln. Umgestaltung der Architektur nach Kostensteigerungen in der Produktion, plus der Glaubwürdigkeitsverlust, wenn Sie eine vermeidbare Kostenüberraschung erklären. Logging-Details gegen niedrigere Latenz handelnSchnellere wahrgenommene Antwort und eine glattere Endbenutzererfahrung. Reduzierte Sichtbarkeit in das, was in jeder Interaktion passiert ist. In einer regulierten Workload ein potenzieller Compliance-Lücke, der Abhilfe erfordert. Einzelne Lieferroute versus Multi-PlatformNiedrigere Build-Komplexität und ein konsistentes Authentifizierungs- und Logging-Profil. Weniger Flexibilität, um unterschiedliche regionale, Compliance- oder Beschaffungsanforderungen zu erfüllen. Ein verzögerter oder blockierter Produktions-Cutover, wenn die gewählte Route eine spät auftauchende Datenresidenz- oder Bereitstellungsanforderung nicht erfüllen kann.

Die Karte existiert, um dem Stakeholder zu helfen, die Konsequenz seiner Wahl klar genug zu sehen, um zu entscheiden.

Demo-Design ist eine eigenständige Fähigkeit, und ein schwaches Demo kann das zunichte machen, was Discovery verdient hat Stellen Sie sich das Käufer-Treffen vor, bei dem Discovery gut gelaufen ist. Das Team stimmte dem Problem, dem Use Case und dem Wert auf dem Spiel zu. Dann beginnt das Demo. Anstatt die Welt des Käufers zu zeigen, zeigt es einen polierten, aber generischen Satz von Features. Die Reaktion ist normalerweise höflich, dass das Demo interessant war, aber nicht ganz das, was sie sich vorgestellt haben.

Ein schwaches Demo kann den Käufer in Frage stellen lassen, ob das Team das Kernproblem verstanden hat. Dies geschieht, wenn Teams zwei verschiedene Jobs verwechseln. Ein Capabilities-Demo antwortet: „Was kann dieses System tun? " Ein szenariospezifisches Demo antwortet: „Was macht dieses System mit meinem Problem, meinem Workflow und meinen Einschränkungen? " Das erste schafft Interesse; nur das zweite schafft Vertrauen. Das Gestalten von Beweis, dass die Lösung zum Kontext des Käufers passt, ist Teil der Aufgabe des Demos. Ein gut gestaltetes Demo treibt die Gelegenheit voran, während ein schwaches die Vertrauensfähigkeit zunichte machen kann, die Discovery aufgebaut hat.

Partner TrackNicht vom Architect-Examen getestet Bevor Sie Bildschirme bauen, treffen Sie vier Design-Entscheidungen. Diese Entscheidungen bestimmen, ob sich das Demo maßgeschneidert und glaubwürdig oder generisch und leicht zu verwerfen anfühlt.

Design-EntscheidungWas der Architect entscheidetWarum es das Ergebnis bestimmt

SzenarioauswahlWählen Sie einen Workflow, den der Käufer sofort aus seinen eigenen Operationen erkennen wird, einschließlich vertrauter Datenformen, Genehmigungsschritte und Grenzfälle. Vermeiden Sie eine generische Dokumentaufgabe oder einen abstrakten Abfrage-Flow. Käufer vertrauen dem, was sich vertraut anfühlt. Wenn sie ihr eigenes Vokabular und Fehlerpunkte auf dem Bildschirm sehen, fühlt sich das Demo relevant und glaubwürdig an. Erkennung ist oft überzeugender als eine polierte, aber generische Feature-Tour. Limit-PlatzierungEntscheiden Sie im Voraus, welche ein oder zwei Einschränkungen das Demo identifizieren wird, und rahmen Sie sie als beabsichtigte Umfang-Grenzen. Geben Sie an, was das System nicht tut und warum. Wenn ein Käufer eine Einschränkung in der Mitte des Demos entdeckt, sinkt das Vertrauen. Wenn Sie die Einschränkung früh benennen, liest es sich als Disziplin und Ehrlichkeit. In regulierten Einstellungen ist die vorausgehende Offenlegung von Grenzen oft ein positives Signal. Zusammenarbeit des Verkaufsteams Gestalten Sie die Demo-Erzählung mit dem Verkaufsteam, bevor Sie etwas bauen. Sie wissen, was der Käufer in früheren Gesprächen aufgebracht hat, und Sie wissen, was das System realistisch unter Produktionsbedingungen zeigen kann. Ein Demo, das ohne Verkaufsteam gebaut wurde, kann Fragen beantworten, die der Käufer nie gestellt hat. Ein Demo, das ohne den Architect gebaut wurde, kann zu viel versprechen. Auf jeden Fall verliert das Demo Glaubwürdigkeit und verlangsamt die Gelegenheit. Datenvorbereitung Verwenden Sie Informationen, die den Daten des Käufers in Struktur und Volumen ähneln. Für regulierte Käufer verwenden Sie anonymisierte Daten, die immer noch die gleichen strukturellen Einschränkungen wie die echte Umgebung widerspiegeln. Käufer beurteilen das Demo nach den Daten darin. Realistische Feldnamen und Datenmuster machen das Szenario real. Wenn die Daten wie ihre aussehen, argumentiert das Demo für sich selbst.

Limit-Platzierung verdient bewusste Aufmerksamkeit Von den vier Demo-Design-Entscheidungen ist Limit-Platzierung die, die am häufigsten gegen Instinkt läuft. In der Praxis kann das Benennen einer Schwäche sich riskant anfühlen, daher ist die Versuchung, sie zu verstecken oder zu erweichen. Dies schlägt normalerweise fehl. Stellen Sie sich den Moment vor, in dem der Käufer fragt: „Was behandelt das nicht gut? " Wenn die Antwort vage ist, sinkt das Vertrauen. Wenn die Antwort klar und begrenzt ist, sieht der Käufer Disziplin statt Defensivität.

Deshalb sollten Sie im Voraus entscheiden, welche ein oder zwei Einschränkungen Sie benennen und wie Sie sie rahmen. Zeigen Sie, dass die Grenze absichtlich ist, dass dies das ist, wofür die Lösung gebaut ist, und das ist das, wofür sie nicht gebaut ist. Dies ist noch wichtiger in regulierten Branchen wie Gesundheitswesen, Finanzdienstleistungen und dem öffentlichen Sektor. In diesen Einstellungen signalisiert eine klare Grenze oft Strenge, während eine Ablenkung Risiko signalisiert. Eine einfache Möglichkeit, sich vorzubereiten, ist zu fragen:

Was ist die Grenze? Warum existiert sie? Was passiert, wenn der Use Case über sie hinausgehen muss?

Erfolgreiche gemeinsame Scoping beginnt, bevor die Sitzung beginnt Partner TrackNicht vom Architect-Examen getestet Diese gleiche Disziplin trägt direkt in die gemeinsame Scoping mit dem Applied AI Team. Eine gute Scoping-Sitzung ist kein Ort, um die Grundlagen zum ersten Mal herauszufinden. Es ist ein Ort, um Entscheidungen zu verfeinern, Annahmen zu testen und die Fragen zu lösen, die Spezialist-Input benötigen.

Wenn das Demo beweist, dass Sie das Problem des Käufers verstehen, beweist die Scoping-Sitzung, dass Sie bereit sind, eine glaubwürdige Lösung darum zu gestalten. Das funktioniert nur, wenn Sie mit drei Dingen vorbereitet ankommen:

Eine dokumentierte Ansicht der Anforderungen und Einschränkungen des Kunden. Dies erfasst, was aus Discovery kam: der Use Case, Workflow, Stakeholder, Datenbedingungen, technische Umgebung, Compliance-Bedenken und Erfolgskriterien. Dies gibt der Sitzung einen gemeinsamen Ausgangspunkt. Ein vorgeschlagenes Muster oder kleiner Satz von Kandidatenmustern, mit Tradeoffs bereits benannt. Gehen Sie mit einem Standpunkt hinein. Zeigen Sie die wahrscheinlichen Optionen, was jede Ihnen gibt, was jede aufgibt, und wo die Risiken sitzen. Eine kurze Liste offener Fragen, die das Applied AI Team am besten beantworten kann. Dies sind die Fragen, die es wert sind, die Sitzung zu verbringen: Modellverhalten, Architektur-Implikationen, Skalierungs-Einschränkungen, Evaluierungs-Ansatz, Sicherheitsüberlegungen oder Muster-Fit.

Im Demo verdienen Sie Vertrauen, indem Sie Einschränkungen klar identifizieren. In gemeinsamer Scoping behalten Sie dieses Vertrauen, indem Sie eine strukturierte Ansicht des Problems, der Optionen und der unbeantworteten Fragen bringen.

Einwände fallen in verschiedene Kategorien, und jede erfordert eine andere Antwort Technische Einwände in einem Verkaufszyklus fallen normalerweise in drei Kategorien. Capability-Einwände fragen, ob das System die Sache überhaupt tun kann. Governance- und Compliance-Einwände fragen, ob die Bereitstellung vertraut, kontrolliert und nachgewiesen werden kann, auf eine Weise, die der Käufer verteidigen kann. Design-Choice-Einwände fragen, warum Sie diese Wahl statt einer anderen gemacht haben. Diese erfordern mehr als nur Rechtfertigung. Sie müssen den Tradeoff erklären, den die Wahl macht, und was die Alternative gekostet hätte, indem Sie die gleiche Übersetzungsstruktur verwenden, die Sie bei der Präsentation des Tradeoffs zum ersten Mal verwendet haben.

Partner TrackNicht vom Architect-Examen getestet Die Go-to-Market-Engagement-Karte sollte Demo-Design als verfolgten Workstream behandeln. Deshalb enthält sie eine Demo-Design-Spalte mit Szenario, identifizierten Einschränkungen, bestätigter Datenquelle und Verkaufsteam-Genehmigung als explizite Liefergegenstände. Dies ist am wichtigsten, wenn ein Partner parallele Gelegenheiten läuft oder wenn Architects mid-cycle übergeben, da Kontinuität entscheidend davon abhängt, was dokumentiert ist.

Kosten · Komplexität · Risiko

Kosten: Das Vorbereiten einer Tradeoff-Präsentation und eines szenariospezifischen Demos erfordert echte Architect-Zeit, aber es ist weit weniger teuer als eine stagnierte Gelegenheit oder eine Genehmigung, die ein Stakeholder später zurückzieht. Komplexität: Drei unterschiedliche Fähigkeiten liegen unter dieser Arbeit, und zwei davon laufen oft gegen die Instinkte: Umkehrungskosten zu benennen und Grenzen klar zu platzieren. Beide erfordern bewusste Übung, um sich zu verbessern. Risiko: Das kostspielige Versagen ist falsche Ausrichtung. Wenn eine Entscheidung im Raum genehmigt aussieht, aber die Umkehrungskosten nie explizit gemacht wurden, und die Konsequenz taucht später auf.

Screen 6: The approval that was not an informed choice

Watch OutTradeoffs & GTM5 min Die Genehmigung, die keine informierte Wahl war

SetupEin Stakeholder, der am Ende einer Tradeoff-Präsentation ja sagt, scheint den Tradeoff verstanden zu haben. Die Präsentation war vollständig und technisch genau, und der Raum fühlte sich ausgerichtet. Dieses Gefühl ist die Falle.

Ein rekonstruiertes Pre-Production-Review aus der Perspektive des CTO Der Architect präsentierte einen Kontext-Strategie-Tradeoff in technischen Begriffen. Der CTO stellte eine Frage zu Kosten, der Architect beantwortete sie genau, und der CTO genehmigte. Sechs Wochen später erschien die höhere Pro-Anruf-Kosten auf der Produktionsrechnung. Dies ist der Austausch, und dann die Notiz, die der CTO schrieb, als die Rechnung empfangen wurde. Es zeigt, wo die Präsentation die falsche Version der Frage beantwortete.

Rekonstruierter Austausch + Nachverfolgung

Architect: „Wir empfehlen das größere Kontextfenster, damit das vollständige Richtliniendokument bei jedem Anruf in Sicht bleibt. Es hält das Design einfacher und vermeidet eine Abruf-Schicht. " CTO: „Wie sieht die Kosten pro Anruf aus? " Architect: „Etwa vier Cent pro Interaktion auf der Modell-Ebene, die wir verwenden. Wenn das Richtliniendokument über Anrufe statisch ist, könnte Prompt Caching den Eingabeteil davon erheblich senken. " CTO: „Okay, genehmigt. Lassen Sie es einfach. " [Sechs Wochen später, auf der Produktionsrechnung] CTO's Notiz an das Account-Team: „Ich habe eine Richtung genehmigt, nicht eine Zahl. Niemand hat mir gesagt, dass vier Cent mal unser Anruf-Volumen eine fünfstellige monatliche Linie ist. Wenn das Dokument statisch war, warum haben wir es nicht gecacht? Und wenn wir um volle Kontexte herum bauen würden, musste ich wissen, was das Auflösen davon kosten würde, sobald das System darum herum abhängt. "

Das Problem: Die Umkehrungskosten traten nie in das Gespräch ein Die Präsentation benannte, was das Design gewann, Einfachheit, und sie beantwortete die Pro-Anruf-Kosten wie gefragt. Was sie nie identifizierte, war das dritte Element: Was passiert mit dem Geschäft, wenn diese Wahl das Produktionsvolumen trifft und nach dem Bauen des Systems darum herum rückgängig gemacht werden muss. Der CTO genehmigte eine Pro-Anruf-Zahl, nicht eine monatliche Rechnung, und nicht die Kosten für das Auflösen einer Entscheidung später. Zwei Teile des Tradeoffs wurden klar kommuniziert und verstanden. Der dritte war nicht, und es stellte sich heraus, dass er der tragende war.

Warum das brach: Eine genaue Präsentation kann immer noch die falsche Frage beantworten Ein Stakeholder, der eine Empfehlung ohne Verständnis der Umkehrungskosten genehmigte, hat keine informierte Wahl getroffen. Der CTO hörte eine Pro-Anruf-Zahl und ein Einfachheits-Argument und sagte vernünftigerweise ja. Das Umkehrungskosten-Element war der eine Faktor, der die Entscheidung geändert hätte. Benennen Sie alle drei Elemente jedes Mal und benennen Sie die Umkehrungskosten besonders, wenn das Design sich offensichtlich einfacher anfühlt.

Screen 7: Checkpoint: recommend the option and name the missing element

Tradeoffs & GTM · Checkpoint Checkpoint: Empfehlen Sie die Option und benennen Sie das fehlende Element

Versuchen Sie es jetzt. Lesen Sie die einseitige Stakeholder-Briefing und die drei Optionspräsentationen in einfacher Sprache geschrieben. Eine Option ist technisch genau und umfassend präsentiert. Eine ist technisch genau, aber ihre Präsentation fehlt ein Element. Eine ist für die angegebenen Einschränkungen unangemessen. Empfehlen Sie die Option zum Vorlegen, dann benennen Sie das einzelne fehlende Element aus der Präsentation der zweiten Option.

Briefing Ein mittelgroßer Versicherer möchte Claude verwenden, um Anpassungsantworten auf Versicherungsnehmer-Anfragen zu entwerfen. Der Workflow wird durch staatliche Versicherungsregulierung mit einer Audit-Trail-Verpflichtung abgedeckt. Das Volumen ist hoch und stabil. Der Sponsor kümmert sich um Antwortqualität und um die Aufrechterhaltung eines verteidigbaren Datensatzes jeder automatisierten Interaktion.

OptionPräsentation wie gezeigt

AWorkflow-Muster mit Pro-Interaktions-Logging eingebaut. Gewinne: vollständiger Audit-Trail, Qualitäts-Gate vor dem Versand. Gibt auf: ein kleiner Latenz-Kosten vom Logging-Schritt. Umkehrung: gering, Logging kann ohne Umgestaltung abgestimmt werden. BWorkflow-Muster, das den Logging-Schritt gegen niedrigere Latenz handelt. Gewinne: schnellere Antworten. Gibt auf: Pro-Interaktions-Audit-Detail. CEinziger erweiterter Anruf ohne Logging und ohne menschliches Gate, gewählt für niedrigste Build-Kosten.

Teil 1: Welche Option sollten Sie empfehlen?

AOption A, Logging eingebaut, vollständiger Audit-Trail BOption B, handelt Logging gegen niedrigere Latenz COption C, kein Logging, kein menschliches Gate

Teil 2: Welches einzelne Element fehlt aus der Präsentation von Option B?

AWas Option B gewinnt (schnellere Antworten ist nicht klar genug benannt) BWas Option B aufgibt (Audit-Detail-Verlust ist nicht erklärt) CDie Umkehrungskosten, was es kostet, Logging wiederherzustellen, nachdem das Design von dem Latenz-Gewinn abhängt DDie Compliance-Position, die diese Option schafft

Antwort überprüfen Überspringen

Screen 8: The feedback loop decides which signals reach a stakeholder, and the SLA names w

Feedback Loops Die Feedback-Loop entscheidet, welche Signale einen Stakeholder erreichen, und die SLA benennt, was Sie schulden, wenn eine bricht Produktions-Observability und der Audit-Trail zeichnen auf, was eine Live-Bereitstellung tut. Dieses Thema behandelt das Filtern dieser Signale, das Entscheiden, wann über das Team hinaus eskaliert werden soll, und das Definieren, was die SLA erfordert, wenn die Leistung unter Standard fällt. Das System ist live; es braucht Aufwand, es über die Zeit vertrauenswürdig zu halten. In Lebenszyklus-Begriffen ist die Feedback-Loop die Monitoring-und-Iterations-Phase des Bereitstellungs-Lebenszyklus.

Eine Live-Bereitstellung driftet ohne aktives Monitoring Stellen Sie sich einen Kundenservice-Assistenten vor, der in guter Form gestartet wird. Er antwortet schnell, bleibt in einem Ton, und behandelt die häufigsten Fragen gut. Zuerst sieht alles stabil aus. Aber im Laufe der Zeit ändern sich Nutzungsmuster, neue Prompt-Stile erscheinen, und Kundenprobleme werden komplexer. Einige Antworten verlangsamen sich nur, und einige Antworten beginnen, das Ziel zu verfehlen.

Nichts bricht dramatisch, was das macht, dass Drift schwer zu fangen ist. Die Qualität erodiert allmählich statt auf einmal. Ein Team ohne Feedback-Loop sieht möglicherweise den Rückgang nicht, bis Benutzer ihn bereits fühlen.

Die Feedback-Loop ist eine Entscheidungsebene, die über dem Observability-Stack sitzt Observability gibt Ihnen das Rohmaterial: Latenz, Fehlerraten, Eval-Scores, Nutzungsmuster und andere Signale vom System. Aber ein Signal allein ist noch keine Entscheidung. Ein Spike kann Rauschen sein. Ein anderer kann auf ein echtes Problem hinweisen. Ein dritter kann nur wichtig sein, wenn es weiterhin passiert. Die Feedback-Loop sitzt auf Observability, um fünf Fragen zu beantworten: Signale → Triage → Entscheiden → Handeln → Überprüfen

1Signale: Was zeigt uns das System? 2Triage: Was braucht jetzt Aufmerksamkeit, und was kann warten? 3Entscheiden: Braucht das Problem eine Team-Reparatur, eine Stakeholder-Überprüfung oder keine Aktion? 4Handeln: Welche Korrektur, Guardrail-Update oder Eskalation ist erforderlich? 5Überprüfen: Hat die Antwort funktioniert und muss die Regel geändert werden?

Denken Sie daran wie ein Kontrollraum in einem Bahnhof. Die Sensoren können Ihnen sagen, wo die Züge verspätet sind, aber jemand muss immer noch entscheiden, ob eine Verzögerung gering ist, ob Passagiere informiert werden müssen, und ob der Zeitplan geändert werden muss. Diese Urteilsebene ist das, was das System verwaltbar statt nur messbar macht.

Eine SLA benennt drei Dinge, und die Schwellenwerte kommen von irgendwo Greifbarem. Sobald die Feedback-Loop entscheidet, dass etwas wichtig ist, definiert die SLA, was passiert, wenn es die Linie kreuzt. Eine SLA ist eine Verpflichtung, die drei Dinge klar macht:

1Was messen wir? 2Was zählt als Verstoß? 3Was passiert, wenn ein Verstoß auftritt?

Der Schwellenwert sollte nie willkürlich sein. Er sollte auf etwas Greifbares zurückführen:

1Latenz sollte die Benutzer-Erfahrung-Erwartung widerspiegeln, die früher identifiziert wurde 2Verfügbarkeit sollte widerspiegeln, wie kritisch die Bereitstellung für das Geschäft ist 3Qualität sollte die Eval-Ergebnisse und Akzeptanzkriterien widerspiegeln, die bereits etabliert sind

Diese Rückverfolgbarkeit ist wichtig, weil sie die SLA verteidigbar hält. Wenn die Zahl nicht an eine dieser Quellen gebunden werden kann, ist sie wahrscheinlich nur ein Ziel, das jemand gewählt hat, weil es vernünftig klang. Kosten ist die Erwartung, die nach dem Start am häufigsten bricht. Das Produktionsvolumen läuft routinemäßig ein bis zwei Größenordnungen über dem Pilot, daher wird eine Kosten, die im Proof of Concept trivial aussah, zu einer fünfstelligen monatlichen Linie im Maßstab. Zuvorkommen: Geben Sie dem Stakeholder eine Verbrauchsprognose bei erwartetem Produktionsvolumen, benennen Sie die Ausgaben-Kontroll-Position (Caching, Modell-Tiering, Budget-Alerts), und rahmen Sie die Modell-Tiering-Erzählung, bevor die erste Rechnung statt danach.

Regulierte Bereitstellungen fügen Überprüfungs-Checkpoints hinzu, die nach einem Zeitplan laufen Observability zeichnet auf, was passiert ist; die Feedback-Loop bestimmt, was man dagegen tun soll. In regulierten Bereitstellungen müssen einige Überprüfungen auch dann stattfinden, wenn nichts schiefgelaufen ist. Ein Gesundheits-Workflow mit einer Dokumentations-Verpflichtung kann regelmäßige Output-Audits nach einem definierten Zeitplan erfordern. Eine Datenresidenz-Bereitstellung kann geplante Bestätigung benötigen, dass die Umgebung immer noch Residenz-Regeln erfüllt. Dies sind Design-Zeit-Verpflichtungen statt Aufgaben, die später hinzugefügt werden. Wenn sie nicht früh gebaut werden, werden sie weit teurer, wenn jemand nach Beweis fragt. Bauen Sie eine Governance-Tabelle, die jedes Signal seinem Trigger, der Architect-Antwort und jedem regulatorischen Checkpoint zuordnet. Die Tabelle sollte vor dem Start vorhanden sein. Sie ist der Mechanismus, der Politik in eine Betriebsroutine verwandelt. Produktions-Signal-Governance-Tabelle Signal-TypÜberprüfungs-TriggerArchitect-AktionRegulierter-Industrie-Checkpoint

Output-Qualität (Eval-Score)Score kreuzt den Schwellenwert aus der Eval-Suite. Diagnostizieren Sie, ob die Ursache Prompt, Daten oder Modell-Drift ist, dann entscheiden Sie zu iterieren versus neu zu architekturieren. Regelmäßiger Output-Audit gegen den Dokumentations-Standard, nach einem etablierten Zeitplan, unabhängig vom Score. Latenz p95Kreuzt das Budget, das aus Benutzer-Erfahrungs-Anforderungen gesetzt wurde. Untersuchen Sie den Engpass, dann stimmen Sie ab oder eskalieren Sie zu einer Stakeholder-Überprüfung, wenn das Budget selbst falsch ist. Normalerweise keine, es sei denn, Latenz verbirgt eine Logging- oder Rückverfolgbarkeits-Lücke. Kosten pro InteraktionKreuzt die Ausgaben-Hülle, die in Discovery vereinbart wurde. Identifizieren Sie den Treiber, dann bringen Sie einen Tradeoff zum Stakeholder, wenn die Ausgaben-Hülle überprüft werden muss. Normalerweise keine, es sei denn, Ausgaben-Kontrollen sind Teil einer regulierten Betriebseinschränkung. Datenresidenz-KonfigurationGeplante Bestätigung. Bestätigen und zeichnen Sie die Residenz-Position auf und kennzeichnen Sie jeden Drift sofort. Residenz-Bestätigung nach dem etablierten Zeitplan.

Kosten · Komplexität · Risiko

Kosten: Die Loop schafft einen laufenden Architect-Aufwand. Beachten Sie, dass dies billiger ist als den Rückgang in einer vierteljährlichen Überprüfung zu entdecken, nachdem jedes Dashboard gut aussah. Komplexität: Der schwierigste Teil ist das Entscheiden, welche Signale Aufmerksamkeit verdienen, und welche Rauschen sind, weil Observability-Tooling diese Urteilsfähigkeit nicht für Sie treffen kann. Risiko: Der größte Fehlermodus ist ein Compliance-Checkpoint, der nie an einen Trigger verdrahtet wurde, was einen dokumentierten-Standard-Verstoß Wochen lang laufen lässt, bevor eine Routine-Überprüfung ihn fängt.

Screen 9: The observability stack that replaced the feedback loop

Watch OutFeedback Loops5 min Der Observability-Stack, der die Feedback-Loop ersetzte

SetupEin Architect, der einen rigorosen Observability-Stack gebaut hat, hat die schwierigere technische Arbeit geleistet. Die Dashboards sind live, die Alerts sind konfiguriert, und die Daten fließen. Es ist einfach und vernünftig, zu dem Schluss zu kommen, dass Stakeholder-Feedback abgedeckt ist.

Eine rekonstruierte Spur: 90 Tage Alert-Log gegen den Stakeholder-Überprüfungs-Kalender Der Auszug unten platziert ein Bereitstellungs-Alert-Log neben seinen Stakeholder-Überprüfungs-Kalender über ein 90-Tage-Fenster. Das Alert-Log zeigt einen anhaltenden Drift in der Output-Qualität über Wochen vier bis sieben. Der Überprüfungs-Kalender zeigt keine Überprüfung, die in diesem Fenster stattfand. Eine einzelne Zeile in einer Feedback-Loop-Governance-Tabelle hätte die zwei verbunden. Dies zeigt, wie die Lücke im Datensatz aussieht.

FensterObservability-Stack zeichnete aufStakeholder-Überprüfungs-KalenderWas die Loop hätte tun sollen

Wochen 1-3Eval-Score stabil bei Baseline, mit Latenz und Kosten nominal. Launch-Überprüfung in Woche 1 stattgefunden. Nominal. Keine Eskalation erforderlich. Wochen 4-7Eval-Score driftet Woche für Woche nach unten, mit Fehlerrate flach, daher wird kein harter Alert ausgelöst. Keine Überprüfung geplant oder stattgefunden. Ein Qualitäts-Drift-Trigger hätte bis Woche 5 zu einer Architect-Überprüfung eskalieren sollen, und weiter zu einer Stakeholder-Überprüfung, sobald die Diagnose den Drift bestätigte. Wochen 8-12Score sinkt immer noch, und der Stakeholder berichtet, dass die Ausgabe „in letzter Zeit weniger nützlich" ist. Vierteljährliche Überprüfung taucht es endlich in Woche 12 auf. Nach Design hätte die Loop das sieben Wochen früher gefangen.

Das Problem: Die Signale existierten, aber nichts entschied, dass sie wichtig waren Jede Metrik, die die Bereitstellung brauchte, wurde bereits gesammelt. Der Eval-Score driftete sichtbar seit Woche vier nach unten. Was fehlte, war die Entscheidungsebene: keine Governance-Regel ordnete einen langsamen Qualitäts-Drift einem Überprüfungs-Trigger zu. Der Drift kreuzte nie einen Fehlerrate-Schwellenwert, daher wurde kein Alert ausgelöst. Ein Drift ohne Trigger ist unsichtbar, bis ein Mensch zufällig bemerkt. Der Stack maß das richtige Ding und sagte niemandem, dass es wichtig war.

Warum das brach: Monitoring ist keine Feedback-Loop Ein Dashboard sammelt und zeigt Signale. Eine Feedback-Loop ordnet jedes Signal einem Trigger, einem Eigentümer und einer erforderlichen Aktion zu. Der Observability-Stack sammelte die Signale, aber hatte keine Governance-Regel, die ein Signal einem Trigger oder Eigentümer zuordnete. Bauen Sie die Governance-Tabelle, die jedes Signal einem Trigger, einer Aktion und einem Eigentümer zuordnet. Schließen Sie sowohl die langsamen Drifts als auch die harten Fehler ein.

Screen 10: Checkpoint: triage the production signals

Feedback Loops · Checkpoint Checkpoint: Triage die Produktions-Signale

Versuchen Sie es jetzt. Hier sind neun Signale von einer Produktions-Bereitstellung. Ziehen Sie jedes in den Bucket, wo es gehört: Internes Monitoring, Architect-Überprüfung, Stakeholder-Überprüfung oder Rauschen.

1 · Latenz p99 zuckte 40ms, immer noch im Budget. 2 · Eval-Score drei Wochen laufen nach unten, Trend ist klar. 3 · Geplante Datenresidenz-Bestätigung ist fällig. 4 · Eine malformed Anfrage von einem bekannten schlechten Client. 5 · Kosten pro Interaktion kreuzte den vereinbarten Budget-Schwellenwert. 6 · Ein 2 a. m. Batch-Job protokollierte einen Retry, der dann erfolgreich war. 7 · Vierteljährlicher Output-Audit gegen den Dokumentations-Standard ist fällig. 8 · Token-Nutzung stieg mit einem bekannten saisonalen Traffic-Bump. 9 · Eine neue Prompt-Vorlage wurde ausgeliefert, und Fehlerrate ist flach.

Internes Monitoring

Architect-Überprüfung

Stakeholder-Überprüfung

Rauschen

Platzierungen überprüfen Überspringen

Screen 11: Documentation that survives your absence serves the handoff recipient, the audit

Documentation Dokumentation, die Ihre Abwesenheit übersteht, dient dem Übergabe-Empfänger, dem Auditor und dem zurückkehrenden Architect Die Feedback-Loop hält das System gesund, während Sie es laufen. Dokumentation ist das, was es funktionieren lässt, nachdem Sie weg sind. Dieses Thema verwandelt das vollständige Design in Dokumentation, die eine Übergabe überlebt und einen Compliance-Reviewer befriedigt. Entweder trägt das Design seine eigene Begründung in diese Übergabe, oder diese Begründung verschwindet, sobald Sie gehen. In Lebenszyklus-Begriffen ist Dokumentation die Übergabephase des Bereitstellungs-Lebenszyklus.

Ein Dokument dient drei Lesern, und das Dienen nur eines von ihnen macht es unvollständig Architektur-Dokumentation dient drei Lesern. Der erbende Ingenieur übernimmt eine Bereitstellung, an der sie nicht beteiligt waren. Der Auditor kommt später an und sucht nach Beweis, dass eine spezifische Kontrolle live und berücksichtigt ist. Der zurückkehrende Architect, oft Sie, kommt Monate später ohne Erinnerung an die Design-Sitzungen zurück. Ein Dokument, das für einen dieser Leser gebaut wurde und nicht für die anderen, ist unvollständig, auch wenn es detailliert ist.

Für den Übergabe-Empfänger: Die abgelehnten Alternativen sind genauso wichtig wie die getroffenen Entscheidungen Für wer auch immer das System erbt, muss das Dokument die Entscheidungen tragen, die getroffen wurden, die Alternativen, die abgelehnt wurden, und den Grund, warum jede Ablehnung passierte. Ein Design, das ohne seine abgelehnten Alternativen geliefert wurde, kann von jemandem, der nicht im Raum war, nicht verstanden werden. Sie werden die richtige Entscheidung aus dem falschen Grund rückgängig machen oder die falsche Entscheidung verteidigen, weil sie nicht sagen können, welcher Tradeoff sie löste. Die abgelehnten Optionen erklären, warum das Design so geformt ist, wie es ist.

Für den Compliance-Reviewer: Beweis ist wichtiger als Behauptungen Für den Compliance-Reviewer muss das Dokument jede regulatorische Verpflichtung, die technische Kontrolle, die sie erfüllt, den Eigentümer dieser Kontrolle und das Beweis-Artefakt, das demonstriert, dass die Kontrolle operiert, tragen. Dies ist das regulierte Bereitstellungs-Kontroll-Register, das in das lebende Dokument getragen wird, das das Produktionsleben der Bereitstellung regiert. Der Reviewer akzeptiert bloße Behauptungen nicht. Sie benötigen Beweis, was bedeutet, dass eine Aussage, dass eine Kontrolle existiert, nicht allein ausreicht.

Für den zurückkehrenden Architect: Navigierbar ohne eine Briefing Für den Architect, der Monate später zurückkommt, muss das Dokument allein stehen. Entscheidungen sind datiert. Annahmen sind explizit als Annahmen gekennzeichnet, statt als Fakten eingebettet. Offene Elemente haben Eigentümer und Lösungs-Kriterien. Der Test ist praktisch: Nach dem Lesen des Dokuments kann ein kompetenter Architect, der nicht bei den Design-Sitzungen anwesend war, eine sichere Änderung am System vornehmen? Wenn die Antwort nein ist, ist das Dokument nicht vollständig.

Die Dokumentations-Vollständigkeits-Checkliste: Dokumentations-Vollständigkeits-Checkliste FeldWas es erfasstLeser, den es hauptsächlich dient

EntscheidungDie architektonische Wahl, die getroffen wurde, einschließlich des Datums. Alle drei Leser. Abgelehnte AlternativenDie Optionen, die in Betracht gezogen, aber nicht gewählt wurden. Übergabe-Empfänger. Benannter TradeoffDer Tradeoff, den die Entscheidung löste, ausgedrückt in Begriffen von Gewinnen, Kosten und Umkehr-Implikationen. Übergabe-Empfänger und zurückkehrender Architect. EigentümerDie Person oder das Team, das für die Entscheidung oder die Kontrolle verantwortlich ist, die vorwärts geht. Compliance-Reviewer und Übergabe-Empfänger. Beweis-ArtefaktDas Artefakt, das demonstriert, dass eine Kontrolle tatsächlich operiert. Compliance-Reviewer. Audit-bereiter StatusOb der verfügbare Beweis aktuell und ausreichend für die Überprüfung ist. Compliance-Reviewer.

Kosten · Komplexität · Risiko

Kosten: Das Schreiben der Begründung und des Beweises bei Design kostet Zeit. Das Rekonstruieren später aus E-Mail-Threads, oder das Versäumnis, kostet eine falsche Umkehrung in der Produktion. Komplexität: Die Disziplin ist das Aufschreiben von Warum, nicht nur Was, und das Kennzeichnen von Annahmen als Annahmen, was einfach zu überspringen ist, wenn die Begründung sich für die Person, die sie lebte, offensichtlich anfühlt. Risiko: Das kostspielige Versagen ist ein Nachfolger, der eine tragende Entscheidung rückgängig macht, weil die Begründung nie dokumentiert wurde, was eine Einschränkungs-Verletzung wieder einführt, die das ursprüngliche Design gelöst hatte.

Screen 12: The design rationale that lived in the Architect's head

Watch OutDocumentation5 min Die Design-Begründung, die im Kopf des Architects lebte

SetupEin Architect, der bei jeder Design-Entscheidung anwesend war, hält die Begründung für alle. Das Aufschreiben fühlt sich redundant an, wenn Sie es bereits wissen, und es gibt immer etwas Dringenderes als Dokumentation. Das ist genau, wie die Begründung mit der Person geht.

Eine Postmortem: Eine Finanzdienstleistungs-Übergabe, bei der die Begründung nie die Seite erreichte In diesem Fall verließ der ursprüngliche Architect ein mittelgroßes Finanzdienstleistungs-Engagement 12 Wochen nach dem Start. Ihr Ersatz erbte ein gründliches Architektur-Diagramm ohne Begründung. Ein Leistungs-Problem veranlasste einen Vorschlag, Kontext-Strategien zu wechseln, der Ersatz machte den Wechsel, und er führte ein Datenbehandlungs-Muster wieder ein, das die Datenresidenz-Einschränkung der Bereitstellung verletzt. Die Postmortem verfolgt das Versagen zu der einen Zeile, die fehlte. Dies ist, wie das im Datensatz aussieht.

PhaseWas passierteWas das Dokument trug

StartDer ursprüngliche Architect gestaltet eine Kontext-Strategie speziell, um regulierte Daten in-Region zu halten. Ein Architektur-Diagramm, das das endgültige Design zeigt. ÜbergabeDer ursprüngliche Architect geht in Woche 12. Keine Design-Sitzungen werden aufgezeichnet. Das Diagramm, ohne abgelehnte Alternativen und ohne Begründung. ÄnderungDer Ersatz trifft ein Leistungs-Problem und wechselt Kontext-Strategien, um es zu reparieren. Nichts erklärt, warum die ursprüngliche Strategie gewählt wurde. FehlschlagDer Wechsel führt ein Datenbehandlungs-Muster wieder ein, das die Datenresidenz-Regel bricht. Der Grund, warum das ursprüngliche Design dieses Muster vermied, existierte nur im Kopf des abgegangenen Architects.

Was brach: Das Diagramm zeigte das Was und verlor das Warum Der Ersatz war kompetent und handelte vernünftig auf den Informationen, die er hatte. Das Diagramm sagte ihm, was das System war, nicht warum es so war. Die ursprüngliche Kontext-Strategie war eine bewusste Wahl, um eine Residenz-Einschränkung zu erfüllen, und diese Begründung wurde nie als Entscheidung mit einem benannten Tradeoff und einer abgelehnten Alternative geschrieben. Ohne dokumentierte Begründung konnte der Ersatz nicht sagen, dass die Strategie, die er änderte, tragend für Compliance war, daher änderte er die richtige Entscheidung aus einem verständlichen falschen Grund.

Warum das brach: Ein Design ohne seine Begründung ist ein Design, das nicht sicher geändert werden kann Der Vollständigkeits-Test ist, ob ein kompetenter Architect, der nicht im Raum war, nach dem Lesen des Dokuments eine sichere Änderung vornehmen kann. Hier war die Antwort nein, und niemand wusste es, bis die Produktion brach. Zeichnen Sie die Entscheidung, die abgelehnten Alternativen und den Tradeoff, den jede löste, auf, während Sie immer noch die Begründung halten. Denken Sie daran, wenn es nie geschrieben wird, dann geht es mit Ihnen.

Screen 13: Checkpoint: place the documentation artifacts

Documentation · Checkpoint Checkpoint: Platzieren Sie die Dokumentations-Artefakte

Versuchen Sie es jetzt. Die Ebene hat zwei Achsen: eine läuft von „dient dem Übergabe-Empfänger" zu „dient dem Compliance-Reviewer," die andere von „dokumentiert Absicht" zu „dokumentiert Beweis. " Ziehen Sie jede der sechs Artefakt-Karten in die Zone, die ihre primäre Funktion am besten beschreibt.

Architektur-Diagramm Entscheidungs-Log mit Begründung Kontroll-Register mit Beweis-Links Bereitstellungs-Runbook Test-Ergebnis-Zusammenfassung Annahmen-Register

← Übergabe-EmpfängerCompliance-Reviewer →

Übergabe · Absicht

Compliance · Absicht

Übergabe · Beweis

Compliance · Beweis

↑ Dokumentiert Absicht / Dokumentiert Beweis ↓

Platzierungen überprüfen Überspringen

Screen 14: Entry point selection returns with the full production picture, and the outcome

Entry Point & Outcomes Entry-Point-Auswahl kehrt mit dem vollständigen Produktions-Bild zurück, und das Ergebnis-Dokument verwandelt die Arbeit in wiederverwendbare IP Dieses Thema behandelt, wie die Bereitstellung geroutet wurde und was sie produzierte, und verwandelt die Arbeit in Partner-IP, die das Engagement überlebt. Entry-Point-Auswahl kehrt hier mit dem vollständigen Produktions-Kontext zurück.

Die Entry-Point-Frage ändert sich, sobald die Bereitstellung über mehr als eine Plattform live ist Das frühere Modul führte Route-Auswahl als Entry-Point-und-Compliance-Pre-Filter ein: die direkte Anthropic API, AWS Bedrock, GCP Vertex AI und Microsoft Foundry dienen jeweils unterschiedlichen Partner-Beschaffungs-Positionen und regionalen Compliance-Anforderungen. Dieses Thema kehrt zu dieser Entscheidung mit dem vollständigen Produktions-Kontext zurück. Die Frage ist nicht mehr, welche Route den Compliance-Pre-Filter überlebt. Es ist, welche Route über die Latenz-, Kosten- und Compliance-Dimensionen einer Live-Multi-Platform-Bereitstellung am besten funktioniert. Weil Entry-Point-Fähigkeiten sich ändern, wird jede spezifische Behauptung in diesem Abschnitt bei Build-Zeit gegen platform. claude. com/docs und anthropic. com re-verifiziert.

Cross-Platform-Bereitstellungen offenbaren Probleme, die ein Single-Entry-Point nie zeigt Eine Bereitstellung, die mehr als einen Entry-Point umfasst, offenbart eine Klasse von Problemen, die ein Single-Entry-Point-System nicht zeigt. Modell-Identifier-Strings unterscheiden sich über Routen. Feature-Verfügbarkeit kann auf einer Route, die von einem Cloud-Service-Provider vermittelt wird, gegenüber der direkten API verzögert sein. Regionale Verfügbarkeit auf Bedrock und Vertex erfordert explizite Konfiguration, und das Standardieren auf einen globalen Endpoint ist das häufige Muster, das eine Datenresidenz-Anforderung bricht. Ein Architect, der über Entry-Points gestaltet, braucht eine dokumentierte Entry-Point-Verantwortungs-Karte, bevor die erste Integrations-Codezeile geschrieben wird.

Eine Multi-Entry-Point-App muss sagen, welcher Entry-Point welche Aufgabe besitzt, und warum Eine App, die mehrere Claude Entry-Points in einem Workflow integriert, erfordert, dass Sie angeben, welcher Entry-Point welche Aufgabe handhabt und den Grund. Ein Workflow, der die API für Back-End-Inferenz, Claude Code für eine Engineering-Sub-Aufgabe und einen Bedrock-Endpoint für einen regulierten Daten-Pfad verwendet, ist nicht ungewöhnlich im Enterprise-Maßstab. Jede Entry-Point-Grenze ist ein Integrations-Punkt mit seinem eigenen Authentifizierungs-, Logging- und Fehler-Modus-Profil. Die Entry-Point-Verantwortungs-Karte macht diese Grenzen explizit und verhindert das häufigste Multi-Entry-Point-Versagen: ein Entry-Point, der für eine Aufgabe gewählt wurde, nimmt allmählich eine andere auf, weil die Routing-Logik nie dokumentiert wurde.

Das Ergebnis-Dokument macht den Wert über das Team hinaus verständlich Kunden-Ergebnis-Dokumentation ist das Artefakt, das den Wert einer Bereitstellung für Menschen verständlich macht, die nicht beim Build waren. Ein gut strukturiertes Ergebnis-Dokument behandelt sechs Felder: der Use Case und seine Umfang-Grenze, die Metrik vor Bereitstellung, die Metrik nach Bereitstellung, die Kontrolle, die das Ergebnis nachvollziehbar macht, der Eigentümer, der für laufende Messung verantwortlich ist, und das Potenzial, das Muster für andere Kunden oder Engagements wiederzuverwenden. Die technischen Metriken allein machen dieses Dokument nicht. Die Vorher-Nachher-Geschäfts-Ergebnisse und die Wiederverwendungs-Notizen sind das, was es in ein wiederverwendbares Artefakt verwandelt.

Die Bereitstellungs-Entry-Point-Entscheidungs-Matrix: Bereitstellungs-Entry-Point-Entscheidungs-Matrix PlattformLatenz-ProfilCompliance-PostureWann man es wählt

Direkte Anthropic APINeue Features zuerst, mit den wenigsten zusätzlichen Hops. Starke Standardposition, aber bestätigen Sie die Abdeckung durch Konfiguration. Verwenden Sie standardmäßig, es sei denn, eine Beschaffungs- oder Residenz-Regel zeigt anderswo. AWS BedrockRegion-konfigurierbar, mit möglichem Feature-Lag gegenüber direkt. Passt zu AWS-zentrierten Beschaffungs- und Regions-Regeln, wenn explizit konfiguriert. Partner standardisiert auf AWS und braucht In-Region-Ausführung. GCP Vertex AIRegion-konfigurierbar, mit möglichem Feature-Lag gegenüber direkt. Passt zu GCP-zentrierten Beschaffungs- und Regions-Regeln, wenn explizit konfiguriert. Partner standardisiert auf GCP mit einem Vertex-Beschaffungs-Pfad. Microsoft Foundry (Azure) RouteVariiert je nach Hosting-Form: Auf-Azure gehostete Modelle führen Inferenz in der Partner-Azure-Umgebung aus (GA); auf-Anthropic gehostete Modelle routen zu Anthropic-Infrastruktur. Bestätigen Sie Residenz und Abdeckung pro Route, und nehmen Sie nicht vom Plattform-Namen an. Partner-Beschaffungs- oder Residenz-Position erfordert diese spezifische Route.

Partner TrackDie „Muster für andere Kunden oder Engagements wiederverwenden" Framing und das Wiederverwendungs-Potenzial-Feld in der Vorlage unten sind Partner-Track-relevante Inhalte; der Rest des Ergebnis-Dokuments ist auf-Blueprint (6. 4). Die Kunden-Ergebnis-Dokumentations-Vorlage: Kunden-Ergebnis-Dokumentations-Vorlage FeldWas es aufzeichnet

Use Case mit Umfang-GrenzeWas macht die Bereitstellung und was nicht. Metrik vorherDie geschäftliche Metrik, wie sie vor Bereitstellung stand. Metrik nachherDie gleiche Metrik nach Bereitstellung, gemessen mit der gleichen Definition. Kontrolle an PlatzWas macht den Vorher-Nachher-Vergleich nachvollziehbar statt bloß behauptet. Messung-EigentümerWer besitzt laufende Messung, nachdem das Engagement schließt. Wiederverwendungs-PotenzialWie das Muster zu anderen Kunden oder Engagements als IP überträgt.

Kosten · Komplexität · Risiko

Kosten: Die falsche Bereitstellungs-Plattform zu wählen oder ein dünnes Ergebnis-Dokument zu produzieren ist billig zu tun und teuer rückgängig zu machen: Residenz-Nichtübereinstimmung kann Cutover blockieren, und ein Nur-Metriken-Dokument kann Expansion nicht rechtfertigen. Komplexität: Multi-Platform-Routing multipliziert Integrations-Punkte, jeder mit seinem eigenen Auth, Logging und Fehler-Profil. Die Entry-Point-Verantwortungs-Karte ist das einzige, das sie über die Zeit verständlich hält. Risiko: Das kostspielige Versagen ist eine Standard-Konfiguration, die leise Datenresidenz bricht, oder ein Ergebnis-Dokument, das ein Sponsor nicht zu einem CFO nehmen kann, weil es nie Geschäftswert erfasste.

Screen 15: The outcome document that measured the wrong thing

Watch OutEntry Point & Outcomes5 min Das Ergebnis-Dokument, das das falsche Ding maß

SetupEine Bereitstellung, die während eines kontrollierten Rollouts gut funktionierte, hat Daten dahinter. Ein Architect, der das Engagement schließt, hat alles, was sie brauchen, um das Ergebnis-Dokument zu schreiben. Es schnell aus den Metriken zu schreiben, die bereits auf der Hand sind, fühlt sich wie der richtige Schritt an, und das Engagement ist vorbei, bevor jemand bemerkt, was das Dokument nicht beantworten kann.

Eine Anekdote: Das Ergebnis-Dokument, das einen CFO's erste Frage nicht überstehen konnte Ein Architect produzierte ein Kunden-Ergebnis-Dokument mit den Metriken, die am einfachsten aus dem Observability-Stack zu exportieren waren: Request-Volumen, durchschnittliche Latenz und Fehlerrate. Der Kunden-Sponsor nahm es zu ihrem CFO, um eine Expansion zu rechtfertigen. Die erste Frage des CFO war, was die Bereitstellung in geschäftlichen Begriffen gespart oder produziert hatte, und das Dokument konnte nicht antworten. Die zwei Felder, die es nutzbar gemacht hätten, wurden nie gefüllt. Dies ist, wie das ablief.

Der Sponsor öffnete mit dem Dokument wie geschrieben: „Hier ist die Bereitstellung. 40. 000 Anfragen pro Monat, durchschnittliche Latenz unter zwei Sekunden, Fehlerrate unter einem halben Prozent. " Der CFO: „Das sagt mir, dass es läuft. Was hat es für uns getan? Was waren Anspruchs-Verarbeitungszeiten vor dem, und was sind sie jetzt? Weil das die Zahl ist, die mehr Ausgaben rechtfertigt. " Der Sponsor hatte keinen Beweis, auf den er zeigen konnte. Das Dokument maß, dass das System funktionierte, aber es maß nicht, was es änderte.

Was brach: Das Dokument erfasste technische Metriken ohne Geschäfts-Ergebnisse Volumen, Latenz und Fehlerrate sind real und wert zu verfolgen, aber keine von ihnen ist ein Geschäfts-Ergebnis. Die Felder, die das Dokument für das CFO-Gespräch nutzbar gemacht hätten, waren die Vorher-Nachher bei der Geschäfts-Metrik, auf die der Use Case abzielte, Anspruchs-Verarbeitungszeit, und die Kontrolle, die diesen Vergleich nachvollziehbar machte. Ohne die Vorher-Zahl gibt es keine Geschichte. Ohne Kontrolle ist die Nachher-Zahl eine Behauptung. Das Dokument war vollständig als technischer Datensatz und nutzlos als Fall für Expansion.

Warum das brach: Die einfach-zu-exportierenden Metriken sind selten die, die Kosten rechtfertigen Der Observability-Stack sammelt Ihre technischen Metriken kostenlos, aber ohne sie in Daten zu verankern, bleiben Sie mit Dashboards, die informativ aussehen und nichts bedeuten. Aber das Ergebnis-Dokument existiert für einen anderen Leser, den Sponsor, der die Bereitstellung nach oben rechtfertigen muss. Erfassen Sie die Vorher-Metrik am Anfang, benennen Sie die Kontrolle, die den Vergleich nachvollziehbar macht, und fügen Sie die Wiederverwendungs-Notiz hinzu, damit das Dokument die eine Aufgabe tun kann, die ein technisches Dashboard nicht kann.

Screen 16: Checkpoint: pick the platform and the required outcome fields

Entry Point & Outcomes · Checkpoint Checkpoint: Wählen Sie die Plattform und die erforderlichen Ergebnis-Felder

Versuchen Sie es jetzt. Sie erhalten ein Bereitstellungs-Szenario mit drei Variablen: die primäre Cloud-Plattform des Partners, das Regulierungs-Verpflichtungs-Niveau der Bereitstellung und die primäre Leistungs-Einschränkung. Setzen Sie die drei Variablen. Ein Entscheidungs-Modell ordnet die Kombination einer empfohlenen primären Plattform, einer sekundären Plattform, wo eine gilt, und den zwei Ergebnis-Dokument-Feldern zu, die die Kombination wiederverwendbar macht.

Primäre Cloud-Plattform

Wählen Sie... AWS GCP Microsoft Foundry Direkt (keine Cloud)

Regulierungs-Verpflichtungs-Niveau

Wählen Sie... Keine Moderat Streng

Primäre Leistungs-Einschränkung

Wählen Sie... Latenz-empfindlich Kosten-empfindlich Compliance-empfindlich

Ihre Antwort: primäre Plattform

Wählen Sie... AWS Bedrock GCP Vertex AI Microsoft Foundry Direkte Anthropic API

Ihre Antwort: sekundäre Plattform

Wählen Sie... Direkte Anthropic API Keine erforderlich

Ihre Antwort: erforderliche Ergebnis-Felder

Wählen Sie... Kontrolle an Platz (nachvollziehbar) + Messung-Eigentümer Metrik vorher + Metrik nachher Metrik vorher + Metrik nachher + Wiederverwendungs-Potenzial

Empfohlene primäre Plattform: Sekundäre Plattform: Erforderliche Ergebnis-Felder für Wiederverwendung:

Antwort überprüfen Überspringen

Screen 17: Cumulative: architect a regulated multi-platform deployment end to end

Module · Cumulative Kumulativ: Architekturieren Sie eine regulierte Multi-Platform-Bereitstellung von Ende zu Ende

Hier ist ein eigenständiges Briefing. Ein regionales Gesundheitsnetzwerk mit einer Gesundheitsdaten-Schutz-Verpflichtung stellt einen klinischen Dokumentations-Assistenten über zwei Cloud-Plattformen bereit. Der ursprüngliche Architect rotiert ab, und der CFO des Kunden fragt nach Beweis des Geschäftswerts. Arbeiten Sie durch die sieben Entscheidungen in Ordnung. Jede baut auf der letzten auf.

Das Briefing Das Netzwerk läuft über zwei Staaten. Krankenschwestern diktieren Patienteninteraktionen, und der Assistent entwirft die strukturierte klinische Notiz. Ein lizenzierter Kliniker muss jede Notiz autorisieren, bevor sie die Patientenakte erreicht. Die Bereitstellung trägt eine Gesundheitsdaten-Schutz-Verpflichtung mit einer Audit-Trail-Anforderung und einer Datenresidenz-Regel. Der Partner ist auf AWS standardisiert, führt aber einige nicht-regulierte Back-End-Arbeit auf der direkten API aus. Sie sind vier Wochen in die Bereitstellung, und der CFO möchte wissen, was die Bereitstellung wert ist.

Entscheidung 1 · Discovery: Aus dem Briefing, benennen Sie die Must-Prove-Einschränkung, die die Architektur am meisten formt, und schreiben Sie die eine Anforderungs-Zeile, die sie erzwingt. (Wendet das Discovery-Übersetzungs-Framework an. )

Modell-Antwort offenbaren Must-Prove-Einschränkung: Die Gesundheitsdaten-Schutz-Verpflichtung mit Audit-Trail-Anforderung. Anforderungs-Zeile: Die Bereitstellung muss einen nachvollziehbaren Datensatz jeder Modell-generierten Notiz, die von einem lizenzierten Kliniker überprüft wurde, produzieren, nachvollziehbar zur spezifischen Interaktion, weil der Workflow eine formale Beweispflicht unter einem Gesundheitsdaten-Schutz-Regime trägt. Annahme zu dokumentieren: Umfang mit Compliance bestätigt, bevor Design.

Entscheidung 2 · Tradeoff-Framing: Das Netzwerk fragt nach dem niedrigsten-Latenz-Design. Rahmen Sie den Tradeoff zwischen Logging-Trimmen für Latenz und Audit-Trail-Halten in drei Elementen einschließlich der Umkehrungskosten. (Wendet die Tradeoff-Übersetzungs-Karte an. )

Modell-Antwort offenbaren Gewinn (Logging trimmen): Schnellere wahrgenommene Antwort; glatterer Kliniker-Workflow. Aufgeben: Pro-Interaktions-Audit-Detail, das erforderlich ist, um die Gesundheitsdaten-Schutz-Verpflichtung zu erfüllen. Umkehrungskosten: Sobald das System um den Latenz-Gewinn herum gebaut ist, erfordert das Wiederherstellen von Logging eine Umgestaltung der Interaktions-Schicht, und jede Lücken-Periode schafft eine Compliance-Exposition, die offengelegt und behoben werden muss.

Entscheidung 3 · Feedback-Loop: Definieren Sie eine Governance-Tabellen-Zeile, die das erforderliche Output-Audit einem Stakeholder-Überprüfungs-Trigger nach Zeitplan, unabhängig von jeder Metrik, zuordnet. (Wendet die Feedback-Loop-Governance-Tabelle an. )

Modell-Antwort offenbaren Signal: Regelmäßiger Output-Audit gegen Gesundheitsdaten-Schutz-Dokumentations-Standard. Trigger: Kalender-basiert (vierteljährlich, pro regulatorischer Verpflichtung), feuert unabhängig von Eval-Scores oder Fehlerraten. Eigentümer: Compliance-Lead. Aktion: Stakeholder-Überprüfung mit Audit-Datensatz eingereicht an Compliance-Officer.

Entscheidung 4 · Dokumentation: Benennen Sie die eine Entscheidungs-Log-Zeile, deren Abwesenheit Ihrem Nachfolger erlauben würde, eine Compliance-tragende Wahl rückgängig zu machen, und geben Sie die abgelehnte Alternative an, die sie tragen muss. (Wendet die Dokumentations-Vollständigkeits-Checkliste an. )

Modell-Antwort offenbaren Entscheidungs-Zeile: Kontext-Strategie, explizit in-Region-Ausführung über Bedrock, nicht ein globaler Endpoint. Abgelehnte Alternative: Globaler Bedrock-Endpoint für einfachere Konfiguration. Benannter Tradeoff: Einfacheres Setup versus Datenresidenz-Compliance. Warum tragend: Ein Nachfolger, der diese Begründung nicht sieht, wird zu globaler Konfiguration zurückgehen, um ein Leistungs-Problem zu lösen, und wird Residenz brechen, genau wie in der Finanzdienstleistungs-Postmortem.

Entscheidung 5 · Entry-Point-Auswahl: Wählen Sie die primären und sekundären Entry-Points angesichts AWS-Standardisierung, einer strikten Verpflichtung und einer Residenz-Regel, und benennen Sie den Konfigurationsschritt, der das häufige Residenz-Versagen verhindert. (Wendet die Entry-Point-Entscheidungs-Matrix an. )

Modell-Antwort offenbaren Primär: AWS Bedrock, konfiguriert für explizite In-Region-Ausführung (nicht globaler Endpoint), weil der Partner AWS-standardisiert ist und die Residenz-Regel regiert. Bestätigen Sie, dass die spezifische Compliance-Anforderung (HIPAA BAA oder Daten-Souveränität) durch die Bedrock-Konfiguration in Gebrauch erfüllt wird. Sekundär: Direkte API für nicht-regulierte Back-End-Aufgaben, wo neue Features wichtig sind und keine Residenz-Regel gilt. Konfigurationsschritt: Setzen Sie den Region-Parameter explizit im Bedrock-Client, verlassen Sie sich nicht auf Standard-Endpoint-Auflösung.

Entscheidung 6 · Ergebnis-Dokument: Benennen Sie die Vorher-Nachher-Geschäfts-Metrik und die nachvollziehbare Kontrolle, die das Dokument für den CFO's Expansions-Fall nutzbar machen. (Wendet die Kunden-Ergebnis-Dokumentations-Vorlage an. )

Modell-Antwort offenbaren Vorher-Metrik: Durchschnittliche Zeit von Krankenschwester-Diktation zu abgeschlossener, Kliniker-autorisierter klinischer Notiz (Baseline vor Bereitstellung gemessen). Nachher-Metrik: Gleiche Metrik nach Bereitstellung, mit der gleichen Messung-Definition. Nachvollziehbare Kontrolle: Das Kliniker-Autorisierungs-Log, jede Notiz hat einen Zeitstempel-Autorisierungs-Datensatz, der den Kliniker, die Notiz und die Interaktion bindet, was den Vorher-Nachher-Vergleich nachvollziehbar statt behauptet macht.

Entscheidung 7 · Phasen-Übergang: Benennen Sie das Artefakt, das den nächsten Phasen-Übergang für dieses Briefing gatet, und beurteilen Sie, ob dieses Gate erfüllt ist. (Wendet Lebenszyklus-Phasen-Gating an. )

Modell-Antwort offenbaren Gate-Artefakt: Das Ergebnis-Dokument mit Vorher-Nachher-Metrik, nachvollziehbarer Kontrolle und Messung-Eigentümer benannt, dies gatet den Übergang von der aktuellen Bereitstellungs-Phase zur Expansions-Entscheidung, die der CFO gemacht wird. Beurteilung: Das Gate ist nicht noch erfüllt bei Woche vier, die Vorher-Metrik existiert aus Baseline, aber die Nachher-Metrik erfordert genug Post-Launch-Laufzeit zum Messen. Das Ergebnis-Dokument kann nicht abgeschlossen werden, bis ausreichend Daten angesammelt haben. Die korrekte Aktion: Benennen Sie den Messung-Eigentümer, bestätigen Sie, dass die Kontrolle protokolliert, und planen Sie die Ergebnis-Dokument-Fertigstellung bei einem definierten Post-Launch-Meilenstein.

Alle Entscheidungen als abgeschlossen markieren

Screen 18: Glossary

Wrap-up · Reference Glossar Die Schlüsselbegriffe, die über dieses Modul verwendet werden, in alphabetischer Ordnung. Klicken Sie auf einen Begriff, um seine Definition zu erweitern.

KontrollregisterDie Tabelle, die aus der regulierten-Bereitstellungs-Arbeit getragen wird, die jede regulatorische Verpflichtung einer technischen Kontrolle, einem verantwortlichen Eigentümer und einem Beweis-Artefakt, das ein Reviewer inspizieren kann, zuordnet. In Dokumentation wird es der lebende Datensatz, der das Produktionsleben der Bereitstellung regiert. Entscheidungs-Log (mit Begründung)Ein Datensatz jeder architektonischen Wahl, die nicht nur die Entscheidung erfasst, sondern die abgelehnten Alternativen und den Tradeoff, den jede löste, damit ein Nachfolger eine tragende Wahl nicht aus einem verständlichen falschen Grund rückgängig macht. Bereitstellungs-Lebenszyklus Die Phasen, die eine Bereitstellung durchläuft: Discovery → Design → Übergabe → Monitoring → Iteration. Discovery und Tradeoff-Framing führen die Discovery-und-Design-Arbeit durch, die Feedback-Loop ist Monitoring-und-Iteration, Dokumentation ist Übergabe, und Entry-Point-Auswahl mit dem Ergebnis-Dokument schließt die Loop. Die Identifizierung der Phase, zu der eine Entscheidung gehört, ist das, was es Ihnen ermöglicht, zu beurteilen, wann eine Phase bereit ist, zur nächsten zu wechseln. DiscoveryEine strukturierte Elicitation, keine Konversation: ein dreiteiliger Filter von Zuhören, Übersetzen und Aufschreiben, der das geschäftliche Ziel eines Stakeholders in Anforderungen, Annahmen und Einschränkungen verwandelt, gegen die das Design gebaut und gemessen werden kann. Dokumentations-VollständigkeitDer Test, ob ein kompetenter Architect, der nicht im Raum war, nach dem Lesen des Dokuments eine sichere Änderung vornehmen kann. Es erfordert die Entscheidung, die abgelehnten Alternativen, den Tradeoff, den jede löste, den Eigentümer und das Beweis-Artefakt, und Annahmen als Annahmen gekennzeichnet. Entry-Point-Verantwortungs-KarteEin dokumentierter Datensatz, welcher Claude Entry-Point (direkte API, Claude Code, Bedrock, Vertex, Microsoft Foundry) welche Aufgabe besitzt und warum, geschrieben, bevor die Integration beginnt. Es verhindert das häufige Multi-Platform-Versagen eines Entry-Points, der für eine Aufgabe gewählt wurde, nimmt leise eine andere auf, weil das Routing nie dokumentiert wurde. Beweis-ArtefaktKonkreter Beweis, dass eine Kontrolle operiert, ein unterzeichnetes Abkommen, ein Konfigurationsbildschirm, ein Autorisierungs-Datensatz oder ein zurückgegebenes Log-Query. Eine Kontrolle, die in einem Design-Dokument behauptet wird, ohne Artefakt, ist eine Behauptung, nicht Beweis. Feedback-LoopDie Entscheidungsebene, die über dem Observability-Stack sitzt und Signale → Triage → Entscheiden → Handeln → Überprüfen beantwortet, ordnet jedes Signal einem Trigger, einem Eigentümer und einer Aktion zu. Monitoring sammelt Signale; die Feedback-Loop entscheidet, welche das Verhalten ändern und wessen. Governance-TabelleThe pre-launch table that maps each production signal to its review trigger, the Architect's action, and any scheduled regulated checkpoint. It is the mechanism that turns policy into an operating routine and must exist before launch. Gemeinsame ScopingEine Arbeits-Sitzung mit dem Anthropic Applied AI Team, um Entscheidungen zu verfeinern und Spezialist-Fragen zu lösen. Sie kommen mit einer dokumentierten Ansicht von Anforderungen und Einschränkungen, einem vorgeschlagenen Muster oder Kandidaten-Satz mit Tradeoffs benannt, und einer kurzen Liste offener Fragen, die nur das Applied AI Team beantworten kann. Limit-PlatzierungEntscheiden Sie im Voraus, welche ein oder zwei Einschränkungen ein Demo benennen wird, und rahmen Sie sie als beabsichtigte Umfang-Grenzen. Geben Sie an, was das System nicht tut und warum. ErgebnisDokumentDas Artefakt, das den Wert einer Bereitstellung für einen Sponsor verständlich macht, der nicht beim Build war. Sechs Felder: der Use Case mit Umfang-Grenze, die Metrik vorher, die Metrik nachher, die nachvollziehbare Kontrolle, der Messung-Eigentümer und das Wiederverwendungs-Potenzial. Die Vorher-Nachher-Geschäfts-Ergebnis und die Wiederverwendungs-Notizen sind das, was es in wiederverwendbare IP statt einen technischen Datensatz verwandelt. Anforderung vs AnnahmeEine Anforderung führt auf etwas zurück, das der Stakeholder tatsächlich sagte; eine Annahme ist etwas, das das Design für selbstverständlich nimmt, das nie angegeben wurde. Eine ungesourcte Annahme ist die gefährlichste Art, weil niemand sich erinnert, sie entschieden zu haben. UmkehrungskostenWas es kostet, eine Entscheidung rückgängig zu machen, nachdem das System um sie herum gebaut wurde, das dritte Element einer Tradeoff-Präsentation. Es ist das Element, das die meisten Präsentationen auslassen, und das, das das Treffen am häufigsten ändert, indem es „was ist die bessere technische Antwort? " in „was ist die bessere geschäftliche Wahl? " verwandelt. Szenariospezifisches DemoEin Demo, das gegen den eigenen Workflow des Käufers, Datenformen und Einschränkungen gebaut wurde, beantwortet es „was macht das mit meinem Problem? " statt eines Capabilities-Demos „was kann dieses System tun? " Nur das szenariospezifische Demo schafft Vertrauen statt bloßes Interesse. SLA (Service Level Agreement)Eine Verpflichtung, die benennt, was gemessen wird, was als Verstoß zählt, und was passiert, wenn ein Verstoß auftritt. Die Schwellenwerte führen auf eine greifbare Quelle zurück, die Benutzer-Erfahrungs-Erwartung, die Geschäfts-Kritikalität der Bereitstellung oder die Eval-Akzeptanzkriterien, statt auf ein willkürliches Ziel. Tradeoff-FramingEine architektonische Entscheidung in Begriffen präsentieren, auf die ein Stakeholder handeln kann: was die Wahl gewinnt, was sie aufgibt, und was eine Umkehrung kostet, sobald das System um sie herum gebaut ist (plus, in regulierten Einstellungen, was es zur Compliance-Position macht). Das Ziel ist, eine informierte Entscheidung möglich zu machen, nicht einen Urteil zu liefern. Übersetzung (Discovery)Der Kern-Discovery-Schritt: Umwandlung einer Stakeholder-Vorliebe („nahtlos," „schnell," „simpel") in eine testbare, begrenzte Einschränkung, indem Sie fragen, was die Erfahrung brechen würde, was der Benutzer nie bemerken sollte, und was noch wahr sein muss, wenn etwas schiefgeht. ÜbersetzungstabelleThe output of discovery: one row per item capturing the stakeholder statement as said, the implied constraint, the required architectural decision, and any assumption being documented until it is confirmed. One row per item keeps the reasoning intact as work moves from discovery into design.

Screen 19: Recap: five things that hold across everything here

Module · Recap · 3 min Recap: fünf Dinge, die überall hier gelten

Wichtigste Erkenntnisse

01

Strukturierte Discovery Führen Sie Discovery als vierkategorigen Prozess durch, übersetzen Sie jede Vorliebe in eine Einschränkung, und schreiben Sie jedes Element als Anforderungs-Zeile mit ihrer Annahme gekennzeichnet, damit das Design zum Business Case zurückgeht.

02

Kommunikation von Tradeoffs und GTM Präsentieren Sie jeden Tradeoff in drei Elementen einschließlich der Umkehrungskosten. Partner Track[Partner-Track Relevant, nicht vom Architect-Examen getestet] Gestalten Sie das Demo gegen das echte Szenario des Käufers mit Einschränkungen zuerst identifiziert, und gehen Sie in gemeinsame Scoping mit Anforderungen, Kandidaten-Mustern und offenen Fragen in Hand.

03

Feedback-Loops und SLA-Management Bauen Sie die Entscheidungsebene, die Signale Trigger-Aktionen Eigentümern zuordnet, setzen Sie SLA-Schwellenwerte aus ihren echten Quellen, und verdrahten Sie regulierte Checkpoints, um nach Zeitplan zu laufen.

04

Dokumentation für Übergabe und Audit Schreiben Sie die Entscheidung, die abgelehnten Alternativen und den Tradeoff, den jede löste, während Sie immer noch die Begründung halten, und tragen Sie das Kontroll-Register als Beweis vorwärts, den ein Reviewer akzeptiert.

05

Entry-Point-Auswahl und Ergebnisse Wählen Sie die Route auf Latenz, Compliance und Kosten mit einer Entry-Point-Verantwortungs-Karte für Multi-Entry-Point-Designs, und erfassen Sie die Vorher-Metrik, die nachvollziehbare Kontrolle und die Wiederverwendungs-Notiz, damit das Ergebnis-Dokument Expansion rechtfertigt.

Das nächste Modul behandelt Team-Enablement und operative Produktivität: Konfigurieren von Claude-Tooling für ein Team, Aufbauen von Developer-Workflows, die AI-unterstützte Arbeit vertrauenswürdig halten, und Unterstützung der operativen Gesundheit einer Live-Bereitstellung. Sie können jetzt eine Bereitstellung vom ersten Satz eines Stakeholders zu einem Ergebnis-Dokument führen, das das Engagement überlebt. Das nächste Modul behandelt, was passiert, nachdem Sie diese Bereitstellung dem Team übergeben, das sie läuft.

Quellen

Building with the Claude API (Skilljar): stateless request lifecycle, system prompts, evals and graders, tool use, RAG, prompt caching, code execution. Claude 101 (Skilljar): general Claude capabilities and everyday-use framing. (Claude 101 does not carry model-family or context-window teaching per the live catalog; those concepts trace to platform documentation; verify the current model lineup at publish time. ) AI Capabilities and Limitations (Skilljar): the four-properties decision lens carried forward from earlier modules. platform. claude. com/docs: model names, platform capabilities, route availability, residency configuration. Re-verify at build. anthropic. com partner program documentation: partner GTM stage definitions, IP-contribution protocols. Anthropic Applied AI team documentation: joint-scoping engagement structure and preparation inputs.

Screen 20: Congratulations! You have successfully completed this module.

Module Complete · Architect · 2 min Glückwunsch! Sie haben dieses Modul erfolgreich abgeschlossen. Modul 4 behandelt die Stakeholder-Kommunikation, Lebenszyklus-Governance und Go-to-Market-Entscheidungen, die eine funktionierende AI-Bereitstellung in ein verteidigbares, skalierbares Geschäfts-Artefakt verwandeln. Die Bereitstellung ist nur so dauerhaft wie die Dokumentation, Governance und Ergebnis-Beweis, die sie umgeben.

0 von 0 Checkpoints bestanden

M1

Claude Platform & Solution Design Modellauswahl, Prompt-Architektur, Tool-Design und Plattform-Layer-Tradeoffs.

M2

Enterprise Integration & Production Bereitstellungs-Muster, Integrations-Architektur und Produktions-Zuverlässigkeit.

M3

Responsible AI, Safety & Risk Sicherheits-Frameworks, Risiko-Identifikation und Governance-Praktiken.

M4

Stakeholder Engagement, Lifecycle & Go-to-Market Stakeholder-Kommunikation, Lebenszyklus-Management und Go-to-Market-Strategie.

Sie sind hier

M5

Team Enablement and Operational Productivity Team-Tooling-Konfiguration und operative Support-Praktiken.

Nächstes

Modul überprüfen Von vorne beginnen