Jeden zdroj pravdy pro každý atribut

🌐 K dispozici také v 29 jazycích

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Obrázek vytvořený pomocí AI

Přeloženo pomocí AI. Komunita překlad zatím nezkontrolovala. Číst anglicky

Modul 1 z 6 kapitoly Kmenová data a identita, kapitoly 6 kurzu Data Architect. Každý modul stojí sám o sobě. Další: Čtyři způsoby správy kmenových dat

Otázka, na kterou tento modul odpovídá: Co doopravdy znamená „jediný zdroj pravdy“?

Je jedna věta, kterou slýchám pořád: „Potřebujeme jediný zdroj pravdy.“ Dobře. Pro co? Pro zákazníka? To není dost konkrétní. Vezměte účet. Kdo vlastní jméno zákazníka, fakturační adresu, úvěrový limit, account executive, úroveň podpory, marketingové preference? Ty odpovědi neukazují na stejný systém. ERP může řídit oficiální název, fakturační adresu a úvěrový stav; Salesforce vlastníka vztahu a obchodní atributy; jiná platforma souhlas. Když mi tedy někdo řekne „Salesforce je náš jediný zdroj pravdy o zákazníkovi“, moje další otázka zní: jaké pravdy?

Pravda patří atributu

První princip kmenových dat je tento: autorita se přiděluje po atributech, ne po záznamech. Účet může žít v Salesforce, aniž by byl Salesforce autoritativní pro každé pole na něm. Sedm polí na jednom záznamu, dvě autority:

Atribut	Autoritativní systém
Oficiální název, fakturační adresa, zákaznické ID v ERP, úvěrový limit	ERP
Account executive, příznak strategického účtu, úroveň péče	Salesforce

Jeden záznam; pravda je rozprostřená. To je normální. „Zdrojový systém = Salesforce“ to nepopisuje. Popisuje to model autorit.

Vytvořeno, upraveno, odkazováno a jak rychle?

Když učím kmenová data, vracím se u každého důležitého kusu dat ke stejným otázkám: kde se vytváří, kde se upravuje, kde se na něj odkazuje a jaká je latence jeho změn? Rychle odhalí architekturu. (S prvními třemi jste se setkali v kapitole 4 při třídění druhů dat; tady odvádějí svou skutečnou práci.)

Vezměte majetek (asset). Zákazník objedná tři jízdní kola. Salesforce má příležitost a její řádkové položky a objednávka jde do ERP. ERP ji vyřídí, a tam se majetek vytváří: tři kola, tři sériová čísla, poslaná zpět do Salesforce. O měsíce později zákazník volá kvůli jednomu z nich a podpora na majetek odkazuje v případu. Teď někdo potřebuje opravit atribut. Které smí Salesforce upravit a které patří ERP, které je vytvořilo? A když ERP jeden z nich změní, jak rychle to Salesforce potřebuje vědět? Jeden majetek, čtyři otázky a odpovědi nejsou pro každé pole stejné.

Řekněme, že oficiální název se vytváří v ERP a v Salesforce se na něj odkazuje a obchodník si všimne, že je špatně. Má ho opravit v Salesforce? Pokud pole vlastní ERP, oprava kopie nic nevyřeší. V lepším případě ji další synchronizace přepíše; v horším se teď oba systémy neshodují a nikdo neví, kterému věřit. Pokud byznys chce, aby obchodník opravu zahájil, je to něco jiného: Salesforce poskytne zážitek, pošle požadavek do ERP, ERP změnu provede nebo schválí a autoritativní hodnota se vrátí. To je úplně jiná architektura, než nechat Salesforce pole upravovat po svém.

I latence je součástí pravdy. ERP změní úvěrový stav zákazníka v 10 hodin dopoledne; Salesforce ho synchronizuje přes noc; ve 3 odpoledne se obchodník podívá do Salesforce. Je hodnota špatně? Je zastaralá. Pokud se hodnota mění jednou ročně a den zpoždění nic nestojí, noční synchronizace stačí. Pokud rozhoduje o tom, jestli dnes přijmete objednávku za milion dolarů, nestačí. Autorita říká, odkud pravda přichází; latence říká, jak rychle se ostatní musí dozvědět, že se změnila. Dvě samostatná rozhodnutí.

Zdrojový systém, systém interakce, referenční systém

Tady pomáhá slovník z kapitoly 4. Zdrojový systém (system of record) udržuje autoritativní verzi. Systém interakce (system of engagement) je místo, kde s ní lidé pracují. Referenční systém (system of reference) dodává data, která jiný systém používá, ale nevlastní. Salesforce může být systémem interakce pro vztah se zákazníkem, zatímco ERP zůstává zdrojovým systémem pro jeho právní a finanční atributy. To není slabina architektury; to je architektura. Chybou je předstírat, že jeden systém musí vlastnit všechno, aby diagram vypadal jednodušeji.

Hybridní zlatý záznam

To mění, co znamená „zlatý záznam“ (golden record). Kapitola 5 tu myšlenku představila u udržování špatných dat venku; tady je srdcem návrhu. Lidé si představují jeden kouzelný záznam s každým polem spravovaným na jednom místě. Někdy je to návrh. V Salesforce ale častěji vidím hybrid: část účtu spravovaná jinde a zkopírovaná dovnitř (oficiální název, zákaznické číslo z ERP, fakturační adresa, úvěrový stav) a část, která existuje jen proto, že ji potřebuje Salesforce (account executive, strategie příležitostí, úroveň péče, poznámky ke vztahu). Pole z ERP přicházejí dovnitř, aby je lidé mohli používat. Pole Salesforce se nikdy nevracejí, protože ERP o ně nestojí. Naprosto rozumné, pokud všichni vědí, co je co.

Udělejte autoritu viditelnou

Vnější autoritu proto ve schématu dávám jasně najevo. Pokud pole řídí SAP, dostane předponu: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. Je to stejná myšlenka jako předpona erp_ z kapitoly 4. Použijte název systému, když je ta autorita konkrétní a stabilní, a obecnou předponu, když víc záleží na významu než na dnešním dodavateli. Jde o to, aby za šest měsíců někdo, kdo model čte, viděl: tohle není jen další pole Salesforce; tuto hodnotu vlastní jiný systém. Nenuťte lidi objevovat autoritu znovu zpětným inženýrstvím integrací.

Sestavte mapu autorit

U důležitých kmenových dat chci mapu autorit (authority map): u každého klíčového atributu kdo ho vytváří, kdo vlastní obchodní rozhodnutí, který systém je autoritativní a kdo nebo co ho smí měnit. Čtyři různé otázky:

Atribut	Vytváří	Obchodní vlastník	Autoritativní systém	Smí ho měnit
Oficiální název	Finance	Finance	ERP	Finanční proces
Úvěrový limit	Finance	Finance	ERP	Úvěrový tým
Account executive	Obchodní provoz	Obchod	Salesforce	Vedení obchodu
Úroveň podpory	Servisní provoz	Servis	Salesforce	Vedení servisu
Souhlas	Zákazník	Ochrana soukromí	Platforma pro souhlasy	Zákazník, schválený proces

Všimněte si, že obchodní vlastník a autoritativní systém nejsou totéž. Systém nevlastní pravidla; vlastní je lidé. Systém výsledek ukládá a vynucuje. To je zase kapitola 5: vlastníci stanovují pravidla; architekti je vynucují.

Kliknutím zvětšíte

Jeden zákazník. Mnoho atributů. Pro každý jedna autorita.

Autorita se během životního cyklu mění

Obchodník se setká s potenciálním zákazníkem, o kterém ERP nikdy neslyšelo, a vytvoří účet v Salesforce. V tu chvíli je Salesforce autoritativní pro název, adresu, kontakty i kvalifikaci. Z potenciálního zákazníka se stane zákazník; ERP vytvoří oficiálního zákazníka a přidělí zákaznické číslo, oficiální název, fakturační adresu a úvěr. Autorita se přesunula. Salesforce předtím nebyl špatně; změnil se životní cyklus. Je to vzor z kapitoly 5, od prozatímního k řízenému: před konverzí vlastní potenciálního zákazníka Salesforce; po ní vlastní řízené atributy ERP a Salesforce dál vlastní ty své. „Který systém vlastní účet?“ je tedy slabá otázka. Ptejte se: který systém vlastní tento atribut v tomto bodě životního cyklu?

Kopie není autorita

Data z ERP kopírujeme do Salesforce, protože je lidé neustále potřebují. Tím se ze Salesforce stává pohodlná lokální kopie, ne master, a architektura by se podle toho měla chovat: pro uživatele jen pro čtení, obnovovaná integrací, označená svým zdrojem, měněná jen přes požadavek, kontrolovaná odsouhlasením, když se kopie rozejde. Kopie je užitečná. Autorita se nepřesunula.

Důvěra potřebuje víc než hodnotu

„Fakturační adresa: 123 Main Street.“ Máte jí věřit? Chci signály důvěry: odkud přišla, kdy byla naposledy potvrzena, který systém ji dodal a kdo nebo co ji naposledy změnil: člověk, integrace, agent? Teď ERP říká 123 Main Street, Salesforce říká 125 a soubor od partnera říká „123 Main St., Suite 200“. Co je správně? Neodpovídejte „použijte tu nejnovější“. Možná. Ale „nejnovější“ je samo pravidlo, které předpokládá, že kdo to změnil naposledy, zaslouží si vyhrát. To může být pravda, nebo katastrofa. Modul 3 se do toho pouští. Důvěra pochází z autority a původu, ne z nalezení pole, které je vyplněné.

Steve Trucking: čí je to pravda?

Maloobchodní partner pošle doručení a v té jedné transakci se skrývá několik pravd. Partnerova reference objednávky je partnerova; Steve Trucking si ji drží, aby mohl párovat aktualizace, ale nestává se jejím masterem. Stav doručení (přijelo, doručeno, nainstalováno, výjimka) je Steve Trucking; partner ho dostává, ale přijímání stavu z partnera nedělá autoritu pro to, co se stalo na kamionu. A příjemce je zákazníkem partnera. Partner dodá jméno, adresu, telefon a poznámky k doručení, protože je Steve Trucking potřebuje, aby mohl doručit. To ze Steve Trucking nedělá mastera identity té osoby, a právě toto rozlišení rozhodne o návrhu příjemce u kontrolního bodu.

Kliknutím zvětšíte

Jedno doručení, dvě autority.

Kde data žijí a kdo vlastní jejich pravdu, jsou různé otázky. Salesforce může držet zákaznické číslo z ERP, aniž by ho vlastnil; Snowflake může držet stav doručení, aniž by byl jeho provozním masterem; platforma zákaznických dat může sjednotit identity, aniž by vlastnila každý atribut. Agent může číst všechny tři, a to agentovi rozhodně nedává právo rozhodovat, co je pravda.

Nad rámec zkoušky: co mění AI. Agenti dělají z autority nad atributy pravidlo provádění. Člověk vidí špatnou fakturační adresu a ví: „to přichází ze SAP; tady bych to měnit neměl.“ Agent, kterému řeknete „aktualizuj fakturační adresu zákazníka“, to vědět nebude, pokud to tak nenavrhneme. Potřebuje stejnou mapu autorit, jakou má architekt: přístup k poli z něj nedělá správné místo pro zápis.

Co tady rozhoduje architekt

• Který systém je autoritativní pro každý důležitý atribut, místo jednoho systému pro celý záznam.
• Kde se každý atribut vytváří, upravuje a odkazuje a jak rychle musí jeho změny cestovat.
• Kdo stanovuje pravidla pro každý atribut a kteří lidé, integrace nebo agenti ho smějí měnit.
• Jak se vnější autorita projevuje v modelu: předpony v názvech, oprávnění, chování integrací.
• Jak se autorita během životního cyklu posouvá, třeba když se z potenciálního zákazníka stane zákazník řízený ERP.

Jediný zdroj pravdy neznamená jeden org, jedno ERP, jednu platformu MDM ani jeden obří záznam. Znamená, že pro každou řízenou informaci dokáže architektura říct, kde je autoritativní hodnota, a každý další systém díky tomu ví, jak se chovat. To není jediný zdroj pravdy. Je to architektura pravdy.

K prozkoumání

• Salesforce Architects, Data 360 Architecture (otevře se v nové kartě), ověřeno 2026-10-17.