Systemy danych zmierzają w kierunku produkcji

W ciągu ostatnich dziesięciu lat nastąpił niemal całkowity obrót narzędziami dostępnymi dla profesjonalistów zajmujących się danymi. Patrząc na dzisiejszy Modern Data Stack, większość narzędzi (dbt, Looker, Snowflake, Fivetran, Hightouch, Census) nie była dostępna komercyjnie w 2012 roku. Całe kategorie (ELT, Reverse ETL, hurtownie w chmurze) i frameworki (aktywacja danych, siatki danych , struktury danych, kontrakty danych). (Lub w niektórych przypadkach istniejące od dziesięcioleci praktyki SWE zostały na nowo odkryte przez zespoły ds. danych). Liczba obserwujących na Twitterze + Substack, projekty open source, kariery i firmy rosły i spadały. Możliwości jest mnóstwo.

Możliwości i powierzchnia wpływu specjalisty ds. danych na kierunek firmy są znacznie większe niż dziesięć lat temu. Niestety, powierzchnia tego, co może pójść nie tak, rośnie równie szybko. Wyzwania obejmują zarówno niskopoziomowe techniczne umowy SLA, jak i systemy wysokiego poziomu, kulturę, standardy i projekty organizacyjne. Nowe narzędzia są niezwykle wydajne. Firmy mogą zarówno budować, jak i niszczyć systemy danych z większą szybkością niż kiedykolwiek wcześniej.

W ciągu ostatnich pięciu lat zaobserwowałem trzy trendy dotyczące systemów danych, zarówno w pionach technicznych w zespołach danych, jak iw pionach biznesowych wspieranych przez dane. Spróbuję opisać te trendy za pomocą przykładów, które dotyczą wielu firm, i mam nadzieję, że opiszę możliwości, problemy i rozwiązania w sposób, który można uogólnić na Twój zespół. Trendy, możliwości, problemy i rozwiązania:

Systemy dążą do produkcji

• Podsumowanie : wartościowa praca z danymi i dane wyjściowe są ostatecznie zużywane w przypadkach użycia, które są coraz ważniejsze/stopień produkcyjny.
• Szansa : dane wyjściowe zespołu danych można rozłożyć na znacznie większej i bardziej wpływowej powierzchni.
• Problem : ponieważ dane wyjściowe są wykorzystywane przez ważniejsze przypadki użycia, nie ma odpowiedniego „utwardzenia” przepływów pracy, które początkowo zostały skonfigurowane w bardzo lekki sposób.
• Rozwiązanie : Utwórz ścieżkę promowania lekkich przepływów do „produkcji”, świętuj czas spędzony na hartowaniu systemów, gdy zbliżają się one do klasy produkcyjnej.

• Podsumowanie : dane wyjściowe przeznaczone początkowo do określonego celu w coraz większym stopniu i nieświadomie znajdują zastosowanie w wielu zespołach i przypadkach użycia.
• Szansa: spostrzeżenia zaprojektowane dla konkretnego przypadku użycia mogą pomóc w podejmowaniu lepszych decyzji / osiąganiu lepszych wyników w większej liczbie zespołów.
• Problem : żadne dwa zespoły nie mają dokładnie takich samych specyfikacji, ulepszenia dla jednego przypadku użycia nie są wykorzystywane gdzie indziej.
• Rozwiązanie : stwórz zobowiązania konsumenta/producenta + wgląd w zależności, scentralizuj logikę biznesową.

• Podsumowanie : Dane mogą być przekształcane na wielu etapach ich podróży, logika biznesowa żyje w różnych narzędziach.
• Możliwości : nowoczesne narzędzia danych umożliwiają interesariuszom dostęp do danych i przeprowadzanie transformacji ostatniej mili, aby działać szybciej i odblokować się.
• Problem : logika biznesowa w całym stosie uniemożliwia odtwarzalność, transformacje ostatniej mili nie przynoszą korzyści innym odbiorcom danych.
• Rozwiązanie : Zmniejsz obszary, w których można wstrzyknąć logikę biznesową, stwórz zasady „time to live” dla transformacji ostatniej mili, zbuduj kulturę standaryzacji + celebrowania dostępu do wielofunkcyjnych baz kodu.

Lato 2019 . Powstanie kolczastego seltzera jest nie do powstrzymania, ale wciąż jest kilku nieświadomych właścicieli sklepów monopolowych. Jesteś inżynierem analitykiem na rynku alkoholi B2C. Twoi menedżerowie konta (eksperci od spożywania alkoholu) WIEDZĄ, że Pazury znikną z półek, jeśli tylko będziesz mógł je dostać w sklepach. Jest to nieuchwytna rynkowa poprawa pareto typu „wygrana/wygrana/wygrana”, gdzie lepsze zapasy przynoszą korzyści klientowi, sprzedawcy detalicznemu i firmie. Otrzymałeś zadanie znalezienia najlepiej sprzedających się produktów, których sklep monopolowy w Twojej sieci nie oferuje.

1. Zastosowanie wewnętrzne (narzędzie BI / Looker)

Początkowe zapytanie jest łatwe do napisania. Dostępna jest tabela sklepów (z market_id, najlepiej sprzedającymi się jednostkami SKU według rynków i codziennym plikiem danych o asortymencie dla każdego sklepu). Każdy sklep ma dzienny kanał zapasów. Coś takiego daje najlepiej sprzedające się produkty, których nie ma żaden sklep:

select
  s.store_id,
  skus.sku_id,
  skus.market_rank
from dim_stores as s
left join tbl_top_selling_market_skus as skus
  on s.market_id = skus.market_id
left outer join dim_store_inventory as inv
  on s.store_id = inv.store_id
  and inv.sku_id = skus.sku_id
  and inv.remaining_qty > 0
where inv.sku_id is null
order by store_id, skus.market_rank desc
;

…początkowy menedżer konta przekazuje informacje zwrotne na pulpicie nawigacyjnym w trakcie całego procesu.

Uwaga: Narzędzie BI to infrastruktura zespołu danych. Żadne spostrzeżenia / przypadki użycia / produkty nie opuściły domeny zespołu danych. Błąd ma niewielkie konsekwencje, informacja zwrotna jest prawdopodobna + natychmiastowa.

2. Użytek wewnętrzny (Narzędzia wewnętrzne / Salesforce)

Jednak zespół sprzedaży / sukcesu klienta / zarządzania kontem nie spędza całego dnia w Lookerze — spędza cały dzień w Salesforce. Posiadanie dwóch otwartych przeglądarek jest uciążliwe. Jest to podręcznikowy przypadek użycia odwróconego ETL. Umieść dane tam, gdzie będą używane . To było trudne lata temu, teraz jest trywialne — podpisz umowę z dostawcą odwrotnego ETL, przenieś swoje punkty danych z punktu A do punktu B w niecały dzień.

Najlepiej sprzedające się produkty , których nie ma w sklepie , znajdują się teraz w Salesforce. Zespół ds. danych dodał kontekst dla innego zespołu w sposób bezproblemowy. Na tym właśnie polega aktywacja danych — umożliwienie innym zespołom lepszego wykonywania pracy przy użyciu narzędzi, które znają. Więcej menedżerów kont sprawdza więcej brakujących pozycji w magazynie, dzwoni do większej liczby sklepów, więcej najlepszych SKU trafia do sklepów monopolowych, następuje większa sprzedaż. Wszyscy wygrywają.

…jeden z menedżerów konta zauważa, że ​​sklep z piwem i winem ma na swojej liście najlepiej sprzedających się artykułów alkoholowych. AM wykorzystuje kontekst biznesowy i pomija polecanie produktów, o których wie, że sklep nie może ich legalnie przewozić. Dodano dodatkową logikę biznesową za pośrednictwem warstwy podejmowania decyzji przez człowieka.

Uwaga: Salesforce NIE jest infrastrukturą zespołu danych. Wnioski i przypadki użycia opuściły domenę zespołu danych, ale nie firmy. Nic nie jest skierowane do klienta. Błąd ma niewielkie konsekwencje, ale informacja zwrotna nie jest gwarantowana. Dodano dodatkową logikę (poprzez ludzką ocenę).

3. Zastosowanie zewnętrzne (Marketing Automation)

Wdrożenie Salesforce jest pomocne, ale nadal ma charakter ręczny. Menedżerowie kont i właściciele sklepów monopolowych spędzają zbyt dużo czasu przy telefonie. Większość sklepów monopolowych składa zamówienia inwentaryzacyjne raz w tygodniu. AM werbuje pomoc z danych i operacji marketingowych, aby usprawnić komunikację za pośrednictwem automatycznych wiadomości e-mail w rytmie tygodniowym.

Potrzebnych jest jeszcze kilka kolumn, a następnie surowa tabela jest odwrócona ETL do Hubspot / Iterable / Braze. Pracownik CRM wprowadza ostatnie szlify w kampanię e-mailową, a kampania e-mailowa zatytułowana „Najważniejsze przedmioty, których nie nosisz” zostaje uruchomiona.

…współpracownik CRM odpowiedzialny za wiadomości e-mail zauważa, że ​​niektóre z najlepiej sprzedających się produktów (według liczby) to nisze alkoholowe. To nie pasuje do wizji marki firmy / przypadku użycia pożądanego przez klienta. Większość systemów pocztowych pozwala na dodatkową warstwę logiki — współpracownik CRM wykorzystuje swoją ocenę, aby odfiltrować wszelkie elementy o objętości 50 ml lub mniejszej.

Uwaga: Wnioski i przypadki użycia opuściły domenę zespołu danych i firmy. Dane wyjściowe zespołu danych są teraz skierowane do klienta. Błąd ma większe konsekwencje, jest mniejsze prawdopodobieństwo, że informacja zwrotna zostanie prawidłowo dostarczona do właściwego interesariusza. Dodano dodatkową logikę biznesową (poprzez transformację ostatniej mili w warstwie CRM).

4. Zastosowanie zewnętrzne (aplikacja produkcyjna)

Zespół ds. danych otrzymuje informacje od zespołu AM i CRM — niektóre sklepy monopolowe są dość staroświeckie i nie sprawdzają poczty e-mail. Inne sklepy monopolowe to nowa szkoła i nie chcą czekać całego tygodnia na wiadomość e-mail z informacjami o trendach na ich rynku. Grupa postanawia włączyć zespół ds. aplikacji dla handlu detalicznego, aby umieścić „Najważniejsze produkty, których nie nosisz” w aplikacji produkcyjnej, na której działają wszyscy sprzedawcy detaliczni. Zespół ds. danych przenosi dane wyjściowe do zasobnika AWS S3, gdzie są one odbierane przez inżynierię produkcji. Pracownicy sklepów monopolowych mogą teraz przeglądać tę listę codziennie, bez konieczności korzystania z pomocy menedżera konta lub tarć e-mailowych. White Claw i Whispering Angel trafiają do każdego sklepu w Ameryce.

…jeden sprzedawca złożył skargę do Retailer CX — celowo zaprzestał sprzedaży wódki Smirnoff Peppermint po wakacjach. Może to być dosłownie najlepiej sprzedający się przedmiot L90, ale jest wyjątkowo sezonowy i nie chcą go widzieć na swojej zalecanej liście. Ta informacja zwrotna trafia do zespołu inżynierów prod, który wprowadza poprawkę logiczną w warstwie aplikacji, aby identyfikować i usuwać przeszłe elementy sezonowe.

Uwaga: Wnioski i przypadki użycia opuściły domenę zespołu danych i firmy. Dane wyjściowe zespołu danych są skierowane do klienta. Błąd ma większe konsekwencje, istnieje mniejsze prawdopodobieństwo, że informacja zwrotna trafi do właściwego interesariusza. Dodano dodatkową logikę (poprzez logikę biznesową w warstwie aplikacji produkcyjnej).

Ostatnia hipoteza: zespół inżynierów odpowiedzialny za wykorzystywanie plików danych o asortymencie (inny niż zespół odpowiedzialny za aplikację sprzedawcy) przenosi się do nowego schematu asortymentu. Nie są świadomi ani jednego etapu projektu „Najważniejsze przedmioty, których nie nosisz”, zależności, które zespół ds. danych zbudował po cichu na podstawie ich pracy, ani zależności, które inni zbudowali na podstawie pracy zespołu ds. danych. Usuwają początkową tabelę. NULLs przepływa do Looker, Salesforce, Hubspot i produkcyjnej aplikacji detalicznej. Zespół ds. danych zepsuł prod.

Podsumujmy, co się stało, zarówno dobre, jak i złe:

Z perspektywy profesjonalisty danych, który rozpoczął swoją karierę przed „aktywacją danych”, wszystko, co się właśnie wydarzyło (poza zakończeniem), jest niesamowite! To, co zaczęło się jako kokpit Lookera, szybko przekształciło się w aplikację produkcyjną, która na każdym kroku demonstrowała wartość biznesową. Żadne zasoby SWE nie były potrzebne do samego końca – kiedy sugerowany produkt został już zweryfikowany przez użytkowników.

Wpływ i trajektoria kariery specjalisty ds. danych są ograniczone przez obszar, na który może wpływać. Analityk Business Intelligence z 2012 roku został ograniczony do prezentacji wewnętrznych Tableau +. Dzisiejszy specjalista ds. danych MOŻE umieszczać wiersze w Salesforce, uruchamiać e-maile marketingowe i tworzyć produkty z danymi do użytku w usługach i aplikacjach produkcyjnych. To jest niesamowita wiadomość!

Z drugiej strony: specjalista ds. danych dziesięć lat temu był przyzwyczajony do komunikatów „Hej, dane wyglądają na nieprawdziwe”. Najgorszym scenariuszem było umieszczenie niewłaściwych wskaźników w talii planszy. Dziś zespół ds. danych może obudzić się, słysząc powiadomienia Pagerduty, że zepsuły Salesforce, Hubspot i aplikację produkcyjną, jeśli Pagerduty jest w ogóle skonfigurowane . Aktywacja danych podniosła stawkę tego, co zespół danych może złamać.

W tym hipotetycznym przypadku sklepy i kierownicy kont będą denerwowani przez dzień lub dwa, dopóki błąd nie zostanie naprawiony. Biorąc wszystko pod uwagę — ten błąd jest stosunkowo niedrogi.

Co nie znaczy, że nie może być kosztowne! Wyobraź sobie dane wyjściowe analizy danych, które przewidują odejście klientów, a kod promocyjny o wartości 5 USD jest wysyłany, gdy to prawdopodobieństwo przekroczy określony próg. Teraz wyobraź sobie, że model jest niewłaściwie przeszkolony lub ponownie skalibrowany, lub naprawdę cokolwiek. Te same potoki aktywacji danych mogą zostać użyte do nieumyślnego wysłania kodów promocyjnych o wartości milionów dolarów.

Nowoczesny stos danych sprawia, że ​​produkcja danych wyjściowych jest niezwykle łatwa — niezależnie od tego, czy powinny one zostać wyprodukowane, czy też zespół, który zbudował dane wejściowe, wie, w jaki sposób dane wyjściowe są wykorzystywane. Te narzędzia nie wymagają zaostrzenia początkowego zapytania ani potoku, ponieważ są podnoszone do ważniejszych przypadków użycia. Nie wymagają zgody ani widoczności tych, którzy zbudowali początkowy wynik.

Jeśli pamiętasz dodatkową logikę biznesową:

• Menedżer konta wykorzystał swój osąd i pominął rekomendowanie jednostek SKU alkoholi sklepom z piwem/winem
• Współpracownik CRM usunął jednostki SKU <= 50 ml ze względu na kwestie związane z marką
• Zespół ds. aplikacji sprzedawców detalicznych usunął wysoce sezonowe kody SKU ze względu na opinie klientów

Co zatem możemy zrobić, aby rozwiązać te problemy?

Systemy dążą do produkcji

Historie grozy, uogólnione problemy i rozwiązania techniczne dla systemów produkcyjnych zostały elokwentnie opisane na twitterze danych i substacku. Rozwiązania są w dużej mierze najlepszymi praktykami, które SWE znają od dziesięcioleci (lub, jak powiedział Zach Kanter w inny sposób , inżynieria danych status quo to po prostu inżynieria oprogramowania bez najlepszych praktyk ). Kilka elementów/zasad, które najlepiej utkwiły mi w zespołach danych:

Zespoły danych nie kontrolują swoich danych wejściowych (h/t Nick Schrock )

Dane wyjściowe są podstawą wielu decyzji w organizacjach, niezależnie od tego, czy odpowiedzialny jest za to człowiek, czy algorytm. Jednak zespoły danych nie kontrolują swoich danych wejściowych tak, jak robią to inżynierowie oprogramowania. Zespoły ds. danych muszą przyjąć defensywną strategię w swoich obliczeniach, inwestując w zapewnienie jakości; dla problemów z przeszłości, jak również dla problemów, które jeszcze nie wystąpiły. Badanie to powinno obejmować:

• Ważność pojedynczych wierszy ( intgdy oczekujesz int, <50 gdy oczekujesz <50)
• Ważność wierszy zagregowanych (założenia dotyczące szczegółowości, kontekst biznesowy wokół liczby wierszy, liczba wierszy w stosunku do wczoraj, rozkłady agregacji, takie jak sumy, średnie, p90, mediany)
• Istnienie / nieaktualność danych (ostatnia aktualizacja tabel)

Koszt błędu jest wykładniczo wyższy w systemie produkcyjnym niż w przypadku inscenizacji. Twórz potoki testowania danych oraz wzorce programowania i wdrażania, które wykrywają błędy i testują założenia tak wcześnie, jak to możliwe.

Są to rozwiązania, które mogą zostać zaimplementowane przez zespoły danych, które dobiorą odpowiednie narzędzia (lubimy Wielkie nadzieje ) i włożą w to wysiłek. To 20% problemu. Pozostałe 80% wyzwań organizacyjnych i komunikacyjnych jest przyczyną awarii systemów. Oto rozwiązania dla całej firmy:

Twórz wyciągi danych klasy produkcyjnej

Lub celowo twórz dane . Firmy, które uważają, że nauka o danych jest potężna, powinny również wierzyć w celowe tworzenie danych produkcyjnych w celu wspierania przypadków użycia uczenia maszynowego i zaawansowanej analizy (h/t Yali Sasoon). Wymaga to współpracy z inżynierami i uzgodnienia w całej firmie, że dane mogą być celowo tworzone, a nie boleśnie wydobywane.

Twórz i świętuj ścieżkę do produkcji

Firmy zbyt często świętują szybkie iteracje w środowisku programistycznym, nie poświęcając wskazówek ani czasu na wzmocnienie tej pracy do poziomu produkcyjnego. Świętuj tę pracę i wyznacz czas międzyfunkcjonalny i własność systemów hartowania.

Systemy dążą do ślepej federacji

Ponownie — świętujmy ten problem! Jeśli wiele osób znajduje różne przypadki użycia biznesowego dla danych wyjściowych zespołu danych, robisz coś dobrze. Ale w ten sam sposób, w jaki niektóre pulpity nawigacyjne ad-hoc mogły znaleźć się na pokładzie tablicy 10 lat temu, to zapytanie ad-hoc może przekształcić się w aplikację produkcyjną bez Twojej wiedzy.

Wykorzystaj pojedynczą płaszczyznę kontroli do orkiestracji sterowanej zdarzeniami

Fivetran, dbt i Hightouch mają możliwość planowania zadań za pomocą harmonogramów cron i interfejsu użytkownika. Dzięki temu aranżacja może być budowana w sposób, który nie ujawnia widoczności w niejawnych zależnościach. Wyobraź sobie, że Hightouch ma się poruszać exp_fb_click_idscodziennie o 8 rano za pośrednictwem interfejsu użytkownika. Fivetran i dbt nie mają wglądu w tę zależność, podobnie jak ci, którzy współtworzą bazy kodów przed Hightouch.

Zamiast tego użyj narzędzia do orkiestracji (Dagster/Prefect/Airflow) jako pojedynczej płaszczyzny sterowania. Połącz zależności między narzędziami i stwórz holistyczny DAG, który działa w oparciu o sukcesy poprzednich kroków, w przeciwieństwie do nadziei, że zadania nadrzędne zakończą się pomyślnie o określonej porze dnia. zgrupować .

Twórz mapowania jeden do jednego eksportowanych przez zespół danych do dalszych przypadków użycia

Zespoły ds. danych powinny być zaznajomione z sugestiami dbt dotyczącymi strukturyzacji projektów . Zazwyczaj warstwa pomostowa jest zorganizowana i nazwana w sposób, który sprawia, że ​​relacja jeden do jednego z wejściowymi danymi źródłowymi jest niezwykle wyraźna. Użyj podobnego wzorca dla danych wyjściowych. W takim samym stopniu powinno być oczywiste, że obiekty Salesforce Opportunity i Account reprezentują tabelę dbt podczas przemieszczania, powinno być oczywiste, że eksport danych jest używany tylko w jednym przypadku użycia.

select * -- Extremely clear this comes from one and only one place
from raw.salesforce.opportunity
;

select * -- Extremely clear this comes from one and only one place
from raw.salesforce.account
;

select * -- Extremely clear this goes to one and only one place
from ml_outputs.model_results.exp_top_items_retailer_app
;

select * -- Extremely clear this goes to one and only one place
from ml_outputs.model_results.exp_top_items_salesfrce
;

Zamiast streszczać Layerinitis, ponownie skieruję was do wspaniałego wątku i definicji Jeana-Michela Lemieux. Ogólna rada jest jego, z pewnymi szczegółami danych, które zadziałały dla mnie.

Techniczna definicja Layerinitis polega na tym, że zespoły umieszczają kod tam, gdzie jest im najwygodniej, jednocześnie optymalizując pod kątem szybkości, a nie umieszczając kodu tam, gdzie należy, biorąc pod uwagę długoterminową perspektywę całego systemu oprogramowania.

Zmniejsz obszary, w których logika biznesowa może zostać wstrzyknięta na ostatniej mili:

Hightouch i Census pozwalają na transformacje SQL. Fivetran kiedyś . Większość konsumentów aktywacji danych (Sales/CX CRM, CDP) zezwala na SQL lub warstwę logiki biznesowej o niskim lub zerowym kodzie. Jeśli to możliwe, nie pisz logiki biznesowej w tych narzędziach. Jeśli postępujesz zgodnie z indywidualnym mapowaniem eksportów danych przez zespół do dalszych przypadków użycia, odwrotny ETL zawsze może wyglądać następująco:

select * from exp_table_for_single_use_case;

Zmiany w logice biznesowej należy zastosować do tego modelu dbt, a nie na ostatniej mili.

Stwórz zasady „Time To Live” dotyczące transformacji ostatniej mili:

Zespół ds. danych nie może całkowicie pozbyć się transformacji ostatniej mili. Nie chcesz, aby Twoi interesariusze czuli się zablokowani przez zespół ds. danych. Zawsze będzie potrzeba wprowadzenia poprawek lub iteracji logiki biznesowej, które są szybsze niż odświeżenie dbt PR + Snowflake.

Mówiąc bardziej ogólnie, Twoi interesariusze biznesowi mają kontekst, którego Ty nie masz. Chcesz zobaczyć , jak zmieniają Twoje dane. Przypomnij sobie sezonową SKU, wolumen, logikę kategoryzacji sklepu, którą przeoczył inżynier analityk. Stwórz świat, w którym interesariusze biznesowi mogą usprawnić Twoją pracę!

Polityka „Czas żyć” jest grawitacyjnym powrotem do centralizacji. Zezwól na transformacje ostatniej mili, ale przejrzyj je i przenieś logikę biznesową z powrotem do centralnej warstwy dbt / data science w rytmie, który działa dla Twojego zespołu danych i interesariuszy biznesowych

Zbuduj kulturę standaryzacji i celebrowania dostępu do wielofunkcyjnych baz kodu

Ludzie domyślnie piszą logikę biznesową w narzędziu, z którym czują się najlepiej. Dla współpracownika CRM może to być Hubspot / Iterable / Braze. Najlepszym sposobem, w jaki zespoły danych mogą zapobiegać rozrastaniu się logiki biznesowej, jest nie tylko ograniczenie transformacji ostatniej mili w innych narzędziach, ale także zapraszanie innych do korzystania z ich narzędzi.

To może być ️️️ ujęcie. Istnieje wiele powodów, aby martwić się, że członkowie zespołu niezwiązani z danymi będą pisać logikę w języku SQL i tworzyć dbt PR. To, co mogę zagwarantować — ta logika zostanie napisana, a jeśli zespół ds. Jeśli zespół ds. danych może edukować i zachęcać do wnoszenia wkładu w swoją bazę kodów, zachęca do pisania kodu tam, gdzie jest on najbardziej odpowiedni.

Lądowanie samolotu:

To świetny czas, aby być liderem danych. Ostatnia dekada rozwoju ekosystemu danych spowodowała utowarowienie przepływu i manipulacji danymi za pośrednictwem narzędzi własnych i innych firm. Jeden utalentowany analityk z marzeniem i kartą kredytową może zasilać raporty wewnętrzne, narzędzia wewnętrzne, automatyzację marketingu i aplikacje produkcyjne. To obiektywnie niesamowita wiadomość dla firm i specjalistów od danych.

• Nowoczesny stos danych pozwala zespołowi zajmującemu się danymi produkować wszystko, niezależnie od tego, czy powinny, i bez pozwolenia lub widoczności inżynierii produkcji.
• Nowoczesny stos danych pozwala interesariuszom biznesowym dodać logikę biznesową ostatniej mili do napędzania przepływów pracy w produkcji, niezależnie od tego, czy powinny, i bez pozwolenia zespołu danych lub wglądu.

W pewnym momencie Twoje produkty danych spowodują awarię aplikacji produkcyjnej. E-maile marketingowe zostaną wysłane, co nie powinno być. Zespół CRM obwinia zespół ds. danych, zespół ds. danych obwinia zespół inżynierów prod. Jedna z najważniejszych lekcji, których się nauczyłam, ale wciąż mam z nią codziennie problem: możliwość wejścia do napiętego pokoju/Zoom i przypomnienia wszystkim, że wszyscy jesteśmy w tej samej drużynie, to supermoc. To jest prawdziwe podsumowanie tego, jak wprowadzić systemy danych do produkcji.

Jeśli możesz stworzyć kulturę, w której:

• Inżynierowie produkcji tworzą wyczerpanie danych z zamiarem i podekscytowaniem tym, w jaki sposób dane zostaną wykorzystane
• Członkowie zespołu danych szukają przypadków użycia, proszą o opinie i pytają interesariuszy: „Hej, co właściwie robisz z danymi, które ci wysyłam?”
• SWE mogą doradzać i doskonalić najlepsze praktyki i standardy zespołu ds. danych, aby podnieść doraźne przepływy danych do poziomu produkcyjnego
• Członkowie zespołu ds. danych mogą doradzać interesariuszom biznesowym i podnosić ich poziom w zakresie dodawania logiki biznesowej, ram dla tego, gdzie należy logika
• Każdy zespół zaprasza inne osoby do swoich baz kodów i zachęca do długoterminowego spojrzenia na ogólną architekturę firmy

Ian Macomber jest szefem działu Data Science and Analytics Engineering w Ramp, pierwszej i jedynej karcie korporacyjnej, która pomaga firmom wydawać mniej. Wcześniej był wiceprezesem ds. analityki i inżynierii danych w firmie Drizly.

Jest też czwarty trend! Bądź na bieżąco z Data Systems Tend Towards Calculation , której było trochę za dużo, aby zmieścić się w jednym artykule.