DataInsiders.Space

#zerobuzzwords

Helping discover POWER OF DATA, as today, it’s all about data and its value!

MailChimp

Helping discover POWER OF DATA, as today, it’s all about data and its value!

MailChimp

#zerobuzzwords

Magicy od danych – Odcinek 2: Co ja tutaj robię?

Jeśli jesteś tutaj po raz pierwszy to zachęcam do lektury pierwszego odcinka – czyli Magicy od danych – Odcinek 1: Dawno, dawno temu…

W tym odcinku zobaczysz jak ewaluowały role w świecie danych, a także umiejętności które mogą być kluczowe, aby stać się “wzorem” danej roli.

Jak już wspomniałem w odcinku 1, nieco ponad dekadę temu role świata danych były mocno ograniczone, często połączone z innymi (jak chociażby wspominany architekt rozwiązań). Sam od początku moich przygód zawodowych stawiałem i stawiam na specjalizację (Miałem w swojej ścieżce co prawda “skok w bok”, ale był on bardzo świadomym krokiem i pozwolił lepiej zrozumieć inne obszary architektury, ale o tym w odcinku nr 3).

Wracając do świata sprzed ponad 10 lat. Zacznijmy od tego, co przetrwało do dzisiaj i jest dość naturalnym podziałem wśród ról technicznych (czasem techniczono-biznesowych). Od początku widać jasny i klarowny podział na obszary 4 obszary:

AnalizaArchitekturaDevelopmentAdministracja

W ówczesnych czasach rozwinięciem tych obszarów były odpowiednio role:

Analityk biznesowy/rozwiązania – którego główną rolą było zrozumienie potrzeb klienta i ich transformacja na obszar produktów, które te wymagania mogły zaadresować. Dla przykładu w przypadku budowania rozwiązania raportowego, analityk musiał zrozumieć dokładne potrzeby, aby dopasować do nich dane/źródła, wizualizacje, czy funkcjonalności uzupełniające platformę np. odpowiednie parametryzacje raportów, czy automatyzacje (np. automatyczna wysyłka).

Główne umiejętności: Kreatywne myślenie, znajomość funkcjonalności biznesowych platform raportowych/wizualizacji danych, umiejętność słuchania

Co ciekawe akurat rola analityka biznesowego można powiedzieć, że przetrwała nienaurosza do dzisiaj. Pojawiły się co prawda elementy specjalizacji np. Analityk Business Intelligence, a rola częściej nazywana jest konsultantem Business Intelligence, jednak znacząca część odpowiedzialności pozostała w formie zbliżonej do punktu wyjścia.

Drugi obszar, który jest mi akurat najbliższy, przeszedł olbrzymią i bardzo zauważalną transformację. Architekt – to osoba, która budowała architekturę całego ww planując odpowiednie użycie komponentów (bazując na wsadzie od analityka), jak również dopasowując komponenty od strony ich wydajności, kompatybilności czy skalowalności. Architekci początkowo skupiali się na całości rozwiązania, projektując jego elementy na każdej niemal warstwie. Właśnie dlatego bardzo często mówiono o architektach rozwiązaniach (tych nieco bardziej związanych z biznesem) oraz architektach IT. Architekt był (czy nadal jest?) osobą o szerokiej wiedzy dot. projektowania systemów od warstwy sieciowej, przez bazy danych, aż po warstwę aplikacyjną. Duże wyzwanie, duża odpowiedzialność.

W świecie danych trudno było spotkać osoby wyspecjalizowane w danym obszarze, a nawet jeśli, to już na pewno nie był to poziom specjalizacji spotykany dzisiaj. Rozwój usług, pojawienie się nowych obszarów i sposobów przetwarzania danych doprowadziło w ostatnich kilku latach do wykreowania znaczącej liczby ról na poziomie architektów. Co ciekawe dzisiaj architekci to zarówno osoby skrajnie techniczne, ale również osoby skrajnie biznesowe. Specjalizacja doprowadziła również do sytuacji, w której architekci patrzą na rozwiązania, bardzo modułowo. Tymczasem dobra architektura nadal wymaga spojrzenia holistycznego.

Czy to oznacza, że role specjalizowane w danym obszarze nie mają sensu? Wręcz przeciwnie, stały się niemal niezbędne, ze względu na ogrom technologii, jaki nas otacza i konieczność jej odpowiedniego dopasowania do aktualnie opracowywanej architektury. Nie zmienia to jednak faktu, że nadal potrzebny jest architekt patrzący na całość rozwiązania, który wspomagany jest przez architektów danego obszaru.

W wyniku wspomnianych specjalizacji mamy dzisiaj chociażby takie role:

Architekt Baz Danych

Architekt Hurtowni Danych

Architekt ETL

Architekt Platformy Danych

Architekt Danych

Architekt Business Intelligence

Architekt BigData

Architekt AI

Oczywiście dla każdej z takich ról zarezerwowana jest wiedza technologiczna o jednym lub kilku stosach technologicznych niezbędnych do budowy poprawnej architektury, jednak odnoszę wrażenie, że z każdą chwilą znacząco zwiększa się wymiar specjalizacji. Co więcej, chmura publiczna i związane z nią usługi doprowadziły do sytuacji, w której powyższe role mogą wymagać dodatkowych, nieco innych umiejętności, niż przypadku tradycyjnej rozwiązań on-premises, aby optymalnie planować taką architekturę. Przykładem takich obszarów jest chociażby planowanie elementów Disaster Recovery w chmurze vs on-premises.

Jakie zatem stawiamy wymagania przed dzisiejszymi architektami jeśli chodzi o ich umiejętności?

Umiejętność rozwiązywania problemów, współpraca zespołowa, myślenie projektowe, spojrzenie holistyczne

Czemu akurat takie?
Zmieniły się sposoby pracy – mamy większą specjalizację, co wymaga wymiany informacji z innymi architektami, często pracujemy w modelach rozproszonych, a to wszystko wymaga komunikacji i współpracy zespołowej.

Zadajesz sobie zapewne pytanie, a co z umiejętnościami twardymi, technologicznymi takimi jak Spark, Hadoop, SQL, Kafka, Gremlin, itd. Oczywiście to bardzo ważne, pamiętajmy jednak i pozwól, że zacytuję tutaj Tomasza Onyszko, który już kilka lat temu pisząc o roli architekta odpowiadał na pytanie “Dlaczego nie każdy specjalista może być architektem! Dlaczego nie każdy architekt musi być specjalistą (przynajmniej nie od wszystkiego)!“. No właśnie, wiedza techniczna u architekta to bardzo istotny atrybut, jednak sama głęboka wiedza technologiczna z danego obszaru, nie wystarcza, aby być dobry architektem.

Zaraz zaraz czyli mam głęboką wiedzę technologiczną z danego obszaru, znam każdy jeden najmniejszy szczegół działania danej platformy. Jestem w stanie zaimplementować, zoptymalizować i utrzymać działanie danego rozwiązania. Jeśli tak – po pierwsze WOW! Po drugie prawdopodobnie bliżej Ci do inżyniera, roli, która w ostatnim czasie w świecie danych(ale również świecie chmury) pojawia się bardzo często. Roli, od której wymaga się niskopoziomowej wiedzy technicznej, znajomości niuansów poszczególnych usług czy języków. Ról, które kilka lat temu mogły nazywać się zupełnie inaczej np. Developer BI czy też Administrator BI. Czym zatem różni się wspomniany inżynier danych od developera Business Intelligence czy Administratora? W roli inżyniera, oczywiście piszę to na przykładzie świata danych, bardzo często wykonuje się nieco więcej niż tylko pisanie kodu(jak w przypadku developera) i więcej niż konfiguracje i monitoring (jak w przypadku administratora) . Inżynier odpowiada za implementacje, czasami w modelu “code with”, czasami “no code”. Inżynier odpowiada często także za przygotowanie pod automatyzację procesu, inżynier optymalizuje działania danego modułu. Dużo tego? Fakt. Właśnie dlatego, przynajmniej moim zdaniem, to właśnie role inżynierów są obecnie najbardziej pożądanymi w wielu miejscach. Dobrym przykładem jest tutaj rola inżyniera danych, w której to osoba odpowiada m.in. za pozyskanie danych z systemów źródłowych, ich transformacje i wreszcie modelowanie (np. na potrzeby raportowe). Z czego korzysta inżynier danych w swojej pracy? Różnych narzędzi ETL, ale również języków takich jak SQL, Scala, Python, R, MDX, DAX i wielu innych, bo to tylko skrócony przykład.

Odnajdujesz się w takim świecie?
Zatem jedna z poniższych ról jest właśnie dla Ciebie:

Inżynier danych

Inżynier AI

Inżynier Business Intelligence

Inżynier Jakości Danych

Inżynier BigData

Inżynier Uczenia Maszynowego (ML)

Czy inżynier zstąpił zatem developerów /programistów i administratorów ?
Nie wyciągałbym tak daleko idących wniosków, nadal przecież w wielu miejscach funkcjonują role takie jak:

Developer Business Intelligence

Developer ETL

Developer Hurtowni Danych

A z drugiej strony:

Administrator platformy danych

Administrator baz danych

Czym się różnią?
Umiejętności i kompetencje takich osób bardzo często są zbliżone do wspomnianych powyżej w rolach inżynierskich, dotyczą jednak bardzo wąskiego obszaru odpowiedzialności jak np. tworzenie wyłącznie procedur/zapytań SQL na potrzeby zasilania danymi określonych baz danych czy modeli raportowych. Czasami natomiast są pewną zaszłością i niedopasowaniem nazewnictwa ról do rzeczywistych odpowiedzialności danej osoby. Warto też zauważyć, że w przypadku ról typowo administracyjnych pojawiło się wiele “usprawniaczy”, a usługi w chmurze publicznej dodatkowo sprzyjają szybkiej ewolucji takich ról. Dla przykładu wiele baz danych uruchamianych w chmurze publicznej ma zapewnione automatyczne kopie bezpieczeństwa, czy rekomendacje związane z optymalizacją działania platformy. Nie oznacza to oczywiście, że administrator “nie ma co robić”, zwyczajnie zmienia się jego rola w całym procesie.
Uwaga! Pamiętaj jednak, że powyższe uproszczenie ma zastosowanie WYŁĄCZNIE w świecie danych, ponieważ nigdy nie zaryzykowałbym stwierdzenia, że tradycyjni developerzy aplikacji zostali zastąpieni przez inżynierów.

Czy to już wszystko?

Cóż, wraz z rosnącym wymiarem danych, apetytem na ich wykorzystywanie i pomysłowością rynku pojawiły się także role, które przeżywały (a może nadal przeżywają) rozkwit – mowa tutaj m.in. o magiku najwyższej rangi czyli Data scientist, zgodnie z definicją to osoba, która łączy umiejętności technologiczne oraz społeczne, które pozwalają analizować dane i wyciągać z nich wnioski. Brzmi super!Jednak czy aby na pewno tak to wygląda w rzeczywistości? Myślę, że na to pytanie mogą odpowiedzieć wyłącznie osoby, które w takie roli pracowały lub pracują. Ja po kilku,a nawet kilkudziesięciu rozmowach z różnymi osobami pracującymi w takich rolach mam nieco inne zdanie….

p align=”justify”>Oczywiście to jeszcze nie wszystkie role, które można spotkać w dzisiejszym świecie danych, pojawiają się i funkcjonują role nakierowane na bardzo wąskie specjalizacje np. Specjalista ds. danych referencyjnych (Master Data), czy Data Stuart. Zostawmy je jednak na inny wpis. A może Ty pracujesz w takiej roli i chcesz o tym opowiedzieć? Daj znać w komentarzu, chętnie skorzystam z Twojego doświadczenia i staniesz się współautorem artykułu.

No właśnie, a co dalej?

Już w kolejnym odcinku rozwinę temat specjalizacji – czyli odpowiem na pytanie dot. wad i zalet specjalizacji (bazując na swoim przykładzie) oraz podzielę się ścieżkami kariery w świecie danych…Już teraz zapraszam!

ZOSTAW ODPOWIEDŹ

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *