स्टेकहोल्डर एनगेजमेंट, लाइफसाइकल और जीटीएम

स्क्रीन 1: ओरिएंटेशन: अंत तक आप क्या कर सकेंगे

मॉड्यूल · ओरिएंटेशन ओरिएंटेशन: अंत तक आप क्या कर सकेंगे

पिछले तीन मॉड्यूल ने आपको एक व्यावसायिक समस्या से एक डिज़ाइन किए गए, एकीकृत, शासित Claude डिप्लॉयमेंट तक ले गए। आप एक अनुरोध को तोड़ सकते हैं, एक पैटर्न चुन सकते हैं, एक उपयोग केस को आकार दे सकते हैं, स्वीकृति मानदंड के रूप में evals बना सकते हैं, observability को instrument कर सकते हैं, और एक नियंत्रित कार्यभार के लिए एक auditable नियंत्रण सेट स्थापित कर सकते हैं। जो कुछ भी इसे हल नहीं किया वह काम का वह हिस्सा है जो स्टेकहोल्डर्स के साथ कमरों में होता है: वह खोज बातचीत जहां वास्तविक आवश्यकताएं निर्धारित की जाती हैं, वह अनुमोदन बैठक जहां एक ट्रेडऑफ जीता या हारा जाता है, वह हैंडऑफ जहां आपका डिज़ाइन या तो आपकी अनुपस्थिति में जीवित रहता है या शांति से गिरावट आती है।

यह मॉड्यूल उस काम को कवर करता है। अंत तक आप सक्षम होंगे: 1 एक गैर-तकनीकी स्टेकहोल्डर के साथ एक संरचित खोज बातचीत चलाएं और जो आप सीखते हैं उसे आर्किटेक्चरल आवश्यकताओं और दस्तावेज़ित मान्यताओं में अनुवाद करें, ताकि डिज़ाइन आपकी अपनी तकनीकी प्राथमिकता के बजाय व्यावसायिक केस तक वापस जाए। 2 एक आर्किटेक्चरल ट्रेडऑफ को ऐसे शब्दों में प्रस्तुत करें जो एक व्यावसायिक स्टेकहोल्डर कार्य कर सके, प्रत्येक विकल्प को एक लागत, एक जोखिम, और एक उलटफेर के साथ जोड़ी जाए, ताकि कार्यकारी और खरीद समीक्षाएं एक निर्णय तक पहुंचें, न कि रुकें। 3 डिप्लॉयमेंट लाइफसाइकल में एक स्टेकहोल्डर फीडबैक लूप बनाएं और संचालित करें, यह नाम दें कि क्या समीक्षा को ट्रिगर करता है, एक SLA उल्लंघन क्या आवश्यक है, और कब पुनरावृत्ति करें बनाम पुनः-आर्किटेक्ट करें, शासन चेकपॉइंट्स को एक ही लूप में बनाया गया है। 4 ⟦P0⟧ Partner-Track Relevant, Architect परीक्षा द्वारा परीक्षण नहीं किया गया; partner-track शिक्षार्थियों के लिए बनाए रखा गया] एक partner go-to-market गति में आर्किटेक्ट की भूमिका का नेतृत्व करें, खोज, एक परिदृश्य-आधारित डेमो, तकनीकी आपत्ति हैंडलिंग, और Anthropic Applied AI टीम के साथ संयुक्त scoping के माध्यम से, ताकि एक enterprise अवसर केवल आप जवाब दे सकते हैं ऐसे प्रश्नों पर रुके नहीं। 5 एक multi-platform production system के लिए डिप्लॉयमेंट entry point और cross-platform strategy चुनें, direct API, Bedrock, Vertex, और third-party routes की तुलना latency, compliance, और cost पर करें, और फिर एक outcome document तैयार करें जो मूल्य को एक गैर-तकनीकी प्रायोजक के लिए स्पष्ट करता है और partner IP के रूप में पुन: प्रयोग करने योग्य है। निम्नलिखित अनुभागों में काम मैप किया गया है:

Discovery वह जगह है जहां आप एक स्टेकहोल्डर की प्राथमिकता को एक दस्तावेज़ित बाधा में बदलते हैं जिसके विरुद्ध आर्किटेक्चर डिज़ाइन किया जा सकता है। यह कदम अनुवाद है: एक प्राथमिकता संकेत देती है कि अधिक प्रश्नों की आवश्यकता है, न कि सीधी आवश्यकता के रूप में कार्य करना। एक उपयोगी आवश्यकता परीक्षण योग्य और सीमाबद्ध है। महंगी विफलता एक खोज कॉल है जो अनुवाद पूरा होने से पहले एक डिज़ाइन स्केच में समाप्त होती है। प्रशंसनीय स्केच वह है जो इसे खतरनाक बनाता है: एक स्टेकहोल्डर जो एक आत्मविश्वासी आर्किटेक्चर देखता है, वह मानता है कि प्रश्नों का उत्तर दिया गया है।

Tradeoff framing और go to market वह जगह है जहां आप एक आर्किटेक्चरल निर्णय को ऐसे शब्दों में प्रस्तुत करते हैं जिन पर एक स्टेकहोल्डर कार्य कर सकता है, और जहां आप टीम की अपनी क्षमताओं के बजाय खरीदार के वास्तविक परिदृश्य के विरुद्ध एक डेमो डिज़ाइन करते हैं। तीन तत्व हर ट्रेडऑफ प्रस्तुति में होने चाहिए: विकल्प क्या हासिल करता है, यह क्या छोड़ता है, और एक बार जब सिस्टम इसके चारों ओर बनाया जाता है तो उलटफेर की लागत क्या है। तीसरा तत्व वह है जो बैठक को बदलता है, और यह वह है जो अधिकांश प्रस्तुतियों में गायब है।

Feedback loop वह जगह है जहां आप निर्णय परत बनाते हैं जो observability stack के ऊपर बैठती है और यह निर्धारित करती है कि कौन से संकेत व्यवहार को बदलते हैं और किसके। एक feedback loop एक शासन तालिका है जो प्रत्येक संकेत को एक ट्रिगर, एक मालिक, और एक कार्रवाई से मैप करती है। नियंत्रित डिप्लॉयमेंट में, कुछ समीक्षाएं एक threshold के बजाय एक शेड्यूल पर फायर होती हैं। उन शासन पंक्तियों को लॉन्च से पहले जगह में होना चाहिए। यदि कोई परिभाषित ट्रिगर नहीं है, तो एक compliance checkpoint तब तक सतह पर नहीं आएगा जब तक कोई समीक्षक रिकॉर्ड की तलाश में न आए।

Documentation for handoff और audit वह जगह है जहां आप न केवल किए गए निर्णयों को रिकॉर्ड करते हैं बल्कि अस्वीकार किए गए विकल्पों और प्रत्येक को हल करने वाले ट्रेडऑफ को भी रिकॉर्ड करते हैं। पूर्णता परीक्षण यह है कि क्या एक सक्षम आर्किटेक्ट जो कमरे में नहीं था, दस्तावेज़ को पढ़ने के बाद सिस्टम में एक सुरक्षित परिवर्तन कर सकता है। एक आरेख यह दिखाता है कि सिस्टम क्या है। निर्णयों के लिए तर्क के बिना, आरेख उत्तराधिकारी को यह नहीं बता सकता कि कौन से विकल्प load bearing हैं और कौन से केवल प्राथमिकताएं हैं। जिस क्षण आप engagement छोड़ते हैं, वह क्षण है जब वह तर्क चला जाता है यदि यह कभी दस्तावेज़ित नहीं था।

Entry point selection और outcome document वह जगह है जहां आप एक live production system के लिए सही डिप्लॉयमेंट route की पुष्टि करते हैं और डिप्लॉयमेंट के परिणामों को एक artifact में बदलते हैं जो engagement से बचता है। Outcome document एक पाठक के लिए व्यावसायिक केस बनाता है जो build का हिस्सा नहीं था। Volume, latency, और error rate एक प्रायोजक को बताते हैं कि सिस्टम चलता है। उपयोग केस द्वारा लक्षित व्यावसायिक मीट्रिक पर एक before-and-after, एक auditable control द्वारा समर्थित, एक CFO को बताता है कि इसे विस्तारित करने के लिए क्या मूल्य है।

ये पाँच विषय स्वतंत्र नहीं हैं, वास्तव में, प्रत्येक अंतिम से विस्तारित होता है। Discovery से constraint set वह है जिसे ट्रेडऑफ प्रस्तुति बचा रही है। Feedback loop governance table register में कैप्चर किए गए compliance controls को current रखता है जैसे-जैसे डिप्लॉयमेंट चलता है। Documentation rationale register में निहित निर्णयों को एक उत्तराधिकारी द्वारा चुप्पी से उलट दिए जाने से रोकता है। Outcome document इसके ऊपर की हर परत से खींचता है ताकि मूल्य को एक पाठक के लिए समझदारी से समझाया जा सके जिसने कभी काम नहीं देखा। अंत में cumulative कार्य आपको एक नियंत्रित multi-platform डिप्लॉयमेंट को एक स्टेकहोल्डर के पहले वाक्य से एक outcome document तक ले जाता है जो विस्तार को न्यायसंगत ठहराता है। वास्तव में, यह बिल्कुल वही है जो यह मॉड्यूल आपको हैंडऑफ से पहले करने के लिए सुसज्जित करता है।

इन पाँच विषयों में project lifecycle ही चलता है: discovery → design → handoff → monitoring → iteration। Discovery और tradeoff framing discovery-and-design काम करते हैं; feedback loop monitoring-and-iteration चरण है; documentation handoff चरण है; और entry-point selection outcome document के साथ लूप को बंद करता है। यह पहचानना कि एक निर्णय किस चरण से संबंधित है, आपको यह आंकने देता है कि एक चरण अगले चरण में कब जाने के लिए तैयार है।

शैक्षणिक सामग्री के लिए अस्वीकरण / नोटिस

हमने Claude के साथ वास्तविक काम करने में आपकी मदद करने के लिए यह Architect course Module 4: Stakeholder Engagement, Lifecycle, and Go-to-Market बनाया। इसे शैक्षणिक सामग्री के रूप में मानें। यह कानूनी, वित्तीय, या अन्य व्यावसायिक सलाह का गठन नहीं करता है, इसलिए जो आप सीखते हैं उसे अपनी स्थिति के अनुसार अनुकूलित करें। हमारे उत्पाद और सेवाएं तेजी से विकसित होती हैं, इसलिए कुछ सामग्री में त्रुटियां हो सकती हैं या पुरानी हो सकती हैं; Anthropic की वेबसाइट या docs पर सत्यापित करना याद रखें। पाठ्यक्रम में उपयोग किए गए उदाहरण और परिदृश्य illustrative हैं और अक्सर काल्पनिक हैं। यदि पाठ्यक्रम सामग्री किसी कंपनी या उत्पाद का उल्लेख करती है, तो इसका मतलब यह नहीं है कि Anthropic उनका समर्थन करता है, वे Anthropic का समर्थन करते हैं, या कि हम संबद्ध हैं। यह भी ध्यान दें कि Anthropic उत्पादों और सेवाओं का आपका उपयोग हमारी शर्तों, नीतियों और दस्तावेज़ द्वारा कवर किया गया है; यदि इस पाठ्यक्रम में कुछ उनके साथ विरोध करता है, तो वे नियंत्रण करते हैं।

स्क्रीन 2: एक खोज कॉल एक संरचित elicitation है, एक बातचीत नहीं

Discovery एक खोज कॉल एक संरचित elicitation है, एक बातचीत नहीं आप पैटर्न, डिप्लॉयमेंट प्लेटफॉर्म, और control posture का मूल्यांकन करना जानते हैं। Discovery यह प्रकट करता है कि क्या आप सही समस्या को हल कर रहे हैं। एक स्टेकहोल्डर आमतौर पर समस्या को व्यावसायिक शब्दों में वर्णित करेगा। आपका काम यह सुनना है कि व्यावसायिकता क्या हासिल करने की कोशिश कर रही है, उस विवरण में छिपी बाधाओं की पहचान करना, और कॉल को एक रिकॉर्ड के साथ छोड़ना जिसे डिज़ाइन अनुसरण कर सकता है।

Discovery उन artifacts को स्थापित करता है जिन पर डिज़ाइन निर्भर करता है एक खोज बातचीत एक तीन-चरणीय फ़िल्टर के रूप में कार्य करती है: सुनो, अनुवाद करो, और नीचे लिखो।

1पहले, व्यावसायिक लक्ष्य को सादे भाषा में सुनें और शब्द के पीछे के अर्थ पर ध्यान दें। स्टेकहोल्डर्स आमतौर पर उस परिणाम का वर्णन करते हैं जो वे चाहते हैं लेकिन उस बाधा का नहीं जिसे आपको डिज़ाइन करने की आवश्यकता है। 2दूसरा, इसे आवश्यकताओं, मान्यताओं, और अनसुलझी बाधाओं में अनुवाद करें। यह आपको यह देखने देता है कि डिज़ाइन को क्या समर्थन करना चाहिए, क्या अभी भी पुष्टि की आवश्यकता है, और क्या बाद में समाधान को अवरुद्ध कर सकता है। 3तीसरा, बातचीत आगे बढ़ने से पहले उन items को नीचे लिखें। डिज़ाइन को एक स्पष्ट रिकॉर्ड की आवश्यकता है। उस फ़िल्टर के बिना, डिज़ाइन आपकी मान्यताओं को विरासत में लेता है। असमानता बहुत बाद में प्रकट हो सकती है, जब trajectory बदलना धीमा, कठिन, और अधिक महंगा हो।

मुख्य कदम अनुवाद है: एक stated preference लगभग हमेशा एक बाधा को छुपाता है Discovery में सबसे महत्वपूर्ण कौशल अनुवाद है। स्टेकहोल्डर्स आमतौर पर प्राथमिकताओं में बोलते हैं, लेकिन डिज़ाइन निर्णय बाधाओं के विरुद्ध किए जाते हैं। कल्पना करें कि एक स्टेकहोल्डर कहता है, "हम चाहते हैं कि यह seamless महसूस हो।" यदि आप "seamless" को आवश्यकता के रूप में नीचे लिखते हैं, तो आपने कुछ भी डिज़ाइन करने के लिए पर्याप्त नहीं सीखा है। आपके पास केवल स्टेकहोल्डर का अनुभव का सारांश है जो वे चाहते हैं।

वास्तविक काम अगले प्रश्न के साथ शुरू होता है: क्या इसे seamless महसूस नहीं कराएगा? वह है जहां छिपी बाधाएं दिखाई देने लगती हैं। शायद उपयोगकर्ता को अगले चरण के लिए एक या दो सेकंड से अधिक प्रतीक्षा नहीं करनी चाहिए। शायद उन्हें ऐसी जानकारी फिर से दर्ज नहीं करनी चाहिए जो पहले से upstream में मौजूद है। शायद exceptions एक मानव समीक्षक को शांति से जाना चाहिए, न कि एक तकनीकी त्रुटि को expose करना। शायद workflow एक एप्लिकेशन के अंदर रहना चाहिए, इसलिए उपयोगकर्ता को कभी tools के बीच कूदना नहीं पड़ता। प्रत्येक उत्तर डिज़ाइन को तीक्ष्ण करता है।

वह exchange "seamless" को आवश्यकताओं में बदल देता है जिन्हें आर्किटेक्चर को समर्थन करना चाहिए: एक latency target, एक integration requirement, एक handoff rule, और एक safe failure path। स्टेकहोल्डर व्यावसायिक भाषा में परिणाम का नाम देता है। आप इसे कुछ ऐसा बदलते हैं जिसे सिस्टम बना सकता है और इसके विरुद्ध मापा जा सकता है।

Preference top level पर बैठती है, और constraint इसके नीचे बैठती है। जब एक स्टेकहोल्डर आपको seamless, easy, fast, simple, या intuitive जैसा एक experience word देता है, तो इसे एक संकेत के रूप में मानें कि अधिक discovery की आवश्यकता है। पूछें कि क्या उस अनुभव को तोड़ेगा, उपयोगकर्ता को क्या कभी नहीं देखना चाहिए, पर्दे के पीछे क्या होना चाहिए, और कुछ गलत होने पर भी क्या सच रहना चाहिए। वे उत्तर हैं जो डिज़ाइन रिकॉर्ड में होने चाहिए।

एक testable, bounded constraint वह है जिसके विरुद्ध डिज़ाइन बनाया जा सकता है। एक स्टेकहोल्डर preference आपको बताता है कि कहां जांच करनी है, जबकि follow-up प्रश्न constraint को ही produce करते हैं।

चार प्रश्न discovery को आवश्यकताओं में बदल देते हैं Discovery तब सबसे अच्छा काम करता है जब आप एक vague स्टेकहोल्डर statement को नीचे दिए गए चार buckets में force करते हैं। "हम चाहते हैं कि यह seamless महसूस हो" जैसा एक statement अभी तक कुछ नहीं है जिसके विरुद्ध आप डिज़ाइन कर सकते हैं। यह आमतौर पर एक या अधिक specific उत्तरों को छुपाता है। निम्नलिखित की जांच करें:

1सिस्टम को क्या करना चाहिए। ये वे capabilities हैं जिन्हें डिप्लॉयमेंट को deliver करना चाहिए, features के बजाय business outcomes के रूप में व्यक्त किए गए। यह है जहां आप Claude के मालिक काम को एक existing system या एक मानव के साथ रहने वाले काम से अलग करते हैं। 2सिस्टम को क्या नहीं करना चाहिए। ये boundaries हैं, prohibited actions, और cases जिन्हें एक मानव को route करना चाहिए। स्टेकहोल्डर्स शायद ही कभी इन्हें volunteer करते हैं, इसलिए आपको उन्हें explicitly पूछना चाहिए। 3सिस्टम की लागत क्या होनी चाहिए। यह budget constraint है, स्टेकहोल्डर द्वारा नियंत्रित शब्दों में व्यक्त किया गया। एक latency target, एक per-interaction cost ceiling, या एक volume forecast सभी को यहां ध्यान में रखा जाना चाहिए। ये महत्वपूर्ण डिज़ाइन constraints बन जाते हैं। 4सिस्टम को क्या साबित करना चाहिए। यह वह evidence है जिसे डिप्लॉयमेंट produce करने में सक्षम होना चाहिए कि कुछ मूल्य का है। नियंत्रित workflows में, proof obligations requirement set का हिस्सा हैं। Discovery में उन्हें पहचानना कानूनी समीक्षा के सप्ताह बाद की तुलना में बहुत सस्ता है।

"Seamless" वास्तव में एक latency budget हो सकता है जिसे उपयोगकर्ता को notice नहीं करना चाहिए, एक handoff जो flow को interrupt नहीं करना चाहिए, या एक failure state जो system internals को expose नहीं करना चाहिए। एक बार जब आप उन उत्तरों को discover करते हैं, तो आपके पास requirements होती हैं जिन्हें टीम डिज़ाइन, test, और defend कर सकता है।

Discovery का output एक translation table है Discovery में पाया गया प्रत्येक item एक translation table में एक row बन जाता है। Row stakeholder statement को capture करता है जैसा कि कहा गया था, implied constraint, required architectural decision, और कोई भी assumption जिसे आप document कर रहे हैं जब constraint अभी तक confirmed नहीं हुई है। एक item per row reasoning को intact रखता है जैसे-जैसे काम discovery से design में जाता है, और यह assumptions को top of mind रखता है।

Stakeholder statementImplied constraintRequired architectural decisionAssumption of document

"हम चाहते हैं कि यह seamless महसूस हो।"अनुभव को एक agreed-upon latency budget के अंदर रहना चाहिए। Failures को system internals को expose नहीं करना चाहिए या flow को break नहीं करना चाहिए।एक p95 latency target को design constraint के रूप में set करें, फिर एक graceful, internal-safe failure state design करें।मानता है कि "seamless" perceived responsiveness और continuity of flow को संदर्भित करता है। समझ की पुष्टि करें। "इसे बस form को read करना और route करना है।"Routing एक deterministic business rule हो सकता है।Routing decision को rule engine में रखें। Claude extracts, और system routes।मानता है कि routing logic model के बाहर owned और maintained है। Owner की पुष्टि करें। "Clinicians वैसे भी output को review करेंगे।"एक licensed मानव को output को authorize करना चाहिए इससे पहले कि यह एक record का हिस्सा बन जाए जिसके legal, financial, या clinical परिणाम हों।एक human-in-the-loop authorization step को एक mandatory checkpoint के रूप में build करें।मानता है कि review एक architectural gate है। Authority और timing की पुष्टि करें। "हम healthcare में हैं, इसलिए data के साथ सावधान रहें।"Workflow संभवतः एक health-privacy regime के तहत एक proof obligation carry करता है।Audit-trail और data-handling evidence को एक core requirement के रूप में day one से treat करें।मानता है कि एक covered workflow एक formal obligation के साथ है। Compliance के साथ scope की पुष्टि करें।

लागत · जटिलता · जोखिम

लागत: एक discovery कॉल जो real constraints की पहचान करने के लिए काफी लंबा चलता है, एक hidden constraint के बाद डिज़ाइन को redesign करने की तुलना में बहुत सस्ता है जो legal या compliance समीक्षा के दौरान उभरता है। जटिलता: चार प्रश्न categories के माध्यम से काम करना आवश्यक structure जोड़ता है, और preferences को real time में constraints में अनुवाद करना deliberate practice लेता है। जोखिम: महंगी विफलता unstated constraint है जो test को survive करती है और एक production review blocker बन जाती है, जब design को बदलने की लागत अपने highest पर होती है।

स्क्रीन 3: वह खोज कॉल जो एक डिज़ाइन सेशन में बदल गई

Watch OutDiscovery5 मिनट वह खोज कॉल जो एक डिज़ाइन सेशन में बदल गई

SetupDiscovery वह है जहां काम शुरू होता है। Design वह है जहां यह accelerate होता है। एक अच्छा Architect कॉल के आधे रास्ते में एक समाधान बनाना शुरू करता है। Sketching और visualizing इसे productive महसूस कराता है, और stakeholder progress देखकर pleased लगता है। वह बिल्कुल वह क्षण है जब प्रश्न बंद हो जाते हैं।

एक reconstructed खोज कॉल, जहां प्रश्न जल्दी बंद हो गए नीचे दिए गए exchange में, Architect दो stakeholder statements सुनता है और एक समाधान propose करना शुरू करता है। Stakeholder initial proposal की पुष्टि करता है क्योंकि यह competent लगता है। Constraints जो उस architecture को rule out करते, कभी identified नहीं होते। वे दो सप्ताह बाद एक compliance समीक्षा के दौरान उभरते हैं। यह section बिल्कुल दिखाता है कि प्रश्न जो प्रत्येक constraint को catch करता, कहां होना चाहिए था। इस उदाहरण का उपयोग अपनी खुद की कॉल में pattern को recognize करने के लिए करें।

Reconstructed exchange

Stakeholder: "हम एक regional hospital network चलाते हैं। Nurses patient interactions को लिखने में forever खर्च करते हैं। हम चाहते हैं कि Claude उनके dictation से clinical note को draft करे।" Architect: "समझ गया, यह बस एक clean augmented pattern है। Claude dictation लेता है, structured note को draft करता है, फिर इसे वापस लिखता है। हम अगले हफ्ते एक prototype रख सकते हैं।" Stakeholder: "यह सही लगता है। वहां कहीं एक review step है, लेकिन यह बस एक quick check है।" Architect: "निश्चित, हम एक review step जोड़ेंगे। मुझे design के साथ शुरू करने दें।"

विभिन्न constraints जो fix करने के लिए बहुत देर से identified हुए "Quick check" एक convenience feature नहीं था। Nursing workflow को एक licensed clinician को model output को authorize करना आवश्यक था इससे पहले कि यह patient record तक पहुंचे। यह human authorization को एक required architectural gate बनाता था, एक optional addition के बजाय। Dictation में protected health information था। Protected health information context window के माध्यम से चली गई बिना workflow के लिए आवश्यक handling के। Network दो states में फैला था जिनके अलग-अलग record-retention rules थे, और single-region design ने कभी भी किसी को account में नहीं लिया। ये requirements में से कोई भी unusual या find करने के लिए hard नहीं था। प्रत्येक must-prove और must-not-do categories में एक direct प्रश्न से बाहर आ गया होता, अगर कॉल sketching में जाने से पहले उन प्रश्नों को नहीं पूछा गया होता।

यह क्यों टूटा: एक competent sketch proposal ने discovery कॉल को पूछने के लिए exist करने वाले प्रश्नों को समाप्त कर दिया Sketch plausible था, और plausibility वह है जो इसे खतरनाक बनाता है। एक stakeholder जो एक confident architecture सुनता है, वह मानता है कि Architect के पास इसे build करने की जानकारी है। आपको protect करने वाली कदम boring है: चार-category प्रश्न set को पूरा करें कुछ भी propose करने से पहले और हर "it's just a review" को एक constraint के रूप में treat करें जिसे chase down करना है।

स्क्रीन 4: चेकपॉइंट: undocumented assumption को खोजें

Discovery · Checkpoint चेकपॉइंट: undocumented assumption को खोजें

अभी कोशिश करें। नीचे एक discovery-call summary है और एक requirements document है जो एक Architect ने इससे produce किया। तीन items कुछ ऐसा trace करते हैं जो stakeholder ने कहा; एक एक assumption है जो Architect ने बिना constraint को surface किए बिना बनाया। वह item चुनें जो undocumented assumption है, फिर पुष्टि करें कि कोई stakeholder statement इसे support नहीं करता।

Requirements document

• Claude customer email को draft करता है, लेकिन एक person वास्तव में इसे भेजता है।
• Responses दो-सेकंड perceived budget के भीतर return करना चाहिए।
• Threshold से ऊपर refunds एक human approver को route करते हैं।
• Conversation transcripts analytics के लिए साठ दिनों के लिए retain किए जाते हैं।

जो stakeholder ने कहा

"कुछ भी बड़ा एक person के sign off की आवश्यकता है।" "Draft reply करो, लेकिन हम इसे खुद भेजते हैं।" "इसे user के लिए instant महसूस करना चाहिए।"

भाग 1: कौन सा item undocumented assumption है?

AItem 1, email drafting with human send BItem 2, two-second latency budget CItem 3, refund routing to human approver DItem 4, sixty-day transcript retention

भाग 2: item 4 को किस stakeholder statement को trace back करना चाहिए?

A"Draft reply करो, लेकिन हम इसे खुद भेजते हैं।" B"इसे user के लिए instant महसूस करना चाहिए।" C"कुछ भी बड़ा एक person के sign off की आवश्यकता है।" Dकोई stakeholder statement इस item को support नहीं करता।

उत्तर की जांच करें Skip

स्क्रीन 5: एक ट्रेडऑफ प्रस्तुत करें ताकि स्टेकहोल्डर इस पर कार्य कर सके, और एक डेमो डिज़ाइन करें जो deal को advance करे

Tradeoffs & GTM एक ट्रेडऑफ प्रस्तुत करें ताकि स्टेकहोल्डर इस पर कार्य कर सके, और एक डेमो डिज़ाइन करें जो deal को advance करे Discovery ने आपको बताया कि खरीदार को क्या चाहिए। उन आवश्यकताओं को एक निर्णय में बदलना जो एक स्टेकहोल्डर कर सकता है, अगला काम है। Architect अब stakeholder को ट्रेडऑफ को समझने, व्यावसायिक परिणामों को देखने, और आत्मविश्वास के साथ एक रास्ता आगे बढ़ाने में मदद कर रहा है।

आपका काम ट्रेडऑफ को बैठक से पहले resolve करना नहीं है। आपका काम विकल्पों को स्पष्ट रूप से वर्णित करना है ताकि स्टेकहोल्डर एक informed choice कर सके। हर meaningful डिज़ाइन निर्णय का एक ट्रेडऑफ होता है। एक विकल्प लागत या जटिलता को कम कर सकता है लेकिन latency, जोखिम, या compliance burden को बढ़ा सकता है। दूसरा user experience को improve कर सकता है या बेहतर scale कर सकता है लेकिन upfront अधिक प्रयास की आवश्यकता है। यदि आप केवल निष्कर्ष प्रस्तुत करते हैं, तो निर्णय स्पष्ट दिख सकता है, लेकिन यह कमजोर है। जब downside बाद में दिखाई देता है, तो stakeholder महसूस कर सकता है कि उन्होंने एक recommendation को approve किया बिना समझे कि इसके साथ क्या आया। तो, एक simple decision frame का उपयोग करें:

1हम क्या हासिल करते हैं? 2हम क्या छोड़ते हैं? 3यदि हम अभी यह चुनते हैं लेकिन बाद में इसे उलट देना पड़ता है तो क्या होता है? 4नियंत्रित environments में, यह हमारे compliance posture को क्या करता है?

वह तीसरा प्रश्न वह है जो अधिकांश लोग skip करते हैं, और यह अक्सर वह है जो बैठक को बदलता है। यह discussion को "क्या बेहतर तकनीकी उत्तर है? " से "क्या बेहतर व्यावसायिक विकल्प है? " में बदल देता है। तकनीकी precision आवश्यक है, लेकिन यह sufficient नहीं है। Architecture समीक्षाओं में, recommendation अक्सर तकनीकी रूप से सही होता है लेकिन फिर भी उस व्यक्ति के लिए समझदारी से नहीं होता जिसे इसे approve करना चाहिए। Architect विकल्पों को तकनीकी vocabulary में समझा सकता है (अर्थात latency, logging depth, context size, retrieval pattern, deployment route) लेकिन executive एक सरल प्रश्न पूछ रहा है: "यदि हम गलत विकल्प बनाते हैं तो व्यावसायिकता को क्या होता है? " उस बिंदु पर, कमरे को अधिक detail की आवश्यकता नहीं है, इसे कुछ ऐसा चाहिए जिसे एक व्यक्ति समझ सके। जब आप यह अच्छी तरह करते हैं, तो stakeholder केवल आपकी recommendation नहीं सुन रहा है। वे एक informed decision कर रहे हैं जिसे वे बाद में अपनी leadership को defend कर सकते हैं।

निर्णय को एक package के रूप में frame करें, न कि एक verdict के रूप में निर्णय को एक package के रूप में प्रस्तुत करें जिस पर stakeholder कार्य कर सकता है: विकल्प जिन पर आपने विचार किया, मानदंड जिन्हें आपने weigh किया, आपकी recommendation, और जोखिम जो remain करते हैं। Stakeholder आपके architecture को adopt नहीं कर रहा है; वे एक निर्णय accept कर रहे हैं जिसे वे अपनी leadership को defend करना होगा।

Description वह competency है जो package को land कराता है Description चार AI Fluency competencies में से एक है: AI के साथ effectively communicate करना। Stakeholder side के काम तक extended, एक ही discipline का मतलब है audience को precisely बताना कि उन्हें क्या चाहिए, उन शब्दों में जिन्हें वे समझते हैं। Stakeholder communication पर applied, Description का मतलब है system के behavior, इसकी limits, और इसके चारों ओर oversight को stakeholder के goal term में frame करना। Framing को उनकी AI familiarity के साथ match करना चाहिए बिना accuracy को sacrifice किए। तीन rules practice में apply होते हैं: business outcome के साथ lead करें architecture के बजाय; limitations को honestly frame करें, क्योंकि एक security stakeholder एक system को trust करता है जिसकी limits स्पष्ट रूप से stated हैं; और peer-proof demand को anticipate करें, क्योंकि stakeholder को choice को दूसरों को justify करना होगा और conversation को उस justification के साथ छोड़ना चाहिए।

Tradeoff translation map का उपयोग करें architecture framing से stakeholder decision language में shift करने के लिए।

Architectural decisionWhat you gainWhat you give upWhat a wrong, reversed choice costs

Larger context window per call versus retrieval over chunksSimpler initial design, the full document in view, और fewer moving parts को manage करना early on।Higher per-call cost और slower response times जैसे-जैसे production volume बढ़ता है। Prompt caching static content जैसे policy documents के लिए input cost का एक significant portion recover कर सकता है जो call के across held होते हैं, इसलिए per-call cost को fixed के रूप में treat करने से पहले caching का evaluate करें।Production में cost spike के बाद architecture को rework करना, plus एक avoidable expense surprise को explain करने का credibility hit। Trade logging details for lower latencyFaster perceived response और एक smoother end-user experience।Reduced visibility में क्या हुआ प्रत्येक interaction में।एक regulated workload में, एक potential compliance gap जिसे remediation की आवश्यकता है। Single delivery route versus multi-platformLower build complexity और एक consistent authentication और logging profile।Less flexibility को meet करने के लिए different regional, compliance, या procurement needs।एक delayed या blocked production cutover यदि chosen route एक late-emerging data residency या deployment requirement को satisfy नहीं कर सकता।

Map stakeholder को consequence को अपने choice का स्पष्ट रूप से देखने में मदद करने के लिए exist करता है।

Demo design एक distinct skill है, और एक weak demo वह कर सकता है जो discovery ने earned किया उसे undo कर सकता है Picture करें buyer meeting जहां discovery अच्छी तरह गई। Team problem, use case, और value at stake पर aligned हो गया। फिर demo शुरू होता है। Buyer के world को show करने के बजाय, यह features का एक polished लेकिन generic set show करता है। Reaction आमतौर पर polite होता है, कि demo interesting था, लेकिन बिल्कुल वह नहीं जो उन्होंने envisioned किया।

एक weak demo buyer को question करा सकता है कि क्या team को core problem समझ आया। यह तब होता है जब teams दो different jobs को confuse करते हैं। एक capabilities demo answer देता है, "यह system क्या कर सकता है? " एक scenario-specific demo answer देता है, "यह system मेरी problem, मेरे workflow, और मेरी constraints के साथ क्या करता है? " पहला interest create करता है; केवल दूसरा confidence create करता है। Proof design करना कि solution buyer के context में fit करता है, demo के job का हिस्सा है। एक well-designed demo opportunity को advance करता है जबकि एक weak एक discovery को build करने वाले trust को undo कर सकता है।

Partner TrackNot tested by the Architect exam किसी भी screens को build करने से पहले, चार design decisions करें। वे decisions determine करते हैं कि क्या demo tailored और credible महसूस होता है या generic और dismiss करने के लिए आसान।

Design decisionWhat the Architect decidesWhy it determines the outcome

Scenario selectionएक workflow चुनें जिसे buyer अपनी operations से immediately recognize करेगा, familiar data shapes, approval steps, और edge cases सहित। एक generic document task या abstract query flow को avoid करें।Buyers trust करते हैं जो familiar महसूस होता है। जब वे अपनी vocabulary और failure points को screen पर देखते हैं, तो demo relevant और credible महसूस होता है। Recognition अक्सर एक polished लेकिन generic feature tour से अधिक persuasive होता है। Limit placementAdvance में decide करें कि demo कौन सी एक या दो limitations को identify करेगा, और उन्हें intentional scope boundaries के रूप में frame करें। State करें कि system क्या नहीं करता है और क्यों।यदि buyer demo के आधे रास्ते में एक limitation discover करता है, तो confidence drops। यदि आप limitation को early name करते हैं, तो यह discipline और honesty के रूप में reads करता है। Regulated settings में, upfront disclosure of boundaries अक्सर एक positive signal होता है। Sales team collaborationDemo narrative को sales team के साथ shape करें building से पहले। वे जानते हैं कि buyer ने earlier conversations में क्या raise किया, और आप जानते हैं कि system production conditions के तहत क्या realistically show कर सकता है।एक demo built without sales उन प्रश्नों का उत्तर दे सकता है जो buyer ने कभी नहीं पूछे। एक demo built without Architect overpromise कर सकता है। किसी भी तरह से, demo credibility खो देता है और opportunity को slow करता है। Data preparationजानकारी का उपयोग करें जो structure और volume में buyer के data को resemble करता है। Regulated buyers के लिए, anonymized data का उपयोग करें जो real environment के समान structural constraints को still reflect करता है।Buyers demo को इसमें data द्वारा judge करते हैं। Realistic field names और data patterns scenario को real महसूस कराते हैं। जब data उनके जैसा दिखता है, तो demo अपने लिए argue करता है।

Limit placement को deliberate attention की deserve करता है चार demo-design decisions में से, limit placement वह है जो अक्सर instinct के विरुद्ध चलता है। Practice में, एक weakness को name करना risky महसूस कर सकता है, इसलिए temptation इसे hide या soften करना है। यह आमतौर पर backfire करता है। उस moment को imagine करें जहां buyer पूछता है, "यह क्या अच्छी तरह handle नहीं करता है? " यदि answer vague है, तो confidence drops। यदि answer clear और scoped है, तो buyer discipline देखता है, न कि defensiveness।

यही कारण है कि आपको advance में decide करना चाहिए कि आप कौन सी एक या दो constraints को name करेंगे और आप उन्हें कैसे frame करेंगे। दिखाएं कि boundary deliberate है, कि यह है जो solution को build किया गया है, और यह है जो इसे build नहीं किया गया है।

यह regulated industries जैसे healthcare, financial services, और public sector में और भी अधिक matters। उन settings में, एक clear boundary अक्सर rigor signal करता है, जबकि एक deflection risk signal करता है।

Prepare करने का एक simple तरीका है पूछना:

Limit क्या है? यह क्यों exist करता है? यदि use case को इसके beyond जाना पड़ता है तो क्या होता है?

Successful joint scoping session से पहले शुरू होता है Partner TrackNot tested by the Architect exam वह same discipline directly joint scoping में Applied AI team के साथ carry करता है। एक अच्छा scoping session वह जगह नहीं है जहां आप पहली बार basics को figure out करते हैं। यह वह जगह है जहां आप choices को refine करते हैं, assumptions को test करते हैं, और उन प्रश्नों को resolve करते हैं जिन्हें specialist input की आवश्यकता है।

यदि demo prove करता है कि आप buyer की problem को समझते हैं, तो scoping session prove करता है कि आप इसके चारों ओर एक credible solution को shape करने के लिए ready हैं। यह केवल तभी काम करता है यदि आप तीन चीजें prepared के साथ आते हैं:

Customer की requirements और constraints का एक documented view। यह capture करता है जो discovery से बाहर आया: use case, workflow, stakeholders, data conditions, technical environment, compliance concerns, और success criteria। यह session को एक shared starting point देता है। एक proposed pattern या candidate patterns का एक small set, tradeoffs already named के साथ। एक point of view के साथ walk in करें। Likely options दिखाएं, प्रत्येक आपको क्या देता है, प्रत्येक क्या छोड़ता है, और जहां risks sit। एक short list of open questions जिन्हें Applied AI team best positioned है answer करने के लिए। ये वे प्रश्न हैं जो session पर खर्च करने के लिए worth हैं: model behavior, architecture implications, scaling constraints, evaluation approach, safety considerations, या pattern fit।

Demo में, आप trust earn करते हैं limitations को clearly identify करके। Joint scoping में, आप उस trust को keep करते हैं problem, options, और unanswered questions का एक structured view लाकर।

Objections विभिन्न categories में fall करते हैं, और प्रत्येक को एक different response की आवश्यकता है Sales cycle में technical objections आमतौर पर तीन categories में fall करते हैं। Capability objections पूछते हैं कि क्या system चीज़ को सब कुछ कर सकता है। Governance और compliance objections पूछते हैं कि क्या deployment को trusted, controlled, और evidenced किया जा सकता है एक तरीके से buyer defend कर सकता है। Design-choice objections पूछते हैं कि आपने यह विकल्प दूसरे के बजाय क्यों बनाया। वे justification से अधिक की आवश्यकता करते हैं। आपको tradeoff को explain करना चाहिए जो choice बनाता है और alternative को क्या cost किया होता, उसी translation structure का उपयोग करके जो आपने ट्रेडऑफ को पहली जगह में present किया था।

Partner TrackNot tested by the Architect exam Go-to-market engagement map को demo design को एक tracked workstream के रूप में treat करना चाहिए। यही कारण है कि इसमें एक demo-design column है scenario, identified limitations, confirmed data source, और sales-team sign-off के साथ explicit deliverables के रूप में। यह सबसे अधिक matters जब एक partner parallel opportunities चला रहा है या जब Architects mid-cycle में hand off करते हैं, क्योंकि continuity crucially पर निर्भर करता है कि क्या documented है।

लागत · जटिलता · जोखिम

लागत: एक ट्रेडऑफ presentation और एक scenario-specific demo को prepare करना real Architect time लेता है, लेकिन यह एक stalled opportunity या एक approval से बहुत कम expensive है जिसे stakeholder बाद में withdraw करता है। जटिलता: तीन distinct skills इस काम के नीचे बैठते हैं, और दो अक्सर एक के instinct के विरुद्ध जाते हैं: reversal cost को name करना और limits को clearly place करना। दोनों को improve करने के लिए deliberate practice की आवश्यकता है। जोखिम: महंगी विफलता false alignment है। जब एक निर्णय room में approved दिखता है, लेकिन reversal cost को कभी explicit नहीं बनाया गया था, और consequence बाद में उठता है।

स्क्रीन 6: वह अनुमोदन जो एक informed choice नहीं था

Watch OutTradeoffs & GTM5 मिनट वह अनुमोदन जो एक informed choice नहीं था

Setupएक stakeholder जो ट्रेडऑफ presentation के अंत में yes कहता है, वह approve किया हुआ दिखता है। Presentation complete और technically accurate था, और room aligned महसूस होता था। वह feeling trap है।

एक reconstructed pre-production समीक्षा, CTO के perspective से Architect ने एक context-strategy ट्रेडऑफ को technical terms में present किया। CTO ने cost के बारे में एक प्रश्न पूछा, Architect ने accurately उत्तर दिया, और CTO ने approve किया। छह सप्ताह बाद higher per-call cost production invoice में दिखाई दिया। यह exchange है, और फिर note जो CTO ने लिखा जब bill receive हुआ। यह दिखाता है जहां presentation गलत version के प्रश्न का उत्तर दिया।

Reconstructed exchange + follow-up

Architect: "हम larger context window की recommend कर रहे हैं, इसलिए full policy document हर call पर view में रहता है। यह design को simpler रखता है और एक retrieval layer को avoid करता है।" CTO: "Per call cost क्या दिखता है? " Architect: "हम जो model tier use कर रहे हैं उसमें लगभग चार cents per interaction। यदि policy document static है calls के across, तो prompt caching input portion को significantly नीचे ला सकता है।" CTO: "ठीक है, approved। इसे simple रखते हैं।" [छह सप्ताह बाद, production invoice पर] CTO का note account team को: "मैंने एक direction approve किया, एक number नहीं। किसी ने मुझे नहीं बताया कि चार cents times हमारे call volume एक five-figure monthly line था। यदि document static था, तो हम इसे cache क्यों नहीं कर रहे थे? और यदि हम full-context के चारों ओर build करने जा रहे थे, तो मुझे जानना चाहिए था कि unwinding करने में क्या cost होगा एक बार system इस पर depend करता है।"

Issue: reversal cost कभी conversation में enter नहीं हुई Presentation ने name किया कि design क्या gained, simplicity, और यह per-call cost को answer किया जैसा पूछा गया। जो कभी identify नहीं किया गया वह तीसरा element था: जब यह choice production volume को meet करता है और system इसके चारों ओर build होने के बाद उलट दिया जाना चाहिए तो व्यावसायिकता को क्या होता है। CTO ने एक per-call number approve किया, एक monthly bill नहीं, और reversal cost नहीं। ट्रेडऑफ के दो parts स्पष्ट रूप से communicated और understood थे। तीसरा नहीं था, और यह load-bearing एक बन गया।

यह क्यों टूटा: एक accurate presentation अभी भी गलत प्रश्न का उत्तर दे सकता है एक stakeholder जिसने reversal cost को समझे बिना एक recommendation approve किया है, एक informed choice नहीं बनाया है। CTO ने एक per-call figure और एक simplicity argument सुना और reasonably yes कहा। Reversal-cost element वह एक factor था जो decision को बदल देता। हर बार सभी तीन elements name करें और reversal cost को especially name करें जब design obviously simpler महसूस होता है।

स्क्रीन 7: चेकपॉइंट: विकल्प की recommend करें और missing element को name करें

Tradeoffs & GTM · Checkpoint चेकपॉइंट: विकल्प की recommend करें और missing element को name करें

अभी कोशिश करें। एक-paragraph stakeholder briefing पढ़ें और तीन option presentations को plain language में लिखा गया। एक विकल्प technically accurate है और comprehensively presented है। एक technically accurate है, लेकिन इसकी presentation एक element को miss कर रहा है। एक stated constraints के लिए inappropriate है। विकल्प को recommend करें forward रखने के लिए, फिर दूसरे विकल्प की presentation से single missing element को name करें।

Briefing एक mid-sized insurer चाहता है कि Claude policyholder queries के लिए adjuster responses को draft करे। Workflow state insurance regulation द्वारा covered है एक audit-trail obligation के साथ। Volume high और steady है। Sponsor response quality के बारे में care करता है और एक defensible record को keep करने के बारे में हर automated interaction का।

OptionPresentation as shown

AWorkflow pattern with per-interaction logging built in। Gains: full audit trail, quality gate before sending। Gives up: logging step से एक small latency cost। Reversal: minor, logging को tune किया जा सकता है बिना redesign के। BWorkflow pattern जो logging step को lower latency के लिए trade करता है। Gains: faster responses। Gives up: per-interaction audit detail। CSingle augmented call with no logging और no human gate, chosen for lowest build cost।

भाग 1: कौन सा विकल्प आपको recommend करना चाहिए?

AOption A, logging built in, full audit trail BOption B, trades logging for lower latency COption C, no logging, no human gate

भाग 2: Option B की presentation से कौन सा single element missing है?

AWhat Option B gains (faster responses को clearly enough name नहीं किया गया है) BWhat Option B gives up (audit detail loss को explain नहीं किया गया है) CThe reversal cost, क्या cost होता है logging को restore करने के बाद design latency gain पर depend करता है DThe compliance posture यह option create करता है

उत्तर की जांच करें Skip

स्क्रीन 8: Feedback loop यह decide करता है कि कौन से signals एक stakeholder तक पहुंचते हैं, और SLA names करता है कि आप क्या owe करते हैं जब एक break होता है

Feedback Loops Feedback loop यह decide करता है कि कौन से signals एक stakeholder तक पहुंचते हैं, और SLA names करता है कि आप क्या owe करते हैं जब एक break होता है Production observability और audit trail record करते हैं कि एक live deployment क्या कर रहा है। यह topic उन signals को filter करना, decide करना कि कब team से beyond escalate करना है, और define करना कि SLA क्या require करता है जब performance standard से नीचे गिरता है। System live है; इसे trustworthy रखना over time effort लेता है। Lifecycle terms में, feedback loop deployment lifecycle का monitoring-and-iteration stage है।

एक live deployment active monitoring के बिना drift करता है एक customer support assistant को imagine करें जो solid shape में launched होता है। यह quickly answer करता है, एक tone में रहता है, और most common questions को अच्छी तरह handle करता है। पहले, सब कुछ stable दिखता है। लेकिन समय के साथ, usage patterns change होते हैं, नए prompt styles दिखाई देते हैं, और customer issues अधिक complex बन जाते हैं। कुछ responses merely slow down होते हैं, और कुछ answers पूरी तरह mark को miss करने लगते हैं।

कुछ भी dramatically break नहीं होता, जो drift को catch करना hard बनाता है। Quality gradually erode होती है सब एक बार के बजाय। एक team बिना feedback loop के decline को तब तक नहीं देख सकता जब तक users पहले से ही इसे feel नहीं करते।

Feedback loop एक decision layer है जो observability stack के ऊपर बैठता है Observability raw material देता है: latency, error rates, eval scores, usage patterns, और system से अन्य signals। लेकिन एक signal by itself अभी तक एक decision नहीं है। एक spike noise हो सकता है। दूसरा एक real problem को point कर सकता है। तीसरा केवल important हो सकता है यदि यह keep happening करता है।

Feedback loop observability के ऊपर बैठता है पाँच प्रश्नों का उत्तर देने के लिए: Signals → Triage → Decide → Act → Review

1Signals: System हमें क्या दिखा रहा है? 2Triage: क्या अभी attention की आवश्यकता है, और क्या wait कर सकता है? 3Decide: क्या issue को एक team fix, एक stakeholder समीक्षा, या कोई action की आवश्यकता है? 4Act: कौन सी correction, guardrail update, या escalation required है? 5Review: क्या response काम किया और क्या rule को change करने की आवश्यकता है?

इसे एक train station में एक control room की तरह सोचें। Sensors आपको बता सकते हैं कि trains कहां late हैं, लेकिन किसी को अभी भी decide करना चाहिए कि क्या delay minor है, क्या passengers को inform करने की आवश्यकता है, और क्या schedule को change करने की आवश्यकता है। वह judgment layer वह है जो system को manageable बनाता है, न कि केवल measurable।

एक SLA तीन चीजें names करता है, और thresholds कहीं tangible से आते हैं। एक बार जब feedback loop decide करता है कि कुछ matters, SLA define करता है कि क्या होता है जब यह line को cross करता है। एक SLA एक commitment है जो तीन चीजें clear बनाता है:

1हम क्या measure कर रहे हैं? 2क्या एक breach के रूप में counts करता है? 3जब एक breach होता है तो क्या होता है?

Threshold कभी arbitrary नहीं होना चाहिए। यह कुछ tangible को trace back करना चाहिए:

1Latency को user experience expectation को reflect करना चाहिए जो earlier identified हुई 2Availability को reflect करना चाहिए कि deployment business के लिए कितना critical है 3Quality को reflect करना चाहिए eval results और acceptance criteria जो पहले से ही established हैं

वह traceability matters क्योंकि यह SLA को defensible रखता है। यदि number को उन sources में से एक को tie नहीं किया जा सकता, तो यह probably केवल एक target है जिसे किसी ने choose किया क्योंकि यह reasonable लगता था।

Cost वह expectation है जो launch के बाद सबसे अधिक break होती है। Production volume routinely pilot से एक से दो orders of magnitude ऊपर चलता है, इसलिए एक cost जो proof of concept में trivial दिखता था production में एक five-figure monthly line बन जाता है। Pre-empt करें: stakeholder को एक consumption forecast दें expected production volume पर, spend-control posture को name करें (caching, model tiering, budget alerts), और model-tiering narrative को frame करें पहले invoice के बजाय।

Regulated deployments review checkpoints जोड़ते हैं जो एक schedule पर चलते हैं Observability record करता है क्या हुआ; feedback loop determine करता है इसके बारे में क्या करना है। Regulated deployments में, कुछ reviews को happen करना चाहिए भले ही कुछ गलत न हुआ हो। एक healthcare workflow एक documentation obligation के साथ एक defined schedule पर periodic output audits require कर सकता है। एक data-residency deployment को scheduled confirmation की आवश्यकता हो सकती है कि environment अभी भी residency rules को meet करता है। ये design-time obligations हैं, न कि tasks जिन्हें बाद में add किया जाए। यदि वे early में build नहीं होते, तो वे establish करने के लिए बहुत अधिक expensive बन जाते हैं जब कोई proof के लिए पूछता है।

एक governance table build करें जो प्रत्येक signal को इसके trigger, Architect के response, और किसी भी regulatory checkpoint से map करता है। Table को launch से पहले exist करना चाहिए। यह mechanism है जो policy को एक operating routine में बदलता है।

Production-signal governance table Signal typeReview triggerArchitect actionRegulated-industry checkpoint

Output quality (eval score)Score threshold को cross करता है जो eval suite से drawn है।Diagnose करें कि cause prompt, data, या model drift है, फिर decide करें iterate करने बनाम re-architect करने के लिए।Periodic output audit documentation standard के विरुद्ध, एक established schedule पर, regardless of score। Latency p95User-experience requirements से set budget को cross करता है।Bottleneck को investigate करें, फिर tune करें या एक stakeholder समीक्षा के लिए escalate करें यदि budget itself गलत है।Usually none, जब तक latency एक logging या traceability gap को mask नहीं कर रहा है। Cost per interactionDiscovery में agreed budget envelope को cross करता है।Driver को identify करें, फिर एक ट्रेडऑफ को stakeholder के लिए लाएं यदि budget को revisit करने की आवश्यकता है।Usually none, जब तक cost controls एक regulated operating constraint का हिस्सा नहीं हैं। Data-residency configurationScheduled confirmation।Residency posture को confirm और record करें और किसी भी drift को immediately flag करें।Residency confirmation established schedule पर।

लागत · जटिलता · जोखिम

लागत: Loop एक ongoing architect effort create करता है। ध्यान दें कि यह quarterly समीक्षा में decline को discover करने की तुलना में सस्ता है जब हर dashboard अच्छा दिखता है। जटिलता: सबसे hard part यह decide करना है कि कौन से signals attention deserve करते हैं, और कौन से noise हैं, क्योंकि observability tooling उस judgment को आपके लिए नहीं बना सकता। जोखिम: सबसे बड़ी failure mode एक compliance checkpoint है जो कभी एक trigger से wire नहीं किया गया, एक documented-standard violation को allow करते हुए weeks के लिए चलने के लिए जब तक एक routine समीक्षा इसे catch नहीं करता।

स्क्रीन 9: Observability stack जिसने feedback loop को replace किया

Watch OutFeedback Loops5 मिनट Observability stack जिसने feedback loop को replace किया

Setupएक Architect जिसने एक rigorous observability stack build किया है harder technical work को किया है। Dashboards live हैं, alerts configured हैं, और data flowing है। यह easy है, और reasonable, conclude करना कि stakeholder feedback covered है।

एक reconstructed trace: ninety days of alert log against stakeholder समीक्षा calendar नीचे दिया गया excerpt एक deployment alert log को इसके stakeholder समीक्षा calendar के साथ एक ninety-day window पर place करता है। Alert log एक sustained drift को output quality में दिखाता है weeks चार के through seven में। समीक्षा calendar दिखाता है कि window में कोई समीक्षा happen नहीं हुई। एक single row एक feedback-loop governance table में दोनों को connect करता। यह दिखाता है कि gap record में क्या दिखता है।

WindowObservability stack recordedStakeholder समीक्षा calendarWhat the loop should have done

Weeks 1-3Eval score steady baseline पर, latency और cost nominal के साथ।Launch समीक्षा week 1 में held।Nominal। कोई escalation needed नहीं। Weeks 4-7Eval score week over week down drifting, error rate flat के साथ, इसलिए कोई hard alert fire नहीं होता।कोई समीक्षा scheduled या held नहीं।एक quality-drift trigger को एक Architect समीक्षा के लिए week 5 तक escalate करना चाहिए, और onward एक stakeholder समीक्षा के लिए एक बार diagnosis drift को confirm करता है। Weeks 8-12Score अभी भी declining है, और stakeholder report करता है output "lately कम useful है।"Quarterly समीक्षा finally इसे week 12 में surface करता है।Design के अनुसार, loop ने इसे सात सप्ताह पहले catch किया होता।

Issue: signals existed, लेकिन कुछ भी decide नहीं किया कि वे matter करते हैं हर metric जिसे deployment को need था पहले से ही collect किया जा रहा था। Eval score visibly week चार से down drifting था। जो missing था वह decision layer था: कोई governance rule slow quality drift को एक समीक्षा trigger से map नहीं करता था। Drift कोई error-rate threshold को cross नहीं करता था, इसलिए कोई alert fire नहीं होता था। एक drift बिना trigger के invisible है जब तक एक human happen नहीं करता इसे notice करने के लिए। Stack सही चीज़ को measure कर रहा था और किसी को नहीं बता रहा था कि यह matters।

यह क्यों टूटा: monitoring एक feedback loop नहीं है एक dashboard signals को collect और display करता है। एक feedback loop प्रत्येक signal को एक trigger, एक owner, और एक required action से map करता है। Observability stack signals को collect किया लेकिन कोई governance rule किसी भी signal को एक trigger या owner से map नहीं करता था। Governance table build करें जो प्रत्येक signal को एक trigger, एक action, और एक owner से map करता है। Slow drifts और hard failures दोनों को include करें।

स्क्रीन 10: चेकपॉइंट: production signals को triage करें

Feedback Loops · Checkpoint चेकपॉइंट: production signals को triage करें

अभी कोशिश करें। यहां एक production deployment से नौ signals हैं। प्रत्येक को उस bucket में drag करें जहां यह belongs: Internal monitoring, Architect समीक्षा, Stakeholder समीक्षा, या Noise।

1 · Latency p99 ticked up 40ms, अभी भी budget के अंदर। 2 · Eval score तीन सप्ताह चल रहा है down, trend clear है। 3 · Scheduled data-residency confirmation due है। 4 · एक known bad client से एक malformed request। 5 · Cost per interaction agreed budget threshold को cross किया। 6 · एक 2 a. m. batch job ने एक retry को log किया जो फिर succeed हुआ। 7 · Quarterly output audit documentation standard के विरुद्ध due है। 8 · Token usage एक known seasonal traffic bump के साथ rose। 9 · एक नया prompt template shipped, और error rate flat है।

Internal monitoring

Architect समीक्षा

Stakeholder समीक्षा

Noise

Placements की जांच करें Skip

स्क्रीन 11: Documentation जो आपकी अनुपस्थिति को survive करता है handoff recipient, auditor, और returning Architect को serve करता है

Documentation Documentation जो आपकी अनुपस्थिति को survive करता है handoff recipient, auditor, और returning Architect को serve करता है Feedback loop system को healthy रखता है जबकि आप इसे चला रहे हैं। Documentation वह है जो इसे handoff के बाद functioning रखता है। यह topic full design को documentation में बदलता है जो एक handoff को outlive करता है और एक compliance reviewer को satisfy करता है। या तो design अपना reasoning उस handoff में carry करता है, या वह reasoning disappear होता है जिस क्षण आप छोड़ते हैं। Lifecycle terms में, documentation deployment lifecycle का handoff stage है।

एक document तीन readers को serve करता है, और केवल एक को serve करना इसे incomplete बनाता है Architecture documentation तीन readers को serve करता है। Inheriting engineer एक deployment को take over करता है जिसका वह कोई हिस्सा नहीं था। Auditor बाद में आता है, एक specific control के लिए evidence की तलाश में जो live है और accounted for है। Returning architect, अक्सर आप, महीनों बाद आते हैं design sessions की कोई memory के साथ। एक document built एक के लिए और दूसरों के लिए नहीं incomplete है भले ही यह detailed हो।

Handoff recipient के लिए: rejected alternatives decisions जितना ही matter करते हैं जो भी system को inherit करता है, document को decisions को carry करना चाहिए जो बनाए गए, alternatives जो rejected हुए, और reason प्रत्येक rejection का। एक design delivered बिना rejected alternatives के नहीं समझा जा सकता किसी द्वारा जो room में नहीं था। वे right decision को wrong reason के लिए reverse करेंगे या wrong decision को defend करेंगे क्योंकि वे नहीं बता सकते कि कौन सा ट्रेडऑफ था। Rejected options explain करते हैं कि design क्यों shaped है जैसे यह है।

Compliance reviewer के लिए: evidence assertions से अधिक matters Compliance reviewer के लिए, document को carry करना चाहिए प्रत्येक regulatory obligation, technical control जो इसे satisfy करता है, owner उस control का, और evidence artifact जो demonstrate करता है control operating है। यह regulated deployment control register है, carried forward living document में जो deployment के production life को govern करता है। Reviewer mere assertions को accept नहीं करता। वे evidence require करते हैं, जिसका मतलब है कि एक statement कि control exist करता है अपने आप में enough नहीं है।

Returning Architect के लिए: एक briefing के बिना navigable Returning Architect के लिए, document को अपने आप पर stand करना चाहिए। Decisions dated हैं। Assumptions explicitly labeled हैं assumptions के रूप में, न कि embedded facts के रूप में। Open items के owners और resolution criteria हैं। Test practical है: document को पढ़ने के बाद, क्या एक competent Architect जो design sessions में present नहीं था system में एक safe change बना सकता है? यदि answer नहीं है, तो document complete नहीं है।

Documentation completeness checklist: Documentation completeness checklist FieldWhat it capturesReader it primarily serves

DecisionArchitectural choice जो बनाया गया, date सहित।सभी तीन readers। Rejected alternativesOptions जो considered लेकिन chosen नहीं हुए।Handoff recipient। Tradeoff namedTradeoff जो decision resolve किया, gains, costs, और reversal implications के terms में expressed।Handoff recipient और returning Architect। OwnerPerson या team responsible decision या control के लिए going forward।Compliance reviewer और handoff recipient। Evidence artifactArtifact जो demonstrate करता है एक control actually operating है।Compliance reviewer। Audit-ready statusWhether available evidence current और sufficient है समीक्षा के लिए।Compliance reviewer।

लागत · जटिलता · जोखिम

लागत: Rationale और evidence को design time पर लिखना time लेता है। इसे बाद में email threads से reconstruct करना, या fail करना, production में एक wrong reversal cost करता है। जटिलता: Discipline है क्या record करना, न कि केवल क्या, और assumptions को assumptions के रूप में label करना, जो skip करना आसान है जब reasoning obvious महसूस होता है उस व्यक्ति को जिसने इसे lived किया। जोखिम: Costly failure एक successor है जो एक load-bearing decision को reverse करता है क्योंकि rationale कभी documented नहीं था, reintroducing एक constraint violation जो original design solve किया था।

स्क्रीन 12: Design rationale जो Architect के head में lived

Watch OutDocumentation5 मिनट Design rationale जो Architect के head में lived

Setupएक Architect जो हर design decision पर present था सभी के लिए rationale hold करता है। इसे नीचे लिखना redundant महसूस होता है जब आप पहले से ही जानते हैं, और documentation से अधिक urgent हमेशा कुछ है। वह बिल्कुल कैसे rationale person के साथ छोड़ता है।

एक postmortem: एक financial-services handoff जहां rationale कभी page तक नहीं बनाया इस case में, original Architect launch के बाद बारह सप्ताह एक mid-sized financial-services engagement छोड़ता है। उनका replacement एक thorough architecture diagram को inherit करता है rationale के साथ attached नहीं। एक performance issue एक proposal को prompt करता है context strategies को switch करने के लिए, replacement switch बनाता है, और यह एक data-handling pattern को reintroduce करता है जो deployment के data-residency constraint को violate करता है। Postmortem failure को trace करता है एक single row के लिए जो missing था। यह है कि record में क्या दिखता है।

StageWhat happenedWhat the document carried

LaunchOriginal Architect एक context strategy design करता है specifically regulated data को in-region रखने के लिए।एक architecture diagram showing final design। HandoffOriginal Architect week twelve में छोड़ता है। कोई design sessions recorded नहीं हैं।Diagram, rejected alternatives और rationale के साथ नहीं। ChangeReplacement एक performance issue hit करता है और context strategies को switch करता है इसे fix करने के लिए।कुछ भी explain नहीं करता कि original strategy क्यों chosen था। FailureSwitch एक data-handling pattern को reintroduce करता है जो data-residency rule को break करता है।Reason original design ने उस pattern को avoid किया केवल departed Architect के head में existed।

क्या टूटा: diagram showed क्या और lost क्यों Replacement competent था और reasonably acted information पर जो उनके पास था। Diagram उन्हें बताता है system क्या है, क्यों नहीं। Original context strategy एक deliberate choice था एक residency constraint को satisfy करने के लिए, और वह reasoning कभी written नहीं था एक decision के रूप में एक named ट्रेडऑफ और rejected alternative के साथ। Rationale documented के बिना, replacement नहीं बता सकता कि strategy जिसे वे change कर रहे थे load-bearing था compliance के लिए, इसलिए वे right decision को understandable wrong reason के लिए reverse किए।

यह क्यों टूटा: एक design बिना इसके rationale के एक design है जिसे safely change नहीं किया जा सकता Completeness test है कि क्या एक competent Architect जो room में नहीं था document को पढ़ने के बाद एक safe change बना सकता है। यहां answer नहीं था, और किसी को पता नहीं था जब तक production break नहीं हुआ। Decision, rejected alternatives, और ट्रेडऑफ को record करें प्रत्येक resolved। याद रखें यदि यह कभी written नहीं है, तो यह आपके साथ छोड़ता है।

स्क्रीन 13: चेकपॉइंट: documentation artifacts को place करें

Documentation · Checkpoint चेकपॉइंट: documentation artifacts को place करें

अभी कोशिश करें। Plane के दो axes हैं: एक "handoff recipient को serve करता है" से "compliance reviewer को serve करता है" तक चलता है, दूसरा "intention को documents करता है" से "evidence को documents करता है" तक। प्रत्येक छह artifact cards को उस zone में drag करें जो इसके primary function को best describe करता है।

Architecture diagram Decision log with rationale Control register with evidence links Deployment runbook Test-result summary Assumption register

← Handoff recipientCompliance reviewer →

Handoff · Intention

Compliance · Intention

Handoff · Evidence

Compliance · Evidence

↑ Documents intention / Documents evidence ↓

Placements की जांच करें Skip

स्क्रीन 14: Entry point selection full production picture के साथ returns, और outcome document काम को reusable IP में बदलता है

Entry Point & Outcomes Entry point selection full production picture के साथ returns, और outcome document काम को reusable IP में बदलता है यह topic covers करता है कि deployment कैसे routed था और क्या produce किया, काम को partner IP में बदलते हुए जो engagement को survive करता है। Entry point selection यहां returns करता है full production context के साथ।

Entry point question changes एक बार deployment live है एक से अधिक platform पर Earlier module ने route selection को introduce किया एक entry-point-and-compliance pre-filter के रूप में: direct Anthropic API, AWS Bedrock, GCP Vertex AI, और Microsoft Foundry प्रत्येक different partner procurement postures और regional compliance requirements को serve करते हैं। यह topic उस decision को return करता है full production context के साथ। Question अब नहीं है कौन सा route compliance pre-filter को survive करता है। यह है कौन सा route best perform करता है एक live multi-platform deployment के latency, cost, और compliance dimensions पर। क्योंकि entry-point capabilities change होती हैं, हर specific claim इस section में re-verified है platform. claude. com/docs और anthropic. com के विरुद्ध build time पर।

Cross-platform deployments problems को expose करते हैं एक single entry point कभी नहीं दिखाता एक deployment जो एक से अधिक entry point पर spans एक class of problems को expose करता है एक single-entry-point system नहीं दिखाता। Model identifier strings routes के across differ करते हैं। Feature availability एक route पर lag कर सकता है mediated by एक cloud service provider relative to direct API। Regional availability Bedrock और Vertex पर explicit configuration require करता है, और एक global endpoint को default करना common pattern है जो एक data-residency requirement को break करता है। एक Architect designing entry points के across को एक documented entry-point-responsibility map की आवश्यकता है integration code की पहली line लिखने से पहले।

एक multi-entry-point app को say करना चाहिए कौन सा entry-point कौन सा task owns करता है, और क्यों एक app जो multiple Claude entry-points को integrate करता है एक workflow में require करता है आप specify करें कौन सा entry-point कौन सा task handle करता है और reason। एक workflow जो API को back-end inference के लिए use करता है, Claude Code को एक engineering sub-task के लिए, और एक Bedrock endpoint को एक regulated data path के लिए unusual नहीं है enterprise scale पर। प्रत्येक entry-point boundary एक integration point है अपने authentication, logging, और failure-mode profile के साथ। Entry-point-responsibility map उन boundaries को explicit बनाता है और most common multi-entry-point failure को prevent करता है: एक entry-point chosen एक task के लिए gradually दूसरा take on करता है क्योंकि routing logic कभी documented नहीं था।

Outcome document value को legible बनाता है team के beyond जिसने इसे build किया Customer outcome documentation artifact है जो deployment के value को understandable बनाता है उन लोगों के लिए जो build पर नहीं थे। एक well-structured outcome document छह fields को cover करता है: use case और इसकी scope boundary, metric before deployment, metric after deployment, control जो result को auditable बनाता है, owner responsible ongoing measurement के लिए, और potential pattern को reuse करने के लिए अन्य customers या engagements के लिए। Technical metrics अकेले यह document नहीं बनाते। Before-and-after business outcomes और reuse notes वह हैं जो इसे एक reusable asset में बदलते हैं।

Deployment-entry-point decision matrix: Deployment entry-point decision matrix PlatformLatency profileCompliance postureWhen to pick it

Direct Anthropic APINewest features first, fewest additional hops के साथ।Strong default लेकिन coverage को configuration द्वारा confirm करें।Default द्वारा use करें जब तक एक procurement या residency rule कहीं और point नहीं करता। AWS BedrockRegion-configurable, possible feature lag versus direct के साथ।Fits AWS-centric procurement और region rules जब explicitly configured।Partner AWS पर standardized और in-region execution को need करता है। GCP Vertex AIRegion-configurable, possible feature lag versus direct के साथ।Fits GCP-centric procurement और region rules जब explicitly configured।Partner GCP पर standardized एक Vertex procurement path के साथ। Microsoft Foundry (Azure) routeVaries hosting form द्वारा: Hosted-on-Azure models inference को partner के Azure environment में run करते हैं (GA); hosted-on-Anthropic models Anthropic infrastructure को route करते हैं।Verify residency और coverage per route, और platform name से assume मत करें।Partner procurement या residency posture उस specific route को require करता है।

Partner TrackThe "reuse pattern अन्य customers या engagements के लिए" framing और Reuse-potential field template में नीचे Partner-Track relevant content हैं; बाकी outcome document on-blueprint है (6. 4)। Customer outcome documentation template: Customer outcome documentation template FieldWhat it records

Use case with scope boundaryDeployment क्या करता है और क्या नहीं। Metric beforeBusiness metric जैसा यह deployment से पहले stood। Metric afterSame metric deployment के बाद, same definition का उपयोग करके measured। Control in placeWhat makes before-and-after comparison auditable rather than merely asserted। Measurement ownerWho owns ongoing measurement engagement close होने के बाद। Reuse potentialHow pattern अन्य customers या engagements को IP के रूप में transfer करता है।

लागत · जटिलता · जोखिम

लागत: गलत deployment platform pick करना या एक thin outcome document produce करना cheap है करना और expensive है undo करना: residency mismatch cutover को block कर सकता है, और एक metrics-only document expansion को justify नहीं कर सकता। जटिलता: Multi-platform routing integration points को multiply करता है, प्रत्येक अपने auth, logging, और failure profile के साथ। Entry-point-responsibility map एकमात्र चीज़ है जो उन्हें over time understandable रखता है। जोखिम: Expensive failure एक default configuration है जो quietly data residency को break करता है, या एक outcome document एक sponsor नहीं ले सकता एक CFO को क्योंकि यह कभी business value को capture नहीं किया।

स्क्रीन 15: Outcome document जिसने गलत चीज़ को measure किया

Watch OutEntry Point & Outcomes5 मिनट Outcome document जिसने गलत चीज़ को measure किया

Setupएक deployment जो एक controlled rollout के दौरान अच्छी तरह perform किया है इसके पीछे data है। एक Architect engagement को close कर रहा है सब कुछ है जिसे outcome document लिखने की आवश्यकता है। इसे quickly write करना observability stack से export करना सबसे आसान metrics से feel करता है सही कदम, और engagement over है किसी को notice करने से पहले कि document क्या नहीं कर सकता।

एक anecdote: outcome document जो CFO के पहले प्रश्न को survive नहीं कर सकता एक Architect एक customer outcome document produce किया observability stack से export करना सबसे आसान metrics का उपयोग करके: request volume, average latency, और error rate। Customer sponsor इसे अपने CFO को ले गया expansion को justify करने के लिए। CFO का पहला प्रश्न था deployment ने business terms में क्या save या produce किया, और document उत्तर नहीं दे सकता। दो fields जो इसे usable बनाते वे कभी fill नहीं हुए। यह है कि कैसे play out हुआ।

Sponsor opened document के साथ जैसा written: "यहां deployment है। चालीस हज़ार requests एक महीने, sub-two-second average latency, error rate आधे प्रतिशत के तहत।" CFO: "यह मुझे बताता है यह runs। यह हमारे लिए क्या किया? Claim processing times क्या थे इससे पहले, और अब क्या हैं? क्योंकि वह number है जो अधिक खर्च को justify करता है।" Sponsor के पास point करने के लिए कोई evidence नहीं था। Document measure किया कि system काम करता है, लेकिन यह measure नहीं किया कि यह क्या बदला।

क्या टूटा: document captured technical metrics बिना business outcomes के Volume, latency, और error rate real हैं और track करने के लिए worth हैं, लेकिन कोई भी एक business outcome नहीं हैं। Fields जो document को CFO conversation के लिए usable बनाते वे use case द्वारा targeted business metric पर before-and-after थे, claim-processing time, और control जो उस comparison को auditable बनाता है। Before number के बिना, कोई story नहीं है। Control के बिना, after number एक assertion है। Document complete था एक technical record के रूप में और useless था expansion के लिए एक case के रूप में।

यह क्यों टूटा: easy-to-export metrics शायद ही कभी वे हैं जो cost को justify करते हैं Observability stack आपके technical metrics को free collect करता है लेकिन बिना उन्हें data में anchoring के, आप left हैं dashboards के साथ जो informative दिखते हैं और mean nothing। लेकिन, outcome document एक different reader के लिए exist करता है, sponsor जिसे deployment को upward justify करना चाहिए। Before metric को start पर capture करें, name करें control जो comparison को auditable बनाता है, और reuse note जोड़ें, इसलिए document कर सकता है एक job जो एक technical dashboard नहीं कर सकता।

स्क्रीन 16: चेकपॉइंट: platform pick करें और required outcome fields

Entry Point & Outcomes · Checkpoint चेकपॉइंट: platform pick करें और required outcome fields

अभी कोशिश करें। आपको एक deployment scenario दिया गया है तीन variables के साथ: partner का primary cloud platform, deployment का regulatory obligation level, और primary performance constraint। तीन variables को set करें। एक decision model combination को एक recommended primary platform, एक secondary platform जहां एक applies, और दो outcome-document fields को map करता है combination को reusable होने के लिए।

Primary cloud platform

Select... AWS GCP Microsoft Foundry Direct (no cloud)

Regulatory obligation level

Select... None Moderate Strict

Primary performance constraint

Select... Latency-sensitive Cost-sensitive Compliance-sensitive

Your answer: primary platform

Select... AWS Bedrock GCP Vertex AI Microsoft Foundry Direct Anthropic API

Your answer: secondary platform

Select... Direct Anthropic API None required

Your answer: required outcome fields

Select... Control in place (auditable) + Measurement owner Metric before + Metric after Metric before + Metric after + Reuse potential

Recommended primary platform: Secondary platform: Required outcome fields for reuse:

उत्तर की जांच करें Skip

स्क्रीन 17: Cumulative: एक regulated multi-platform deployment को end to end architect करें

Module · Cumulative Cumulative: एक regulated multi-platform deployment को end to end architect करें

यहां एक self-contained brief है। एक regional healthcare network एक health-privacy obligation के साथ दो cloud platforms पर एक clinical documentation assistant को deploy कर रहा है। Original Architect rotate off है, और customer का CFO business value के लिए evidence पूछ रहा है। सात decisions के through काम करें order में। प्रत्येक एक last पर builds।

Brief Network दो states के across चलता है। Nurses patient interactions को dictate करते हैं, और assistant structured clinical note को draft करता है। एक licensed clinician को हर note को authorize करना चाहिए इससे पहले कि यह patient record तक पहुंचे। Deployment एक health-privacy obligation carry करता है एक audit-trail requirement और एक data-residency rule के साथ। Partner AWS पर standardized है लेकिन कुछ non-regulated back-end काम direct API पर चलाता है। आप deployment के चार सप्ताह में हैं, और CFO जानना चाहता है deployment क्या worth है।

Decision 1 · Discovery: Brief से, must-prove constraint को name करें जो सबसे अधिक architecture को shape करता है, और एक requirement row लिखें जो यह force करता है। (Discovery translation framework को apply करता है।)

Model answer को reveal करें Must-prove constraint: Health-privacy obligation audit-trail requirement के साथ। Requirement row: Deployment को एक auditable record produce करना चाहिए हर model-generated note का एक licensed clinician द्वारा reviewed, traceable specific interaction को, क्योंकि workflow एक formal proof obligation carry करता है एक health-privacy regime के तहत। Assumption to document: scope confirmed compliance के साथ design से पहले।

Decision 2 · Tradeoff framing: Network lowest-latency design के लिए पूछता है। Logging को trim करने के बीच ट्रेडऑफ को frame करें latency के लिए और audit trail को keep करना, तीन elements में reversal cost सहित। (Tradeoff translation map को apply करता है।)

Model answer को reveal करें Gain (trim logging): Faster perceived response; smoother clinician workflow। Give up: Per-interaction audit detail required health-privacy obligation को satisfy करने के लिए। Reversal cost: एक बार system latency gain के चारों ओर built है, logging को restore करना interaction layer को redesign require करता है, और कोई भी gap period एक compliance exposure create करता है जिसे disclosed और remediated होना चाहिए।

Decision 3 · Feedback loop: एक governance-table row define करें जो required output audit को एक stakeholder-review trigger पर map करता है schedule पर, independent किसी भी metric से। (Feedback-loop governance table को apply करता है।)

Model answer को reveal करें Signal: Periodic output audit health-privacy documentation standard के विरुद्ध। Trigger: Calendar-based (quarterly, per regulatory obligation), fires regardless eval scores या error rates के। Owner: Compliance lead। Action: Stakeholder समीक्षा audit record के साथ compliance officer को submitted।

Decision 4 · Documentation: एक decision-log row को name करें जिसकी absence आपके successor को एक compliance-load-bearing choice को reverse करने देता है और state करें rejected alternative जिसे यह carry करना चाहिए। (Documentation completeness checklist को apply करता है।)

Model answer को reveal करें Decision row: Context strategy, explicit in-region execution via Bedrock, न कि एक global endpoint। Rejected alternative: Global Bedrock endpoint simpler configuration के लिए। Tradeoff named: Simpler setup versus data-residency compliance। Why load-bearing: एक successor जो इस rationale को नहीं देखता एक performance issue को solve करने के लिए global configuration को revert करेगा और residency को break करेगा, बिल्कुल जैसे financial-services postmortem में।

Decision 5 · Entry point selection: Primary और secondary entry points को pick करें AWS standardization, एक strict obligation, और एक residency rule दिया, और configuration step को name करें जो common residency failure को prevent करता है। (Entry-point decision matrix को apply करता है।)

Model answer को reveal करें Primary: AWS Bedrock, configured explicit in-region execution के लिए (न कि global endpoint), क्योंकि partner AWS-standardized है और residency rule govern करता है। Verify specific compliance requirement (HIPAA BAA या data sovereignty) Bedrock configuration द्वारा satisfied है use में। Secondary: Direct API non-regulated back-end tasks के लिए जहां newest features matter और कोई residency rule apply नहीं करता। Configuration step: Bedrock client में region parameter को explicitly set करें, default endpoint resolution पर rely मत करें।

Decision 6 · Outcome document: Before-and-after business metric को name करें और auditable control जो document को CFO के expansion case के लिए usable बनाता है। (Customer outcome documentation template को apply करता है।)

Model answer को reveal करें Before metric: Average time nurse dictation से completed, clinician-authorized clinical note तक (baseline deployment से पहले measured)। After metric: Same metric post-deployment, same measurement definition का उपयोग करके। Auditable control: Clinician-authorization log, हर note एक timestamped authorization record है clinician, note, और interaction को tying करते हुए, before-and-after comparison को auditable बनाते हुए rather than asserted।

Decision 7 · Phase transition: Artifact को name करें जो इस brief के लिए next phase transition को gate करता है और judge करें कि क्या वह gate satisfied है। (Lifecycle-phase gating को apply करता है।)

Model answer को reveal करें Gate artifact: Outcome document before-and-after metric, auditable control, और measurement owner named के साथ, यह transition को gate करता है current deployment phase से expansion decision को CFO को ask किया जा रहा है। Judgment: Gate week चार पर yet satisfied नहीं है, before metric baseline से exist करता है, लेकिन after metric post-deployment runtime को require करता है measure करने के लिए। Outcome document completion को एक defined post-launch milestone पर schedule नहीं किया जा सकता। Correct action: measurement owner को name करें, confirm करें control logging है, और outcome document completion को एक defined post-launch milestone पर schedule करें।

सभी decisions को mark complete करें

स्क्रीन 18: Glossary

Wrap-up · Reference Glossary Key terms इस module के across used, alphabetical order में। एक term को expand करने के लिए click करें।

Control registerTable carried forward regulated-deployment काम से जो प्रत्येक regulatory obligation को एक technical control, एक accountable owner, और एक evidence artifact को map करता है एक reviewer inspect कर सकता है। Documentation में यह living record बन जाता है जो deployment के production life को govern करता है। Decision log (with rationale)Record प्रत्येक architectural choice का जो capture करता है न केवल decision लेकिन alternatives rejected और ट्रेडऑफ प्रत्येक resolved, इसलिए एक successor एक load-bearing decision को reverse नहीं करता एक understandable wrong reason के लिए। Deployment lifecyclePhases एक deployment चलता है through: discovery → design → handoff → monitoring → iteration। Discovery और tradeoff framing discovery-and-design काम करते हैं, feedback loop monitoring-and-iteration है, documentation handoff है, और entry-point selection outcome document के साथ loop को close करता है। Identifying phase एक decision belongs to है जो आपको judge करने देता है जब एक phase अगले के लिए ready है। DiscoveryStructured elicitation, एक बातचीत नहीं: एक three-step filter listen, translate, और write down का जो stakeholder के business goal को requirements, assumptions, और constraints में बदलता है design को build और measure किया जा सकता है। Documentation completenessTest कि क्या एक competent Architect जो room में नहीं था document को पढ़ने के बाद एक safe change बना सकता है। यह require करता है decision, rejected alternatives, ट्रेडऑफ प्रत्येक resolved, owner, और evidence artifact, और assumptions labeled as assumptions। Entry-point-responsibility mapDocumented record कि कौन सा Claude entry point (direct API, Claude Code, Bedrock, Vertex, Microsoft Foundry) कौन सा task owns करता है और क्यों, written integration शुरू होने से पहले। यह common multi-platform failure को prevent करता है एक entry point chosen एक task के लिए quietly दूसरा take on करता है क्योंकि routing कभी documented नहीं था। Evidence artifactConcrete proof कि एक control operating है, एक signed agreement, एक configuration screen, एक authorization record, या एक returned log query। एक control asserted एक design document में बिना artifact के एक claim है, proof नहीं। Feedback loopDecision layer जो observability stack के ऊपर बैठता है और answer करता है Signals → Triage → Decide → Act → Review, प्रत्येक signal को एक trigger, एक owner, और एक action से map करता है। Monitoring signals collect करता है; feedback loop decide करता है कौन से ones behavior को change करते हैं और किसके। Governance tablePre-launch table जो प्रत्येक production signal को इसके review trigger, Architect के action, और किसी भी scheduled regulated checkpoint से map करता है। यह mechanism है जो policy को एक operating routine में बदलता है और launch से पहले exist करना चाहिए। Joint scopingWorking session Anthropic Applied AI team के साथ choices को refine करने और specialist questions को resolve करने के लिए। आप arrive करते हैं requirements और constraints का एक documented view के साथ, एक proposed pattern या candidate set tradeoffs named के साथ, और एक short list of open questions केवल Applied AI team answer कर सकता है। Limit placementDeciding advance में कौन सी एक या दो limitations एक demo identify करेगा, और उन्हें intentional scope boundaries के रूप में frame करना। Regulated settings में एक upfront, clearly scoped boundary rigor signal करता है, जबकि एक discovered या deflected limitation confidence को erode करता है। Outcome documentArtifact जो deployment के value को legible बनाता है एक sponsor को जो build पर नहीं था। छह fields: use case scope boundary के साथ, metric before, metric after, auditable control, measurement owner, और reuse potential। Before-and-after business outcome और reuse notes वह हैं जो इसे एक reusable asset में बदलते हैं एक technical record के बजाय। Requirement vs assumptionRequirement कुछ trace करता है stakeholder actually कहा; assumption कुछ है design takes for granted जो कभी stated नहीं था। एक unsourced assumption सबसे dangerous kind है, क्योंकि किसी को याद नहीं है deciding इसे। Reversal costक्या cost होता है एक decision को undo करने के लिए एक बार system इसके चारों ओर built है, ट्रेडऑफ presentation का तीसरा element। यह element है जो most presentations omit करते हैं और वह है जो most often बैठक को change करता है, "क्या बेहतर technical answer है? " को "क्या बेहतर business choice है? " में बदलते हुए। Scenario-specific demoDemo built buyer के own workflow, data shapes, और constraints के विरुद्ध, यह answer करता है "यह मेरी problem के साथ क्या करता है? " एक capabilities demo के "यह system क्या कर सकता है? " के बजाय। केवल scenario-specific demo confidence create करता है mere interest के बजाय। SLA (Service Level Agreement)Commitment जो name करता है क्या measured है, क्या एक breach के रूप में counts करता है, और जब एक breach होता है तो क्या होता है। Thresholds एक tangible source को trace करते हैं, user-experience expectation, deployment की business criticality, या eval acceptance criteria, एक arbitrary target के बजाय। Tradeoff framingPresenting एक architectural decision ऐसे terms में एक stakeholder कर सकता है act on: क्या choice gains, क्या यह gives up, और क्या reversal cost होता है एक बार system इसके चारों ओर built है (plus, regulated settings में, क्या यह compliance posture को करता है)। Goal है एक informed decision को possible बनाना, एक verdict deliver करने के बजाय। Translation (discovery)Core discovery move: converting एक stakeholder preference ("seamless," "fast," "simple") एक testable, bounded constraint में asking द्वारा क्या experience को break करेगा, user को क्या कभी नहीं देखना चाहिए, और क्या still true होना चाहिए जब कुछ गलत होता है। Translation tableOutput discovery का: एक item per row capturing stakeholder statement जैसा said, implied constraint, required architectural decision, और कोई assumption being documented जब तक confirmed नहीं। एक item per row reasoning को intact रखता है जैसे काम discovery से design में जाता है, और यह assumptions को top of mind रखता है।

स्क्रीन 19: Recap: पाँच चीजें जो यहां सब कुछ के across hold करती हैं

Module · Recap · 3 मिनट Recap: पाँच चीजें जो यहां सब कुछ के across hold करती हैं

Key takeaways

01

Structured discovery Discovery को एक four-category process के रूप में चलाएं, हर preference को एक constraint में translate करें, और प्रत्येक item को एक requirement row के रूप में लिखें इसके assumption labeled के साथ, इसलिए design business case को trace करता है।

02

Communicating tradeoffs और GTM हर ट्रेडऑफ को तीन elements में present करें reversal cost सहित। Partner Track[Partner-Track Relevant, Architect परीक्षा द्वारा tested नहीं] Demo को buyer के real scenario के विरुद्ध design करें limitations identified first के साथ, और joint scoping में walk करें requirements, candidate patterns, और open questions के साथ hand में।

03

Feedback loops और SLA management Decision layer build करें जो signals को trigger actions को owners से map करता है, SLA thresholds को उनके real sources से set करें, और regulated checkpoints को एक schedule पर run करने के लिए wire करें।

04

Documentation for handoff और audit Decision, rejected alternatives, और ट्रेडऑफ को write करें प्रत्येक resolved जबकि आप अभी भी reasoning hold करते हैं, और control register को forward carry करें evidence के रूप में एक reviewer accept करेगा।

05

Entry point selection और outcomes Route को latency, compliance, और cost पर choose करें एक entry-point-responsibility map के साथ multi-entry-point designs के लिए, और before metric, auditable control, और reuse note को capture करें इसलिए outcome document expansion को justify करता है।

अगला module team enablement और operational productivity को cover करता है: एक team के लिए Claude tooling को configure करना, developer workflows को build करना जो AI-assisted काम को trustworthy रखते हैं, और एक live deployment की operational health को support करना। आप अब एक deployment को एक stakeholder के पहले वाक्य से एक outcome document तक ले जा सकते हैं जो engagement को outlive करता है। अगला module cover करता है क्या होता है एक बार आप उस deployment को team को hand करते हैं जो इसे चलाता है।

Sources

Building with the Claude API (Skilljar): stateless request lifecycle, system prompts, evals और graders, tool use, RAG, prompt caching, code execution। Claude 101 (Skilljar): general Claude capabilities और everyday-use framing। (Claude 101 नहीं carry करता model-family या context-window teaching per live catalog; वे concepts platform documentation को trace करते हैं; verify current model lineup publish time पर।) AI Capabilities और Limitations (Skilljar): four-properties decision lens carried forward earlier modules से। platform. claude. com/docs: model names, platform capabilities, route availability, residency configuration। Build time पर re-verify करें। Anthropic partner program documentation: partner GTM stage definitions, IP-contribution protocols। Anthropic Applied AI team documentation: joint-scoping engagement structure और preparation inputs।

स्क्रीन 20: बधाई! आपने successfully इस module को complete किया है।

Module Complete · Architect · 2 मिनट बधाई! आपने successfully इस module को complete किया है। Module 4 stakeholder communication, lifecycle governance, और go-to-market decisions को cover करता है जो एक working AI deployment को एक defensible, scalable business asset में बदलते हैं। Deployment केवल उतना ही durable है जितना documentation, governance, और outcome evidence जो इसे surround करता है।

0 of 0 checkpoints passed

M1

Claude Platform & Solution Design Model selection, prompt architecture, tool design, और platform-layer tradeoffs।

M2

Enterprise Integration & Production Deployment patterns, integration architecture, और production reliability।

M3

Responsible AI, Safety & Risk Safety frameworks, risk identification, और governance practices।

M4

Stakeholder Engagement, Lifecycle & Go-to-Market Stakeholder communication, lifecycle management, और go-to-market strategy।

You Are Here

M5

Team Enablement और Operational Productivity Team tooling configuration और operational support practices।

Up Next

Review module Start over