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

De laatste drie modules hebben je van een bedrijfsprobleem naar een ontworpen, geïntegreerde, beheerde Claude-implementatie gebracht. Je kunt een verzoek opsplitsen, een patroon kiezen, een use case dimensioneren, evals als acceptatiecriteria bouwen, observeerbaarheid instrumenteren en een controleset voor een gereglementeerde workload opzetten. Wat dat allemaal niet heeft opgelost, is het deel van het werk dat in kamers met stakeholders gebeurt: het ontdekkingsgesprek waar de echte vereisten worden gesteld, de goedkeuringsvergadering waar een afweging wordt gewonnen of verloren, de overdracht waar je ontwerp ofwel je afwezigheid overleeft ofwel stilletjes verslechtert.

Deze module behandelt dat werk. Aan het einde kun je: 1 Een gestructureerd ontdekkingsgesprek met een niet-technische stakeholder voeren en wat je leert vertalen in architectuurvereisten en gedocumenteerde aannames, zodat het ontwerp teruggaat naar de business case in plaats van naar je eigen technische voorkeur. 2 Een architectuurafweging presenteren in termen die een business stakeholder kan actie op ondernemen door elke keuze te koppelen aan een kosten, een risico en wat een omkering zou kosten, zodat executive en procurement reviews tot een besluit komen in plaats van vast te lopen. 3 Een stakeholder feedback loop bouwen en bedrijven over de implementatielifecycle door te benoemen wat review triggert, wat een SLA-schending vereist, en wanneer je moet itereren versus herarchitecteren, met governance checkpoints ingebouwd in dezelfde loop. 4 PARTNER TRACK[Partner-Track Relevant, niet getest door het Architect-examen; behouden voor partner-track leerlingen] De rol van de Architect leiden in een partner go-to-market motion door ontdekking, een scenario-gebaseerde demo, technische inwerphantering en gezamenlijke scoping met het Anthropic Applied AI team, zodat een enterprise opportunity niet vast loopt op vragen die alleen jij kunt beantwoorden. 5 Het implementatie-ingangspunt en cross-platform strategie selecteren voor een multi-platform productiesysteem door de directe API, Bedrock, Vertex en third-party routes te vergelijken op latentie, compliance en kosten, en vervolgens een resultaatdocument produceren dat de waarde duidelijk maakt voor een niet-technische sponsor en herbruikbaar is als partner IP. Het werk sluit aan op de secties die volgen:

Discovery is waar je een stakeholder voorkeur omzet in een gedocumenteerde constraint waarop de architectuur kan worden ontworpen. De zet is vertaling: een voorkeur geeft aan dat meer vragen nodig zijn in plaats van als directe vereiste te functioneren. Een bruikbare vereiste is testbaar en begrensd. De kostbare mislukking is een ontdekkingsgesprek dat eindigt in een ontwerpschets voordat de vertaling klaar is. De aannemelijke schets is wat het gevaarlijk maakt: een stakeholder die een zelfverzekerde architectuur ziet, gaat ervan uit dat de vragen zijn beantwoord.

Afwegingskader en go to market is waar je een architectuurbesluit presenteert in termen waarop een stakeholder kan handelen, en waar je een demo ontwerpt tegen het echte scenario van de koper in plaats van de eigen mogelijkheden van het team. Drie elementen horen in elke afweging presentatie: wat de keuze wint, wat het opgeeft, en wat omkering kost zodra het systeem eromheen is gebouwd. Het derde element is degene die de vergadering verandert, en het is degene die de meeste presentaties missen.

De feedback loop is waar je de besluitlaag bouwt die boven de observeerbaarheidsstack zit en bepaalt welke signalen gedrag veranderen en van wie. Een feedback loop is een governance tabel die elk signaal toewijst aan een trigger, een eigenaar en een actie. In gereglementeerde implementaties vuren sommige reviews op schema in plaats van op drempel. Die governance rijen moeten op hun plaats zijn voordat de lancering plaatsvindt. Als er geen gedefinieerde trigger is, zal een compliance checkpoint niet naar boven komen totdat een reviewer naar het record gaat zoeken.

Documentatie voor overdracht en audit is waar je niet alleen de besluiten die zijn genomen opneemt, maar ook de alternatieven die zijn verworpen en de afweging die elk heeft opgelost. De volledigheidstest is of een competente Architect die niet in de kamer was, veilig een wijziging in het systeem kan aanbrengen na het lezen van het document. Een diagram toont wat het systeem is. Zonder de motivering voor de besluiten, kan het diagram de opvolger niet vertellen welke keuzes draagvermogen hebben en welke gewoon voorkeuren zijn. Op het moment dat je het engagement verlaat, is het moment dat die redenering weg is als het nooit is gedocumenteerd.

Entry point selectie en het resultaatdocument is waar je de juiste implementatieroute voor een live productiesysteem bevestigt en de resultaten van de implementatie omzet in een artefact dat het engagement overleeft. Het resultaatdocument maakt de business case voor een lezer die niet deel uitmaakte van de bouw. Volume, latentie en foutpercentage vertellen een sponsor dat het systeem draait. Een voor-en-na op de business metric die de use case beoogde, ondersteund door een controleerbare controle, vertelt een CFO wat het waard is om uit te breiden.

Deze vijf onderwerpen zijn niet onafhankelijk, in feite bouwt elk voort op het vorige. De constraint set uit discovery is wat de afweging presentatie verdedigt. De feedback loop governance tabel houdt de compliance controls die in het register zijn vastgelegd actueel terwijl de implementatie draait. De documentatie motivering houdt de besluiten die het register bevat van stilletjes omgekeerd te worden door een opvolger. Het resultaatdocument put uit elke laag erboven om de waarde begrijpelijk te maken voor een lezer die het werk nooit zag. De cumulatieve taak aan het einde vraagt je om een gereglementeerde multi-platform implementatie van de eerste zin van een stakeholder naar een resultaatdocument te nemen dat uitbreiding rechtvaardigt. Dit is eigenlijk precies wat deze module je in staat stelt om te doen voordat je overdraagt.

Over deze vijf onderwerpen loopt de projectlifecycle zelf: discovery → design → handoff → monitoring → iteration. Discovery en afwegingskader doen het discovery-en-design werk; de feedback loop is de monitoring-en-iteration fase; documentatie is de handoff fase; en entry-point selectie met het resultaatdocument sluit de loop. Het identificeren van de fase waar een besluit bij hoort, is wat je laat oordelen wanneer één fase klaar is om naar de volgende over te gaan.

DISCLAIMER / NOTICE FOR EDUCATIONAL CONTENT

We hebben deze Architect course Module 4: Stakeholder Engagement, Lifecycle, and Go-to-Market gebouwd om je echt werk met Claude te helpen doen. Behandel het als educatieve inhoud. Het vormt geen juridisch, financieel of ander professioneel advies, dus pas wat je leert aan je eigen situatie. Onze producten en services evolueren snel, dus bepaalde inhoud kan fouten bevatten of verouderd zijn; vergeet niet om te verifiëren op de website of docs van Anthropic. Voorbeelden en scenario's die in de cursus worden gebruikt, zijn illustratief en vaak fictief. Als de cursusmateriaal een bedrijf of product noemt, betekent dit niet dat Anthropic ze aanbeveelt, zij Anthropic aanbevelen, of dat we geaffilieerd zijn. Houd er ook rekening mee dat je gebruik van Anthropic producten en services wordt gedekt door onze voorwaarden, beleid en documentatie; als iets in deze cursus daarmee in conflict is, hebben zij voorrang.

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

Discovery A discovery call is a structured elicitation, not a conversation Je weet hoe je het patroon, het implementatieplatform en de controlestelling kunt evalueren. Discovery onthult of je het juiste probleem oplost. Een stakeholder zal het probleem meestal in bedrijfstermen beschrijven. Je taak is luisteren naar wat het bedrijf wil bereiken, de constraints identificeren die in die beschrijving verborgen zitten, en het gesprek verlaten met een record dat het ontwerp kan volgen.

Discovery stelt de artefacten vast waarop het ontwerp afhangt Een ontdekkingsgesprek functioneert als een drietraps filter: luisteren, vertalen en opschrijven.

1Luister eerst naar het bedrijfsdoel in gewone taal en let op de betekenis achter het woord. Stakeholders beschrijven meestal het resultaat dat ze willen, maar niet de constraint die je nodig hebt om voor te ontwerpen. 2Vertaal dat vervolgens in vereisten, aannames en onopgeloste constraints. Dit stelt je in staat om te zien wat het ontwerp moet ondersteunen, wat nog bevestiging nodig heeft, en wat de oplossing later kan blokkeren. 3Schrijf die items op voordat het gesprek verder gaat. Het ontwerp heeft een duidelijk record nodig. Zonder dat filter erft het ontwerp je aannames. De mismatch kan pas veel later worden onthuld, wanneer het veranderen van koers langzamer, moeilijker en duurder is.

De kernzet is vertaling: een gestelde voorkeur verbergt bijna altijd een constraint De belangrijkste vaardigheid in discovery is vertaling. Stakeholders spreken meestal in voorkeuren, maar ontwerpbeslissingen worden genomen tegen constraints. Stel je voor dat een stakeholder zegt: "We willen dat dit naadloos aanvoelt. " Als je "naadloos" als vereiste opschrijft, heb je niet genoeg geleerd om iets te ontwerpen. Je hebt alleen de samenvatting van de stakeholder van de ervaring die ze willen.

Het echte werk begint met de volgende vraag: wat zou het niet naadloos laten aanvoelen? Dat is waar de verborgen constraints beginnen te verschijnen. Misschien zou de gebruiker nooit meer dan een seconde of twee moeten wachten op de volgende stap. Misschien zouden ze geen informatie opnieuw moeten invoeren die al upstream bestaat. Misschien zouden uitzonderingen stilletjes naar een menselijke reviewer moeten gaan in plaats van een technische fout bloot te stellen. Misschien moet de workflow in één applicatie blijven, zodat de gebruiker nooit tussen tools hoeft te springen. Elk antwoord scherpt het ontwerp aan.

Die uitwisseling transformeert "naadloos" in vereisten die de architectuur moet ondersteunen: een latentiedoel, een integratievereiste, een handoff regel en een veilig foutpad. De stakeholder noemt het resultaat in bedrijfstaal. Jij zet het om in iets dat het systeem kan bouwen en meten.

De voorkeur zit op het topniveau, en de constraint zit eronder. Wanneer een stakeholder je een ervaringswoord geeft zoals naadloos, gemakkelijk, snel, eenvoudig of intuïtief, behandel het als een signaal dat meer discovery nodig is. Vraag wat die ervaring zou breken, wat de gebruiker nooit mag opmerken, wat achter de schermen moet gebeuren, en wat nog waar moet zijn wanneer iets misgaat. Die antwoorden zijn wat in het ontwerprecord hoort.

Een testbare, begrensde constraint is wat het ontwerp tegen kan worden gebouwd. Een stakeholder voorkeur vertelt je waar je moet onderzoeken, terwijl de vervolgvragen de constraint zelf produceren.

Vier vragen zetten discovery om in vereisten Discovery werkt het beste wanneer je een vage stakeholder verklaring in de vier buckets hieronder forceert. Een verklaring als "we willen dat dit naadloos aanvoelt" is nog niet iets wat je tegen kunt ontwerpen. Het verbergt meestal een of meer specifieke antwoorden. Onderzoek het volgende:

1Wat het systeem moet doen. Dit zijn de mogelijkheden die de implementatie moet leveren, uitgedrukt als bedrijfsresultaten in plaats van functies. Dit is waar je het werk scheidt dat Claude bezit van het werk dat bij een bestaand systeem of een mens blijft. 2Wat het systeem niet mag doen. Dit zijn de grenzen, verboden acties en gevallen die naar een mens moeten gaan. Stakeholders bieden deze zelden aan, dus je moet er expliciet naar vragen. 3Wat moet het systeem kosten. Dit is de budgetconstraint, uitgedrukt in termen die de stakeholder controleert. Een latentiedoel, een plafond per interactie of een volumeprognose moeten allemaal in aanmerking worden genomen. Deze worden cruciale ontwerpconstraints. 4Wat moet het systeem bewijzen. Dit is het bewijs dat de implementatie moet kunnen produceren iets van waarde. In gereglementeerde workflows maken bewijsverplichting deel uit van de vereisteset. Ze in discovery identificeren is veel goedkoper dan tijdens een juridische beoordeling weken later.

"Naadloos" kan echt betekenen een latentiebudget dat de gebruiker niet mag opmerken, een handoff die de flow niet mag onderbreken, of een foutstatus die systeeminternals niet mag blootstellen. Zodra je die antwoorden ontdekt, heb je vereisten die het team kan ontwerpen, testen en verdedigen.

De output van discovery is een vertaaltabel Elk item dat in discovery is gevonden, wordt één rij in een vertaaltabel. De rij legt de stakeholder verklaring vast zoals deze werd gezegd, de constraint die het impliceert, de architectuurbesluit die die constraint forceert, en elke aanname die je documenteert wanneer de constraint nog niet is bevestigd. Één rij per item houdt de redenering intact terwijl het werk van discovery naar ontwerp gaat, en het houdt aannames in het achterhoofd.

Stakeholder verklaringGeïmpliceerde constraintVereiste architectuurbesluitAanname van document

"We willen dat dit naadloos aanvoelt. "De ervaring moet binnen een afgesproken latentiebudget blijven. Fouten mogen systeeminternals niet blootstellen of de flow niet breken. Stel een p95 latentiedoel in als een ontwerpconstraint, ontwerp vervolgens een gracieuze, intern-veilige foutstatus. Gaat ervan uit dat "naadloos" verwijst naar waargenomen responsiviteit en continuïteit van flow. Bevestig begrip. "Het hoeft alleen het formulier te lezen en het door te sturen. "Routering kan een deterministische bedrijfsregel zijn. Houd de routeringsbesluit in de regelmotor. Claude extraheert, en het systeem routeert. Gaat ervan uit dat de routeringslogica buiten het model wordt bezeten en onderhouden. Bevestig eigenaar. "Clinici zullen de output toch beoordelen. "Een gelicentieerde mens moet output autoriseren voordat het deel wordt van een record met juridische, financiële of klinische gevolgen. Bouw een human-in-the-loop autorisatiestap als een verplichte checkpoint. Gaat ervan uit dat review een architectuurpoort is. Bevestig autoriteit en timing. "We zijn in de gezondheidszorg, dus wees voorzichtig met gegevens. "De workflow draagt waarschijnlijk een bewijsverplichting onder een gezondheidsgeheimregime. Behandel audit-trail en data-handling bewijs als een kernvereiste vanaf dag één. Gaat ervan uit dat een gedekte workflow met een formele verplichting. Bevestig bereik met compliance.

Cost · Complexity · Risk

Cost: Een ontdekkingsgesprek dat lang genoeg duurt om de echte constraints te identificeren, is veel goedkoper dan het herontwerpen van de oplossing nadat een verborgen constraint tijdens een juridische of compliance beoordeling naar voren komt. Complexity: Het doorwerken van de vier vraagcategorieën voegt noodzakelijke structuur toe, en het vertalen van voorkeuren in constraints in real time vereist doelbewuste oefening. Risk: De dure mislukking is de onuitgesproken constraint die de test overleeft en een productiebeoordelingsblocker wordt, wanneer de kosten van het veranderen van het ontwerp op het hoogste punt zijn.

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

Watch OutDiscovery5 min The discovery call that turned into a design session

SetupDiscovery is waar het werk begint. Design is waar het versnelt. Een goed Architect begint halverwege het gesprek een oplossing te vormen. Schetsen en visualiseren voelt productief, en de stakeholder lijkt blij met de vooruitgang. Dat is precies het moment dat de vragen stoppen.

Een gereconstrueerd ontdekkingsgesprek, waar de vragen vroeg stopten In de uitwisseling hieronder hoort de Architect twee stakeholder verklaringen en begint een oplossing voor te stellen. De stakeholder bevestigt het initiële voorstel omdat het competent klinkt. De constraints die die architectuur zouden hebben uitgesloten, worden nooit geïdentificeerd. Ze verschijnen twee weken later tijdens een compliance beoordeling. Dit gedeelte toont precies waar de vraag die elke constraint zou hebben gevangen, hoorde. Gebruik dit voorbeeld om het patroon in je eigen gesprekken te herkennen.

Gereconstrueerde uitwisseling

Stakeholder: "We runnen een regionaal ziekenhuisnetwerk. Verpleegkundigen besteden eeuwig aan het schrijven van patiëntinteracties. We willen dat Claude het klinische notitie uit hun dictaat ontwerpt. " Architect: "Begrepen, dat is gewoon een schoon augmented patroon. Claude neemt het dictaat, ontwerpt de gestructureerde notitie, schrijft het dan terug. We kunnen volgende week een prototype hebben. " Stakeholder: "Dat klinkt goed. Er is ergens een beoordelingsstap, maar het is gewoon een snelle controle. " Architect: "Zeker, we voegen een beoordelingsstap toe. Laat me met het ontwerp beginnen. "

Verschillende constraints die te laat zijn geïdentificeerd om gemakkelijk te repareren De "snelle controle" was geen gemaksfunctie. De verpleegkundige workflow vereiste dat een gelicentieerde clinicus elke modeloutput autoriseerde voordat deze het patiëntrecord bereikte. Dit maakte menselijke autorisatie een vereiste architectuurpoort in plaats van een optionele toevoeging. Het dictaat bevatte beschermde gezondheidsinformatie. Beschermde gezondheidsinformatie verplaatste zich door het context window zonder de verwerking die de workflow vereiste. Het netwerk strekte zich over twee staten met verschillende recordretentieregels, en het single-region ontwerp hield rekening met geen van beide. Geen van deze vereisten waren ongebruikelijk of moeilijk te vinden. Elk zou uit een directe vraag in de must-prove en must-not-do categorieën zijn gekomen, als het gesprek niet naar schetsen was gegaan voordat die vragen werden gesteld.

Waarom dit brak: een competente schetsvoorstel beëindigde de vragen die een ontdekkingsgesprek moet stellen De schets was aannemelijk, en aannemelijkheid is wat dit gevaarlijk maakt. Een stakeholder die een zelfverzekerde architectuur hoort, gaat ervan uit dat de Architect de informatie heeft om het te bouwen. De zet die je beschermt is saai: voltooi de vier-categorie vraagset voordat je iets voorstelt en behandel elke "het is gewoon een review" als een constraint om na te jagen.

Screen 4: Checkpoint: find the undocumented assumption

Discovery · Checkpoint Checkpoint: find the undocumented assumption

Probeer het nu. Hieronder staat een ontdekkingsgesprek samenvatting en het vereistendocument dat een Architect ervan maakte. Drie items traceren terug naar iets dat de stakeholder zei; één is een aanname die de Architect maakte zonder de constraint eronder bloot te stellen. Kies het item dat de ongedocumenteerde aanname is, bevestig vervolgens dat geen stakeholder verklaring het ondersteunt.

Vereistendocument

• Claude ontwerpt de klant e-mail, maar een persoon stuurt het daadwerkelijk.
• Reacties moeten binnen een twee seconden waargenomen budget terugkeren.
• Terugbetalingen boven de drempel gaan naar een menselijke goedkeurder.
• Gespreksafschriften worden zestig dagen bewaard voor analytics.

Wat de stakeholder zei

"Alles groots vereist goedkeuring van een persoon. " "Ontwerp het antwoord, maar we sturen het zelf. " "Het moet instant aanvoelen voor de gebruiker. "

Part 1: Welk item is de ongedocumenteerde aanname?

AItem 1, e-mail ontwerp met menselijke verzending BItem 2, twee seconden latentiebudget CItem 3, terugbetalingsrouting naar menselijke goedkeurder DItem 4, zestig dagen transcript retentie

Part 2: Welke stakeholder verklaring zou item 4 naar moeten traceren?

A"Ontwerp het antwoord, maar we sturen het zelf. " B"Het moet instant aanvoelen voor de gebruiker. " C"Alles groots vereist goedkeuring van een persoon. " DGeen stakeholder verklaring ondersteunt dit item.

Check answer Skip

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

Tradeoffs & GTM Present a tradeoff so the stakeholder can act on it, and design a demo that advances the deal Discovery vertelde je wat de koper nodig heeft. Die vereisten omzetten in een besluit dat een stakeholder kan nemen, is het volgende werk.

De Architect helpt nu de stakeholder de afweging te begrijpen, de bedrijfsgevolgen te zien en met vertrouwen een weg naar voren goed te keuren.

Je taak is niet om de afweging voor de vergadering op te lossen. Je taak is om besluiten mogelijk te maken. Je taak is om de opties duidelijk genoeg te beschrijven zodat de stakeholder een geïnformeerde keuze kan maken. Elke betekenisvolle ontwerpbesluit heeft een afweging. Één optie kan kosten of complexiteit verminderen maar latentie, risico of compliance belasting verhogen. Een ander kan de gebruikerservaring verbeteren of beter schalen maar meer inspanning vooraf vereisen. Als je alleen de conclusie presenteert, kan het besluit duidelijk lijken, maar het is zwak. Wanneer de downside later verschijnt, kan de stakeholder voelen dat ze een aanbeveling hebben goedgekeurd zonder te begrijpen wat ermee kwam. Dus gebruik een eenvoudig besluitkader:

1Wat winnen we? 2Wat geven we op? 3Wat gebeurt er als we dit nu kiezen maar het later moeten omkeren? 4In gereglementeerde omgevingen, wat doet dit met onze compliance positie?

Die derde vraag is degene die de meeste mensen overslaan, en het is vaak degene die de vergadering verandert. Het verandert de discussie van "wat is het betere technische antwoord? " in "wat is de betere bedrijfskeuze? " Technische precisie is noodzakelijk, maar het is niet voldoende. In architectuurbeoordelingen is de aanbeveling vaak technisch correct maar nog steeds niet begrijpelijk voor de persoon die het moet goedkeuren. De Architect kan de opties in technische woordenschat uitleggen (d. w. z. latentie, logging diepte, context grootte, retrieval patroon, implementatieroute) maar de executive stelt een eenvoudiger vraag: "Wat gebeurt er met het bedrijf als we de verkeerde keuze maken? " Op dat moment heeft de kamer niet meer detail nodig, wat het nodig heeft is vertaling in iets wat een persoon kan begrijpen. Wanneer je dit goed doet, hoort de stakeholder niet alleen je aanbeveling. Ze nemen een geïnformeerd besluit dat ze later kunnen verdedigen.

Frame het besluit als een pakket, in plaats van als een vonnis Presenteer het besluit als een pakket dat de stakeholder kan actie op ondernemen: de opties die je hebt overwogen, de criteria die je tegen hebt gewogen, je aanbeveling, en de risico's die blijven. De stakeholder neemt je architectuur niet aan; ze accepteren een besluit dat ze aan hun eigen leiderschap moeten verdedigen.

Beschrijving is de competentie die het pakket doet landen Beschrijving is een van de vier AI Fluency competenties: effectief communiceren met AI. Uitgebreid naar de stakeholder kant van het werk, betekent dezelfde discipline precies vertellen wat het publiek nodig heeft, in termen die ze kunnen begrijpen. Toegepast op stakeholder communicatie, betekent Beschrijving het gedrag van het systeem, zijn grenzen en het toezicht eromheen in de stakeholder doelterm framen. De framing moet aansluiten bij hun AI bekendheid zonder nauwkeurigheid op te offeren. Drie regels gelden in de praktijk: begin met het bedrijfsresultaat in plaats van de architectuur; frame beperkingen eerlijk, omdat een security stakeholder een systeem vertrouwt waarvan de grenzen duidelijk zijn gesteld; en anticipeer op de peer-proof vraag, omdat de stakeholder de keuze aan anderen moet rechtvaardigen en de kamer met die rechtvaardiging moet verlaten.

Gebruik de afweging vertaaltabel om van architectuur framing naar stakeholder besluitstaal te verschuiven.

ArchitectuurbesluitWat je wintWat je opgeeftWat een verkeerde, omgekeerde keuze kost

Groter context window per call versus retrieval over chunksEenvoudiger initieel ontwerp, het volledige document in zicht, en minder bewegende delen om vroeg te beheren. Hogere per-call kosten en langzamere reactietijden naarmate de productie volume groeit. Prompt caching kan een aanzienlijk deel van de input kosten voor statische inhoud zoals beleidsdocumenten in context over call herstellen, dus evalueer caching voordat je per-call kosten als vast behandelt. Het herontwerpen van de architectuur nadat kosten in productie stijgen, plus de geloofwaardigheidsklap van het uitleggen van een vermijdbare kostenverrassing. Trade logging details voor lagere latentieSnellere waargenomen respons en een soepelere eindgebruiker ervaring. Verminderde zichtbaarheid in wat in elke interactie gebeurde. In een gereglementeerde workload, een mogelijke compliance gat dat remediation vereist. Enkele leveringsroute versus multi-platformLagere bouwcomplexiteit en één consistent authenticatie en logging profiel. Minder flexibiliteit om verschillende regionale, compliance of procurement behoeften te vervullen. Een vertraagde of geblokkeerde productie cutover als de gekozen route een laat-opkomende data residency of implementatie vereiste niet kan vervullen.

De kaart bestaat om de stakeholder te helpen de gevolgen van hun keuze duidelijk genoeg te zien om te beslissen.

Demo design is een aparte vaardigheid, en een zwakke demo kan ongedaan maken wat discovery heeft opgeleverd Stel je de kopervergadering voor waar discovery goed ging. Het team stemde in met het probleem, de use case en de waarde op het spel. Dan begint de demo. In plaats van de wereld van de koper te tonen, toont het een gepolijste maar generieke set functies. De reactie is meestal beleefd, dat de demo interessant was, maar niet helemaal wat ze zich voorstelden.

Een zwakke demo kan de koper doen twijfelen of het team het kernprobleem begreep. Dit gebeurt wanneer teams twee verschillende banen verwarren. Een capabilities demo antwoordt: "Wat kan dit systeem doen? " Een scenario-specifieke demo antwoordt: "Wat doet dit systeem met mijn probleem, mijn workflow en mijn constraints? " De eerste creëert interesse; alleen de tweede creëert vertrouwen. Het ontwerpen van bewijs dat de oplossing in de context van de koper past, is onderdeel van de taak van de demo. Een goed ontworpen demo brengt de kans naar voren terwijl een zwakke de vertrouwen die discovery heeft opgebouwd kan ongedaan maken.

Partner TrackNiet getest door het Architect-examen Voordat je schermen bouwt, maak vier ontwerpbeslissingen. Die besluiten bepalen of de demo zich op maat gevoeld en geloofwaardig voelt of generiek en gemakkelijk af te doen.

OntwerpbesluitWat de Architect beslistWaarom het het resultaat bepaalt

Scenario selectieKies een workflow die de koper onmiddellijk zal herkennen uit hun eigen activiteiten, inclusief vertrouwde gegevensvormen, goedkeuringsstappen en edge cases. Vermijd een generieke documenttaak of abstracte querystroom. Kopers vertrouwen wat vertrouwd aanvoelt. Wanneer ze hun eigen woordenschat en foutpunten op het scherm zien, voelt de demo relevant en geloofwaardig. Herkenning is vaak overtuigender dan een gepolijste maar generieke functietour. Limitering plaatsingBesluit van tevoren welke één of twee beperkingen de demo zal identificeren, en frame ze als opzettelijke scope grenzen. Verklaar wat het systeem niet doet en waarom. Als een koper halverwege de demo een beperking ontdekt, daalt het vertrouwen. Als je de beperking vroeg noemt, leest het als discipline en eerlijkheid. In gereglementeerde instellingen is vroege openbaarmaking van grenzen vaak een positief signaal. Verkoopteam samenwerkingVorm het demo verhaal met het verkoopteam voordat je iets bouwt. Ze weten wat de koper in eerdere gesprekken heeft opgeworpen, en jij weet wat het systeem realistisch kan tonen onder productieomstandigheden. Een demo gebouwd zonder verkoopteam kan vragen beantwoorden die de koper nooit heeft gesteld. Een demo gebouwd zonder de Architect kan te veel beloven. Hoe dan ook, de demo verliest geloofwaardigheid en vertraagt de kans. Gegevensvoorbereiding Gebruik informatie die lijkt op de gegevens van de koper in structuur en volume. Voor gereglementeerde kopers, gebruik geanonimiseerde gegevens die nog steeds dezelfde structurele constraints weerspiegelen als de echte omgeving. Kopers beoordelen de demo aan de hand van de gegevens erin. Realistische veldnamen en gegevenspatronen maken het scenario echt aanvoelen. Wanneer de gegevens op de hunne lijken, pleit de demo voor zichzelf.

Limitering plaatsing verdient doelbewuste aandacht Van de vier demo-ontwerp besluiten is limitering plaatsing degene die het meest tegen instinct ingaat. In de praktijk kan het benoemen van een zwakte risicovol aanvoelen, dus de verleiding is om het te verbergen of te verzwakken. Dit slaat meestal terug.

Stel je het moment voor waar de koper vraagt: "Wat handelt dit niet goed? " Als het antwoord vaag is, daalt het vertrouwen. Als het antwoord duidelijk en begrensd is, ziet de koper discipline in plaats van defensiviteit.

Daarom moet je van tevoren beslissen welke één of twee constraints je zult benoemen en hoe je ze zult framen. Toon dat de grens opzettelijk is, dat dit is wat de oplossing is gebouwd om te doen, en dit is wat het niet is gebouwd om te doen.

Dit is nog belangrijker in gereglementeerde industrieën zoals gezondheidszorg, financiële diensten en de publieke sector. In die instellingen signaleert een duidelijke grens vaak nauwkeurigheid, terwijl een afleiding risico signaleert.

Een eenvoudige manier om je voor te bereiden is te vragen:

Wat is de limiet? Waarom bestaat het? Wat gebeurt er als de use case erbuiten moet gaan?

Succesvolle gezamenlijke scoping begint voordat de sessie begint Partner TrackNiet getest door het Architect-examen Die zelfde discipline voert rechtstreeks door in gezamenlijke scoping met het Applied AI team. Een goed scoping sessie is geen plaats om de basis voor het eerst uit te zoeken. Het is een plaats om keuzes te verfijnen, aannames te testen en de vragen op te lossen die specialist input nodig hebben.

Als de demo bewijst dat je het probleem van de koper begrijpt, bewijst de scoping sessie dat je klaar bent om een geloofwaardige oplossing eromheen te vormen. Dat werkt alleen als je met drie dingen voorbereidt:

Een gedocumenteerde weergave van de vereisten en constraints van de klant. Dit legt vast wat uit discovery kwam: de use case, workflow, stakeholders, gegevensomstandigheden, technische omgeving, compliance zorgen en succeskriterium. Dit geeft de sessie een gedeeld startpunt. Een voorgesteld patroon of kleine set kandidaatpatronen, met afwegingen al benoemd. Loop in met een standpunt. Toon de waarschijnlijke opties, wat elk je geeft, wat elk opgeeft, en waar de risico's zitten. Een korte lijst van open vragen die het Applied AI team het best kan beantwoorden. Dit zijn de vragen die de sessie waard zijn: modelgedrag, architectuur implicaties, schaalconstraints, evaluatie aanpak, veiligheid overwegingen of patroon fit.

In de demo verdien je vertrouwen door beperkingen duidelijk te identificeren. In gezamenlijke scoping behoud je dat vertrouwen door een gestructureerde weergave van het probleem, de opties en de onbeantwoorde vragen mee te nemen.

Inwerpen vallen in verschillende categorieën, en elk vereist een ander antwoord Technische inwerpen in een verkoopscyclus vallen meestal in drie categorieën. Capability inwerpen vragen of het systeem het ding helemaal kan doen. Governance en compliance inwerpen vragen of de implementatie kan worden vertrouwd, gecontroleerd en bewezen op een manier die de koper kan verdedigen. Ontwerp-keuze inwerpen vragen waarom je deze keuze in plaats van een ander hebt gemaakt. Die vereisen meer dan alleen rechtvaardiging. Je moet de afweging die de keuze maakt uitleggen en wat het alternatief zou hebben gekost, met dezelfde vertaalstructuur die je hebt gebruikt toen je de afweging voor het eerst presenteerde.

Partner TrackNiet getest door het Architect-examen De go-to-market engagement kaart moet demo design als een getraceerde workstream behandelen. Daarom bevat het een demo-design kolom met scenario, geïdentificeerde beperkingen, bevestigde gegevensbron en verkoopteam sign-off als expliciete deliverables. Dit is het belangrijkst wanneer een partner parallelle kansen draait of wanneer Architects halverwege de cyclus overdragen, omdat continuïteit cruciaal afhangt van wat is gedocumenteerd.

Cost · Complexity · Risk

Cost: Het voorbereiden van een afweging presentatie en een scenario-specifieke demo kost echte Architect tijd, maar het is veel minder duur dan een vastgelopen kans of een goedkeuring die een stakeholder later intrekt. Complexity: Drie aparte vaardigheden zitten onder dit werk, en twee ervan gaan vaak tegen iemands instinct in: het benoemen van omkeerkosten en het duidelijk plaatsen van grenzen. Beide vereisen doelbewuste oefening om te verbeteren. Risk: De dure mislukking is valse afstemming. Wanneer een besluit in de kamer goedgekeurd lijkt, maar de omkeerkosten nooit expliciet werden gemaakt, en de gevolg ontstaat later.

Screen 6: The approval that was not an informed choice

Watch OutTradeoffs & GTM5 min The approval that was not an informed choice

SetupEen stakeholder die ja zegt aan het einde van een afweging presentatie lijkt de afweging te hebben begrepen. De presentatie was compleet en technisch nauwkeurig, en de kamer voelde afgestemd. Dat gevoel is de val.

Een gereconstrueerde pre-productie beoordeling, vanuit het perspectief van de CTO De Architect presenteerde een context-strategie afweging in technische termen. De CTO stelde één vraag over kosten, de Architect beantwoordde het nauwkeurig, en de CTO keurde goed. Zes weken later verscheen de hogere per-call kosten op de productie factuur. Dit is de uitwisseling, en dan de notitie die de CTO schreef toen de rekening werd ontvangen. Het toont waar de presentatie de verkeerde versie van de vraag beantwoordde.

Gereconstrueerde uitwisseling + vervolgnotitie

Architect: "We bevelen het grotere context window aan, zodat het volledige beleidsdocument op elke call in zicht blijft. Het houdt het ontwerp eenvoudiger en vermijdt een retrieval laag. " CTO: "Hoe ziet de kosten per call eruit? " Architect: "Ongeveer vier cent per interactie op het model tier dat we gebruiken. Als het beleidsdocument statisch is over calls, zou prompt caching het input gedeelte van dat aanzienlijk kunnen verlagen. " CTO: "Prima, goedgekeurd. Laten we het eenvoudig houden. " [Zes weken later, op de productie factuur] CTO's notitie aan het account team: "Ik keurde een richting goed, niet een getal. Niemand vertelde me dat vier cent keer ons call volume een vijfcijferig maandelijks bedrag was. Als het document statisch was, waarom cachten we het niet? En als we toch rond volledige context gingen bouwen, moest ik weten wat het ongedaan maken daarvan zou kosten zodra het systeem eromheen gebouwd was. "

Het probleem: de omkeerkosten kwamen nooit in het gesprek De presentatie noemde wat het ontwerp won, eenvoud, en het beantwoordde de per-call kosten zoals gevraagd. Wat het nooit identificeerde was het derde element: wat gebeurt er met het bedrijf wanneer deze keuze productie volume ontmoet en moet worden omgekeerd nadat het systeem eromheen is gebouwd. De CTO keurde een per-call getal goed, niet een maandelijkse rekening, en niet de kosten van het ongedaan maken van een besluit later. Twee delen van de afweging werden duidelijk gecommuniceerd en begrepen. De derde niet, en het bleek de draagvermogen te zijn.

Waarom dit brak: een nauwkeurige presentatie kan nog steeds de verkeerde vraag beantwoorden Een stakeholder die een aanbeveling goedkeurde zonder de omkeerkosten te begrijpen, heeft geen geïnformeerde keuze gemaakt. De CTO hoorde een per-call cijfer en een eenvoudig argument en zei redelijk ja. Het omkeerkosten element was de ene factor die het besluit zou hebben veranderd. Noem alle drie elementen elke keer en noem de omkeerkosten vooral wanneer het ontwerp zich duidelijk eenvoudiger voelt.

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

Tradeoffs & GTM · Checkpoint Checkpoint: recommend the option and name the missing element

Probeer het nu. Lees de één-paragraaf stakeholder briefing en de drie optie presentaties geschreven in gewone taal. Één optie is technisch nauwkeurig en uitgebreid gepresenteerd. Één is technisch nauwkeurig, maar de presentatie mist een element. Één is ongepast voor de gestelde constraints. Beveel de optie aan om naar voren te brengen, noem vervolgens het enkele element dat ontbreekt in de presentatie van de tweede optie.

Briefing Een middelgrote verzekeraar wil dat Claude reacties van schaderegelaars op vragen van polishouders ontwerpt. De workflow wordt gedekt door staatsverzekeringsregeling met een audit-trail verplichting. Volume is hoog en stabiel. De sponsor zorgt zich om reactiekwaliteit en om een verdedigbaar record van elke geautomatiseerde interactie te houden.

OptieAls gepresenteerd

AWorkflow patroon met per-interactie logging ingebouwd. Winsten: volledige audit trail, kwaliteitspoort voordat verzonden. Geeft op: een kleine latentie kosten van de logging stap. Omkering: minor, logging kan worden afgestemd zonder herontwerp. BWorkflow patroon dat de logging stap verhandelt voor lagere latentie. Winsten: snellere reacties. Geeft op: per-interactie audit detail. CEenmalige augmented call zonder logging en geen menselijke poort, gekozen voor laagste bouwkosten.

Part 1: Welke optie zou je aanbevelen?

AOptie A, logging ingebouwd, volledige audit trail BOptie B, verhandelt logging voor lagere latentie COptie C, geen logging, geen menselijke poort

Part 2: Welk enkel element ontbreekt in de presentatie van Optie B?

AWat Optie B wint (snellere reacties is niet duidelijk genoeg benoemd) BWat Optie B opgeeft (audit detail verlies is niet uitgelegd) CDe omkeerkosten, wat het kost om logging te herstellen nadat het ontwerp van de latentie winst afhangt DThe compliance positie die deze optie creëert

Check answer Skip

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

Feedback Loops The feedback loop decides which signals reach a stakeholder, and the SLA names what you owe when one breaks Productie observeerbaarheid en het audit trail record wat een live implementatie doet. Dit onderwerp behandelt het filteren van die signalen, het bepalen wanneer je buiten het team moet escaleren, en het definiëren wat de SLA vereist wanneer prestaties onder standaard vallen. Het systeem is live; het vertrouwenswaardig houden over tijd wat inspanning kost. In lifecycle termen is de feedback loop de monitoring-en-iteration fase van de implementatie lifecycle.

Een live implementatie drijft af zonder actieve monitoring Stel je een klantenondersteuningsassistent voor die in goede vorm wordt gelanceerd. Het antwoordt snel, blijft in een toon, en handelt de meest voorkomende vragen goed af. Eerst ziet alles er stabiel uit. Maar in de loop van de tijd veranderen gebruikspatronen, verschijnen nieuwe prompt stijlen, en klantenproblemen worden complexer. Sommige reacties vertragen gewoon, en sommige antwoorden beginnen helemaal mis te gaan.

Niets breekt dramatisch, wat drift moeilijk maakt om te vangen. Kwaliteit verslechtert geleidelijk in plaats van allemaal tegelijk. Een team zonder feedback loop ziet de achteruitgang mogelijk niet totdat gebruikers het al voelen.

De feedback loop is een besluitlaag die boven de observeerbaarheidsstack zit Observeerbaarheid geeft je het ruwe materiaal: latentie, foutpercentages, eval scores, gebruikspatronen en andere signalen van het systeem. Maar een signaal op zichzelf is nog geen besluit. Één piek kan ruis zijn. Een ander kan naar een echt probleem wijzen. Een derde kan alleen belangrijk zijn als het blijft gebeuren. De feedback loop zit bovenop observeerbaarheid om vijf vragen te beantwoorden: Signalen → Triage → Beslis → Handelen → Beoordeel

1Signalen: Wat toont het systeem ons? 2Triage: Wat heeft nu aandacht nodig, en wat kan wachten? 3Beslis: Heeft het probleem een teamfix, een stakeholder beoordeling of geen actie nodig? 4Handelen: Welke correctie, guardrail update of escalatie is vereist? 5Beoordeel: Werkte de respons en moet de regel veranderen?

Denk eraan als een controleruimte in een treinstation. De sensoren kunnen je vertellen waar de treinen vertraagd zijn, maar iemand moet nog steeds beslissen of een vertraging minor is, of passagiers moeten worden ingelicht, en of het schema moet veranderen. Die oordeelslaag is wat het systeem beheersbaar maakt in plaats van gewoon meetbaar.

Een SLA noemt drie dingen, en de drempels komen van ergens tastbaars. Zodra de feedback loop beslist dat iets belangrijk is, definieert de SLA wat gebeurt wanneer het de lijn overschrijdt. Een SLA is een verbintenis die drie dingen duidelijk maakt:

1Wat meten we? 2Wat telt als een schending? 3Wat gebeurt er wanneer een schending optreedt?

De drempel mag nooit willekeurig zijn. Het moet teruggaan naar iets tastbaars:

1Latentie moet de gebruikerservaring verwachting weerspiegelen die eerder is geïdentificeerd 2Beschikbaarheid moet weerspiegelen hoe kritiek de implementatie voor het bedrijf is 3Kwaliteit moet de eval resultaten en acceptatiecriteria weerspiegelen die al zijn vastgesteld

Die traceerbaarheid is belangrijk omdat het de SLA verdedigbaar houdt. Als het getal niet aan een van die bronnen kan worden gekoppeld, is het waarschijnlijk gewoon een doel dat iemand koos omdat het redelijk klonk. Kosten is de verwachting die het meest breekt na lancering. Productie volume draait routinematig één tot twee ordes van grootte boven de pilot, dus een kosten die triviaal leek in het proof of concept wordt een vijfcijferig maandelijks bedrag op schaal. Zet het voort: geef de stakeholder een verbruiksprognose op verwachte productie volume, noem de spend-control houding (caching, model tiering, budget alerts), en frame het model-tiering verhaal voordat de eerste factuur in plaats van daarna.

Gereglementeerde implementaties voegen beoordelingspunten toe die op schema lopen Observeerbaarheid registreert wat gebeurde; de feedback loop bepaalt wat eraan te doen. In gereglementeerde implementaties moeten sommige beoordelingen zelfs plaatsvinden wanneer niets fout is gegaan. Een gezondheidszorg workflow met een documentatie verplichting kan periodieke output audits op een gedefinieerd schema vereisen. Een data-residency implementatie kan geplande bevestiging nodig hebben dat de omgeving nog steeds aan residency regels voldoet. Dit zijn ontwerp-tijd verplichtingen in plaats van taken die later moeten worden toegevoegd. Als ze niet vroeg worden ingebouwd, worden ze veel duurder om vast te stellen wanneer iemand om bewijs vraagt. Bouw een governance tabel die elk signaal toewijst aan zijn trigger, de Architect actie, en elke regelgeving checkpoint. De tabel moet voor lancering bestaan. Het is het mechanisme dat beleid in een operationele routine omzet. Productie-signaal governance tabel Signaal typeBeoordelings triggerArchitect actieGereglementeerde-industrie checkpoint

Output kwaliteit (eval score)Score overschrijdt de drempel getrokken uit de eval suite. Diagnose of de oorzaak prompt, gegevens of model drift is, beslis vervolgens om te itereren versus herarchitecteren. Periodieke output audit tegen de documentatie standaard, op een vastgesteld schema, ongeacht score. Latentie p95Overschrijdt het budget ingesteld uit gebruikerservaring vereisten. Onderzoek de bottleneck, tune vervolgens of escaleer naar een stakeholder beoordeling als het budget zelf fout is. Meestal geen, tenzij latentie een logging of traceability gat maskeert. Kosten per interactieOverschrijdt de budget envelop afgesproken in discovery. Identificeer de driver, breng vervolgens een afweging naar de stakeholder als het budget moet worden herzien. Meestal geen, tenzij kostencontroles deel uitmaken van een gereglementeerde operationele constraint. Data-residency configuratieGeplande bevestiging. Bevestig en registreer residency houding en vlag elke drift onmiddellijk. Residency bevestiging op het vastgestelde schema.

Cost · Complexity · Risk

Cost: De loop creëert een voortdurende architect inspanning. Merk op dat dit goedkoper is dan achteruitgang ontdekken in een driemaandelijkse beoordeling nadat elk dashboard goed leek. Complexity: Het moeilijkste deel is het bepalen welke signalen aandacht verdienen, en welke ruis zijn, omdat observeerbaarheid tooling dat oordeel niet voor je kan maken. Risk: De grootste foutmodus is een compliance checkpoint die nooit aan een trigger was gekoppeld, waardoor een gedocumenteerde-standaard schending weken kan lopen voordat een routinecontrole het vangt.

Screen 9: The observability stack that replaced the feedback loop

Watch OutFeedback Loops5 min The observability stack that replaced the feedback loop

SetupEen Architect die een rigoureuze observeerbaarheidsstack heeft gebouwd, heeft het moeilijkere technische werk gedaan. De dashboards zijn live, de alerts zijn geconfigureerd, en de gegevens stromen. Het is gemakkelijk, en redelijk, om te concluderen dat stakeholder feedback is gedekt.

Een gereconstrueerde trace: negentig dagen alert log tegen de stakeholder beoordelings kalender Het fragment hieronder plaatst een implementatie alert log naast zijn stakeholder beoordelings kalender over een negentig dagen venster. Het alert log toont een aanhoudende drift in output kwaliteit over weken vier tot zeven. De beoordelings kalender toont geen beoordeling die in dat venster plaatsvond. Een enkele rij in een feedback-loop governance tabel zou de twee hebben verbonden. Dit toont hoe de gat in het record eruit ziet.

VensterObserveerbaarheidsstack registreerdStakeholder beoordelings kalenderWat de loop zou hebben moeten doen

Weken 1-3Eval score stabiel op baseline, met latentie en kosten nominaal. Lancering beoordeling gehouden in week 1. Nominaal. Geen escalatie nodig. Weken 4-7Eval score drijft week na week af, met foutpercentage vlak, dus geen harde alert wordt afgevuurd. Geen beoordeling gepland of gehouden. Een kwaliteit-drift trigger zou naar een Architect beoordeling moeten escaleren tegen week 5, en verder naar een stakeholder beoordeling zodra diagnose drift bevestigde. Weken 8-12Score daalt nog steeds, en de stakeholder rapporteert dat de output "minder nuttig is geworden. "Driemaandelijkse beoordeling oppervlakte het eindelijk in week 12. Bij ontwerp zou de loop dit zeven weken eerder hebben gevangen.

Het probleem: de signalen bestonden, maar niets besloot dat ze belangrijk waren Elke metric die de implementatie nodig had, werd al verzameld. De eval score drijft duidelijk af sinds week vier. Wat ontbrak was de besluitlaag: geen governance regel toewijzing een langzame kwaliteit drift aan een beoordelings trigger. De drift overschreed nooit een foutpercentage drempel, dus geen alert vuurde. Een drift met geen trigger is onzichtbaar totdat een mens het toevallig opmerkt. De stack mat het juiste ding en vertelde niemand dat het belangrijk was.

Waarom dit brak: monitoring is geen feedback loop Een dashboard verzamelt en toont signalen. Een feedback loop toewijst elk signaal aan een trigger, een eigenaar en een vereiste actie. De observeerbaarheidsstack verzamelde de signalen maar had geen governance regel toewijzing elk signaal aan een trigger of eigenaar. Bouw de governance tabel die elk signaal aan een trigger, een actie en een eigenaar toewijst. Voeg zowel de langzame drifts als de harde fouten toe.

Screen 10: Checkpoint: triage the production signals

Feedback Loops · Checkpoint Checkpoint: triage the production signals

Probeer het nu. Hier zijn negen signalen van een productie implementatie. Sleep elk in de bucket waar het hoort: Interne monitoring, Architect beoordeling, Stakeholder beoordeling of Ruis.

1 · Latentie p99 steeg 40ms, nog steeds binnen budget. 2 · Eval score drie weken achtereen omlaag, trend is duidelijk. 3 · Geplande data-residency bevestiging is verschuldigd. 4 · Één misvormde aanvraag van een bekende slechte client. 5 · Kosten per interactie overschreden de afgesproken budget drempel. 6 · Een 2 uur batch job registreerde een retry die vervolgens slaagde. 7 · Driemaandelijkse output audit tegen de documentatie standaard is verschuldigd. 8 · Token gebruik steeg met een bekende seizoensgebonden traffic bump. 9 · Een nieuw prompt template werd verzonden, en foutpercentage is vlak.

Interne monitoring

Architect beoordeling

Stakeholder beoordeling

Ruis

Check placements Skip

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

Documentation Documentation that survives your absence serves the handoff recipient, the auditor, and the returning Architect De feedback loop houdt het systeem gezond terwijl je het draait. Documentatie is wat het laat functioneren nadat je weg bent. Dit onderwerp zet het volledige ontwerp om in documentatie die een overdracht overleeft en een compliance reviewer bevredigt. Ofwel het ontwerp draagt zijn eigen redenering in die overdracht, ofwel die redenering verdwijnt op het moment dat je vertrekt. In lifecycle termen is documentatie de handoff fase van de implementatie lifecycle.

Eén document dient drie lezers, en alleen één ervan dienen maakt het onvolledig Architectuur documentatie dient drie lezers. De erfenissengineer neemt een implementatie over die ze niet hebben gebouwd. De auditor arriveert later, op zoek naar bewijs dat een specifieke controle live is en verantwoord. De terugkerende architect, vaak jij, komt maanden later terug zonder herinnering aan de ontwerp sessies. Een document gebouwd voor één van deze lezers en niet de anderen is onvolledig zelfs wanneer het gedetailleerd is.

Voor de handoff ontvanger: de verworpen alternatieven zijn net zo belangrijk als de gemaakte besluiten Voor wie het systeem erft, moet het document de besluiten dragen die zijn genomen, de alternatieven die zijn verworpen, en de reden waarom elk verwerping gebeurde. Een ontwerp geleverd zonder zijn verworpen alternatieven kan niet worden begrepen door iemand die niet in de kamer was. Ze zullen het juiste besluit om de verkeerde reden omkeren of het verkeerde besluit verdedigen omdat ze niet kunnen zeggen welke afweging het was. De verworpen opties leggen uit waarom het ontwerp zo is gevormd.

Voor de compliance reviewer: bewijs is belangrijker dan stellingen Voor de compliance reviewer moet het document elke regelgeving verplichting dragen, de technische controle die het bevredigt, de eigenaar van die controle, en het bewijs artefact dat aantoont dat de controle werkt. Dit is het gereglementeerde implementatie control register, voortgezet in het levende document dat de productie leven van de implementatie beheerst. De reviewer accepteert geen blote stellingen. Ze vereisen bewijs, wat betekent dat een verklaring dat controle bestaat niet op zichzelf genoeg is.

Voor de terugkerende Architect: navigeerbaar zonder een briefing Voor de Architect die maanden later terugkeert, moet het document op zichzelf staan. Besluiten zijn gedateerd. Aannames zijn expliciet gelabeld als aannames in plaats van ingebed als feiten. Open items hebben eigenaren en resolutie criteria. De test is praktisch: na het lezen van het document, kan een competente Architect die niet aanwezig was bij de ontwerp sessies veilig een wijziging in het systeem aanbrengen? Als het antwoord nee is, is het document niet compleet.

De documentatie volledigheids checklist: Documentatie volledigheids checklist VeldWat het vastlegt Lezer die het primair dient

BesluitDe architectuur keuze die is gemaakt, inclusief de datum. Alle drie lezers. Verworpen alternatieven De opties die zijn overwogen maar niet gekozen. Handoff ontvanger. Afweging benoemd De afweging die het besluit opgelost, uitgedrukt in termen van winsten, kosten en omkeer implicaties Handoff ontvanger en terugkerende Architect. EigenaarDe persoon of team verantwoordelijk voor het besluit of de controle voortaan. Compliance reviewer en handoff ontvanger. Bewijs artefactHet artefact dat aantoont dat een controle daadwerkelijk werkt. Compliance reviewer. Audit-klaar statusOf het beschikbare bewijs actueel en voldoende voor beoordeling is. Compliance reviewer.

Cost · Complexity · Risk

Cost: Het schrijven van de motivering en bewijs bij ontwerp kost tijd. Het reconstrueren later uit email threads, of het niet doen, kost een verkeerde omkering in productie. Complexity: De discipline is het opschrijven waarom, niet alleen wat, en het labelen van aannames als aannames, wat gemakkelijk is om over te slaan wanneer de redenering voor de persoon die het leefde duidelijk aanvoelt. Risk: De dure mislukking is een opvolger die een draagvermogen besluit omkeert omdat de motivering nooit is gedocumenteerd, herintroducering van een constraint schending die het originele ontwerp had opgelost.

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

Watch OutDocumentation5 min The design rationale that lived in the Architect's head

SetupEen Architect die aanwezig was bij elk ontwerp besluit houdt de motivering voor allemaal. Het opschrijven voelt overbodig wanneer je het al weet, en er is altijd iets urgenter dan documentatie. Dat is precies hoe de motivering met de persoon vertrekt.

Een postmortem: een financiële-diensten overdracht waar de motivering nooit op de pagina maakte In dit geval verliet de originele Architect een middelgrote financiële-diensten engagement twaalf weken na lancering. Hun vervanger erfde een grondige architectuur diagram zonder motivering eraan. Een prestatie probleem zette een voorstel aan om context strategieën om te schakelen, de vervanger maakte de schakelaar, en het herintroduceerde een gegevens-verwerking patroon dat de implementatie data-residency constraint schond. De postmortem traceert de mislukking naar de ene rij die ontbrak. Dit is hoe dat in het record eruit ziet.

FaseWat gebeurdeWat het document droeg

LanceringOriginele Architect ontwerpt een context strategie specifiek om gereglementeerde gegevens in-region te houden. Een architectuur diagram dat het uiteindelijke ontwerp toont. OverdrachtOriginele Architect vertrekt in week twaalf. Geen ontwerp sessies zijn opgenomen. Het diagram, zonder verworpen alternatieven en geen motivering. VeranderingVervanger raakt een prestatie probleem en schakelt context strategieën om het op te lossen. Niets legt uit waarom de originele strategie is gekozen. MislukkinDe schakelaar herintroduceert een gegevens-verwerking patroon dat de data-residency regel breekt. De reden dat het originele ontwerp dat patroon vermeed bestond alleen in het hoofd van de vertrokken Architect.

Wat brak: het diagram toonde wat en verloor de waarom De vervanger was competent en handelde redelijk op de informatie die ze hadden. Het diagram vertelde hen wat het systeem was, niet waarom het zo was. De originele context strategie was een doelbewuste keuze om een residency constraint te bevredigen, en die redenering werd nooit geschreven als een besluit met een benoemde afweging en een verworpen alternatief. Zonder motivering gedocumenteerd, kon de vervanger niet zeggen dat de strategie die ze veranderden draagvermogen was voor compliance, dus ze keerden het juiste besluit om voor een begrijpelijke verkeerde reden.

Waarom dit brak: een ontwerp zonder zijn motivering is een ontwerp dat niet veilig kan worden veranderd De volledigheids test is of een competente Architect die niet in de kamer was, veilig een wijziging kan aanbrengen na het lezen van het document. Hier was het antwoord nee, en niemand wist het totdat productie brak. Registreer het besluit, de verworpen alternatieven en de afweging die elk opgelost. Onthoud als het nooit wordt geschreven, dan vertrekt het met jou.

Screen 13: Checkpoint: place the documentation artifacts

Documentation · Checkpoint Checkpoint: place the documentation artifacts

Probeer het nu. Het vlak heeft twee assen: één loopt van "dient de handoff ontvanger" naar "dient de compliance reviewer," de ander van "documenteert intentie" naar "documenteert bewijs. " Sleep elk van de zes artefact kaarten in de zone die zijn primaire functie het beste beschrijft.

Architectuur diagram Besluit log met motivering Control register met bewijs links Implementatie runbook Test-resultaat samenvatting Aanname register

← Handoff ontvangerCompliance reviewer →

Handoff · Intentie

Compliance · Intentie

Handoff · Bewijs

Compliance · Bewijs

↑ Documenteert intentie / Documenteert bewijs ↓

Check placements Skip

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

Entry Point & Outcomes Entry point selection returns with the full production picture, and the outcome document turns the work into reusable IP Dit onderwerp behandelt hoe de implementatie werd gerouteerd en wat het produceerde, het werk omzetten in partner IP dat het engagement overleeft. Entry point selectie keert hier terug met het volledige productie context in zicht.

De entry point vraag verandert zodra de implementatie live is over meer dan één platform De eerdere module introduceerde route selectie als een entry-point-en-compliance pre-filter: de directe Anthropic API, AWS Bedrock, GCP Vertex AI en Microsoft Foundry dienen elk verschillende partner procurement postures en regionale compliance vereisten. Dit onderwerp keert naar die besluit terug met de volledige productie context. De vraag is niet langer welke route de compliance pre-filter overleeft. Het is welke route het beste presteert over de latentie, kosten en compliance dimensies van een live multi-platform implementatie. Omdat entry-point mogelijkheden veranderen, wordt elke specifieke claim in dit gedeelte opnieuw geverifieerd tegen platform. claude. com/docs en anthropic. com bij bouwing.

Cross-platform implementaties blootstellen problemen die een enkel entry point nooit toont Een implementatie die meer dan één entry point overspant, blootstelt een klasse van problemen die een enkel-entry-point systeem niet doet. Model identifier strings verschillen over routes. Feature beschikbaarheid kan achterlopen op een route gemedieerd door een cloud service provider ten opzichte van de directe API. Regionale beschikbaarheid op Bedrock en Vertex vereist expliciete configuratie, en standaard naar een globaal endpoint is het gemeenschappelijke patroon dat een data-residency vereiste breekt. Een Architect die over entry points ontwerpt, heeft een gedocumenteerde entry-point-verantwoordelijkheid kaart nodig voordat de eerste lijn integratiescode wordt geschreven.

Een multi-entry-point app moet zeggen welk entry-point welke taak bezit, en waarom Een app die meerdere Claude entry-points in één workflow integreert, vereist dat je specificeert welk entry-point welke taak handelt en de reden. Een workflow die de API voor back-end inference gebruikt, Claude Code voor een engineering sub-taak, en een Bedrock endpoint voor een gereglementeerde gegevens pad is niet ongebruikelijk op enterprise schaal. Elke entry-point grens is een integratiepoint met zijn eigen authenticatie, logging en foutmodus profiel. De entry-point-verantwoordelijkheid kaart maakt die grenzen expliciet en voorkomt de meest voorkomende multi-entry-point mislukking: een entry-point gekozen voor één taak neemt stilletjes een ander over omdat de routing logica nooit is gedocumenteerd.

Het resultaat document maakt de waarde duidelijk buiten het team dat het bouwde Klant resultaat documentatie is het artefact dat de implementatie waarde begrijpelijk maakt voor mensen die niet op de bouw waren. Een goed gestructureerd resultaat document behandelt zes velden: de use case en zijn scope grens, de metric voor implementatie, de metric na implementatie, de controle die het resultaat controleerbaar maakt, de eigenaar verantwoordelijk voor voortdurende meting, en het potentieel om het patroon voor andere klanten of engagements herbruikbaar te maken. De technische metrics alleen maken dit document niet. De voor-en-na bedrijfs resultaten en de herbruik notities zijn wat het in een herbruikbaar asset omzetten.

De implementatie-entry-point besluit matrix: Implementatie-entry-point besluit matrix PlatformLatentie profielCompliance postuurWanneer te kiezen

Directe Anthropic APINeuwste functies eerst, met de minste extra hops. Sterke standaard maar bevestig dekking per configuratie. Gebruik standaard tenzij een procurement of residency regel ergens anders wijst. AWS BedrockRegio-configureerbaar, met mogelijke feature lag versus direct. Past AWS-centric procurement en region regels wanneer expliciet geconfigureerd. Partner gestandaardiseerd op AWS en heeft in-region uitvoering nodig. GCP Vertex AIRegio-configureerbaar, met mogelijke feature lag versus direct. Past GCP-centric procurement en region regels wanneer expliciet geconfigureerd. Partner gestandaardiseerd op GCP met een Vertex procurement pad. Microsoft Foundry (Azure) routeVarieert per hosting vorm: Hosted-on-Azure modellen voeren inference uit in de partner Azure omgeving (GA); hosted-on-Anthropic modellen routeren naar Anthropic infrastructuur. Verifieer residency en dekking per route, en ga niet uit van de platform naam. Partner procurement of residency houding vereist die specifieke route.

Partner TrackDe "herbruik het patroon voor andere klanten of engagements" framing en het Herbruik-potentieel veld in de template hieronder zijn Partner-Track relevant inhoud; de rest van het resultaat document is op-blueprint (6. 4). De klant resultaat documentatie template: Klant resultaat documentatie template VeldWat het registreert

Use case met scope grensWat doet de implementatie en wat niet. Metric voorDe bedrijfs metric zoals het stond voor implementatie. Metric naHetzelfde metric na implementatie, gemeten met dezelfde definitie. Controle op plaatsDat maakt de voor-en-na vergelijking controleerbaar in plaats van gewoon gesteld. Meting eigenaarWie bezit voortdurende meting nadat het engagement sluit. Herbruik potentiaalHoe het patroon naar andere klanten of engagements als IP overdraagt.

Cost · Complexity · Risk

Cost: Het kiezen van het verkeerde implementatie platform of het produceren van een dun resultaat document is goedkoop om te doen en duur om ongedaan te maken: residency mismatch kan cutover blokkeren, en een metrics-only document kan expansie niet rechtvaardigen. Complexity: Multi-platform routing vermenigvuldigt integratiepoints, elk met zijn eigen auth, logging en foutmodus profiel. De entry-point-verantwoordelijkheid kaart is het enige wat ze begrijpelijk houdt over tijd. Risk: De dure mislukking is een standaard configuratie die stilletjes data residency breekt, of een resultaat document dat een sponsor niet naar een CFO kan nemen omdat het nooit bedrijfs waarde vastlegde.

Screen 15: The outcome document that measured the wrong thing

Watch OutEntry Point & Outcomes5 min The outcome document that measured the wrong thing

SetupEen implementatie die goed presteerde tijdens een gecontroleerde rollout heeft gegevens erachter. Een Architect die het engagement sluit, heeft alles wat ze nodig hebben om het resultaat document te schrijven. Het snel schrijven uit de metrics die al op hand zijn voelt als de juiste zet, en het engagement is voorbij voordat iemand opmerkt wat het document niet kan beantwoorden.

Een anekdote: het resultaat document dat een CFO's eerste vraag niet kon beantwoorden Een Architect produceerde een klant resultaat document met de metrics die het gemakkelijkst uit de observeerbaarheidsstack konden worden geëxporteerd: aanvraag volume, gemiddelde latentie en foutpercentage. De klant sponsor nam het naar hun CFO om expansie te rechtvaardigen. De CFO's eerste vraag was wat de implementatie had bespaard of geproduceerd in bedrijfstermen, en het document kon het niet beantwoorden. De twee velden die het bruikbaar zouden hebben gemaakt waren nooit ingevuld. Dit is hoe dat zich afspeelde.

De sponsor opende met het document zoals geschreven: "Hier is de implementatie. Veertigduizend aanvragen per maand, sub-twee-seconde gemiddelde latentie, foutpercentage onder een half procent. " De CFO: "Dat vertelt me dat het draait. Wat deed het voor ons? Wat waren claim verwerkingstijden voor dit, en wat zijn ze nu? Omdat dat het getal is dat meer uitgaven rechtvaardigt. " De sponsor had geen bewijs om naar te wijzen. Het document mat dat het systeem werkte, maar het mat niet wat het veranderde.

Wat brak: het document legde technische metrics vast zonder bedrijfs resultaten Volume, latentie en foutpercentage zijn echt en waard om te volgen, maar geen ervan zijn een bedrijfs resultaat. De velden die het document bruikbaar voor het CFO gesprek zouden hebben gemaakt waren de voor-en-na op de bedrijfs metric die de use case beoogde, claim-verwerkingstijd, en de controle die die vergelijking controleerbaar maakte. Zonder het voor getal, is er geen verhaal. Zonder controle, is het na getal een stelling. Het document was compleet als een technisch record en nutteloos als een zaak voor expansie.

Waarom dit brak: de gemakkelijk-te-exporteren metrics zijn zelden die die kosten rechtvaardigen De observeerbaarheidsstack verzamelt je technische metrics gratis maar zonder ze in gegevens te verankeren, zit je met dashboards die informatief lijken en niets betekenen. Echter, het resultaat document bestaat voor een ander lezer, de sponsor die de implementatie omhoog moet rechtvaardigen. Leg de voor metric aan het begin vast, noem de controle die de vergelijking controleerbaar maakt, en voeg de herbruik notitie toe, zodat het document het ene werk kan doen dat een technisch dashboard niet kan.

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

Entry Point & Outcomes · Checkpoint Checkpoint: pick the platform and the required outcome fields

Probeer het nu. Je krijgt een implementatie scenario met drie variabelen: het primaire cloud platform van de partner, het regelgeving verplichting niveau van de implementatie, en de primaire prestatie constraint. Stel de drie variabelen in. Een besluit model toewijst de combinatie aan een aanbevolen primair platform, een secundair platform waar van toepassing, en de twee resultaat-document velden die de combinatie herbruikbaar moet maken.

Primair cloud platform

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

Regelgeving verplichting niveau

Select... Geen Matig Streng

Primaire prestatie constraint

Select... Latentie-gevoelig Kosten-gevoelig Compliance-gevoelig Compliance-gevoelig

Je antwoord: primair platform

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

Je antwoord: secundair platform

Select... Directe Anthropic API Geen vereist

Je antwoord: vereiste resultaat velden

Select... Controle op plaats (controleerbaar) + Meting eigenaar Metric voor + Metric na Metric voor + Metric na + Herbruik potentiaal

Aanbevolen primair platform: Secundair platform: Vereiste resultaat velden voor herbruik:

Check answer Skip

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

Module · Cumulative Cumulative: architect a regulated multi-platform deployment end to end

Hier is een zelfstandige brief. Een regionaal gezondheidszorg netwerk met een gezondheidsgeheim verplichting implementeert een klinische documentatie assistent over twee cloud platforms. De originele Architect draait af, en de klant CFO vraagt om bewijs van bedrijfs waarde. Werk door de zeven besluiten in volgorde. Elk bouwt op het vorige.

De brief Het netwerk draait over twee staten. Verpleegkundigen dicteren patiënt interacties, en de assistent ontwerpt de gestructureerde klinische notitie. Een gelicentieerde clinicus moet elke notitie autoriseren voordat het het patiënt record bereikt. De implementatie draagt een gezondheidsgeheim verplichting met een audit-trail vereiste en een data-residency regel. De partner is gestandaardiseerd op AWS maar draait wat niet-gereglementeerde back-end werk op de directe API. Je bent vier weken in de implementatie, en de CFO wil weten wat de implementatie waard is.

Besluit 1 · Discovery: Van de brief, noem de must-prove constraint die het meest het ontwerp vormt, en schrijf de ene vereiste rij die het forceert. (Past het discovery vertaal framework toe. )

Reveal model answer Must-prove constraint: De gezondheidsgeheim verplichting met audit-trail vereiste. Vereiste rij: De implementatie moet een controleerbaar record van elke model-gegenereerde notitie geverifieerd door een gelicentieerde clinicus produceren, traceerbaar naar de specifieke interactie, omdat de workflow een formele bewijsverplichting onder een gezondheidsgeheim regime draagt. Aanname om te documenteren: scope bevestigd met compliance voor ontwerp.

Besluit 2 · Afweging framing: Het netwerk vraagt om het laagste-latentie ontwerp. Frame de afweging tussen logging trimmen voor latentie en het audit trail houden, in drie elementen inclusief de omkeer kosten. (Past de afweging vertaal kaart toe. )

Reveal model answer Winnen (trim logging): Snellere waargenomen respons; soepelere clinicus workflow. Geven op: Per-interactie audit detail vereist om de gezondheidsgeheim verplichting te bevredigen. Omkeer kosten: Zodra het systeem rond de latentie winst is gebouwd, vereist het herstellen van logging een herontwerp van de interactie laag, en elke gat periode creëert een compliance blootstelling die moet worden onthuld en hersteld.

Besluit 3 · Feedback loop: Definieer één governance-tabel rij die de vereiste output audit aan een stakeholder-beoordelings trigger op schema toewijst, onafhankelijk van elke metric. (Past de feedback-loop governance tabel toe. )

Reveal model answer Signaal: Periodieke output audit tegen gezondheidsgeheim documentatie standaard. Trigger: Kalender-gebaseerd (driemaandelijks, per regelgeving verplichting), vuurde ongeacht eval scores of foutpercentages. Eigenaar: Compliance lead. Actie: Stakeholder beoordeling met audit record ingediend bij compliance officer.

Besluit 4 · Documentatie: Noem de ene besluit-log rij waarvan de afwezigheid je opvolger zou laten een compliance-draagvermogen keuze omkeren en verklaar het verworpen alternatief dat het moet dragen. (Past de documentatie volledigheids checklist toe. )

Reveal model answer Besluit rij: Context strategie, expliciet in-region uitvoering via Bedrock, niet een globaal endpoint. Verworpen alternatief: Globaal Bedrock endpoint voor eenvoudiger configuratie. Afweging benoemd: Eenvoudiger setup versus data-residency compliance. Waarom draagvermogen: Een opvolger die deze motivering niet ziet, zal naar globale configuratie terugkeren om een prestatie probleem op te lossen en residency breken, precies zoals in de financiële-diensten postmortem.

Besluit 5 · Entry point selectie: Kies de primaire en secundaire entry points gegeven AWS standaardisatie, een strenge verplichting, en een residency regel, en noem de configuratie stap die de gemeenschappelijke residency mislukking voorkomt. (Past de Entry-point besluit matrix toe. )

Reveal model answer Primair: AWS Bedrock, geconfigureerd voor expliciet in-region uitvoering (niet globaal endpoint), omdat de partner AWS-gestandaardiseerd is en de residency regel beheerst. Verifieer de specifieke compliance vereiste (HIPAA BAA of data soevereiniteit) wordt bevredigd door de Bedrock configuratie in gebruik. Secundair: Directe API voor niet-gereglementeerde back-end taken waar nieuwste functies belangrijk zijn en geen residency regel van toepassing. Configuratie stap: Stel de region parameter expliciet in de Bedrock client in, vertrouw niet op standaard endpoint resolutie.

Besluit 6 · Resultaat document: Noem de voor-en-na bedrijfs metric en de controleerbare controle die het document bruikbaar voor de CFO's expansie zaak maken. (Past de klant resultaat documentatie template toe. )

Reveal model answer Voor metric: Gemiddelde tijd van verpleegkundige dictaat naar voltooid, clinicus-geautoriseerde klinische notitie (baseline gemeten voor implementatie). Na metric: Dezelfde metric post-implementatie, met dezelfde meting definitie. Controleerbare controle: Het clinicus-autorisatie log, elke notitie heeft een tijdstempel autorisatie record dat de clinicus, notitie en interactie bindt, makend de voor-en-na vergelijking controleerbaar in plaats van gesteld.

Besluit 7 · Fase overgang: Noem het artefact dat de volgende fase overgang voor deze brief beheerst en oordeel of die beheerder is bevredigd. (Past lifecycle-fase beheerders toe. )

Reveal model answer Beheerder artefact: Het resultaat document met voor-en-na metric, controleerbare controle en meting eigenaar benoemd, dit beheerst de overgang van de huidige implementatie fase naar de expansie besluit die de CFO wordt gevraagd te maken. Oordeel: De beheerder is niet nog bevredigd op week vier, de voor metric bestaat van baseline, maar de na metric vereist genoeg post-implementatie runtime om te meten. Het resultaat document kan niet worden voltooid totdat voldoende gegevens hebben verzameld. De juiste actie: noem de meting eigenaar, bevestig de controle registreert, en plan de resultaat document voltooiing op een gedefinieerde post-lancering mijlpaal.

Mark all decisions complete

Screen 18: Glossary

Wrap-up · Reference Glossary De sleutel termen gebruikt over deze module, in alfabetische volgorde. Klik een term om zijn definitie uit te breiden.

Control registerDe tabel voortgezet van het gereglementeerde-implementatie werk dat elke regelgeving verplichting toewijst aan een technische controle, een verantwoordelijke eigenaar, en een bewijs artefact dat een reviewer kan inspecteren. In documentatie wordt het het levende record dat de implementatie productie leven beheerst. Besluit log (met motivering)Een record van elke architectuur keuze die niet alleen het besluit vastlegt maar de alternatieven verworpen en de afweging elk opgelost, zodat een opvolger een draagvermogen keuze niet omkeert voor een begrijpelijke verkeerde reden. Implementatie lifecycleDe fasen een implementatie doorloopt: discovery → design → handoff → monitoring → iteration. Discovery en afweging framing doen het discovery-en-design werk, de feedback loop is monitoring-en-iteration, documentatie is handoff, en entry-point selectie met het resultaat document sluit de loop. Het identificeren van de fase waar een besluit bij hoort, is wat je laat oordelen wanneer één fase klaar is om naar de volgende over te gaan. DiscoveryEen gestructureerde elicitatie, geen gesprek: een drietraps filter van luisteren, vertalen en opschrijven dat een stakeholder bedrijfs doel omzet in vereisten, aannames en constraints het ontwerp kan worden gebouwd en gemeten tegen. Documentatie volledigheid De test of een competente Architect die niet in de kamer was, veilig een wijziging kan aanbrengen na het lezen van het document. Het vereist het besluit, de verworpen alternatieven, de afweging elk opgelost, de eigenaar, en het bewijs artefact, en aannames gelabeld als aannames. Entry-point-verantwoordelijkheid kaartEen gedocumenteerd record van welk Claude entry point (directe API, Claude Code, Bedrock, Vertex, Microsoft Foundry) welke taak bezit en waarom, geschreven voordat integratie begint. Het voorkomt de gemeenschappelijke multi-platform mislukking van een entry point gekozen voor één taak stilletjes een ander overnemend omdat de routing nooit is gedocumenteerd. Bewijs artefactConcreet bewijs dat een controle werkt, een ondertekend akkoord, een configuratie scherm, een autorisatie record, of een teruggekeerde log query. Een controle gesteld in een ontwerp document zonder artefact is een claim, niet bewijs. Feedback loopDe besluitlaag die boven de observeerbaarheidsstack zit en Signalen → Triage → Beslis → Handelen → Beoordeel beantwoordt, elk signaal toewijzend aan een trigger, een eigenaar en een actie. Monitoring verzamelt signalen; de feedback loop beslist welke gedrag veranderen en van wie. Governance tabelDe pre-lancering tabel die elk productie signaal aan zijn beoordelings trigger toewijst, de Architect actie, en elke geplande gereglementeerde checkpoint. Het is het mechanisme dat beleid in een operationele routine omzet en moet voor lancering bestaan. Gezamenlijke scopingEen werkende sessie met het Anthropic Applied AI team om keuzes te verfijnen en specialist vragen op te lossen. Je arriveert met een gedocumenteerde weergave van vereisten en constraints, een voorgesteld patroon of kandidaat set met afwegingen benoemd, en een korte lijst van open vragen alleen het Applied AI team kan beantwoorden. Limitering plaatsingBeslissen van tevoren welke één of twee beperkingen een demo zal benoemen, en ze framen als opzettelijke scope grenzen. Verklaar wat het systeem niet doet en waarom. Resultaat documentHet artefact dat een implementatie waarde duidelijk maakt voor een sponsor die niet op de bouw was. Zes velden: de use case met scope grens, de metric voor, de metric na, de controleerbare controle, de meting eigenaar, en het herbruik potentiaal. De voor-en-na bedrijfs resultaat en de herbruik notities zijn wat het in herbruikbaar IP omzetten in plaats van een technisch record. Vereiste versus aannamingEen vereiste traceert terug naar iets dat de stakeholder daadwerkelijk zei; een aanname is iets dat het ontwerp voor lief neemt dat nooit werd gesteld. Een ongebronde aanname is de meest gevaarlijke soort, omdat niemand zich herinnert het te hebben besloten. Omkeer kostenWat het kost om een besluit ongedaan te maken nadat het systeem eromheen is gebouwd, het derde element van een afweging presentatie. Het is het element dat de meeste presentaties weglaten en degene die het meest vaak de vergadering verandert, van "wat is het betere technische antwoord? " in "wat is de betere bedrijfs keuze? " Scenario-specifieke demoEen demo gebouwd tegen de eigen workflow van de koper, gegevens vormen en constraints, het antwoordt "wat doet dit met mijn probleem? " in plaats van een capabilities demo's "wat kan dit systeem doen? " Alleen de scenario-specifieke demo creëert vertrouwen in plaats van gewoon interesse. SLA (Service Level Agreement)Een verbintenis die noemt wat is gemeten, wat telt als een schending, en wat gebeurt wanneer een schending optreedt. De drempels traceren naar een tastbare bron, de gebruikerservaring verwachting, de implementatie bedrijfs kritikaliteit, of de eval acceptatiecriteria, in plaats van een willekeurig doel. Afweging framingEen architectuur besluit presenteren in termen een stakeholder kan actie op ondernemen: wat de keuze wint, wat het opgeeft, en wat een omkering kost zodra het systeem eromheen is gebouwd (plus, in gereglementeerde instellingen, wat het doet aan de compliance houding). Het doel is een geïnformeerd besluit mogelijk te maken, niet een vonnis af te geven. Vertaling (discovery)De kern discovery zet: een stakeholder voorkeur ("naadloos," "snel," "eenvoudig") omzetten in een testbare, begrensde constraint door te vragen wat de ervaring zou breken, wat de gebruiker nooit mag opmerken, en wat nog waar moet zijn wanneer iets misgaat. Vertaal tabelDe output van discovery: één rij per item dat de stakeholder verklaring zoals gezegd vastlegt, de geïmpliceerde constraint, de vereiste architectuur besluit, en elke aanname die wordt gedocumenteerd totdat het is bevestigd. Één rij per item houdt de redenering intact terwijl het werk van discovery naar ontwerp gaat.

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

Module · Recap · 3 min Recap: five things that hold across everything here

Sleutel takeaways

01

Gestructureerde discovery Voer discovery uit als een vier-categorie proces, vertaal elke voorkeur in een constraint, en schrijf elk item als een vereiste rij met zijn aanname gelabeld, zodat het ontwerp naar de business case traceert.

02

Afwegingen en GTM communiceren Presenteer elke afweging in drie elementen inclusief de omkeer kosten. Partner Track[Partner-Track Relevant, niet getest door het Architect-examen] Ontwerp de demo tegen het echte scenario van de koper met beperkingen eerst geïdentificeerd, en loop in gezamenlijke scoping met vereisten, kandidaat patronen en open vragen in hand.

03

Feedback loops en SLA beheer Bouw de besluitlaag die signalen aan trigger acties aan eigenaren toewijst, stel SLA drempels in van hun echte bronnen, en draad gereglementeerde checkpoints om op schema te lopen.

04

Documentatie voor overdracht en audit Schrijf het besluit, de verworpen alternatieven en de afweging elk opgelost terwijl je nog de redenering vasthoudt, en draag het control register voort als bewijs dat een reviewer zal accepteren.

05

Entry point selectie en resultaten Kies de route op latentie, compliance en kosten met een entry-point-verantwoordelijkheid kaart voor multi-entry-point ontwerpen, en leg de voor metric, de controleerbare controle en de herbruik notitie vast zodat het resultaat document expansie rechtvaardigt.

De volgende module behandelt team enablement en operationele productiviteit: Claude tooling configureren voor een team, developer workflows bouwen die AI-ondersteund werk vertrouwenswaardig houden, en de operationele gezondheid van een live implementatie ondersteunen. Je kunt nu een implementatie van de eerste zin van een stakeholder naar een resultaat document nemen dat het engagement overleeft. De volgende module behandelt wat gebeurt nadat je die implementatie aan het team dat het draait overdraagt.

Sources

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 Congratulations! You have successfully completed this module. Module 4 behandelt de stakeholder communicatie, lifecycle governance en go-to-market besluiten die een werkende AI implementatie omzetten in een verdedigbaar, schaalbaar bedrijfs asset. De implementatie is alleen zo duurzaam als de documentatie, governance en resultaat bewijs die eromheen zit.

0 of 0 checkpoints passed

M1

Claude Platform & Solution Design Model selectie, prompt architectuur, tool ontwerp en platform-laag afwegingen.

M2

Enterprise Integration & Production Implementatie patronen, integratie architectuur en productie betrouwbaarheid.

M3

Responsible AI, Safety & Risk Veiligheid frameworks, risico identificatie en governance praktijken.

M4

Stakeholder Engagement, Lifecycle & Go-to-Market Stakeholder communicatie, lifecycle beheer en go-to-market strategie.

You Are Here

M5

Team Enablement and Operational Productivity Team tooling configuratie en operationele ondersteuning praktijken.

Up Next

Review module Start over