Ład danych projektuje się w orgu
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)
Moduł 1 z 6 w rozdziale Jakość danych i ład danych, rozdziale 5 kursu Data Architect. Każdy moduł jest samodzielny. Dalej: Nie wpuszczaj złych danych
Pytanie, na które odpowiada ten moduł: co ład danych znaczy dla architekta i kto co robi?
Gdy ludzie słyszą ład danych (data governance), myślą o spotkaniach: komitetach, politykach, standardach, dokumencie wyjaśniającym, kto ma co robić z danymi. Wszystko to może być częścią programu ładu danych. Jako architekta interesuje mnie inne pytanie: gdzie polityka jest egzekwowana?
Jeśli polityka mówi, że tylko finanse mogą zmieniać pole, co to egzekwuje? Jeśli mówi, że właścicielem prawnego rekordu klienta jest ERP, co powstrzymuje kogoś w Salesforce przed jego zmianą? Jeśli mówi, że ekipy widzą adres odbiorcy tylko dla własnych przystanków i tylko w dniu dostawy, co sprawia, że to naprawdę jest prawdą? Jeśli mówi, żeby przechowywać to siedem lat, co to zarchiwizuje albo usunie po siedmiu latach? Polityka bez punktu egzekwowania to w dużej mierze pobożne życzenie. Ład danych staje się architekturą, gdy te decyzje są wbudowane w system.
Ładu danych nigdy się nie kończy
Dział zatytułowany „Ładu danych nigdy się nie kończy ”Załatwmy to na początku: ładu danych się nie kończy. Widziałem, jak przychodzi falami. Firma poświęca jakości danych prawdziwą uwagę i jest lepiej. Uwaga przenosi się gdzie indziej i jakość spada. Uruchamia się nowa integracja, dział zmienia proces, ktoś importuje plik, firma przejmuje inną, agent zaczyna zapisywać rekordy, a problem znów się zmienia. Celem nie jest mityczny stan, w którym każdy rekord jest na zawsze idealny. Celem jest utrzymanie danych na tyle wiarygodnymi, na ile potrzebuje biznes, i niewpuszczanie najgorszych złych danych. To praca ciągła.
Gdy Salesforce stoi w dużej mierze sam, ład danych oznacza czyszczenie danych w jednym miejscu. Gdy jest jednym węzłem krajobrazu z rozdziału 4, robi się trudniej i bardziej potrzebnie. Teraz klient mieszka w Salesforce, ERP, hurtowni, systemach partnerów, Data 360. Kto jest jego właścicielem? Kto może go zmieniać? Która kopia jest nadrzędna, które atrybuty mogą się przemieszczać, jak długo są przechowywane i kto odpowiada, gdy są złe? To nie są pytania o konfigurację. To pytania o ład danych, które stają się konfiguracją.
Właściciel rekordu to nie właściciel danych
Dział zatytułowany „Właściciel rekordu to nie właściciel danych ”Zacznijmy od słowa właściciel, bo Salesforce je komplikuje. Otwórz konto, a zobaczysz Właściciela: na przykład handlowca. Czy handlowiec jest właścicielem danych klienta? Niekoniecznie. W Salesforce rekord obiektu, który ma właściciela, należy do użytkownika albo kolejki; właściciel ma pełny dostęp i steruje przypisaniem i udostępnianiem przez hierarchię ról i reguły udostępniania (Sharing and Record Access Features (opens in a new tab), po angielsku). To jest własność rekordu: mechanizm platformy.
Właściciel danych (data owner) to coś innego: osoba albo funkcja odpowiedzialna za dane jako zasób biznesowy. Finanse mogą być właścicielem prawnych informacji o klientach, operacje statusu dostaw, HR danych pracowników. Salesforce daje nawet miejsce, żeby to zapisać: pole klasyfikacji Data Owner przy każdym polu (Data Classification Metadata Fields (opens in a new tab), po angielsku).
W Steve Trucking właścicielem konta partnera detalicznego może być dyrektor handlowy, który opiekuje się tym partnerem. Ale tożsamością prawną partnera zarządzają finanse, a źródłem nadrzędnym jest finansowy ERP. Sprzedaż, serwis, operacje i portal partnerów potrzebują konta; nic z tego nie znaczy, że dyrektor handlowy powinien zmieniać tożsamość prawną partnera, gdy finanse ją już ustaliły. Widziałem zespoły, które patrzyły na pole Właściciel i zakładały, że rozwiązały kwestię własności danych. Nie rozwiązały. Przypisanie rekordu to nie odpowiedzialność biznesowa.
Właściciel, steward, opiekun techniczny
Dział zatytułowany „Właściciel, steward, opiekun techniczny ”Trzy role ładu danych, trzy różne zadania.
Właściciel danych ustala politykę. Odpowiada na pytania, co dane znaczą, kto może je tworzyć i zmieniać, jak dokładne muszą być, jak długo są przechowywane, kto może je widzieć, który system jest nadrzędny i co się dzieje, gdy są złe. Architekt nie powinien wymyślać tych odpowiedzi. To jedno z moich najmocniejszych stanowisk: właściciele ustalają politykę; architekci ją egzekwują. Jeśli finanse mówią, że nazwa prawna może się zmieniać tylko przez proces w ERP, gdy klient jest aktywny, to decyzja ładu danych. Sprawienie, żeby była mechanicznie prawdziwa, to moje zadanie.
Data steward (opiekun danych) dba o to, żeby to działało. Steward jest blisko codziennej kondycji danych: obserwuje sygnały jakości, bada duplikaty, rozwiązuje wyjątki, koordynuje poprawki, utrzymuje definicje, wyłapuje proces, który ciągle produkuje złe dane. Do stewarda należą jeszcze dwa zadania. Gdy dwa zespoły nie zgadzają się, co oznacza pole, kto jest jego właścicielem albo kto może je widzieć, steward przekazuje spór właścicielowi i doprowadza decyzję do końca. Steward buduje też kompetencje w zakresie danych (data literacy): pomaga ludziom, którzy wprowadzają dane i z nich korzystają, zrozumieć, co one znaczą i dlaczego istnieją reguły. Steward potrzebuje więcej niż nazwiska na schemacie. Potrzebuje czasu, widoczności, procesu i uprawnień, żeby problemy były naprawiane. Inaczej „data steward” staje się ósmym obowiązkiem kogoś, kto zagląda do tego raz na kwartał.
Opiekun techniczny (custodian) prowadzi system. Administratorzy, zespoły platformowe, zespoły bezpieczeństwa: ci, którzy obsługują technologię przechowującą i przetwarzającą dane. Właściciel mówi, że widzieć je mogą tylko te role; opiekun techniczny obsługuje mechanizmy kontroli, które to zapewniają. Nazwy mają mniejsze znaczenie niż jasność każdej odpowiedzialności, a w małej organizacji jedna osoba może pełnić dwie role.
Jak działa program
Dział zatytułowany „Jak działa program ”Programy ładu danych mają zwykle jeden z trzech kształtów. Scentralizowany: jeden zespół pisze polityki i standardy dla każdej domeny. Jest spójny, ale może stać się wąskim gardłem, daleko od ludzi, którzy wykonują pracę. Sfederowany (zdecentralizowany): każda domena, na przykład finanse, sprzedaż czy operacje, zarządza własnymi danymi w ramach kilku wspólnych reguł. Jest blisko pracy, ale definicje między domenami się rozjeżdżają. Hybrydowy: mały centralny zespół jest właścicielem standardów i wspólnych definicji, a właściciele domen i stewardzi prowadzą własne dane. Większość przedsiębiorstw, które widziałem, ląduje gdzieś w modelu hybrydowym. Dla architekta kształt odpowiada na jedno praktyczne pytanie: kto zatwierdza politykę, zanim ją wyegzekwuję, i gdzie mieszkają wspólne definicje?
Wiedza na egzamin. Znaj trzy sposoby prowadzenia programu ładu danych, scentralizowany, sfederowany (zdecentralizowany) i hybrydowy, oraz to, co każdy z nich oznacza dla tego, kto ustala politykę i gdzie mieszkają wspólne definicje.
Niech RACI zapracuje na swoje miejsce
Dział zatytułowany „Niech RACI zapracuje na swoje miejsce ”RACI (kto jest Responsible, Accountable, Consulted i Informed, czyli wykonuje, odpowiada, jest konsultowany i informowany) pomaga, ale nie jako gigantyczny arkusz zrobiony, bo ład danych „wymaga go”. Chcę, żeby odpowiadał na pytania architektoniczne, zaczynając od trzech z rozdziału 4 (Cztery pytania za kategoriami): gdzie dane są tworzone, gdzie edytowane, a gdzie wskazywane? To często różne systemy. Weźmy produkt: tworzy go ERP, wskazuje Salesforce, pokazuje portal, analizuje hurtownia. Teraz biznes zmienia znaczenie „aktywnego produktu”. Gdzie zaczyna się zmiana, kto ją zatwierdza, jak się rozchodzi i które kopie są tylko do odczytu? Jeśli nie potrafisz odpowiedzieć, nie masz jeszcze ładu danych. Masz kopie. Dobry RACI odsłania właśnie tę niejasność.
Ład danych musi stać się mechaniczny
Dział zatytułowany „Ład danych musi stać się mechaniczny ”Biznes mówi, że tylko finanse mogą zmieniać nazwę prawną klienta. Nie chcę, żeby odpowiedź architektoniczna brzmiała „omówimy to na szkoleniu”. Szkolenie pomaga; to nie jest egzekwowanie. Może to dostęp na poziomie pól, reguła sprawdzania poprawności, pole zapisywane tylko przez integrację albo kontrolowany proces zamiast bezpośredniej edycji. Mechanizm zależy od wymagania, ale musi istnieć:
| Polityka ładu danych | Decyduje właściciel | Możliwy punkt egzekwowania |
|---|---|---|
| ERP jest właścicielem prawnej tożsamości klienta | Finanse | Pola zapisywane tylko przez integrację, uprawnienia, walidacja |
| Dane osobowe widzą tylko osoby, które ich potrzebują | Prywatność, bezpieczeństwo | Udostępnianie, uprawnienia, dostęp do pól |
| Identyfikatory klientów są unikalne | Właściciel biznesowy | Unikalny External ID, reguły duplikatów |
| Zarządzanych rekordów nie tworzy się ręcznie | Właściciel danych | Uprawnienia, automatyzacja, integracja |
| Dane wrażliwe mają ustalony okres retencji | Prywatność, dział prawny | Proces retencji albo usuwania |
| Ważne zmiany muszą dać się udowodnić | Zgodność | Historia pól, ścieżka audytu |
| Źródło danych pozostaje rozpoznawalne | Właściciel danych | Pole źródła, metadane pochodzenia |
Celowo piszę możliwy punkt egzekwowania. To nie jest tabela do wybierania funkcji. To kolejność myślenia: jaka jest polityka, kto jest jej właścicielem i co w architekturze sprawia, że jest prawdą?
Właściciele ustalają politykę; architekci ją egzekwują.
Nie polegaj na dobrym zachowaniu
Dział zatytułowany „Nie polegaj na dobrym zachowaniu ”„Nigdy nie zmieniaj identyfikatora klienta z ERP”. Wszyscy to wiedzą, dopóki ktoś tego nie zrobi: przypadkiem, przez import danych, przez automatyzację, przez integrację, przez agenta. Jeśli zmiana mogłaby zaszkodzić danym przedsiębiorstwa, „proszę, nie rób tego” nie jest mechanizmem kontroli. Zbuduj mechanizm. Ufaj, ale sprawdzaj. Ludzie, integracje, automatyzacja i AI popełniają błędy, więc architektura powinna zakładać, że w końcu coś spróbuje zrobić to, czego zabrania polityka. Co się wtedy stanie?
Ład danych przekracza granice systemów
Dział zatytułowany „Ład danych przekracza granice systemów ”Wróćmy do krajobrazu. ERP jest właścicielem klienta; Salesforce, hurtownia i platforma danych klientów trzymają kopie; partner dostaje część z nich. Do którego systemu stosuje się polityka? Do wszystkich. Salesforce może poprawnie blokować zmianę nazwy prawnej, a integracja pozwala systemowi dalej w łańcuchu ją nadpisać. Salesforce może usunąć dane osobowe, które hurtownia nadal przechowuje. Pole sklasyfikowane w Salesforce jako wrażliwe może trafić gdzie indziej do nieskategoryzowanego pola tekstowego. Ład danych nie może kończyć się na granicy orgu, bo dane się na niej nie kończą. Dlatego rozdział 4 był pierwszy: krajobraz mówi ci, jak daleko musi sięgać ład danych.
Zarządzaj tyle, ile trzeba, a nie wszystkim
Dział zatytułowany „Zarządzaj tyle, ile trzeba, a nie wszystkim ”Przeciwny błąd jest równie realny. Odkrywamy, że ład danych ma znaczenie, więc wszystko blokujemy: nikt nie może tworzyć, każda zmiana wymaga zatwierdzenia. Dane są zarządzane, a nikt nie może wykonywać swojej pracy. Ład danych oznacza odpowiednią kontrolę dla danych: ścisłą dla jednych, lekką dla innych. Niektóre rekordy można tworzyć swobodnie, inne wymagają zatwierdzenia; niektóre pola może edytować niemal każdy, inne tylko integracja. Następny moduł zajmuje się tym praktycznie.
A ponieważ ładu danych nigdy się nie kończy, egzekwowanie potrzebuje informacji zwrotnej. Czy przybywa duplikatów? Czy pola wymagane zapełniają się śmieciami? Czy integracje zawodzą, użytkownicy znajdują obejścia, wyjątków przybywa, stewardzi spędzają cały dzień nad jednym problemem? Te sygnały mówią ci, czy projekt działa, a czasem, że mechanizm kontroli albo polityka wymagają zmiany.
Poza egzaminem: co zmienia AI. Ład danych ma nowego odbiorcę: agenta. Właściciel danych nadal decyduje, czego można używać i w jakim celu; architekt nadal sprawia, że da się to egzekwować. Zmieniają się szybkość i skala. Agent czyta, łączy i wykorzystuje zarządzane dane dużo szybciej niż człowiek, więc polityka, która istnieje tylko w dokumencie, chroni jeszcze mniej.
Co tu decyduje architekt
Dział zatytułowany „Co tu decyduje architekt ”- Kto odpowiada za każdą ważną domenę danych i czym to się różni od własności rekordu.
- Kto jest stewardem danych, a kto obsługuje je jako opiekun techniczny.
- Gdzie w krajobrazie ważne dane są tworzone, edytowane, wskazywane i zarządzane jako dane podstawowe.
- Jaki punkt egzekwowania sprawia, że każda ważna polityka jest mechanicznie prawdziwa.
- Jak architektura pokazuje, czy ład danych działa, czy zaczyna się sypać.
Gdy słyszę wymaganie dotyczące ładu danych, tłumaczę je. „Właścicielem jest ERP”. „Widzieć to mogą tylko te osoby”. „Musimy udowodnić, kto to zmienił”. „Przechowuj to siedem lat”. Za każdym razem: pokaż mi punkt egzekwowania. Architekt nie decyduje o polityce. Projektujemy system, który ją egzekwuje. Tam ład danych przestaje być dokumentem i staje się architekturą.
Do zgłębienia
Dział zatytułowany „Do zgłębienia ”- Pomoc Salesforce, Sharing and Record Access Features (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.
- Pomoc Salesforce, Data Classification Metadata Fields (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.