Znejte své nástroje: devět otázek

🌐 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 6 ze 7 kapitoly Myslet jako datový architekt, první kapitoly kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Stavějte pro dnešek. Plánujte pro zítřek. Plánujte pro selhání. · Další: Datový architekt v době AI

Otázka, na kterou tento modul odpovídá: Jak zhodnotit jakýkoli nástroj, včetně toho, který jste ještě nikdy neviděli?

Architekti potřebují úsudek. Úsudek bez znalostí ale není moc užitečný. Své nástroje pořád musíte znát.

Architekty učím už roky a jeden rámec, který používám, je sada otázek, na které byste měli umět odpovědět u každého důležitého nástroje nebo schopnosti ve vaší architektuře. Původně jsem učil osm otázek. Přidal jsem devátou. Technologie se mění, Salesforce se mění, objevují se nové produkty a staré schopnosti se vyvíjejí, a AI to všechno zrychluje. Tyto otázky fungují dál.

Devět otázek

Kdykoli se nějakou technologii učíte nebo ji hodnotíte, ptejte se:

1. Co to je?
2. Kde se to používá?
3. Jak to používám?
4. Jaké mám alternativy?
5. Jaké jsou silné stránky?
6. Jaké jsou slabé stránky?
7. Jak to vysvětlím vývojářům, byznysu a vedení?
8. Jak se to dlouhodobě udržuje?
9. Kolik to stojí, jaké licence to vyžaduje a jaké má limity?

Pokud dokážete odpovědět na všech devět, začínáte nástroji rozumět jako architekt. Všimněte si, co na seznamu není: „Umím to nakonfigurovat?“ I to je důležité, ale je to jen část znalosti nástroje.

Kliknutím zvětšíte

1. Co to je?

Začněte samozřejmou otázkou, protože ji lidé překvapivě často přeskakují. Slyšíme název produktu nebo funkce a hned začneme debatovat, jestli ho použít. Zpomalte. Co to doopravdy dělá? Jaký problém to mělo řešit? Kde to v architektuře sedí a co to není? Architekt by měl umět technologii popsat, aniž by opakoval marketingový popis. Pokud něco nedokážu vysvětlit pár větami, pravděpodobně tomu zatím dost nerozumím.

2. Kde se to používá?

Vědět, co něco dělá, není totéž jako vědět, kdy to do architektury patří. V jakých problémech je to dobré? Za jakých podmínek je to vhodné a za jakých by mi to mělo být podezřelé? To je krok od „znám tuhle funkci“ k „poznám problém, který tahle funkce řeší“, a je to velký krok. Nechcete chodit kolem a hledat místa, kde použít svou oblíbenou technologii. Chcete rozpoznávat problémy a vědět, které nástroje na ně sedí.

3. Jak to používám?

Ano, architekti by měli rozumět implementaci. Nemusíte stavět každou komponentu, ale měli byste rozumět dost na to, abyste věděli, o co jiné lidi žádáte. Vězte, jak se to konfiguruje, jak s tím pracuje vývojář, jak se data dostávají dovnitř a ven, jak se to nasazuje a zabezpečuje a jak to vypadá v provozu. Nechci, aby architekt navrhoval kolem technologie, kterou viděl jen na produktovém slajdu. Ušpiněte si ruce: něco postavte, něco rozbijte, podívejte se, jak se to doopravdy chová. Architektura je lepší, když stojí na realitě.

4. Jaké mám alternativy?

Tohle je možná nejdůležitější otázka na seznamu. Pokud znáte jen jeden způsob, jak problém vyřešit, nemáte architektonické rozhodnutí; máte výchozí volbu. Kdykoli někdo navrhne technologii, chci vědět, co jiného bychom mohli udělat. Jinou schopnost Salesforce? Něco deklarativního, nebo kód? Mohla by ta schopnost žít mimo Salesforce? Mohli bychom data nechat tam, kde jsou, místo kopírování, použít událost místo volání API, nebo nestavět vůbec nic? Alternativy vytvářejí kompromisy a kompromisy jsou srdcem architektury.

5. Jaké jsou silné stránky?

Každý nástroj existuje z nějakého důvodu. Pochopte, v čem je opravdu dobrý: co usnadňuje, kde dobře škáluje, jakou složitost odstraňuje, jaké problémy elegantně řeší. Používejte technologie tam, kde jejich silné stránky odpovídají problému. Zní to samozřejmě, ale je velmi snadné vybrat nástroj proto, že ho už vlastníme, tým ho zná, je nový nebo někdo viděl demo. To mohou být faktory. Není to ale totéž co architektonická vhodnost.

6. Jaké jsou slabé stránky?

Tohle je stejně důležité. Každá technologie má slabé stránky, úplně každá. Pokud vám někdo umí říct jen silné stránky technologie, architektonickou diskusi ještě nevedete. Co nedělá dobře? Kde se objevuje složitost a co se stane ve velkém měřítku? Jakou provozní zátěž a závislosti přináší? Které požadavky ji vytlačí z jejího ideálního pásma? Slabá stránka neznamená vždycky, že bychom technologii neměli použít. Znamená, že musíme vědět, co přijímáme. Kompromis, kterému rozumíte, může být architektonické rozhodnutí. Kompromis, kterému nerozumíte, se může stát překvapením.

7. Jak to vysvětlím různému publiku?

Tohle je jedna z otázek, které oddělují technické znalosti od architektonické dovednosti. Dokážete stejnou technologii vysvětlit vývojáři, byznysu i vedení? To by neměla být stejná vysvětlení. Vývojář potřebuje API, chování transakcí, zabezpečení, ošetření chyb a implementační vzory. Byznys zajímá, co to umožní a jak se změní jeho proces. Vedení zajímají náklady, rizika, čas, dopad na organizaci a to, které možnosti rozhodnutí nechává otevřené a které zavírá. Neměníte pravdu; měníte úroveň abstrakce. Pokud technologii dokážete vysvětlit jen slovníkem její dokumentace, pracujte na svém porozumění dál.

8. Jak se to dlouhodobě udržuje?

Projekty končí. Systémy ne, nebo aspoň doufáme, že ne. Někdo musí to, co postavíme, vlastnit i potom, co projektový tým odejde. To znamená vědět, jak se to monitoruje, aktualizuje a jak se v tom hledají chyby, kdo potřebuje dovednosti k podpoře, jak se změny nasazují a testují a co se stane, když se technologie vyvine nebo Salesforce pod námi něco změní. Představte si to za tři roky. Viděl jsem architektury, které byly v den spuštění velmi chytré a potom mizerné na provoz. To není úspěch. Udržovatelnost je součást architektury.

9. Kolik to stojí, jaké licence to vyžaduje a jaké má limity?

Tohle je otázka, kterou jsem přidal k původním osmi, a dnes si myslím, že ji nelze vynechat. Technologie může být dokonalé technické řešení, a přesto špatné architektonické řešení, pokud nevychází ekonomika. Je zahrnutá v licencích, které máme, nebo je to doplněk? Licencuje se podle uživatelů, použití, spotřeby, úložiště nebo transakcí? Co se stane s náklady, když budeme škálovat?

Pak jsou tu limity, a ty má každá platforma: limity API, úložiště, dotazů, transakcí, souběžnosti, propustnosti a licencí. Některé jsou pevné, jiné měkké; některé lze zvýšit a jiné ne; některé při našem měřítku nehrají roli, dokud nepřidáme další nulu. Nemusíte se učit nazpaměť každý limit Salesforce a bylo by to strašné plýtvání časem. Potřebujete vědět, že limity existují, které z nich jsou pro vaši architekturu důležité a kdy si jít ověřit aktuální číslo. Čísla se změní. Architektonická otázka zůstane.

Příklad z praxe: sdílení v Apexu

Tady je jeden z mých nejčastějších příkladů otázek v akci. Dostaneme požadavek na složité sdílení, sdílení, které nelze splnit žádným z pravidel sdílení podle vlastníka ani podle kritérií. To nás přivede ke sdílení v Apexu (Apex sharing): kódu, který záznamy sdílení zapisuje sám. Teď tedy potřebujeme vědět, co sdílení v Apexu je, kde se používá, jak ho použít a tak dál. Je to eskalace: sdílení v Apexu je alternativa (otázka 4) pro chvíle, kdy pravidla, která potřebujeme, přesahují to, co sdílení podle vlastníka a kritérií dokáže vyjádřit.

Teď jeho slabé stránky (otázka 6). Řekněme, že máme zákaznickou komunitu s 10 nebo 20 miliony členů a používáme licenci Customer Community, ne Customer Community Plus. To jsou uživatelé s vysokým objemem (high-volume users). Nemají role a model sdílení vůbec nepoužívají: jejich přístup pochází ze sad sdílení a skupin sdílení, spárovaných přes jejich účet a kontakt. Neexistuje pro ně žádný záznam sdílení, který by mohl Apex zapsat, takže sdílení v Apexu pro ně nefunguje. A otázka nákladů a licencí (otázka 9) je to, co nás tam dostalo: volba licence rozhodla o tom, které nástroje sdílení vůbec existují.

Takže stejně jako bylo sdílení v Apexu alternativou k pravidlům podle vlastníka a kritérií, můžete narazit na případ, kdy potřebujete alternativu ke sdílení v Apexu. A v tu chvíli opravdu nejsou k dispozici žádné konfigurační možnosti pro složitá pravidla sdílení. Skončíte tak, že objekt nastavíte jen pro čtení a přístup řídíte přes Apex. Proto si všech devět otázek položte dřív, než si vyberete, ne až potom.

Neučte se platformu nazpaměť

Na tomhle záleží nejvíc, když se učíte architekturu Salesforce. Nesnažte se Salesforce naučit nazpaměť. Nejde to: platforma je příliš velká a mění se příliš rychle. Se Salesforce pracuji dlouho a pořád se učím. To je normální.

Chci, abyste si vypěstovali rámec pro učení. Když Salesforce zítra vydá novou schopnost, nemusím ji znát předem. Vím, na co se zeptat: co to je, kam to zapadá, jak to používám, co jiného bych mohl použít, v čem je to dobré, kde to má potíže, jak to vysvětlím, jak to budu provozovat a kolik to stojí a kde jsou limity? Teď to můžu začít hodnotit. To má mnohem větší hodnotu než naučit se nazpaměť další matici funkcí.

Nad rámec zkoušky: s AI se na devět otázek odpovídá rychleji a snáz se v nich chybuje. Narazíte na technologii, kterou neznáte, a můžete AI požádat, aby ji vysvětlila, porovnala tři přístupy, vyjmenovala její limity a běžné způsoby selhání, nebo aby argumentovala proti jejímu použití. To je pozoruhodný výzkumný asistent. Může se ale mýlit, mít zastaralé informace nebo sebevědomě zaměnit dva podobně pojmenované produkty či edice. U všeho, co ovlivňuje rozhodnutí, si to ověřte: jděte ke zdroji a zkontrolujte aktuální dokumentaci, limity a licence. Důvěřuj, ale prověřuj (modul 7).

Učte se otázky, ne jen odpovědi

V tomto kurzu potkáme spoustu technologií. Nechci, abyste sbírali odpovědi; chci, abyste trénovali otázky. Až budeme mluvit o big objects, externích datech, Data 360, integračních vzorech nebo o schopnosti AI, kterou Salesforce vydá šest měsíců po napsání této kapitoly, položte si stejných devět otázek.

Odpovědi se změní. Otázky vydrží. Právě proto je to architektonický rámec, a ne studijní průvodce.

Znejte své nástroje: v čem jsou dobré, v čem špatné, co jiného byste mohli použít, kolik stojí a kde se lámou. A vězte dost na to, abyste rozhodnutí vysvětlili lidem, kteří s ním budou muset žít. Takhle se architekt učí technologie.

Co tady rozhoduje architekt

• Zda nástroj sedí na problém, posouzeno všemi devíti otázkami, ne jen tím, jestli se dá nakonfigurovat.
• Jaké jsou alternativy a co náklady, licence a limity nástroje znamenají ve vašem měřítku.
• Kdo ho bude za tři roky udržovat a jak.
• Které údaje o nástroji si ověřit dřív, než se na ně spolehnete.

K prozkoumání

• About High-Volume Community or Site Users (otevře se v nové kartě), Salesforce Help (ověřeno 2026-10-17): uživatelé s vysokým objemem (licence External Apps, Customer Community, High Volume Customer Portal a Authenticated Website) nemají role; jejich přístup pochází ze sad sdílení a skupin sdílení; nelze je zahrnout do pravidel sdílení podle vlastníka a záznamy, které vlastní, nelze sdílet ručně.
• Platform Sharing Architecture (otevře se v nové kartě), Salesforce Architects (ověřeno 2026-10-17): uživatelé s vysokým objemem (Customer Community, High Volume Customer Portal, Authenticated Website) nepoužívají model sdílení, protože jejich licence nepodporují role; přístup funguje spárováním uživatele s lookupy Account a Contact, přes sady sdílení nebo skupiny sdílení. Stejná stránka uvádí, kdy je správným nástrojem spravované sdílení v Apexu (Apex managed sharing).
• Account Sharing Sets for High Volume Customer Portal Users (otevře se v nové kartě), otázka v Trailblazer Community, listopad 2024 (ověřeno 2026-10-17): praktik hlásí, že vložení záznamů sdílení pro uživatele s vysokým objemem skončilo chybou. Zpráva z praxe, ne oficiální dokumentace. (Online Trailblazer Community bude od 30. října 2026 jen pro čtení; odkaz se může změnit.)
• Create a Sharing Set for Experience Cloud Site Users (otevře se v nové kartě), Salesforce Help (ověřeno 2026-10-17): sada sdílení uděluje přístup k záznamům souvisejícím s účtem nebo kontaktem uživatele.