Salesforce je jeden systém z mnoha

🌐 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 Porozumění podnikovým datům, kapitoly 4 kurzu Data Architect. Každý modul stojí sám o sobě. Další: Druhy podnikových dat

Otázka, na kterou tento modul odpovídá: Proč datový architekt kreslí to, co obklopuje org, dřív, než navrhne samotný org?

Když učím kandidáty na CTA, domácí úkol po prvním dni je vždycky stejný. Přečtěte si scénář. Začněte systémovou krajinu od prázdného plátna. Teprve pak se pusťte do datového modelu. Ne objekty, ne integrace do detailu: krajinu. Chci vidět, co obklopuje Salesforce, dřív než rozhodneme, co patří dovnitř.

Pro spoustu profesionálů v Salesforce je to změna perspektivy. Pokud jste celou kariéru strávili jako administrátor nebo vývojář, je Salesforce přirozeně středem vašeho světa. Otevřete Setup, vytváříte objekty, stavíte flow, píšete Apex a integrujete jiné systémy do Salesforce. Všechno jako by začínalo orgem. Architekt musí kameru oddálit, protože v podniku je Salesforce jeden systém z mnoha a docela často to není ten, který data vlastní.

Nejdřív nakreslete krajinu

Kapitola 2 sestavila logický model a kapitola 3 se ptala, jak žije v Salesforce. Teď problém zvětším. Než rozhodnu, co má Salesforce vlastnit, chci pochopit podnik kolem něj. Jaké systémy už existují? Kde se vytvářejí zákazníci, definují produkty, zakládají objednávky, generují faktury? Kde žije identita? Kde probíhá analytika, kde se uchovávají dokumenty, kde leží historie? Které systémy potřebují data ze Salesforce a na kterých Salesforce závisí?

Tyto otázky mění architekturu. Začínám proto od prázdného plátna, dám Salesforce doprostřed a nakreslím všechno kolem. Modul 4 přesně ukazuje, jak to rozvrhuji. Prozatím je poučení prosté: nenavrhujte org dřív, než pochopíte svět, ve kterém musí žít.

Salesforce často není zdrojovým systémem

Vezměte velmi běžný podnik: Salesforce plus ERP, systém pro plánování podnikových zdrojů, jako je SAP nebo Oracle, který řídí finance, produkty, zásoby, nákup a vyřizování objednávek. Teď si položte jednoduchou otázku: kde žije zákazník?

Může to být Salesforce, ERP, nebo obojí, a tady to začíná být zajímavé. Obchodníci mohou s potenciálními zákazníky pracovat jako s účty v Salesforce, zatímco ERP vydá oficiální zákaznické číslo, až se z nich stanou platící zákazníci. Produkty a ceny? Nejspíš ERP. Zásoby? Téměř nikdy Salesforce. Objednávky se mohou zachytávat v Salesforce a vyřizovat v ERP; faktury přicházejí z ERP; servis žije v Salesforce; analytika je rozdělená mezi sestavy Salesforce a datový sklad. Najednou náš pěkný datový model Salesforce není podnikovým datovým modelem. Je jeho částí.

Integrace, kterou vidím pořád dokola

Nejčastější integrace, kterou vidím, vypadá takhle: zákazníci, produkty a ceny proudí do Salesforce z ERP a objednávky proudí ven. Dosaďte SAP, Oracle nebo jakékoli jiné ERP; tvar je stejný. ERP vlastní zlatý záznam zákazníka a produktu, takže tyto toky přicházejí zprava do Salesforce. Obchod uzavře obchod v Salesforce, takže objednávka začíná tam a jde zpět do ERP, aby se vyřídila, vyfakturovala a zaúčtovala.

Tyto toky nejsou jen integrace. Říkají mi, kde podnik věří, že žije pravda.

Jednosměrné šipky mě znervózňují

Kdykoli vidím integraci, která má jen jeden tok, začnu mít obavy. Na vysoké úrovni někdo nakreslí jedinou šipku: objednávky ze Salesforce do ERP. Dobře. Teď se podívejte hlouběji. Jak můžu poslat objednávku do ERP, když neznám jeho zákazníky, produkty ani ceny? Objednávka musí být navázaná na zákazníka, kterého ERP už má, a každý řádek musí být SKU, které ERP už prodává. Nemůžu poslat řádkovou položku produktu, který na druhé straně neexistuje. Než tedy šipka objednávek může fungovat, musí existovat zpětné toky opačným směrem.

To je otázka, kterou kladu u každé šipky: na čem tento tok závisí? Šipka, kterou vidíte na vysoké úrovni, obvykle potřebuje zpětné toky, které jste ještě nenakreslili.

Podívejte se ještě hlouběji a najdete cestu zpátky. Salesforce pošle objednávku. A co pak? Byla přijata, nebo odmítnuta? Odešla, odešla zčásti, byla zrušena? Byla vyfakturována? Potřebuje to někdo v Salesforce vědět? Možná ne. Ale někdo se měl zeptat. Pokud se nic nevrací, dobře. Řekněte mi proč.

Podnik nevznikl najednou

Krajiny jsou složité zčásti proto, že je nikdo nepostavil najednou. Data přicházela ve vlnách. Nejdřív soubory: záznamy s pevným formátem, pak soubory s oddělovači, jako CSV. Pak relační databáze pro provozní data. Pak datové sklady, které je spojily pro analýzu. Pak databáze NoSQL pro dokumenty, páry klíč–hodnota a grafy, které se do tabulek úhledně nevejdou. Pak datová jezera (data lake) pro obrovská množství surových a polostrukturovaných dat a lakehouse, který obojí kombinuje. Proudy událostí, jako Kafka nebo sběrnice událostí Salesforce, přesouvají data ve chvíli, kdy se dějí, místo v nočních dávkách. A teď federace, kdy se data nemusí kopírovat na jedno místo, aby je mohla použít jiná platforma.

O technologii zatím nejde. Jde o tohle: nová vlna jen vzácně nechá zmizet tu starou. Vejděte do velkého podniku a najdete je všechny najednou: relační databáze, ERP, Salesforce, datový sklad, datové jezero, výměny přes SFTP, API, proudy událostí, tabulku, kterou někdo pořád posílá e-mailem každý pátek, a ten jeden systém, na který se všichni bojí sáhnout, protože člověk, který ho postavil, je šest let v důchodu. To je podnik, který architektujete, ne ten z produktové brožury.

Různé systémy existují z různých důvodů

Proto také nikdy nezačínám otázkou „jak dostaneme všechna data do Salesforce?“ Proč bych je tam chtěl mít všechna? Salesforce může být nejlepší místo, kde obchodníci a servisní pracovníci pracují se zákazníky. To z něj nedělá finanční systém, podnikový datový sklad, úložiště telemetrie, archiv dokumentů ani domov každého kliknutí, údaje z GPS a historické transakce, kterou firma kdy vytvořila.

Kapitola 3 se ptala kde by tato data měla žít? pro jeden org. Na úrovni podniku je stejná otázka větší: někdy Salesforce data vlastní, někdy si drží kopii, někdy jen odkaz a někdy by je neměl mít vůbec.

Core, mimo core a Hyperforce

Je tu ještě jedna hranice, které je třeba rozumět: ani „Salesforce“ není jeden runtime a jedna databáze. V kapitole 3 znamenalo na core (on core), kde data leží: na vašem stole, ve vlastních objektech orgu. Tady stejná slova popisují, kde běží produkt. Uslyšíte architekty používat obojí.

Historicky hostil runtime Core většinu platformy. Dnes Salesforce popisuje platformu ze stovek nezávislých služeb řízených metadaty, přičemž Core zůstává jediným zdrojovým systémem pro metadata aplikací (The Salesforce Platform: Transformed for Tomorrow (otevře se v nové kartě)). Proto uslyšíte architekty říkat, že schopnost běží na core, nebo mimo core.

Záleželo na tom dávno předtím, než se platforma rozdělila na služby. Když se třídy ptám, proč Salesforce koupil pro nabídky SteelBrick, a ne Apttus, odpověď, kterou chci slyšet, je jednoduchá: SteelBrick byl postavený ze 100 % na core. Flow a triggery žijí v core, takže produkt postavený tam s sebou dostane metadata, přizpůsobení a automatizaci platformy. Ten produkt pro nabídky mezitím nahradil Revenue Cloud, ale poučení zůstalo. Pak je tu blízko core (near-core), a jako příklad používám Data 360. Data 360 není core. Jeho tenant je mimo core: data a mechanismy, které je zpracovávají, běží ve vlastním lakehouse, vedle relační databáze orgu, ne uvnitř ní (The Salesforce Platform: Transformed for Tomorrow (otevře se v nové kartě)). Obrazovky, kterými ho nastavujete a řídíte, se ale zobrazují na core, v orgu. Nejpřesněji to tedy můžu říct takhle: spravováno na core, hostováno mimo core. Žádná data ani zpracování ve skutečnosti v Core neběží; rozhraní na Core řídí tenant mimo core. A pak je tu samozřejmě všechno, co je mimo core, protože to vůbec není Salesforce.

Méně mi záleží na tom, nazpaměť vědět, který produkt letos běží kde, protože to se mění, než na návyku: hranice může ovlivnit přesun dat, latenci, identitu, integraci i rezidenci dat. Nepředpokládejte tedy, že když má produkt v názvu Salesforce, leží jeho data hned vedle vašich záznamů účtů. Podívejte se na skutečnou architekturu.

Pak je tu Hyperforce: infrastruktura Salesforce postavená pro veřejný cloud a definovaná jako kód, místo tradičních vlastních datových center, která zákazníkům dává větší výběr, kde jejich data sídlí (Salesforce Hyperforce: General Information and FAQ (otevře se v nové kartě)). Na tom záleží a modul 5 se k tomu vrací. Infrastrukturní architektura ale není podniková datová architektura. Přesun orgu do veřejného cloudu vám neřekne, kdo vlastní zákazníka, kde žijí zásoby, kde běží analytika ani která data smějí překročit hranici. Hyperforce může některá z těch rozhodnutí ovlivnit, zvlášť rezidenci. Znalost krajiny nenahradí.

Krajina je před krabicí

Tady je tedy ten návyk. Někdo vám podá scénář. Nezačínejte stavět řešení v Salesforce. Nejdřív najděte systémy: ERP, poskytovatele identity, datový sklad, integrační platformu, systémy partnerů, zákaznické kanály, úložiště dokumentů. Pak najděte data, která se mezi nimi přesouvají: zákazníky, produkty, objednávky, faktury, dokumenty, události, identity. Pak se zeptejte, kdo každé z nich vlastní. Teprve pak rozhodněte, co patří do Salesforce. Jinak navrhujete krabici, aniž byste věděli, k čemu se připojuje.

Kliknutím zvětšíte

Krok 1 ze 3: org, který navrhujeme, sám o sobě. Odsud vypadá jako celý svět.

Kliknutím zvětšíte

Krok 2 ze 3: oddalte. Salesforce je jeden systém z mnoha (modul 4 učí toto rozvržení).

Kliknutím zvětšíte

Krok 3 ze 3: první šipky. Zákazníci, produkty a ceny dovnitř z ERP, objednávky ven: říkají, kde podnik věří, že žije pravda.

Krajina mění datový model

Proto na tom datovému architektovi záleží. Kapitola 2 říká, že zákazník je důležitá entita. Dobře. Pak krajina řekne, že pro zákazníka je autoritativní ERP. To mění fyzický model. Salesforce si může dál držet lokální účet, protože ho lidé používají každý den, ale teď potřebujeme identifikátor z ERP jako External ID; potřebujeme vědět, která pole smí Salesforce měnit (pole ERP označuji předponou erp_, jak uvidíme v modulu 3); jak rychle přicházejí změny z ERP; jestli Salesforce může vytvořit zákazníka dřív, než o něm ERP ví; a co se stane, když se ti dva neshodnou. To nejsou integrační otázky na později. Jsou to otázky datové architektury a odhalila je krajina.

Tady je, jak jedna z nich kousne. Obchodník převede zájemce za velkou nápojovou společnost, vytvoří účet, vyhraje obchod a zákazník odejde do ERP. Firma ale s tou nápojovou společností obchoduje už roky a ERP ji už má. Teď jsou dva. Měl obchodník vůbec mít možnost ten účet vytvořit? Kapitoly 5 a 6 se k tomu vracejí; v krajině to uvidíte přicházet.

Co tady rozhoduje architekt

• Které systémy obklopují Salesforce a jakou roli každý hraje.
• Který systém vlastní každý důležitý druh dat, dřív než rozhodneme, kolik z nich si Salesforce ponechá.
• Co proudí do Salesforce, co proudí ven a co se vrací.
• Která data má Salesforce vlastnit, kopírovat, odkazovat, federovat, archivovat nebo nechat být.
• Na kterých hranicích platformy a infrastruktury záleží, místo předpokladu, že všechno se značkou Salesforce žije na jednom místě.

Posun od vývojáře k architektovi často není o tom naučit se další funkci. Je o tom naučit se, kdy se přestat dívat na Salesforce: oddálit kameru, sledovat data, najít, kdo vlastní pravdu, a pak se vrátit a rozhodnout, jaká má být práce Salesforce.

K prozkoumání

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (otevře se v nové kartě), ověřeno 2026-10-17.