Qlik Sense – Go for it!

W artykule omówione zostaną wybrane problemy klasycznego rozwoju oprogramowania i dostępu do treści.  Pokażę na przykładzie Qlik Sense, w jaki sposób można być bardziej Agile i Lean, oraz jak nowe rozwiązania technologiczne redefiniują pojęcie samej aplikacji i roli developera.

Przez wiele lat pracy w IT nauczyłem się, że nikt nie zna swojego biznesu lepiej niż sami klienci – zwłaszcza w bankowości inwestycyjnej. Jako programiści wielokrotnie spotykamy się z sytuacją, że przygotowywany przez wiele iteracji system uzyskuje akceptację po stronie klienta dopiero po upewnieniu się, że założone metryki są spełnione. Często wymaga to weryfikacji danych bezpośrednio u źródła, co wiąże się z tworzeniem kwerend SQL. Dopiero po takiej operacji klient nabiera pewności, że to co widzi na ekranie stworzonego interfejsu jest tym, czym być powinno.

Innym typowym problemem jest fakt, że nawet najwspanialszy wykres lub tabela nie są w stanie zaspokoić wszystkich zmieniających się wymagań. Nowa kolumna na gridzie, lub zapotrzebowanie na pie-chart, w miejsce liniowego wykresu, mogą okazać się wymaganiem, na które nie będzie można czekać. W takich sytuacjach z reguły pojawia się nieśmiała prośba o mały przycisk w postaci ikony Excela, który pozwoli na wyeksportowanie danych do pliku.  Użytkownik, mając dane w Excelu, czuje się bezpieczniej, a jego paląca potrzeba łatwo zamienia się w rozwiązanie. Z tym że nowa kolumna i wykres kołowy powstaną już w Excelu, a nie w naszym systemie.

Niestety nawet i to rozwiązanie nie sprawdzi się, jeśli w wyeksportowanym pliku nie będzie dodatkowej kolumny, lub wykres będzie musiał operować na danych, które będą pochodziły z połączenia wielu tabel. W takie sytuacji klient zostaje odcięty od własnych danych. Niestety development nowego rozwiązania, procedury wdrożenia i iteracje kosztują czas i pieniądze.

Nie to nie! Niech klient sam tworzy aplikacje

Nawet w podejściu Agile, dopiero po zakończeniu iteracji możemy otrzymać produkt, który dodałby nową wartość. Oznacza to, że w najlepszym wypadku kolejna wersja produktu pojawi się zwykle po dwóch tygodniach. Do tego należy dodać okres oczekiwania na testy, akceptację i samo wdrożenie.

Tu z pomocą przychodzą rozwiązania BI, które (w dużym uproszczeniu) dają możliwość wglądu do danych. Jednym z bardzo popularnych narzędzi tego typu jest QlikView. QlikView pozwala na zaawansowaną eksplorację za pomocą przygotowanego przez developerów interfejsu. Sam interfejs jest również bardzo dynamiczny i obudowany został wieloma narzędziami pracy grupowej. Guided Analytics – bo tak się nazywa zaprojektowana strategia dostępu do danych, posiada również swoje ograniczenia. W dalszym ciągu użytkownicy mogą oglądać dane, ale nie mogą sami budować kwerend, modeli i wizualizacji.  Dodatkowo uczestnictwo developera w procesie jest wciąż wymagane, a to właśnie developerzy stanowią wąskie gardło na drodze do informacji.

Klient developerem

A gdyby pozwolić użytkownikowi na budowanie własnych aplikacji z dostępem do danych, z możliwością budowania kwerend i zaawansowanych wizualizacji? Przy takim podejściu ze strategii Guided Analytics przechodzimy do Self-Service Data Discovery. Właśnie z myślą o tej alternatywie powstał Qlik Sense.

Qlik Sense to odpowiedź na ideę Big Data. W obecnej chwili, wiele hurtowni danych migruje się do architektury bazującej na Hadoopie i rozproszonym przetwarzaniu. Oznacza to, że analitycy mają potencjalny dostęp do olbrzymiej ilości nieznormalizowanej informacji. Dane przestały podlegać relacyjnym regułom, a schemat modelu danych określany jest dopiero przy próbie odczytu (schema-on-read).

W tym podejściu dostarczenie aplikacji nie musi wymagać bezpośredniego zaangażowania programisty, a czas na wdrożenie produktu może ograniczyć się do kilku godzin. Dzieje się tak dlatego, że zmienia się samo pojęcie aplikacji. To analityk buduje ją we własnym workspace, korzystając z gotowych konektorów źródeł danych i komponentów do wizualizacji. Samo wdrożenie to prosty proces publikacji aplikacji do strumienia, do którego mają dostęp inni użytkownicy.

Problemy związane z zaawansowaną personalizacją interfejsu, tworzeniem połączeń do danych, lub bezpieczeństwem, zostają wyłączone poza fazę developmentu. To procedury i reguły dostępu przejmują funkcję kontrolną. Rola developera zostaje sprowadzona do dostawcy komponentów wizualnych, konektorów źródeł danych lub twórcy dedykowanych mashupów.

Granulacja reguł dostępu odbywa się nie tylko na poziomie dostępu do interfejsu, ale też samych kwerend. Można skonstruować zapytanie SQL, które będzie możliwe do uruchomienia przez jednego użytkownika, a przez innego już nie. Z drugiej strony, stworzenie zapytania, które załaduje wszystko może okazać się dla klienta pokusą nie do odparcia – a zarazem nieszczęściem dla repozytorium danych.

Wobec tego do czego potrzebny mi developer?

Aplikacje budowane w ten sposób tworzą przestrzeń dla klienta/BA kosztem developera, dając możliwość wglądu i interpretacji własnych danych. Przyspieszają również sam proces dostarczenia i analizy treści. Niestety w dalszym ciągu mamy tu do czynienia z narzędziem BI i danymi w trybie “do odczytu”. Oznacza to, że modyfikacja istniejącej treści wciąż pozostaje domeną zespołów developerskich.

Jednak i w tym wymiarze Qlik Sense nie pozwala o sobie zapomnieć. Każda aplikacja w Qlik Sense może zostać udostępniona i osadzona w przeglądarce internetowej, jako część typowej strony HTML5. Sama strona może komunikować się ze swoim backendem, a tam wpłynąć na dane, z których korzysta Qlik Sense.

Lean UX

Jeśli spojrzymy na problem od strony UX, to podejście zastosowane przez Qlik Sense jest odpowiedzią na ducha nowych czasów. Jeff Gothelf w swojej książce “Lean UX” określa 3 główne filary podejścia “lean”: Design Thinking, Agile, Lean Startup Method (based on MVP). 

Design Thinking to metodyka skupiona na zrozumieniu użytkownika i jego potrzeb.  Domyślnym założeniem (assumption), które należałoby poddać pod rozwagę, jest w wielu przypadkach potrzeba samego budowania aplikacji (o Design Thinking przeczytasz więcej w artykułach Małgorzaty Barskiej na naszym blogu). Dodatkowo, oddając kontrolę w ręce samych użytkowników, otrzymamy bardzo dużą liczbę MVP (Minimum Viable Product) w postaci aplikacji typu Self-Service Data Discovery.

Jeśli przyjmiemy, że jednym z największych narzędzi UX do weryfikacji założeń MVP jest prototyp i spróbujemy trzymać się klasyfikacji:

• Low Fidelity (np. stworzony na papierze),
• Mid Fidelity (np. stworzony w Visio, Balsamiq),
• High Fidelity (np. opracowany w Axure RP),
• Coded ( np. “zmockowany” feature),

…to małe aplikacje budowane przez samych użytkowników wychodzą tu poza skalę. Wśród “Coded Prototypes” istnieje klasyfikacja na “Hand-coded” i “Live-data”. Ostatnia z nich, “Live-data”, balansuje na granicy herezji, ponieważ wystawia zmockowane funkcjonalności użytkownikowi  jako część produkcyjnego systemu, a to umożliwia uzyskanie  informacji czy faktycznie jej potrzebuje.

Czy przeprowadzenie testu A-B tworzonych aplikacji, w oparciu o rozwiązania samych użytkowników, nie będzie bardziej wartościową analizą MVP, niż zbudowanie choćby najbardziej wyszukanego prototypu? Oczywiście… to zależy. Zestawienie obok siebie alternatywnych rozwiazań nie musi wcale skutkować sytuacją, w której użytkownik będzie w stanie dokonać łatwego wyboru. To, co powstaje z jego własnych rąk mogłoby lepiej odzwierciedlić jego potrzeby i priorytety. Oczywiście o ile narzędzia dadzą mu ku temu sposobność.

W kolejnym artykule…

W kolejnym artykule przedstawię w jaki sposób można przygotować prostą aplikację w Qlik Sense. W tym celu posłużymy się aktualnymi notowaniami giełdowymi naszej spółki z oficjalnej strony internetowej GFT.  Pokażę jak w przeciągu kilku godzin w łatwy sposób udało mi się przygotować dashboard z masą ciekawych kontrolek i technologicznych rozwiązań.

Z drugiej strony skonfrontujemy omawiane rozwiązanie na przykładzie rzeczywistego projektu, z użyciem pełnego stosu technologicznego Cloudera i sprawdzimy, jak nowe podejście radzi sobie w boju.