Strategie orgů je rozhodnutí o krajině

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

Otázka, na kterou tento modul odpovídá: Jeden org, nebo mnoho, a kde poběží?

Když učím kandidáty na CTA, říkám jim, že největší rozhodnutí ve scénáři přichází v prvních pěti nebo deseti minutách: s kolika orgy Salesforce máme co do činění? Jeden velký org? Regionální orgy pro Severní Ameriku, EMEA a APAC? Samostatné orgy pro samostatné obchodní jednotky? Zvláštní org pro zemi s vlastními pravidly? A přímo s tím spojené: kde ty orgy běží?

To nejsou administrátorské detaily. Mění, kde data žijí, integrace, sestavy, identitu a to, jak se lidé po celém světě k systému dostávají. Proto beru strategii orgů jako rozhodnutí o krajině a proto ho dělám jako první.

Začněte jedním orgem

Můj výchozí postoj je jednoduchý: začněte jedním orgem. Ne proto, že by jeden org byl vždycky správně, ale proto, že potřebuji důvod přidat další. Jeden org mi dává jedno místo pro sdílená zákaznická data, jeden model zabezpečení, jedno místo pro nasazování, jednu sadu integrací, jedno místo pro sestavy. A jeden org pořád dokáže podporovat různé obchodní jednotky, země, procesy, typy záznamů, aplikace, modely sdílení i zážitky.

Nepřidávám tedy org proto, že Evropa dělá věci trochu jinak, nebo že divize má vlastní prodejní proces, nebo že se obchodní jednotky nemají rády. To jsou požadavky, ne hranice orgů. Otázka zní: jaká síla je dost silná, aby ospravedlnila další org?

Více orgů něco stojí

Rozdělte jeden org na tři (Severní Amerika, Evropa, Asie a Tichomoří) a nenakreslili jste tři úhledné krabice; vytvořili jste nové otázky. Kde žije globální zákazník? Co když působí ve dvou regionech: dvě kopie, a která ho vlastní? Jak kdokoli udělá globální sestavu? Integruje se ERP se všemi třemi, dostane datový sklad tři zdroje, připojí se poskytovatel identity ke všem třem? Nasazujeme stejnou funkčnost třikrát a udržujeme tři datové modely v souladu? Pokud agent potřebuje globální pohled na zákazníka, kterého orgu se zeptá?

Vraťte se ke krajině z modulu 4. Z jedné krabice Salesforce jsou tři a každá šipka se překreslí. Více orgů není špatně. Nikdy to ale není zadarmo.

Hledejte skutečné hranice

Co může ospravedlnit další org? Hranice dost skutečné na to, aby utvářely architekturu: rezidence dat, regulace, právní oddělení, opravdu odlišné provozní modely, akvizice, která se ještě nesloučila, omezení regionálního hostingu, velmi odlišné řízení, někdy měřítko nebo izolace. Seznam není úplný. Jde o to rozlišit „tyto skupiny jsou odlišné“ od „tyto skupiny potřebují architektonickou hranici“. Druhá laťka je mnohem výš.

Geografie není automaticky strategie orgů

„Působíme ve 30 zemích, takže potřebujeme 30 orgů.“ Ne. Geografie je důležitá, když přináší architektonický požadavek. Firma může mít uživatele po celém světě na jedné společné architektuře. Nepočítám tedy země; ptám se, co s nimi přichází. Kde smějí být data uložená? Kde se smějí zpracovávat? Jsou omezení pro přenos osobních údajů přes hranice? Smluvní sliby o rezidenci? Potřebuje region jinou službu nebo hostitele Salesforce? „Máme kancelář v Německu“ samo o sobě nestačí.

Hosting je součástí kresby

Tady moderní platforma dělá krajinu zajímavější. Hyperforce provozuje Salesforce na infrastruktuře veřejného cloudu v regionech po celém světě a dává zákazníkům větší výběr a kontrolu nad tím, kde jejich data sídlí (Salesforce Hyperforce: General Information and FAQ (otevře se v nové kartě)). Když tedy krabici označím „Salesforce, Evropa“, to umístění může mít význam.

Buďte ale přesní. Volba, kde org žije, není slib, že každý bajt každé služby zůstane tam. Salesforce zákazníkům říká, ať si projdou dokumentaci k důvěře a souladu pro Hyperforce, včetně dalších subzpracovatelů pro služby, které kupují (stejný zdroj). Neříkejte tedy „jsme na Hyperforce v zemi X, takže všechno zůstává v zemi X“. Vězte, které služby skutečně používáte a který požadavek plníte. A všimněte si, co volíte: region, ne cloud pod ním. Hyperforce běží na AWS, od konce roku 2026 i na Google Cloud, a o tom, na kterém poskytovateli org sedí, rozhoduje Salesforce; zákazník se zdokumentovaným regulatorním důvodem se některému vyhnout to řeší se svým account týmem (stejný zdroj).

Nehrajte si na právníka

Tady také architekti musí znát svou roli. Když někdo řekne „evropské právo na ochranu soukromí vyžaduje samostatný org“, nepřijmu to slepě. Zároveň se nejmenuji firemním právníkem a neprohlásím, že ne. Zeptám se: jaký konkrétní požadavek plníme? Kde se data ukládají, kde se zpracovávají, přenos přes hranice, kdo k nim má přístup kvůli podpoře, smlouva, interní pravidla? Pak s lidmi z ochrany soukromí, bezpečnosti, compliance a práva převedu ten požadavek na architekturu. Nevymýšlejte si právní požadavky a neignorujte je. Překládejte je.

Když Evropa dostane vlastní org

Tady je hranice, kterou vídám ve skutečných scénářích. Firma má silnou přítomnost v USA a silnou přítomnost v Evropě: dvě velké zákaznické základny, dva prodejní a servisní provozy a evropský program ochrany soukromí postavený kolem GDPR. GDPR neříká „potřebujete samostatný org Salesforce“. Stanovuje pravidla pro osobní údaje, včetně toho, kdy smějí být předány mimo EU (GDPR, kapitola V (otevře se v nové kartě)). Tato firma ale ve spolupráci se svými týmy pro ochranu soukromí a právo rozhodne, že osobní údaje jejích evropských zákazníků mají žít v orgu hostovaném v Evropě, provozovaném jejím evropským týmem, pod jejím evropským řízením. To je skutečný požadavek, a je jejich, ne můj.

Teď už „jeden velký globální org“ není preference. V krajině je hranice, Salesforce AMER a Salesforce EMEA, a já ji musím nakreslit. A druhý org nikdy není jen o jednu krabici víc.

Kliknutím zvětšíte

Dva orgy, AMER a EMEA. Jantarová barva je to, co přidává druhý org: ne o jednu krabici víc, ale znovu každou šipku.

Projděte šipky znovu

S více než jedním orgem projděte krajinu znovu. Posílá ERP produkty do každého orgu? Posílá každý z nich objednávky zpět? Kde jsou zákazníci spravovaní jako kmenová data a smějí jejich data překročit regiony? Je integrační vrstva globální, nebo regionální? Který poskytovatel identity přihlašuje které uživatele? Kam jdou analytická data?

Cenu nejrychleji ukazují tři místa:

Sestavy. Generální ředitel chce globální pipeline. V jednom orgu je to sestava v Salesforce. Ve třech je to problém podnikových sestav: replikovat, poslat do datového skladu, federovat? Jak aktuální to musí být a definují orgy „pipeline“ vůbec stejně? Kde žije analytika, se řídí tím, kde žijí data, a pokud záměrně rozdělíte provozní data, musíte navrhnout, jak se poznatky znovu spojí.

Kmenová data. Globální zákazník nakupuje v USA, Německu a Japonsku. Tři orgy, takže nejspíš tři účty. Jak poznáte, že jde o stejnou firmu? Jaký je globální identifikátor a kdo ho vlastní? Pokud jeden region změní adresu, má se to rozšířit? Které atributy jsou globální a které regionální? Strategie orgů problém identity neřeší; mění ho. To je kapitola 6.

Integrace. Jeden org: Salesforce, integrační vrstva, ERP. Tři orgy: tři spojení do integrační vrstvy, možná jedno s vlastním hostitelem a konektivitou, některé toky sdílené, některé regionální, některá data smějí přes hranici a některá ne. Změnit se může i síť: pokud podnik potřebuje vyhrazenou soukromou konektivitu do Hyperforce (na AWS Salesforce doporučuje AWS Direct Connect; stejné FAQ k Hyperforce), je každý org a hostitel na kresbě dalším spojením k naplánování. Kde org běží, může změnit, jak se k němu dostává zbytek podniku.

Jeden org, nebo mnoho, je rozhodnutí, které děláte teď, na začátku, v krajině. Jak pak orgy sdílejí data (Salesforce Connect mezi orgy, integrace mezi nimi, Data 360), je mechanika a pokrývá ji kapitola 14, Jeden org, nebo mnoho? (coming soon).

Pokud navrhnete celý datový model a integrační architekturu a teprve pak uslyšíte „mimochodem, tohle musí být tři orgy“, neudělali jste malou úpravu. Změnili jste architekturu. Proto to rozhodnutí přichází první.

Nedělte jen proto, aby byly krabice menší

Velký org působí složitě: spousta jednotek, objektů, uživatelů, integrací. Někdo řekne: „Nebylo by čistší, kdyby měl každý vlastní org?“ Kresba může být čistší. Podnik možná ne. Vyměnili jste vnitřní složitost za rozptýlenou: synchronizaci, duplicitní data, identitu napříč orgy, globální sestavy, několik pipeline vydání, zduplikované integrace a automatizaci a řízení toho všeho. Někdy je to pořád správná výměna. Ale oddělené není totéž co jednoduché.

A ani jeden org není zadarmo. Víc záleží na společném řízení, týmy se mohou navzájem ovlivňovat, hranice zabezpečení potřebují pečlivý návrh, datový model musí sloužit mnoha skupinám, vydání potřebují koordinaci a regionální pravidla mohou omezovat všechny. Neplatí tedy „Steve říká vždycky jeden org“. Můj výchozí sklon je jeden org; pak hledám požadavek dost silný na to, aby mě z něj posunul.

Udělejte rozhodnutí viditelným

Pokud na strategii orgů záleží, nekreslete obecný mrak Salesforce. Nakreslete orgy a popište je (AMER, EMEA, cokoli je skutečné), poznamenejte požadavek na hosting nebo rezidenci za každým z nich a projděte spojení. Jiný architekt by měl vidět, proč každá hranice existuje. Pokud neumím vysvětlit, proč jsou tu tři krabice Salesforce, nedokončil jsem rozhodnutí.

Steve Trucking provozuje jeden org v USA a nic v jeho zadání další nevyžaduje. Tento modul si ale pamatujte pro závěrečný projekt: akvizice, která přijde s vlastním orgem, je přesně ten druh hranice, který tyto otázky prověří.

Nad rámec zkoušky: co mění AI. Agent může hranici orgu před uživatelem skrýt. Pod tím musí architektura pořád rozhodnout, kterého orgu nebo systému se agent smí ptát, která data smějí překročit regiony a která odpověď je autoritativní. AI může složitost v zážitku skrýt; řízení ani hranici neodstraní.

Co tady rozhoduje architekt

• Zda existuje skutečný architektonický důvod pro víc než jeden org, místo řešení rozdílů uvnitř jednoho.
• Kde každý org běží a který požadavek na rezidenci, regulaci, smlouvu nebo byznys ho tam dává.
• Která data smějí překračovat hranice orgů a regionů, kde jsou kmenová data autoritativní a jak funguje globální identita.
• Jak se mění integrace, identita, analytika a sestavy, když se z jedné krabice Salesforce stane několik.
• Zda přínos oddělení stojí za rozptýlenou architekturu, kterou vytváří.

Když čtu scénář, hledám nejdřív toto rozhodnutí: jeden org, nebo mnoho, hostovaný kde a vynucený čím? Odpovězte na to a zbytek krajiny začne dostávat tvar.

K prozkoumání

• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (otevře se v nové kartě), ověřeno 2026-10-17.
• EUR-Lex, Nařízení (EU) 2016/679, obecné nařízení o ochraně osobních údajů (otevře se v nové kartě), kapitola V (předávání osobních údajů do třetích zemí), ověřeno 2026-10-17.