Posts in category: Artykuły

Słowo teorii

Ł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.

Wprowadzenie

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 roku¹, która mówi o 4 zasadach:

1. Upewnij się, że program robi tylko jedną rzecz, i robi to dobrze. […]
2. Oczekuj tego, że wyjście jednego programu staje się wejściem kolejnego, niekoniecznie już znanego. [..]
3. Buduj systemy i testuj je tak szybko jak to możliwe. […]
4. 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ń², 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ść³. 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.”⁴

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’a⁵. 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.

Co powinniśmy wyciągnąć z koncepcji Data Mesh:

• Orientacja Domenowa (Filozofia Unixa, Domain-Driven Design⁶)
• 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, Gartner⁷

Odnośniki

1. https://archive.org/details/bstj57-6-1899/page/n3/mode/2u ↩︎
2. https://roman.pt/posts/accelerate/ ↩︎
3. https://dash.harvard.edu/bitstream/handle/1/34403525/maccormack%2Cbaldwin%2Crusnak_exploring-the-duality.pdf ↩︎
4. https://www.melconway.com/Home/Committees_Paper.html ↩︎
5. https://www.bbc.com/future/article/20191001-dunbars-number-why-we-can-only-maintain-150-relationships ↩︎
6. https://martinfowler.com/bliki/DomainDrivenDesign.html ↩︎
7. https://www.denodo.com/en/document/analyst-report/gartner-hype-cycle-data-management-2023 ↩︎