Wczoraj miała miejsce konferencja: Business Intelligence GigaCon 2011. Więcej tu: Hurtownie danych jako standardowe moduły COTS (Commercial off the shelf) nowoprojektownych systemów dedykowanych December 6th.

Poruszyłem między innymi problematykę: aspekty projektowe systemów dedykowanych i dostosowywanych oraz ?core domain? i pojęcie COTS (Szczegółowe informacje http://gigacon.org/bi_2011).

Nie jest moim celem powielanie tu referatu, dlatego tylko kilka kwestii a potem mała uwaga na temat metod argumentacji osób reklamujących swoje produkty, ale po kolei.

Hurtownia danych jako skład historii

W swoim referacie wskazałem na hurtownie danych i metody składowania tam danych oraz na pojęcie “system dedykowany”. I tak:

1. MIT: Oprogramowanie dedykowane to kosztowne, długo wykonywane i ryzykowne, projekty tworzenia oprogramowania od zera dla klienta,
2. PRAWDA: Oprogramowanie dedykowane to oprogramowanie (System) zaprojektowane na bazie dobrze opisanych wymagań, złożone z komponentów (typowe gotowe komponenty to ERP, CRM, SCM, inne).

To znaczy, że docelowo  – jako system dedykowany – klient otrzyma zestaw zintegrowanych komponentów (podsystemów, aplikacji). Możliwe jest, że niektóre zostaną opracowane i wykonane specjalnie dla niego. Pełny Zintegrowany System wspomagający zarządzanie (wszystkie aplikacje w firmie)  najczęściej nawet w 90% składa się z oprogramowania gotowego (COTS ? Commercial of the shelf).

Kolejnym mitem jest teza, że koszt integracji jest duży. Powiem tak: zły projekt zawsze kończy się wysokimi kosztami, projekt integracyjny także.

Praktyka pokazuje, że poprawnie postawione wymagania oraz projekt wykonany przed wyborem rozwiązania, to najczęściej projekty, w których koszty integracji są wielokrotnie niższe od kosztów kastomizacji systemów zintegrowanych ERP i paradoksalnie trwa to krócej.

Po trzecie wdrażanie etapami (aplikacja po aplikacji) pozwala na to, by te poszczególne podsystemy pracowały na siebie bez czekania na całkowite zakończenie wdrożenia całości, jak to ma miejsce najczęściej podczas wdrażania dużego i zintegrowanego systemu. Warto także zauważyć, że taka – tak zwana komponentowa – architektura jest łatwa w modyfikacji (możliwa jest wymiana dowolnego składnika bez szkody dla innych czego nie można powiedzieć o dużych systemach ERP). Przykład z systemami BI (Business Inteligence),  które będę tu zwał Raportowaniem.

Ogólnie wymagania na system wspomagający zarządzanie maja taką strukturę:

Diagram jest prosty. Chcę zwrócić uwagę na to, że wiele funkcjonalności (może nawet wszystkie) systemów wspomagających zarządzanie można na takie dwie kategorie podzielić. Przypomnę, że diagramy przypadków użycia to nie “projekty systemu” a ich “spis treści”. Projektem, na wysokim poziomie abstrakcji (ang. HLD czyli [[Hihg Level Design]]), jest dopiero to:

Załóżmy, że architekt systemu stworzył powyższy model. Decyzja projektowa: system transakcyjny obsługuje naszą specyfikę biznesową, jest odpowiedzią na wymaganie: Obsługa tego co się teraz dzieje.  Opracowano dokładanie wymagania, na rynku nie znaleziono wymaganych funkcjonaliści i ta część systemu zostanie wytworzona.

W ramach wymagań jednak, jak widać na poprzednim diagramie, mamy także wymaganie: Pokaż co wydarzyło się kiedyś. Są to funkcjonalności raportowe.  Raportowanie jako funkcja systemu jest dość dobrze opanowana, są na rynku gotowe produkty (jest ich wiele). Więc z projektu developerskiego (oprogramowanie projektowane) wyłączono ten zakres i kupiono podsystem, popularnie zwany hurtownia danych. Większość tego typu aplikacji ma bardzo dobre, uniwersalne interfejsy, więc ich integracja nie stanowi żadnego problemu.

System transakcyjny, projektowany, w ogóle nie zajmuje się historią, przetwarza wyłącznie dane bieżące dzięki czemu stał się znacznie prostszy, czytaj tańszy w wykonaniu. Wszelkie dane o historycznych stanach naszych danych są w hurtowni danych a tę mamy już gotową, taniej niż koszt wytworzenia podobnego systemu.

I tak: ta część, która opisuje specyfikę naszej organizacji (oznaczona na niebiesko), to tak zwane “core domain” czyli główny element dziedziny systemu. Jeżeli nie znajdziemy na rynku produktu, który w 100% mu odpowiada należy wydzielić taki fragment i stworzyć sobie dedykowany. Kastomizacja gotowego produktu zawsze jest kompromisem, najczęściej bardzo kosztownym. (więcej o praktyce projektowania zwanej DDD).

Pojecie [[COTS (Commercial off the shelf)]], o którym już na blogu nie raz wspominałem, to tu nasz gotowy komponent: hurtownia danych. W efekcie wszelkie funkcjonalności związane z raportowaniem implementujemy w tej hurtowni, pozostałe musimy wytworzyć. To dodatkowa korzyść: baza danych systemu transakcyjnego staje się dużo prostsza, czytaj tańsza, bo model danych nie musi “obsługiwać historii”.

Jeżeli potrzebne nam zaawansowane metody raportowania i analiz należy raczej zakupić aplikację z rodzaju Business Inteligence zamiast zlecać dostawcy systemu (np. ERP) kolejne implementowanie wyrafinowanych – kosztownych w opracowaniu i utrzymaniu – raportów.

Przy okazji: użycie hurtowni danych “w tle”, to nic innego jak cloud computing :), tu tak zwana chmura prywatna”.

Demagogia na konferencji

Z ust osoby promującej pewien produkt zaliczony do Business Intelligence padło stwierdzenie:  Nasz produkt jest prosty, pobiera dane do raportów bezpośrednio z systemu ERP, nie musimy więc dodatkowo inwestować w pośredniczący system hurtowni danych, ktory może mieć dane nieaktualne. Tezę tę miał poprzeć diagram podobny do tego:

U góry mam “skomplikowany system BI” a na dole “nasz prosty i łatwy w obsłudze system”. To jak by usunąć zielony komponent z powyższego diagramu komponentów. Gdzie haczyk? Ano tu:

Górny diagram to przykład modelu danych dla hurtowni danych. Jest prosty, w praktyce skomentowany “po ludzku”, jako metadane, jest czymś, z czym może pracować każdy, kto tylko zna daną dziedzinę, taki model danych (tak zwana gwiazda) odwzorowuje w prosty sposób znane biznesowe pojęcia.

Diagram niżej to model danych niewielkiego systemu biznesowego (model danych systemu ERP, mający nawet tysiące relacyjnych, nic nie mówiących zwykłemu śmiertelnikowi tabel,  byłby w tej proporcji zwykłą kolorową nieczytelną plamą…). Wykonanie samodzielnie jakiegokolwiek raportu z tego drugiego systemu tabel graniczy z cudem. Można przygotować (administrator bazy) tak zwane “widoki” dla użytkowników co nie zmienia faktu, że  ich opracowanie to “wiedza tajemna” i nikt z “biznesu” sam tego nie zrobi. I najważniejsze: dostęp do pełnego modelu danych najczęściej wymaga złamania zasad bezpieczeństwa to jest udostępnienia danych z pominięciem mechanizmów kontrolnych aplikacji ERP.

Hurtownia danych to model stworzony pod kątem przetwarzania faktów historycznych na prostym modelu danych (diagram powyżej, górny, to tak zwana kostka OLAP). Opracowanie takiego modelu wymaga specjalnej analizy i projektu, ale nie zapominajmy: analizę się robi raz a raporty stale… tu przeszkolony użytkownik biznesowy sam daje radę bez problemu.

Tak więc szanowni Państwo. Jeśli tylko Wasza firma jest bliżej czołówki niż ogona rankingu rynku w Waszej branży, nie dajcie się namówić na jeden zintegrowany ERP i jakiś model referencyjny,  bo nawet jak uda się go wdrożyć, to zmiana czegokolwiek będzie trudna a upgrade do nowszej wersji niemożliwy. Opracowanie projektu systemu składającego się z komponentów, pozwoli Wam dobrać najlepiej spełniające Wasze wymagania aplikacje. Jak z klocków LEGO można złożyć “dedykowany system” pomagający utrzymać przewagę na rynku, a nie cofający Waszą firmą do poziomu “innych podmiotów w branży”.

Prognozowanie

Problem w tym, że z tych samych danych różne firmy analityczne potrafią wyciągnąć różne wnioski. Nie mam wątpliwości, że w najbliższych czasie czeka nas wysyp firm specjalizujących się w analizie danych płynących z internetu, ale póki co, wnioski są frustrujące: nie potrafimy wiarygodnie przewidywać trendów rynkowych. (Piotr Podleśny, prezes firmy Atena, źr. Prognozy wymagają zrozumienia danych – Computerworld).

Nauka wykazała, że sama analiza danych historycznie nie stanowi żadnej prognozy. Do tak zwanej predykcji  wymagany jest model “przedmiotu”, którego zachowania chcemy przewidywać. Czy to możliwe? Tak. Czy to łatwe? Znowu odpowiem: nie. Potrzebny jest model a nie tylko dane historyczne (te pozwalają wyłącznie na analizę tego co było), więcej o tym w artykule o metodach naukowych analizy.