Rozterki architekta danych

Data: 2019-04-05
Autor: Sebastian Konkol
Rozterki architekta danych

Uczestniczyłem ostatnio w seminarium, w czasie którego znany dostawca oprogramowania opowiadał o swoich rozwiązaniach służących przetwarzaniu danych. Co drugie wypowiadane zdanie zawierało BigData, Data Scientist, czy Machine Learning. Gdyby uwierzyć tym zapewnieniom, to sprawy dotyczące danych są tak proste, jak budowa cepa. Tylko w realu jakoś to nie działa.

Częściowo jeszcze w czasie tego seminarium, a bardziej już po powrocie do codzienności zmagań z cyfrowym transformowaniem dużej polskiej firmy, dochodziło do mnie zrozumienie powodów tego swoistego konfliktu rzeczywistości. Choć powodów tych jest bez wątpienia więcej, kilka z nich ma – w mojej ocenie – znaczenie szczególne.

W praktyce większości komunikacji o danych mówi się przez pryzmat systemu informatycznego lub aplikacji. Trochę tak, jakby to systemy informatyczne były powodem, dla którego mamy dane. To bardzo łatwa i kusząca droga, ale kompletnie błędna i prowadząca na manowce. Dane w systemach nie pojawiają się znikąd – dane pojawiają się w wyniku konkretnych, zorganizowanych działań (procesów), w których systemy mają tylko stanowić wsparcie. Odpowiedzialność za dane nie leży po stronie systemów – leży po stronie organizacji decydującej o włączeniu systemu informatycznego do wsparcia określonego działania. Przeniesienie dyskusji o danych na grunt systemów informatycznych przesuwa ją ze sfery odpowiedzialności do sfery narzędzi. I nagle okazuje się, że to system odpowiada za taki, czy inny stan biznesu firmy. Ślepa uliczka. Na marginesie, ciekawe, że na każdym takim przypadku zyskują dostawcy takich czy innych systemów, bo zawsze coś sprzedadzą.

W przytłaczającej większości przypadków firmy opierają swe działania na wsparciu takich czy innych rozwiązań dziedzinowych (zarządzania klientem, przedsiębiorstwem, magazynem, sprzedażą itd.) kupowanych jak „gotowe”. Każdy z tych systemów konstruowany jest z myślą rozwiązywania określonych zagadnień, a w trakcie tworzenia takiego systemu podejmowanych jest szereg decyzji projektowych. Takie systemy tworzone są jako systemy zamknięte – co prawda realizują one swoje cele, ale dane składowane w tych systemach są niejako produktem ubocznym działania takiego systemu. Podczas konstrukcji takiego rozwiązania, które miałoby być sprzedawane jako gotowe, dane nie uzyskują statusu elementu o mierzalnej wartości. Kiedy system zostanie już wdrożony okazuje się, że dane z tego systemu mają wartość dla biznesu firmy – muszą być wydobyte z systemu i zintegrowane z danymi z innych systemów. Staje się to uzasadnieniem podjęcia realizacji trudnego i kosztownego projektu konsolidacji takich danych. Ponieważ kupiony został system „gotowy” dostępne kupującemu informacje o danych w tym systemie są raczej szczątkowe, więc realizowany jest metodami prób i błędów. Taki projekt najprawdopodobniej już nigdy się nie skończy, a możliwość korzystania z danych jedynie składowanych w tym systemie wymaga podpięcia ciągłego strumienia finansowania – mimo, że koszty wytworzenia tych danych są ponoszone przez firmę, która ten system już kupiła.

Może więc tworzenie systemów „na miarę” rozwiązuje wszystkie te problemy? W praktyce wytwarzania oprogramowania żadna firma nie może sobie pozwolić na nie bycie „edżajlową”. Wszyscy sprintują, aby dostarczyć wartość biznesową tak szybko, jak to tylko możliwe. Nawet w przypadku w pełni poprawnego zwinnego podejścia im bardziej ewolucyjnie, tym trudniej z danymi – przyrosty funkcjonalne powstają, a później są zmieniane, co wymaga wielokrotnych powrotów do zagadnień integracji danych. W konsekwencji powszechnych braków w praktykach zwinnego tworzenia oprogramowania, w przytłaczającej większości przypadków w wyniku takich projektów powstają w trybie ewolucyjnym systemy, których każdy przyrost jest realizowany jako quick’n’dirty i który – mimo hucznych deklaracji o refactoringach – nigdy nie jest porządkowany. Skoro funkcjonalność aplikacji jest taktowana tak lekko, to czego oczekiwać po danych. W większości przypadków dane z takich systemów są koszmarem nawet dla najtwardszych integratorów danych, nawet już po zakończeniu tych „edżajlowych” projektów wytwarzania systemu.

Jakiś czas temu modne było szybkie tworzenie aplikacji, aby „dostarczać wartość biznesową”. „Edżajlowo” było nie zastanawiać się za wiele, tylko robić. Teraz modne jest operowanie na danych. Wartość biznesowa przechyla się w kierunku zdolności rozumienia danych. Jeśli ktoś poszedł za poprzednią falą namów marketingowych i zrobił się „edżajlowy”, to dzisiaj ma naprawdę poważne problemy, żeby cokolwiek zrobić ze swoimi danymi. Prawda jest bowiem niezwykle banalna. Jeśli chcesz mieć dobre dane, musisz konsekwentnie i nieprzerwanie wkładać wysiłek w ich jakość. Biznes jednak słucha tych komunikatów marketingowych i zaczyna liczyć zyski, a później przychodzi do „swoich IT” i dowiaduje się, że „się nie da”. I konflikt gotowy. Kiedyś znajomy wyjaśnił mi, skąd się bierze taki wysoki poziom kultury prawników, kiedy wylewnie się witają, choć reprezentują strony pozostające w konflikcie – bez względu na to, co się dalej stanie, prawnicy na pewno zarobią. Czy aby nie dajemy się wciskać w takie sztuczne konflikty, na których zarobić mogą tylko dostawcy „srebrnych kul” – coraz bardziej magicznych rozwiązań IT?

Pozostaw komentarz