Ład Danych (Data Governance) oraz Zarządzanie Danymi (Data Management) to koncepty mocno ze sobą powiązane, przez co często używane są zamiennie. W języku polskim jest to jeszcze bardziej mylące, ponieważ można o nich mówić jako o Zarządzaniu – co nie jest aż tak drastycznie nieprawdziwe.
Zacznijmy od książkowych definicji z DMBOK.
“Data Governance to sposób sprawowania zwierzchnictwa oraz kontroli (planowania, implementacji, monitoringu, wykonywania) zarządzania zasobów informacyjnych.”
“Data Management to rozwój, wykonywanie, nadzór planów, polityk, programów i praktyk dostarczających, kontrolujących, chroniących oraz zwiększających wartość zasobów informacyjnych w trakcie trwania ich życia.”
Definicje te zatem można zwizualizować następująco:
Jak to wygląda w praktyce
Zespół Ładu Danych jako scentralizowana jednostka spotyka się raz w tygodniu, aby zrobić przegląd aktualnych postępów związanych z Danymi w organizacji. Przegląd zawiera zagregowane metryki dotyczące zespołów oraz produktów informacyjnych, a także wszelkich inicjatyw z nimi związanych. Jeżeli coś wymaga poprawy, zmiany lub restrukturyzacji to ten zespół powinien jasno zdefiniować swoje rekomendacje oraz przekazać je do zespołów Zarządzania Danymi.
Zespoły Zarządzania Danymi jako zdecentralizowana jednostka spotyka się raz dziennie w celu zrozumienia aktualnych priorytetów, projektów oraz potencjalnych zagrożeń, aby odpowiednio pracować ze swoimi zespołami w celu dostarczenia wartości z danych. Ich praca musi być zgodna z wizją zespołu Ładu Danych, od którego otrzymują rekomendacje.
Podsumujmy
Warto zwrócić uwagę na sposób współpracy: scentralizowany zespół ma lepszy ogląd na całokształt, dlatego też są w stanie wystosować trafne rekomendacje (nie nakazy), których wykonanie leży po stronie wielu mniejszych zespołów Zarządzania Danymi, bądź po prostu samych przedstawicieli domen, którzy dzielą pracę pomiędzy swoje mniejsze zespoły.
Proces ten będzie różny w zależności od wielkości organizacji – mniejsze będą miały mniej poziomów, natomiast większe powinny zadbać o to, aby wysokość hierarchii nie zablokowała transferu wiedzy oraz komunikacji wzwyż i wszerz.
Informacje wykorzystywane są od zarania dziejów, przede wszystkim do upewniania się, że nasze decyzje są trafne, co niezaprzeczalnie zwiększa jakość naszych działań.
Z czasem tworzymy coraz to bardziej złożone byty, struktury, czy organizacje. Proces ten w dużej mierze bazuje na danych oraz ich poprawnym wykorzystaniu. Oznacza to, że ich wartość rośnie z czasem – dziś jest to niezwykle cenny zasób mówiący o tym, czy przedsiębiorstwo jest rentowne. Fakt ten staje się także coraz bardziej widoczny i oczywisty.
Praca z samą informacją, jej zdobywanie i składowanie może nie wydawać się aż tak trudnym zadaniem. Problemem jest jednak jej odpowiednie przygotowanie oraz udostępnianie, gdyż każdy człowiek inaczej rozumie świat, ma inny punkt widzenia, doświadczenia oraz cele i preferencje. Często zdarza się, że mówimy o tej samej rzeczy, zgadzamy się ze sobą, a ostatecznie myślimy o czym innym, przez co podejmowane akcje drastycznie się różnią.
Zbudowanie wspólnego języka oraz modelu świata, w którym współpracujemy jest kluczowym aspektem każdego zespołu. Jest to szczególnie istotne przy pracy z danymi oraz w innowacyjnych środowiskach. Pozwoli to na spójne i świadome podejmowanie decyzji, co znacznie zwiększy ich jakość i zredukuje ilość nieporozumień i przestojów z nimi związanych.
Koncepty do zaaplikowania w świecie Danych
Tworzenie rozwiązań w dużej skali niewątpliwie sprawia, że wszystko jest o wiele trudniejsze, zwłaszcza pod kątem zasad, procesów oraz zarządzania. Mikroserwisy nauczyły nas, że małe i niezależne komponenty komunikujące się ze sobą asynchronicznie poprzez wzorzec X-as-a-Service sprawdza się w dużej skali. Pomysł ten sam w sobie wywodzi się z Filozofii Unixa z 1978 roku1, która mówi o 4 zasadach:
Upewnij się, że program robi tylko jedną rzecz, i robi to dobrze. […]
Oczekuj tego, że wyjście jednego programu staje się wejściem kolejnego, niekoniecznie już znanego. [..]
Buduj systemy i testuj je tak szybko jak to możliwe. […]
Używaj narzędzi prostych w obsłudze, aby wesprzeć innych ich użytkowników. […]
Dla praktyków metodologii DevOps zasady te na pewno są znane – małe iteracje, szybka informacja zwrotna, luźno sprzężona architektura, kultura innowacji.
Zasady DevOps
W 2018 roku wyszła publikacja, która naukowo zbadała i potwierdziła przydatność techniczną i biznesową tych założeń2, dzięki czemu mamy pewność, że tą to koncepty warte wdrożenia.
Ostatecznie powinniśmy być kolejnego konceptu sprzed dekad – Prawa Conway’a. Nie spełnia ono co prawda wymogów bycia pełnoprawnym prawem, choć doczekało się wielu badań potwierdzających jego prawdziwość3. Mówi ono o tym, że komunikacja pomiędzy pracownikami i zespołami znacznie wpływa na architekturę systemów, które zespoły te wytwarzają.
“Każda organizacja, która tworzy systemy (szeroko rozumiane) stworzy system, którego architektura jest kopią struktur komunikacyjnych tej organizacji.”4
Dzięki temu wiemy, że informacja, jak i sposób jej przekazywania znacznie wpływa na jakość oprogramowania. Implikuje to fakt, że kultura jest niezwykle istotna – definiuje jakość organizacji.
Jak widać Prawo Conway’a (1967), Filozofia Unixa (1978) oraz DevOps (2009) dają nam wiele wskazówek dotyczących tego jak efektywnie pracować z, i skalować systemy informacyjne. Skalowanie organizacji może wyglądać bardzo podobnie, zwłaszcza w świecie danych.
Sposoby pracy z Danymi
Dane wnoszą o wiele więcej złożoności, a także potencjalnej wartości, ze względu na fakt, że dodajemy nowe typy systemów i przepływów do naszych architektur. To samo dotyczy AI w ostatnich latach.
Jest to możliwe dzięki odpowiednim metodologiom programistycznym. AI nie może być stabilne i niezawodne, jeśli nie mamy odpowiednich fundamentów danych, które obejmują właściwą kulturę i zarządzanie.
Doświadczenie pokazuje, że świat danych wciąż jest mocno chaotyczny i nieuporządkowany, jednak sytuacja znacznie się poprawia dzięki technologii (m. in. MS Fabric lub Purview, Snowflake, BigQuery lub Redshift) oraz świadomości (m. in. Data Management Body of Knowledge). Jednak nadal brakuje wielu ludzi, kompetencji, budżetu i ustalania odpowiednich priorytetów.
Ostatnie dekady w świecie Danych koncentrowały się na jednym scentralizowanym źródle prawdy, co jest świetnym pomysłem, który pomógł nam osiągnąć dzisiejszy poziom zaawansowania. Jednak w tym przypadku Prawo Conway’a sugeruje, że centralizacja informacji implikuje posiadanie pojedynczego zespołu odpowiedzialnego za nią, co tworzy wąskie gardło zgodnie z zasadami DevOps i zdecydowanie nie jest wspierane jest przez Filozofię Uniksa.
Może to nie być wystarczające, ponieważ nie możemy w nieskończoność skalować pojedynczego zespołu, o czym dobrze mówi Liczba Dunbar’a5. Takie skalowanie zgodnie z Filozofią Unixa oraz DevOps się nie utrzyma. Oprogramowanie poradziło sobie z tym poprzez asynchronizację komunikacji oraz elastyczne skalowanie poprzez Cloud Computing oraz Mikroserwisy.
Jak w takim razie możemy zaaplikować to do naszych zespołów? Rozwiązaniem zdaje się być Data Mesh szerzej opisany w tym artykule.
Filary Data Mesh i relacje między nimi
Zamiast tworzyć fizycznie scentralizowany zespół oraz oprogramowanie (Data Warehouses, Data Lakes, Data LakeHouses) możliwe jest utworzenie spójnego i ujednoliconego widoku na fizycznie rozproszone dane, przy pomocy technik wirtualizacji, oraz rozproszyć właścicielstwo poszczególnych zbiorów danych, zapewniając przy tym spójne procesy komunikacji pomiędzy producentami oraz potencjalnymi konsumentami. Usprawni to komunikację, a co za tym idzie – architektury systemów, kulturę oraz zwiększy ilość innowacji. Wynikiem będzie minimalizacja zależności oraz szybkie testowanie zmian, co jest bezpośrednio promowane przez Filozofię Unixa, Prawo Conway’a oraz kulturę DevOps.
Dane jako pełnoprawne Produkty (zapewnianie odpowiedniej jakości oraz budżetów dla Danych, a także dedykowanych od nich specjalistów)
Samoobsługowa Platforma Danych (ujednolicony wgląd, decentralizacja oraz asnychronizacja prac nad informacjami w celu zapewnienia możliwości innowacji, o czym mówi podejście mikroserwisowe)
Rozproszone zarządzanie zasadami i procesami (dzielenie się wiedzą wewnątrz domeny oraz pomiędzy nimi).
Podsumowanie
W ciągu ostatnich dekad przeprowadzono wiele badań mających na celu usprawnienie pracy z oprogramowaniem. Powstało wiele konceptów i metodologii, które mniej lub bardziej się sprawdzały i są dziś wykorzystywane na co dzień. Teraz potrzebujemy upewnić się, że świat Danych nie pozostaje w tyle. Prawo Conway’a jasno wskazuje co powinniśmy zrobić w związku z powyższymi założeniami. Przede wszystkim należy zadbać o kulturę oraz świadomość w tym zakresie tak, abyśmy sami mogli usprawniać naszą codzienną pracę. Założenie to wsparte jest także przez tzw. Turkusowe Organizacje.
Data Mesh wywodzący się z systemów rozproszonych jest bardzo odważnym konceptem, który ma zastosowanie oraz odpowiednie uzasadnienie. Niestety wiele implementacji pokazało jak trudne jest rzeczywiste wdrożenie. Jest to wciąż koncept eksperymentalny i wymaga wielu lat edukacji, pracy, ciągłego budowania kultury, silnego Data Governance, a także dostosowania samego podejścia pod specyfikę organizacji.
Przebudowa struktur fizycznych oraz komunikacyjnych w dużej organizacji to nietrywialne zajęcie, które pochłania zarówno wiele czasu, jak i budżetu. Świadomość tego, że jest to eksperyment sprawia, że podjęcie tego ryzyka jest bardzo ciężko uzasadnić, a sam sposób wdrożenia musi być bezpośrednio dopasowany pod kulturę i domenę przedsiębiorstwa. Możemy wywnioskować z tego, że podejście Data Mesh wciąż wymaga standaryzacji, dobrych praktyk wielu pomyślnych, jak i niepomyślnych wdrożeń, z których liderzy wyciągną wnioski. Firma Gartner jasno wyraziła swoje stanowisko dotyczące Data Mesh – nieużyteczne przed osiągnięciem dojrzałości, choć dojrzałość nie nastąpi bez wielu prób i dalszych innowacji.
Coroczny Hype Cycle Zarządzania Danymi na rok 2023, Gartner7
Data Mesh to zdecentralizowane podejście do zarządzania danymi w dużej skali opierające się o cztery filary mające za zadanie wytworzenie pewnej kultury i jakości pracy.
Oznacza to, że:
Jest to podejście skierowane nie tylko na technologię, ale przede wszystkim na ludzi.
Jest to podejście pracy zdecentralizowanej, gdzie autonomia jest na dole organizacji.
Jest to podejście stosowane w dużej skali.
Pomysłów na pracę z danymi w organizacji jest wiele, ten jednak proponuje skupienie się na zasobach ludzkich, które, dzięki zaakceptowaniu prawa Conway’a1, mogą być efektywnie wykorzystane bez wiecznej walki z naturą człowieka, jak i przedsiębiorstwa.
Data Mesh rekomenduje iteracyjną ewolucję organizacji w kierunku wyznaczonym przez liderów zarządzania informacją w rozproszonych środowiskach. Transformacja ta opisana została czterema filarami, które są zestawem rekomendacji i próbą utworzenia nowych najlepszych praktyk w świecie danych.
Cztery Filary Data Mesh
Domeny
Organizacje wymagają coraz większej skali oraz dynamiki swojej działalności. Aby to osiągnąć poszczególne departamenty muszą redukować oczekiwanie na inne zespoły oraz decyzje płynące z zewnątrz. Sprawia to, że autonomia jest głównym czynnikiem napędzającym biznes. Okazuje się, że zorientowanie domenowe znacznie wspiera te postulaty.
Podejście domenowe pojawiło się już w 2003 roku w kontekście programistycznym, natomiast w przypadku organizacji, w prostych słowach, oznacza tyle, że należy zapewnić wykonywanie przepływu pracy od początku do końca wewnątrz jednego zespołu (lub grupie zespołów) złożonego ze wszystkich wymaganych na co dzień kompetencji. Pozwala to na dużą autonomię oraz znacząco zmniejsza liczbę nieporozumień, jako że łatwiej się porozumiewać jednym językiem, w jednym kontekście. Jest to również zgodne z Prawem Conway’a2 oraz Liczbą Dunbar’a3. Ostatecznie powinniśmy otrzymać tzw. Agile Release Train4, który jest wirtualną organizacją złożoną z zespołów Agile.
Dane jako Produkt
Od lat podejście projektowe w stylu kaskadowym przekształcane jest w podejście oparte o produkty żyjące zgodnie z metodykami zwinnymi. Dane jednak od zawsze były produktem pobocznym, odkładanym na dysku i czekającym na dalsze procesowanie.
W przypadku Data Mesh chcemy zadbać o jakość, niezawodność oraz transparentność informacji, a do tego potrzebne jest zaaplikowanie podejścia inżynieryjnego do samych danych i tego, co za nimi idzie.
Dziś dane to monetyzowalny produkt o konkretnej wartości, który jest stale udoskonalany przez konkretną domenę oraz posiada całą charakterystykę pełnoprawnego modułu składającego się z kodu, danych oraz wszystkich innych wymaganych artefaktów.
Koncept Data Mesh jest wspierany przez takie pojęcia jak Data Product, Data Ownership czy Data Contract.
Samoobsługowa Scentralizowana Platforma Danych
Dane niosą coraz większą wartość, od prostej analityki i diagnostyki, aż po skomplikowane algorytmy predykcyjne i kognitywne wymagające bardzo wysokiej jakości ogromnych stale przetwarzanych informacji. Organizacja musi mieć zapewnione miejsce, w którym może odnaleźć dane, wstępnie się im przyjrzeć, ustalić z kim o nich rozmawiać oraz na jakich zasadach można z nich korzystać. Z pomocą przychodzi Platforma Danych oraz Katalog Danych.
Platforma Danych pozwala na autonomię osób poszukujących danych. Jest to bardzo duża zmiana kulturowa, ponieważ taka zdolność organizacji zwiększa ilość oraz jakość inicjatyw, promuje przejrzystość prac i zachęca do rozwoju, a nawet zdrowej rywalizacji, w czym pomóc może m.in. Grywalizacja5.
Federacyjne Ustalanie i Zarządzanie Praktykami
Ostatecznym filarem jest zarządzanie praktykami (Governance). Zespół wspierający złożony z najbardziej doświadczonych osób, w tym członków domen, ustala to, w jaki sposób warto pracować oraz jak kontrolować rozwój domen w dobrym kierunku. Jest to ogromne wsparcie, zwłaszcza w wysoce uregulowanych środowiskach, gdzie część zasad zależy od domeny, jednak wiele zależy od całej branży. Spojrzenie z góry nie tylko pomaga znaleźć wąskie gardła oraz problemy, lecz także dobre praktyki, które warto rozdystrybuować w całej organizacji. Wymiana doświadczeń, wspólne spojrzenie na przedsiębiorstwo, oraz aplikowanie coraz to nowszych wymagań i praktyk z zewnątrz to przykłady korzyści wynikające ze współpracy zespołu wspierającego.
Podsumowanie zasad, zależności oraz korzyści płynących z wykorzystania Data Mesh6
Rozpoczęcie Prac
Implementacja tak dużych zmian wymaga przygotowania strategii, planowania oraz nauki na każdym poziomie całego przedsiębiorstwa. Data Mesh stawia przed nami bardzo wymagające założenia, wdrożenie których może się zwyczajnie nie udać, choćby przez sam fakt częstych zmian na stanowiskach decyzyjnych, nie mówiąc o ciągłym rozwoju oraz zmianach kierunku organizacji.
Nie bez powodu Gartner umieścił Data Mesh jako “obsolete before plateau”, które może zostać osiągnięte za kilka lub kilkanaście lat.
Coroczny Hype Cycle Zarządzania Danymi na rok 2023, Gartner7
Bez względu na eksperymentalność tego podejścia wiele organizacji decyduje się na implementację, aby potencjalnie zyskać ogromną przewagę na rynku8.
Rozpoczynając implementację należy zadbać o 4 ważne aspekty:
Wsparcie sponsora C-Level
Ustalenie zespołu odpowiedzialnego za inicjatywę (Data Mesh Council)
Wykonanie warsztatów w celu zrozumienia AS-IS oraz TO-BE
Znalezienie (i/lub wyszkolenie) osób potrafiących i chcących szerzyć dobre praktyki
Wdrażanie Data Mesh nie jest tanie, ani szybkie, dlatego też decyzja ta musi być dobrze uzasadniona i zaplanowana. Bez względu na podejście warto pamiętać, że zasady wymienione w poprzednim rozdziale są uniwersalne i ich implementacja – zarówno pod pełnym szyldem Data Mesh, bądź osobno jako innowacje – dają ogromne korzyści na polu technologicznym oraz kulturowym.