Dlaczego Chief Data Officer powinien zarządzać danymi jak produktem?
Chief Data Officers (CDO) stają się coraz ważniejszymi postaciami w swoich organizacjach. Ich rola przekracza tylko zapewnienie zgodności z regulacjami – teraz są odpowiedzialni za kluczowe inicjatywy związane z danymi, takie jak przyspieszenie procesu dostarczania wartości z danych czy umożliwienie pracownikom samodzielnego dostępu do danych (demokratyzacja danych). Ważne jest także dbanie o to, aby dane były odpowiednio zarządzane i były wysokiej jakości, by można było wykorzystać je do analiz i sztucznej inteligencji. Niemniej jednak, ze względu na niepewność gospodarczą, narastające regulacje RODO na poziomie globalnym, CDO są zmuszeni szukać nowych sposobów radzenia sobie z tymi wyzwaniami.
Ostatnio Informatica zorganizowała spotkanie z członkami Rady Doradczej Wykonawców CDO (EAB), aby omówić zagadnienia, takie jak produkty danych i generatywna sztuczna inteligencja. Specjalnym gościem był Sanjeev Mohan, Dyrektor w firmie SanjMo Advisory Services oraz były Wiceprezes ds. badań związanych z Big Data i zaawansowaną analizą w Gartnerze. Wspólnie z członkami EAB analizowali, w jaki sposób zarządzanie danymi jako produktem może pomóc CDO w radzeniu sobie z wyzwaniami, przed jakimi stoją. Aby lepiej wyjaśnić, dlaczego to podejście może przynieść korzyści, Sanjeev przyjrzał się najpierw ogólnemu obrazowi danych.
Dążenie do decentralizacji za pomocą Data Mesh
Potrzeba większej elastyczności i samoobsługi w biznesie prowadzi do przyjęcia zdecentralizowanego podejścia do danych, takiego jak Data Mesh. Według Sanjeeva Data Mesh obejmuje cztery zasady:
- własność domeny,
- dane jako produkt,
- samoobsługa infrastruktury danych,
- zdecentralizowane zarządzanie obliczeniowe.
Wprowadzenie Data Mesh niesie ze sobą wiele korzyści. Opiera się na projektowaniu zorientowanym na domenę, co zwiększa poziom odpowiedzialności i pomaga w wypełnianiu luk w umiejętnościach związanych z inżynierią danych. Dodatkowo, przyczynia się do zwiększenia elastyczności i ma potencjał zmniejszenia zbiorów oraz nadmiaru danych. Jednak nie każda organizacja nadaje się do wdrożenia architektury Data Mesh. Przede wszystkim brakuje jasnych wytycznych dotyczących „jak to zrobić”. Ponadto, wiele właścicieli domen może nie być gotowych lub nie posiadać odpowiednich umiejętności do zarządzania infrastrukturą danych. Taka sytuacja może skutkować powstawaniem nowych zbiorów danych. Co więcej, zarządzanie danymi współdzielonymi może stanowić wyzwanie, trudno bowiem efektywnie nimi zarządzać.
8 kluczowych atrybutów produktów danych
Jak wspomniano wcześniej, produkty danych stanowią istotny element implementacji architektury Data Mesh. Choć ściśle związane z Data Mesh produkty danych, według Sanjeeva, przynoszą wartość niezależnie od przyjętego przez organizacje podejścia do zarządzania danymi. Opisuje produkt danych jako kodowanie reguł, kontekst oraz semantykę odnoszącą się zarówno do samych danych, jak i metadanych.
Kontrakt danych służy do zapisania specyfikacji produktu danych, zawierając takie elementy jak dostęp do interfejsu API, jakość, możliwość odnalezienia, dostępność, niezawodność, warunki umów SLA i wiele innych. Kontrakt danych działa jak pośrednik pomiędzy pojedynczym producentem danych a wieloma różnymi konsumentami. W rezultacie prowadzi do wspólnego zrozumienia danych, eliminując potencjalne niejasności i domysły.
Produkty danych, jak mówi Sanjeev, posiadają osiem kluczowych atrybutów, powinny być:
- wartościowe,
- bezpieczne,
- możliwe do odnalezienia,
- adresowalne,
- zrozumiałe,
- godne zaufania,
- naturalnie dostępne,
- współdziałające.
Kilku członków Rady Doradczej Wykonawców (EAB), którzy już podjęli działania w kierunku przyjęcia produktów danych, podzieliło się niektórymi najlepszymi praktykami. Jeden z członków EAB stwierdził, że produkt danych może być tym, czym zechcesz. Każdy rodzaj zasobu danych może być produktem danych, takim jak pulpit nawigacyjny, raport, tabela klientów itp. Kluczem jest zdecydowanie, w jaki sposób podchodzisz do projektowania i korzystania z produktów danych, stosując zasady zarządzania produktami. Innymi słowy, definiujesz, w jaki sposób uzyskasz doświadczenie związane z produktem.
Warto również zaznaczyć, że pojawiło się pojęcie menedżera produktu danych (nie mylić z data steward). Inny uczestnik EAB podzielił się koncepcją struktury organizacyjnej podobnej do zespołów zajmujących się rozwojem produktów, gdzie lider produktu danych nadzoruje wielu menedżerów produktu danych, którzy zarządzają portfolio produktów danych.
Zmiana w myśleniu i podejściu
Realizacja podejścia Data Mesh i wdrożenie produktów danych wymagają rewizji sposobu myślenia. Obecnie wiele organizacji skupia się przede wszystkim na technologii, przyjmując wąskie, od dołu do góry skoncentrowane podejście. Tego rodzaju myślenie, oparte na danych, może prowadzić do powstawania długu technologicznego, wymagając znacznych zasobów związanych z inżynierią danych oraz skutkując opóźnieniami w zapewnieniu wysokiej jakości danych, co często prowadzi do powielania i izolacji danych.
Natomiast nowoczesna architektura produktów danych opiera się na wynikach biznesowych i skupia się na procesach oraz samodzielnej obsłudze. To podejście koncentruje się na wspólnym obszarze metadanych, który ma za zadanie zapewnić dostępność danych, ich zrozumienie i zarządzanie, ochronę prywatności oraz udostępnianie danych.
Sanjeev zauważył, że organizacje, które przyjmują strategię opartą na produktach danych, mogą zaobserwować obniżenie ogólnych kosztów związanych z danymi o około 30%, jak wynika z badań przeprowadzonych przez firmę McKinsey & Co.
Wykorzystanie dużych modeli językowych w środowisku korporacyjnym
W zakończeniu dyskusji grupa skierowała swoją uwagę na temat dużych modeli językowych (LLM) oraz konsekwencji, jakie niesie za sobą generatywna sztuczna inteligencja dla produktów danych. Sanjeev podkreślił, że obecnie LLM-y są wybitnie zdolne w przewidywaniu języka, jednak nie osiągają takiego samego poziomu w zrozumieniu treści. Dzięki treningowi na ogromnych zbiorach publicznych danych, pozwalają firmom na przyjęcie podejścia „gen AI first”.
Niemniej jednak, istnieją pewne ograniczenia związane z LLM-ami. Skupiają się głównie na przetwarzaniu danych nieustrukturyzowanych, pomijając dane ustrukturyzowane, oraz są trenowane w trybie wsadowym, co może wpływać na ich wydajność i wiązać się z wysokimi kosztami. Wymaga to także specjalistycznej inżynierii promptów, aby uzyskać pożądane rezultaty w formułowaniu pytań.
Sanjeev wprowadził również pojęcie prywatnych lub korporacyjnych LLM-ów, jednak członkowie EAB wyrazili obawy dotyczące kwestii prywatności, stwierdzając, że nie chcą umieszczać danych korporacyjnych w LLM-ach. W odpowiedzi zaproponowano podejście hybrydowe, w którym najlepsze aspekty publicznych LLM-ów z bogatszymi metadanymi dziedzinowymi łączą się z prywatnymi, dedykowanymi metadanymi firmy.
Członkowie EAB zgodzili się, że zagadnienia prywatności i ochrony danych są istotnymi wyzwaniami, które są stale obecne w myślach ich organizacji.
Jeśli chcesz dalszej eksploracji tematów, które są ważne dla Głównych Oficerów Danych (CDO), zapraszamy do odwiedzenia strony dla CDO pod adresem: www.informatica.com/cdo.
Źródło: https://www.informatica.com/blogs/why-chief-data-officers-should-manage-data-as-a-product.html