Systémy kolem Salesforce

🌐 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 3 z 6 kapitoly Porozumění podnikovým datům, kapitoly 4 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Druhy podnikových dat · Další: Nakreslete systémovou krajinu

Otázka, na kterou tento modul odpovídá: Co obklopuje Salesforce a jakou roli hraje každý systém?

Minulý modul data roztřídil. Teď je chci někam dát, a tady se architekti Salesforce dostávají do potíží. Salesforce známe, takže zákaznická data znamenají účet, data objednávek znamenají Order, dokumenty znamenají Files, analytika znamená sestavy. Podnik si ale Salesforce nekoupil, aby nahradil všechno ostatní, co vlastní. Může tu být ERP, které řídí finance a vyřizování objednávek, datový sklad s lety historie, integrační platforma, poskytovatel identity, systémy partnerů, platforma událostí, platforma MDM a Data 360, které několik z nich propojuje. Úkolem není učit se technologie nazpaměť. Je to pochopit, jakou práci má každý systém.

Nezačínejte názvem produktu

„Máme SAP“ mi neříká dost. Stejně tak Snowflake, MuleSoft, Tableau nebo Data 360. Chci vědět, co ten systém dělá v této architektuře: jaká data vlastní, co čte, co mění, kdo ho používá, co na něm závisí, co se stane, když nejede. Dvě firmy mohou vlastnit úplně stejné produkty a mít úplně odlišné architektury.

Systémy tedy označuji podle role. Většinu pokrývají čtyři role:

• Zdrojový systém (system of record): kde se udržuje autoritativní verze něčeho.
• Systém interakce (system of engagement): kde lidé dělají práci.
• Referenční systém (system of reference): kam systém chodí pro informace, které potřebuje, ale nevlastní.
• Analytický systém (system of insight): kde se data scházejí, aby se dalo měřit, analyzovat a předpovídat.

Jedna platforma může hrát několik rolí a role se liší podle dat. Salesforce může být zdrojovým systémem pro případy, systémem interakce pro servisní agenty a spotřebitelem produktových dat, která vlastní ERP. Když tedy někdo řekne „Salesforce je náš zdrojový systém“, dokončete větu: zdrojový systém pro co?

ERP: back office má gravitaci

ERP je systém, který vedle Salesforce najdete nejčastěji: řídí finance, zásoby, nákup, vyřizování objednávek a fakturaci. Vzor z modulu 1 (zákazníci a produkty dovnitř, objednávky ven) znamená, že produkty vlastní ERP, ale obchodníci je v Salesforce pořád potřebují. Dobře: přineste je dovnitř. Kopírováním dat se ale vlastnictví nepřevádí. Kopie není autorita.

Můj postoj: data vlastněná ERP se čtou lokálně a zapisují pod kontrolou. Uživatelé Salesforce dostanou data tam, kde pracují, ale Salesforce nesmí měnit to, co vlastní ERP. A dávám to najevo ve schématu: pole ERP nesou předponu erp_, třeba erp_Product_Number__c, takže každý, kdo objekt čte, ví, kdo každé pole vlastní a že má být při jeho změně opatrný. Předpona nic nevynucuje; to dělají oprávnění, ověřování a integrační vzor. Sděluje záměr a je to mapa autorit, kterou je vidět.

Datový sklad, datové jezero a lakehouse

Provozní systémy řídí byznys; analytické systémy pomáhají mu porozumět. „Ukaž mi mé otevřené příležitosti“ je sestava v Salesforce. „Ukaž mi pět let prodejů, vyřizování objednávek, vratek, případů, zásob a financí napříč všemi kanály“ je jiný problém.

Potkáte tři druhy analytických úložišť. Datový sklad (data warehouse) obsahuje strukturovaná data připravená pro analýzu. Datové jezero (data lake) obsahuje mnohem víc dat ve více podobách, často surových. Lakehouse kombinuje obojí: úložiště ve stylu jezera s analýzou ve stylu skladu. Znejte je, protože se v krajinách objevují. Moje zkušenost ale je, že lakehouse a data mesh jsou na projektech Salesforce pořád okrajové. Typická krajina je CRM, ERP, datový sklad a integrační vrstva, s dalšími platformami tam, kde je byznys opravdu potřebuje. Učte se architekturu; nehoňte se za slovníkem.

Analytika žije tam, kde žijí data

Tohle je jeden z mých nejpevnějších postojů: kde žije analytika, se řídí tím, kde žijí data. Pokud sestava potřebuje jen účty, příležitosti a obchodníky, je všechno na core: standardní sestavy a řídicí panely. Pak byznys požádá o přidání faktur z ERP. Pak nákladů na produkty. Pak pěti let objednávek z datového skladu. Pak aktivity na webu. V určité chvíli přestane dávat smysl tahat to všechno do provozního CRM jen kvůli sestavám. Jakmile se zapojí další úložiště dat, je potřeba analytická platforma: Tableau (včetně Tableau Next postaveného na Data 360), nebo CRM Analytics, kde už se používá. Je nezbytná, když se data Salesforce spojují s datovým skladem. Požadavek se nejen zkomplikoval; krajina změnila, kde se má na otázku odpovídat. Nikdy tedy nezačínám otázkou „jaký analytický nástroj?“ Začínám otázkou kde jsou data?

Kandidátů na CTA se ptám na totéž: „Který z mých diagramů tohle krásně řeší? Krajina.“ Pokud jste celí na core, použijte sestavy. Pokud máte data v jiných úložištích, chci vidět analytickou platformu. Krajina odpoví na otázku sestav dřív, než kdokoli otevře nástroj na tvorbu sestav. (Názvy produktů se mění; kde je dnes analytika Salesforce, pokrývá kapitola o Data 360.)

MDM: kdo je ten zákazník doopravdy?

Teď předpokládejme, že informace o zákaznících žijí v Salesforce, v ERP, v e-shopu, ve věrnostní platformě a v systému partnera a každý z nich si myslí, že ví, kdo zákazník je. Tady přichází správa kmenových dat (master data management, MDM): stanovení a řízení autoritativní identity klíčových dat napříč systémy. MDM ale není „hlavní databáze zákazníků“. Těžké otázky jsou, který systém smí zákazníka vytvořit, které atributy vlastní který systém, jak se hledají duplicity, který identifikátor přežije a co se stane, když se systémy neshodnou. O tom je celá kapitola 6. Tady rozpoznejte roli: pokud platforma MDM existuje, může být kritickou autoritou mezi Salesforce a zbytkem podniku.

Integrační vrstva a události

Propojte každý systém přímo s každým dalším a z krajiny se rychle stanou špagety. Proto mají podniky integrační vrstvu: ESB (enterprise service bus) nebo iPaaS (integrační platformu jako službu). MuleSoft je ta, kterou v krajinách Salesforce potkáte nejčastěji. Zprostředkovává, takže každá aplikace nemusí rozumět každé jiné.

Krabice MuleSoft uprostřed ale integraci nedělá dobrou. Pořád chci vědět, co přes ni jde a co ne, kdo data transformuje, kdo vlastní kontrakt, co se stane, když cíl nejede, jestli je to synchronní, nebo asynchronní, a jak poznáme, že zpráva uspěla. Kurz Integration Architect jde do hloubky; tady ji rozpoznejte jako samostatnou roli.

A ne každá integrace je systém A, který volá systém B. Někdy se něco stane (vytvoří se objednávka, doručení změní stav, kamion vjede do regionu), zveřejní se událost a kdo má zájem, ten zareaguje. I události v pohybu mají infrastrukturu: vlastní schopnosti událostí v Salesforce, podnikovou sběrnici událostí, jiné zasílání zpráv. Kreslete mechanismy, které data nesou, ne jen databáze.

Systém, na který vývojáři zapomínají: identita

Je jedna krabice, kterou chci v krajině vždycky mít a na kterou vývojáři myslí jen zřídka: poskytovatel identity. Vývojáři se do svých sandboxů přihlašují rovnou jménem a heslem, takže identita je během stavby neviditelná. Pak přijde UAT nebo produkce a najednou je tu firemní jednotné přihlášení pro zaměstnance, možná druhý poskytovatel pro partnery, přihlášení přes sociální sítě pro zákazníky. Identita byla vždycky součástí architektury. Vývojář ji jen ještě neviděl.

Poskytovatel identity (IdP) je systém, který ověří uživatele a stanoví identitu, které Salesforce věří. Do krajiny patří od prvního dne, i když se konfiguruje později v pipeline vydání, protože kdo se dostane dovnitř, rozhoduje o tom, kdo se dostane k datům.

Je tu i praktický háček: konfigurace identity je nasaditelná, ale ne úplně. Konfigurace jednotného přihlášení SAML a poskytovatelé ověřování jsou typy Metadata API, takže putují pipeline (SamlSsoConfig (otevře se v nové kartě)). Tajné klíče spotřebitele u poskytovatelů ověřování se ale v odpovědích Metadata API už nevracejí (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (otevře se v nové kartě)) a certifikáty se obvykle liší podle prostředí. Plánujte pro části, které putují, i pro ty, které ne.

Kliknutím zvětšíte

Čtěte krajinu jako role, ne jako loga: co každý systém vlastní, čte nebo rozhoduje.

Kam patří Data 360?

Data 360 přináší pěknou otázku pro kreslení. Dávám ho doprava, pod ESB nebo MuleSoft. Důvodem jsou jeho spojení: uživatelé se k němu nikdy nepřipojují přímo, zatímco on se přímo připojuje k mnoha systémům na back endu. Patří tedy k datovému potrubí, kde tyto čáry zůstanou krátké, ne ven k uživatelům. Nakreslete ho jako další obrazovku, do které se lidé přihlašují, a vyprávíte špatný příběh.

Administrátoři a datové týmy obrazovky Data 360 otevírají, ale ty obrazovky jsou v orgu, na core. Tenant, který dělá práci, jeho data i zpracování, běží mimo core. Proto mu říkám blízko core: spravováno na core, hostováno mimo core (pojmy vysvětluje modul 1). Kresba se řídí tenantem: sedí u potrubí, s jednou čárou zpět k orgu, který ho spravuje.

Co dělá, slovy Salesforce, zahrnuje zero copy: technologii federace dat, která podniku umožňuje přistupovat k datům a dotazovat se na ně bez kopírování (Zero Copy (otevře se v nové kartě)). Schopnosti a konektory se rychle mění, takže je pořádně pokrývá kapitola o Data 360, místo aby se z tohoto modulu stala prohlídka produktu.

Čtěte krajinu jako odpovědnosti

Když se díváte na krajinu, nečtěte loga; čtěte odpovědnosti. ERP: co vlastní? Datový sklad: na jaké otázky odpovídá? Integrační platforma: co přesouvá? IdP: koho ověřuje? MDM: jakou identitu řídí? Data 360: co propojuje a k čemu? Salesforce: za co doopravdy odpovídá? Jakmile na to umíte odpovědět, krabice něco znamenají a šipky mezi nimi jsou mnohem zajímavější. Příště je nakreslíme záměrně.

Co tady rozhoduje architekt

• Jakou roli hraje každý systém, nad rámec názvu produktu.
• Který systém je autoritativní pro každou důležitou sadu dat a kde má Salesforce jen lokální kopii.
• Zda jsou data vlastněná ERP v Salesforce k dispozici s řízenými zápisy a jak se toto vlastnictví projevuje ve schématu.
• Kam patří analytika, podle toho, kde žijí data.
• Kde v krajině sedí identita, integrace, události a autorita nad kmenovými daty.

Krajina s deseti obdélníky není architektura; je to inventura. Architektura začíná, když můžete ukázat na každý obdélník a říct, proč tam je, co vlastní, kdo ho používá, co od něj Salesforce potřebuje a co se rozbije, když jeho roli špatně pochopíte.

K prozkoumání

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce, Zero Copy (otevře se v nové kartě) (produktová stránka), ověřeno 2026-10-17.
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (otevře se v nové kartě), martinfowler.com, 2019.