Test Odwracalności

🌐 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ł 3 z 7 w rozdziale Myśleć jak architekt danych, pierwszym rozdziale kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Model danych to szkielet · Dalej: Architektura to sztuka kompromisów

Pytanie, na które odpowiada ten moduł: jak odróżnić decyzję architektoniczną od zwykłej?

Architekci podejmują mnóstwo decyzji.

Ale nie każda decyzja jest decyzją architektoniczną.

To ważne rozróżnienie. Jeśli każdą decyzję potraktujemy jak architekturę, cały czas spędzimy na dyskusjach o rzeczach, które stosunkowo łatwo zmienić. Jeśli nie rozpoznamy decyzji, które naprawdę są architektoniczne, możemy dziś w pięć minut podjąć decyzję, której odkręcanie zajmie pięć lat.

Jak więc poznać różnicę?

Lubię zadawać proste pytanie:

Jak trudno będzie później odwrócić tę decyzję?

Nazywam to Testem Odwracalności.

Im trudniej coś odwrócić i im więcej innych rzeczy będzie od tego zależeć, tym więcej uwagi architektonicznej to coś wymaga.

Niektóre decyzje tanio się zmienia

Zacznijmy od czegoś prostego.

Nazywamy pole Kategoria klienta. Pół roku później biznes stwierdza, że wszyscy tak naprawdę mówią na to Segment klienta. Zmieniamy etykietę. Może trzeba zaktualizować trochę dokumentacji i przeszkolić użytkowników, ale to nie jest wielkie wydarzenie architektoniczne. Z pierwotną nazwą API trzeba będzie jednak żyć, bo jej zmiana ma dużo poważniejsze konsekwencje. Może to więc oznaczać tylko zmianę etykiety i zamieszanie, które może z nią przyjść.

Podjęliśmy decyzję. Zmieniliśmy zdanie. Poszliśmy dalej.

Teraz porównaj to z inną decyzją.

Tworzymy identyfikator klientów. Decydujemy, co oznacza, jaki ma format i który system go tworzy. Potem go publikujemy.

Używa go Salesforce. Używa go hurtownia danych. Używa go platforma integracyjna. Używa go portal klienta. Pięć innych aplikacji zaczyna go przechowywać. Korzystają z niego raporty i potoki danych. Może w końcu zobaczą go klienci.

Trzy lata później ktoś mówi:

Chyba nie powinniśmy byli projektować identyfikatora w ten sposób.

To zupełnie inna rozmowa.

Różnica nie polega na tym, że jedna decyzja jest bardziej techniczna od drugiej.

Różnicą jest odwracalność.

Oto jak to może się stać. Powiedzmy, że firma buduje klucze z fragmentu nazwy klienta i numeru. Działa to latami, bo nikt nigdy nie musiał zmieniać nazwy. Potem, po roku albo dłużej, nazwa jednak się zmienia i nagle klucze nie pasują do wzorca, którego oczekuje reszta danych. To jeden z powodów, dla których klucze nie powinny nieść żadnego znaczenia.

Architektura tworzy grawitację

Wokół decyzji architektonicznej zwykle gromadzą się inne rzeczy. Myślę o tym jak o grawitacji.

Wybierz model obiektów, a wokół niego powstanie automatyzacja.

Wybierz klucz, a inne systemy zaczną go przechowywać.

Wybierz miejsce dla danych podstawowych, a integracje zaczną płynąć do niego i od niego.

Wybierz model udostępniania, a procesy biznesowe zaczną zależeć od tego, kto co widzi.

Wybierz wzorzec integracji, a systemy zaczną zależeć od jego czasu działania i zachowania.

Im dłużej te decyzje istnieją, tym większą mają grawitację. W końcu zmiana pierwotnej decyzji oznacza zmianę wszystkiego, co się wokół niej nagromadziło.

AI też czuje tę grawitację. Narzędzie AI pracuje na tym, co już jest w systemie: kiedy kluczowy element projektu już tam jest, każda kolejna interakcja z AI traktuje go jak fakt i dalej na nim buduje, i buduje, i buduje. Decyzja odbija się echem w wielu kolejnych decyzjach, a żaden człowiek nigdy nie wraca, żeby przemyśleć tę pierwotną. Każde kolejne generowanie dokłada grawitacji.

Dlatego to, że model danych jest „szkieletem”, ma znaczenie. Nie jesteśmy ostrożni dlatego, że zmiana jest zła. Jesteśmy ostrożni, bo zależności sprawiają, że zmiana jest droga.

Zadaj dwa pytania

Kiedy patrzę na decyzję projektową, zadaję dwa pytania:

Jak trudno to odwrócić?

Ile będzie od tego zależeć?

Są powiązane, ale nie identyczne. Coś może być technicznie łatwe do zmiany, a mieć setki odbiorców. Kiedyś dla jasności zmieniano etykiety obiektów standardowych, na przykład konto na „Klient”. Łatwe do zrobienia. Potem inny system chciał używać kont dla partnerów i nie mógł. Coś innego może mieć tylko kilku odbiorców, a jego zmiana wymaga ogromnej migracji, jak nazwa API obiektu, do której odwołuje się wiele miejsc wewnątrz systemu. Nikt z zewnątrz jej nie widzi, ale zła nazwa ciągle myli zespół. Jedno i drugie zasługuje na uwagę.

Pomyśl o kilku typowych decyzjach dotyczących danych:

• Który obiekt Salesforce odwzorowuje to pojęcie biznesowe?
• Co jest unikalnym identyfikatorem?
• Który system jest system of record?
• Czy te dane są kopiowane do Salesforce, czy dostępne gdzie indziej?
• Czy to jeden obiekt, czy kilka powiązanych obiektów?
• Kto jest właścicielem danych i jak długo je przechowujemy?
• Jakie są nasze domyślne granice dostępu?
• Jak te dane przemieszczają się między systemami?

To coś zupełnie innego niż decyzja, gdzie pole pojawi się na stronie Lightning. Projekt strony też ma znaczenie. Koszt pomyłki jest inny.

Click to enlarge

Pomyśl o zasięgu rażenia

Inny sposób myślenia o odwracalności to zasięg rażenia: jeśli zmienię tę decyzję, co jeszcze się poruszy?

Załóżmy, że coś, co zamodelowaliśmy jako pole, naprawdę musi stać się obiektem podrzędnym. To nie jest tylko zmiana schematu. Co stanie się z istniejącymi danymi? Z raportami, integracjami, które oczekują tego pola, z Apex i Flow, które się do niego odwołują, z bezpieczeństwem, z analizami, z agentem AI, którego działania zależą od pierwotnej struktury?

Im większy zasięg, tym staranniej powinniśmy podjąć pierwotną decyzję.

Dlatego też architekci muszą patrzeć poza własną część systemu. Z wnętrza Salesforce zmiana może wyglądać na łatwą. Z perspektywy przedsiębiorstwa może dotyczyć dwunastu innych systemów.

Decyzje przedsiębiorstwa i decyzje w Salesforce

Architekt danych myśli na dwóch poziomach.

Wewnątrz Salesforce decydujemy o obiektach, relacjach, kluczach, wolumenie, dostępie, automatyzacji i o tym, jak dane zachowują się na platformie.

W całym przedsiębiorstwie zadajemy szersze pytania. Gdzie naprawdę mieszka klient? Kto jest właścicielem produktu? Który system tworzy zamówienie? Jaki jest nasz nadrzędny identyfikator? Które informacje są kopiowane między systemami, a które zostają tam, gdzie są?

Oba poziomy muszą się łączyć. Widziałem wdrożenia Salesforce, w których wewnętrzny model sam w sobie miał doskonały sens, ale nie pasował do przedsiębiorstwa wokół niego. To nie wystarczy. Struktury Salesforce muszą być odwzorowane na poziomie przedsiębiorstwa, a decyzje przedsiębiorstwa muszą wracać do Salesforce.

Architektura to ruch dwukierunkowy.

Click to enlarge

Zwolnij przy drogich decyzjach

Jedno z zagrożeń w technologii polega na tym, że decyzje najłatwiejsze do wdrożenia mogą wyglądać na najłatwiejsze do podjęcia. To nie to samo.

Utworzenie kolejnego obiektu niestandardowego jest łatwe. Utworzenie kolejnego pola jest łatwe. Podłączenie kolejnego API jest coraz łatwiejsze, a AI ułatwia to wszystko jeszcze bardziej.

Ale łatwość wdrożenia nie mówi nam prawie nic o koszcie decyzji architektonicznej.

Przed decyzją trudną do odwrócenia zwolnij na tyle, żeby zapytać: jaki problem naprawdę rozwiązujemy? Jakie alternatywy rozważyliśmy? Co zakładamy? Co się stanie, gdy wolumen urośnie i gdy biznes się zmieni? Co jeszcze będzie od tego zależeć? Co się stanie, jeśli się mylimy?

Nie potrzebujemy pół roku przeglądów za każdym razem, gdy tworzymy obiekt. Potrzebujemy namysłu proporcjonalnego do kosztu pomyłki. Jeśli to obiekt dla jednego działu albo podsystemu, możesz działać szybciej. Jeśli to dane referencyjne, kluczowy obiekt klienta albo coś używanego w wielu systemach, poświęć czas, żeby to przemyśleć.

Zapisz, dlaczego

Z ważnymi decyzjami jest jeszcze jeden problem: ludzie zapominają, dlaczego je podjęto.

Ktoś patrzy na architekturę trzy lata później i pyta: „Dlaczego ktokolwiek zaprojektowałby to w ten sposób?”. Czasem odpowiedź brzmi: bo to był zły projekt. Zdarza się. Ale czasem był bardzo dobry powód: ograniczenie platformy, które już nie istnieje, wymóg regulacyjny, inny system, który nie obsługiwał preferowanego podejścia, kompromis świadomie przyjęty, żeby zdążyć z terminem.

Jeśli zapisujemy tylko, co zdecydowaliśmy, a nie dlaczego, następny architekt nie ma jak się tego dowiedzieć.

Ważne decyzje zapisuj. Nie musi to być 50-stronicowy dokument. Użyteczny rejestr decyzji może być bardzo mały:

Kontekst: jaki problem rozwiązujemy?

Opcje: jakie realistyczne alternatywy rozważyliśmy?

Decyzja: co wybraliśmy?

Konsekwencje: co zyskujemy, a z czego rezygnujemy?

Właściciel: kto odpowiada za tę decyzję?

Przegląd: jaki powód albo jaka data powinny skłonić nas do powrotu do niej?

Wartością nie jest dokument. Wartością jest zachowanie rozumowania.

A gdy decyzja się zmienia, nie wymazuj pierwotnej. Zastąp ją nową. Decyzja, która była słuszna w 2027 roku, może nie być słuszna w 2030, bo zmieniają się wolumeny, biznes, Salesforce i nasze zrozumienie. Chcę zachować historię: taki był kontekst, taka była decyzja i dlaczego, oto co się zmieniło i oto co decydujemy teraz. To dużo cenniejsze niż udawanie, że zawsze znaliśmy odpowiedź.

Click to enlarge

Poza egzaminem: AI skraca czas od decyzji do zależności. Narzędzie AI może w kilka sekund zaproponować model danych, a potem utworzyć na nim obiekty, automatyzację, kod integracji i interfejs użytkownika. Kiedyś wątpliwa decyzja potrzebowała miesięcy pracy, zanim wiele od niej zależało; teraz zależności pojawiają się niemal od razu. Przeglądaj więc decyzje pod wynikiem, a nie tylko sam wynik. AI może pomóc: może wypisać opcje, podważyć założenia i przygotować szkic rejestru decyzji. Ale decyduje nadal architekt, a im trudniej odwrócić decyzję, tym bardziej liczy się ludzki osąd.

Wiedz, które decyzje się liczą

Jedna z umiejętności, które chcę ci pomóc wyrobić, to wiedza, na co poświęcić uwagę.

Nie zamieniaj każdego wyboru konfiguracyjnego w szczyt architektoniczny.

Ale nie podejmuj od niechcenia decyzji, z którą organizacja będzie żyć przez następną dekadę.

Zapytaj:

Jak trudno będzie to odwrócić?

Ile będzie od tego zależeć?

Jeśli odpowiedzi brzmią bardzo trudno i dużo, to prawdopodobnie masz przed sobą decyzję architektoniczną.

Click to enlarge

Zwolnij. Zrozum wymaganie. Zbadaj alternatywy. Pokaż kompromisy. Podejmij decyzję. I zapisz, dlaczego.

Celem architektury nie jest podejmowanie decyzji, których nigdy nie da się zmienić.

Celem jest rozpoznanie decyzji, przy których zmiana zdania będzie kosztowna.

Co tu decyduje architekt

• Które decyzje są architektoniczne: trudne do odwrócenia i z dużą liczbą zależności.
• Ile uwagi dostaje każda decyzja, proporcjonalnie do kosztu pomyłki.
• Które decyzje są zapisywane, razem z kontekstem, opcjami, konsekwencjami, właścicielem i momentem przeglądu.
• Jak decyzje w Salesforce zgrywają się z decyzjami przedsiębiorstwa.

Do zgłębienia

• Object Relationships Overview (opens in a new tab), Pomoc Salesforce (po angielsku, sprawdzono 2026-10-09; ponownie sprawdzono 2026-10-12): w relacji master-detail dostęp i własność rekordu szczegółowego wynikają z rekordu nadrzędnego, a usunięcie rekordu nadrzędnego usuwa jego rekordy szczegółowe.
• Considerations for Object Relationships (opens in a new tab), Pomoc Salesforce (po angielsku, sprawdzono 2026-10-09; ponownie sprawdzono 2026-10-12): lookup da się przekształcić w master-detail tylko wtedy, gdy każdy rekord ma w nim wartość; przekształcenie zmienia model udostępniania (na Controlled by Parent, czyli kontrolowany przez rekord nadrzędny), a typ relacji decyduje o tym, które standardowe typy raportów są dostępne.
• Roll-Up Summary Field (opens in a new tab), Pomoc Salesforce (po angielsku, sprawdzono 2026-10-09; ponownie sprawdzono 2026-10-12): pola podsumowania zbiorczego istnieją tylko w relacjach master-detail i trzeba je usunąć, zanim master-detail będzie mógł stać się lookupem.