Poznaj swoje narzędzia: dziewięć pytań

🌐 Dostępne także w 28 językach

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

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku

Moduł 6 z 7 w rozdziale Myśleć jak architekt danych, pierwszym rozdziale kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Buduj na dziś. Planuj na jutro. Planuj na awarię. · Dalej: Architekt danych w czasach AI

Pytanie, na które odpowiada ten moduł: jak ocenić dowolne narzędzie, także takie, którego nigdy wcześniej nie widziano?

Architekci potrzebują osądu. Ale osąd bez wiedzy niewiele daje. Nadal musisz znać swoje narzędzia.

Uczę architektów od lat, a jednym z narzędzi, których używam, jest zestaw pytań, na które powinno się umieć odpowiedzieć w odniesieniu do każdego ważnego narzędzia lub funkcji w twojej architekturze. Pierwotnie uczyłem ośmiu pytań. Dodałem dziewiąte. Technologie się zmieniają, Salesforce się zmienia, pojawiają się nowe produkty, a stare funkcje ewoluują, i AI to wszystko przyspiesza. Te pytania nadal działają.

Dziewięć pytań

Kiedy uczysz się technologii albo ją oceniasz, zapytaj:

1. Co to jest?
2. Gdzie się tego używa?
3. Jak tego używać?
4. Jakie mam alternatywy?
5. Jakie są mocne strony?
6. Jakie są słabe strony?
7. Jak to wyjaśnić programistom, biznesowi i zarządowi?
8. Jak to utrzymywać w długim okresie?
9. Ile to kosztuje, jakich licencji wymaga i jakie ma limity?

Jeśli potrafisz odpowiedzieć na wszystkie dziewięć, zaczynasz rozumieć narzędzie jak architekt. Zauważ, czego nie ma na liście: „Czy potrafię to skonfigurować?”. To ważne, ale to tylko część znajomości narzędzia.

Click to enlarge

1. Co to jest?

Zacznij od oczywistego pytania, bo ludzie zaskakująco często je pomijają. Słyszymy nazwę produktu albo funkcji i od razu zaczynamy dyskutować, czy jej użyć. Zwolnij. Co to właściwie robi? Jaki problem miało rozwiązywać? Gdzie leży w architekturze i czym nie jest? Architekt powinien umieć opisać technologię bez powtarzania opisu marketingowego. Jeśli nie potrafię czegoś wyjaśnić w kilku zdaniach, pewnie jeszcze nie rozumiem tego wystarczająco dobrze.

2. Gdzie się tego używa?

Wiedzieć, co coś robi, to nie to samo co wiedzieć, kiedy pasuje do architektury. W jakich problemach to się sprawdza? Jakie warunki sprawiają, że jest odpowiednie, a jakie powinny wzbudzić moją podejrzliwość? To krok od „znam tę funkcję” do „rozpoznaję problem, który ta funkcja rozwiązuje”, i to krok duży. Nie chcesz chodzić i szukać miejsc, gdzie można użyć ulubionej technologii. Chcesz rozpoznawać problemy i wiedzieć, które narzędzia do nich pasują.

3. Jak tego używać?

Tak, architekci powinni rozumieć implementację. Nie musisz budować każdego komponentu, ale musisz rozumieć dość, żeby wiedzieć, o co prosisz innych. Wiedz, jak to się konfiguruje, jak pracuje z tym programista, jak dane trafiają do środka i na zewnątrz, jak to się wdraża i zabezpiecza i jak wygląda w działaniu. Nie chcę, żeby architekt projektował wokół technologii, którą widział tylko na slajdzie produktowym. Ubrudź sobie ręce: zbuduj coś, zepsuj coś, zobacz, jak to naprawdę się zachowuje. Architektura jest lepsza, gdy stoi na rzeczywistości.

4. Jakie mam alternatywy?

To może być najważniejsze pytanie na liście. Jeśli znasz tylko jeden sposób rozwiązania problemu, nie masz decyzji architektonicznej; masz ustawienie domyślne. Kiedy ktoś proponuje technologię, chcę wiedzieć, co jeszcze moglibyśmy zrobić. Inna funkcja Salesforce? Coś deklaratywnego czy kod? Czy ta funkcja mogłaby działać poza Salesforce? Czy moglibyśmy zostawić dane tam, gdzie są, zamiast je kopiować, użyć zdarzenia zamiast wywołania API albo w ogóle niczego nie budować? Alternatywy tworzą kompromisy, a kompromisy są sercem architektury.

5. Jakie są mocne strony?

Każde narzędzie istnieje z jakiegoś powodu. Zrozum, w czym jest naprawdę dobre: co ułatwia, gdzie dobrze się skaluje, jaką złożoność usuwa, jakie problemy rozwiązuje elegancko. Używaj technologii tam, gdzie ich mocne strony pasują do problemu. Brzmi to oczywiście, ale bardzo łatwo wybrać narzędzie, bo już je mamy, zespół je zna, jest nowe albo ktoś widział demo. To mogą być czynniki. Ale to nie to samo co dopasowanie architektoniczne.

6. Jakie są słabe strony?

To równie ważne. Każda technologia ma słabe strony, każda. Jeśli ktoś potrafi wymienić tylko mocne strony technologii, nie prowadzicie jeszcze rozmowy o architekturze. Czego nie robi dobrze? Gdzie pojawia się złożoność i co się dzieje w skali? Jakie obciążenie operacyjne i zależności wnosi? Jakie wymagania wypychają ją poza jej najlepszy obszar? Słaba strona nie zawsze oznacza, że nie powinniśmy używać technologii. Oznacza, że musimy wiedzieć, co akceptujemy. Kompromis, który rozumiesz, może być decyzją architektoniczną. Kompromis, którego nie rozumiesz, może stać się niespodzianką.

7. Jak to wyjaśnić różnym odbiorcom?

To jedno z pytań, które oddzielają wiedzę techniczną od umiejętności architektonicznych. Czy potrafisz wyjaśnić tę samą technologię programiście, biznesowi i członkowi zarządu? To nie powinno być to samo wyjaśnienie. Programista potrzebuje API, zachowania transakcji, bezpieczeństwa, obsługi błędów i wzorców implementacji. Biznes interesuje, co to umożliwia i jak zmienia się jego proces. Członka zarządu interesują koszty, ryzyko, czas, wpływ na organizację i to, które opcje decyzja zostawia otwarte, a które zamyka. Nie zmieniasz prawdy; zmieniasz poziom abstrakcji. Jeśli jedyny sposób, w jaki potrafisz wyjaśnić technologię, to słownictwo z jej dokumentacji, pracuj dalej nad zrozumieniem.

8. Jak to utrzymywać w długim okresie?

Projekty się kończą. Systemy nie, a przynajmniej mamy taką nadzieję. Ktoś musi być właścicielem tego, co zbudowaliśmy, po odejściu zespołu projektowego. To znaczy wiedzieć, jak to się monitoruje, aktualizuje i diagnozuje, kto potrzebuje umiejętności, żeby to wspierać, jak wdraża się i testuje zmiany i co się stanie, gdy technologia ewoluuje albo Salesforce zmieni coś pod naszymi stopami. Wyobraź to sobie za trzy lata. Widziałem architektury, które w dniu startu były bardzo sprytne, a potem fatalne w eksploatacji. To nie jest sukces. Łatwość utrzymania jest częścią architektury.

9. Ile to kosztuje, jakich licencji wymaga i jakie ma limity?

To pytanie dodałem do pierwotnych ośmiu i dziś uważam, że nie da się go pominąć. Technologia może być idealnym rozwiązaniem technicznym, a mimo to złym rozwiązaniem architektonicznym, jeśli nie zgadza się ekonomia. Czy jest zawarta w licencjach, które mamy, czy to dodatek? Czy licencjonuje się ją na użytkownika, użycie, zużycie, przestrzeń dyskową czy transakcje? Co dzieje się z kosztem, gdy się skalujemy?

Do tego dochodzą limity, a każda platforma je ma: limity API, przestrzeni, zapytań, transakcji, współbieżności, przepustowości i licencji. Niektóre są twarde, inne miękkie; niektóre można podnieść, innych nie; niektóre nie mają znaczenia w naszej skali, dopóki nie dodamy kolejnego zera. Nie musisz zapamiętywać każdego limitu Salesforce, a robienie tego byłoby fatalnym wykorzystaniem twojego czasu. Musisz wiedzieć, że limity istnieją, które z nich mają znaczenie dla twojej architektury i kiedy sprawdzić aktualną liczbę. Liczby się zmienią. Pytanie architektoniczne zostaje.

Przykład krok po kroku: udostępnianie przez Apex

Oto jeden z moich najczęstszych przykładów tych pytań w działaniu. Dostajemy wymaganie dotyczące skomplikowanego udostępniania, którego nie da się spełnić żadną z reguł udostępniania opartych na właścicielu ani na kryteriach. To prowadzi nas do udostępniania przez Apex (Apex sharing): kodu, który sam zapisuje rekordy udostępniania. Musimy więc wiedzieć, czym jest udostępnianie przez Apex, gdzie się go używa, jak go używać i tak dalej. To eskalacja: udostępnianie przez Apex to alternatywa (pytanie 4) na sytuację, gdy potrzebne reguły wykraczają poza to, co da się wyrazić udostępnianiem opartym na właścicielu i kryteriach.

Teraz jego słabe strony (pytanie 6). Powiedzmy, że mamy społeczność klientów z 10 albo 20 milionami członków i używamy licencji Customer Community, a nie Customer Community Plus. To użytkownicy o dużym wolumenie (high-volume). Nie mają ról i w ogóle nie korzystają z modelu udostępniania: ich dostęp wynika z zestawów udostępniania i grup udostępniania, dopasowywanych przez ich konto i kontakt. Nie ma dla nich rekordu udostępniania, który Apex mógłby zapisać, więc udostępnianie przez Apex dla nich nie działa. A to pytanie o koszty i licencje (pytanie 9) nas tu doprowadziło: wybór licencji zdecydował, które narzędzia udostępniania w ogóle istnieją.

Tak jak udostępnianie przez Apex było alternatywą dla reguł opartych na właścicielu i kryteriach, możesz trafić na przypadek, w którym potrzebujesz alternatywy dla udostępniania przez Apex. A na tym etapie naprawdę nie ma już opcji konfiguracyjnych dla złożonych reguł udostępniania. Kończy się na tym, że obiekt jest tylko do odczytu, a dostęp kontroluje Apex. Dlatego wszystkie dziewięć pytań zadajesz, zanim wybierzesz, a nie potem.

Nie ucz się platformy na pamięć

To najważniejsze, kiedy uczysz się architektury Salesforce. Nie próbuj zapamiętać Salesforce. Nie da się: platforma jest zbyt duża i zmienia się zbyt szybko. Pracuję z Salesforce od dawna i wciąż się uczę. To normalne.

Chcę dać ci ramę do nauki. Kiedy Salesforce jutro wypuści nową funkcję, nie muszę jej wcześniej znać. Wiem, o co zapytać: co to jest, gdzie pasuje, jak tego używać, czego jeszcze mógłbym użyć, w czym to jest dobre, gdzie ma trudności, jak to wyjaśnić, jak to obsługiwać, ile kosztuje i gdzie są limity? Teraz mogę zacząć to oceniać. To dużo cenniejsze niż zapamiętywanie kolejnej tabeli funkcji.

Poza egzaminem: AI sprawia, że na dziewięć pytań łatwiej odpowiedzieć, ale też łatwiej się pomylić. Trafiasz na technologię, której nie znasz, i możesz poprosić AI, żeby ją wyjaśniła, porównała trzy podejścia, wypisała limity i typowe sposoby awarii albo przedstawiła argumenty przeciwko jej użyciu. To niezwykły asystent badawczy. Ale może się mylić, być nieaktualny albo z pełnym przekonaniem pomylić dwa produkty lub edycje o podobnych nazwach. Wszystko, co wpływa na decyzję, sprawdzaj: idź do źródła i sprawdź aktualną dokumentację, limity i licencje. Ufaj, ale sprawdzaj (moduł 7).

Ucz się pytań, nie tylko odpowiedzi

W tym kursie spotkamy wiele technologii. Nie chodzi o kolekcjonowanie odpowiedzi; chodzi o ćwiczenie pytań. Kiedy mówimy o big objects, danych zewnętrznych, Data 360, wzorcach integracji albo o funkcji AI, którą Salesforce wypuści pół roku po napisaniu tego rozdziału, zadaj te same dziewięć pytań.

Odpowiedzi się zmienią. Pytania są trwałe. Dlatego to jest rama architektoniczna, a nie przewodnik do nauki.

Poznaj swoje narzędzia: w czym są dobre, w czym słabe, czego jeszcze możesz użyć, ile kosztują i gdzie się psują. I wiedz dość, żeby wyjaśnić decyzję ludziom, którzy będą musieli z nią żyć. Tak architekt uczy się technologii.

Co tu decyduje architekt

• Czy narzędzie pasuje do problemu, ocenione wszystkimi dziewięcioma pytaniami, a nie tylko tym, czy da się je skonfigurować.
• Jakie są alternatywy i co koszty, licencje i limity narzędzia oznaczają w twojej skali.
• Kto będzie je utrzymywać i jak, za trzy lata.
• Które fakty o narzędziu trzeba sprawdzić, zanim się na nich oprze.

Do zgłębienia

• About High-Volume Community or Site Users (opens in a new tab), Pomoc Salesforce (po angielsku, sprawdzono 2026-10-09; ponownie sprawdzono 2026-10-12): użytkownicy o dużym wolumenie (licencje External Apps, Customer Community, High Volume Customer Portal i Authenticated Website) nie mają ról; ich dostęp wynika z zestawów udostępniania i grup udostępniania; nie można ich uwzględnić w regułach udostępniania opartych na właścicielu, a rekordów, których są właścicielami, nie można udostępniać ręcznie.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (po angielsku, sprawdzono 2026-10-09; ponownie sprawdzono 2026-10-12): użytkownicy o dużym wolumenie (Customer Community, High Volume Customer Portal, Authenticated Website) nie korzystają z modelu udostępniania, bo ich licencje nie obsługują ról; dostęp działa przez dopasowanie użytkownika do relacji wyszukiwania na koncie i kontakcie, za pomocą zestawów udostępniania lub grup udostępniania. Ta sama strona wymienia, kiedy właściwym narzędziem jest udostępnianie zarządzane przez Apex.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), pytanie w Trailblazer Community, listopad 2024 (po angielsku, sprawdzono 2026-10-09; ponownie sprawdzono 2026-10-12): praktyk zgłasza, że wstawianie rekordów udostępniania dla użytkowników o dużym wolumenie kończyło się błędem. Relacja z praktyki, nie oficjalna dokumentacja. (Internetowa Trailblazer Community przechodzi w tryb tylko do odczytu 30 października 2026; link może się zmienić.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Pomoc Salesforce (po angielsku, sprawdzono 2026-10-09): zestaw udostępniania daje dostęp do rekordów powiązanych z kontem lub kontaktem użytkownika.