Spreadsheet Oriented Architecture (SOA)
Przewrót kopernikański w Business Intelligence (2)
Wojciech Gardziński
Jakub Rumiński
Krzysztof Rumiński
Ukazał się właśnie, we
wrześniowym numerze Controllingu i Rachunkowości Zarządczej II odcinek naszej sagi
o architekturze. W październiku będzie przerwa, bo mamy przejściowe trudności
twórcze. Na listopad szykujemy bombę. Jeśli zapłon ma opóźniony, to siła
wybuchu nie będzie zmniejszona. Co się odwlecze to nie uciecze.
Na razie więc
publikuję tu fragmenty części II – giej w swojej interpretacji.
Różnię się z
Czcigodnym Redaktorem Stanisławem trochę w rozłożeniu akcentów. No i nie mogę darować
redakcyjnemu grafikowi takiego zmasakrowania naszych wypieszczonych schematów. Tutaj będą rysunki może nie tak profesjonalne
ale na pewno lepiej oddają istotę idei, które tu prezentujemy. A są to idee dla
nas fundamentalne.
Ten fragment tekstu,
to kwintesencja naszych wieloletnich doświadczeń. Prosimy o uwagę. To nasza
krwawica.
W
poprzednim artykule ostro skrytykowaliśmy obowiązującą
obecnie, klasyczną architekturę środowiska analiz i zapowiedzieliśmy przewrót.
Pora przedstawić alternatywę.
Zmieniamy optykę na excelocentryczną!
Optyka excelocentryczna
Oznacza to, że punkt obserwacyjny znajduje się w Excelu,
zaś wszystkie żmudne, pracochłonne,
zautomatyzowane lub ręczne, operacje, decydujące o wykonaniu istniejącego raportu na nowy okres, są
oceniane z tego punktu obserwacyjnego. Przyjmujemy więc swego rodzaju excelocentryczny punkt widzenia. Wyraźmy
to takim, trzypunktowym manifestem:
1. Jestem w Excelu, nigdzie się nie ruszam,
cokolwiek się dzieje, w Excelu, lub poza Excelem, oceniam z punktu widzenia możliwości
i metod Excela.
2. W szczególności mam świadomość, że metody i
obiekty Excela są przystosowane do współpracy ze współczesnymi bazami danych.
3. I dlatego Excel ma wszelkie dane,
przynajmniej przy sporządzaniu raportów, żeby „rządzić”! Czyli to ja, analityk,
organizuję przepływ danych dla moich raportów.
Zespół tych metod, obiektów i operacji w Excelu ma swoją
logikę, wymagania i specyfikę. Innymi słowy, ma określony state of art, profesjonalny sposób projektowania, sporządzania,
pielęgnowania i odświeżania raportów.
Ten state of art
jest w dużej części zapoznany. Zwłaszcza w części dotyczącej współpracy z
bazami danych, które są źródłem ciągle zmieniających się wartości do raportów,
które z kolei mają za zadanie przetworzyć te dane w informacje.
A jaka jest teraz sytuacja w zakresie aktualizacji raportów
nowymi danymi, skąd analityk bierze dane? Najczęściej dostarczają mu je
informatycy. Oni zaś zachowują się przy tym, jak w starym dowcipie, o
umorusanym wozaku w gumowcach, który wparowuje do gabinetu Dyrektora i informuje:
-
Przywiozłem węgiel, gdzie zrucić?
Informatyk myśli o danych, które musi „dostarczyć”, jak ten
wozak. Potem… jest wolny. Jest z siebie wyjątkowo dumny, zwłaszcza wtedy, gdy
dostarczy je w formacie Excela.
Zaś analityk ma coś w rodzaju węgla na błotnistym podwórku.
I musi jakoś wnieść ten węgiel do piwnicy.
Jak zmienić tę sytuację?
Kontynuując naszą analogię z węglem, powinniśmy mieć sposób,
żeby nie wychodząc z gabinetu i nie używając ani gumowców, ani rękawic, ani
łopaty, ściągnąć węgiel do piwnicy. A nawet, żeby w skrajnym wypadku, ściągnąć
węgiel wprost ze składu opałowego do tej piwnicy, eliminując wozaka.
Czyli powinniśmy tak zorganizować przepływ danych
wykorzystywanych przez raport w Excelu,
żeby nigdy nie opuszczać Excela.
Informatycy, którzy odpowiadają za informatyczny przepływ
informacji, uważają, że to serwery bazodanowe są jej jedynym centrum, a Excel
to taki drobny, wręcz nieistotny, dodatek do nich – to „Front-End” systemu – do
którego dane się eksportuje.
A raport, żeby mógł
przetwarzać na bieżąco dane źródłowe na informację, powinien mieć
połączenie z danymi i możliwość błyskawicznego ich odświeżenia i zaktualizowania
informacji.
Aktualizacja informacji, zawartych w raporcie oznacza, że
analitycy do raportu informację… ciągną!
Lub ssą, jak kto woli.
I to analitycy powinni zorganizować sobie pracę według tej
nowej zasady. Oni wiedzą najlepiej, czego im potrzeba, aby otrzymać kompletny raport. Definiują zakres danych, ich
pochodzenie (sic! – nie zawsze dane, dot. wielkości sprzedaży bierze się z
programu sprzedaży, choć to niby takie oczywiste – przykład: niezaksięgowane
odbiory towarów), definiują stopień ich agregacji, formę, a często również zakres uprawnień.
Żaden „gotowy raport BI” nie uwzględni wszystkich potrzeb,
jakie pojawią się jutro. Dlatego, po zaistnieniu nowej sytuacji, „kreśli się”
raport – tabelę w Excelu, a potem „szuka się” danych: otwiera się aplikacje
transakcyjne, zastanawia się, skąd wziąć to, a skąd tamto?
Ale gdy się je odnajdzie, nie przerabia się danych w Excelu,
tylko projektuje się nowe źródło danych dla Excela oraz uruchamia się
odpowiednią procedurę zasilania źródła danych – nowymi danymi. Nowe źródło
danych może bazować na pliku-eksporcie.
To trwa dotąd, aż profesjonalny,
przejrzysty raport będzie miał kompletny zestaw źródeł danych.
Istota SOA (Spreadsheet
Oriented Architecture)
Co stanowi o istocie?
Zacznijmy od porównania dwóch
rysunków:
Na pierwszym, prezentowanym już w pierwszej części tego
artykułu, widzimy pomiędzy naszym skoroszytem, a źródłami danych „błoto”, czyli
żmudne czynności przeklejenia i umieszczenia w odpowiednich miejscach nowych
danych. Dane, dostarczane są do Excela niejako wózkami inwalidzkimi, pchanymi
przez owo arkuszowe „błoto”.
Widok: Praktyczna, obecna, architektura analiz
Widok: Architektura SOA
Drugi rysunek pokazuje dwa nowe elementy:
Pierwszy – to
mechanizm podłączania źródeł danych i „wciągania” danych do Excela. Mechanizm
ten działa wewnątrz Excela, co zapewnia, że analityk ma pełną kontrolę nad procesem
odświeżania, a sam proces staje się łatwy i przyjemny. Reprezentowany jest
przez pierwszą pompę ssącą (PS1), tę znajdującą się wewnątrz skoroszytu.
Drugi – to
dodatkowa warstwa danych, pełniąca rolę źródła danych bezpośredniego dostępu
dla Excela, za pośrednictwem wspomnianej pompy (Data Mart for Analysis).
Ta warstwa danych może zaopatrzona być w szereg procedur ją
zasilających. Z kolei, te procedury działają na podobnej zasadzie, jak warstwa
pierwsza, dlatego są symbolizowane przez
drugą pompę ssącą (PS2) i, w świecie informatyki, noszą nazwę –
Data Transformation Services
- DTS).
Ale te procedury nie są nawet konieczne. Ważne jest, że dane
znajdują się w źródle DMA, obojętnie, jak się tam znalazły: sposobem ręcznym,
czy przy pomocy najbardziej zaawansowanych procedur zasilających,
porządkujących, uszlachetniających. Najważniejsze, że pompa PS1 może z nich
swobodnie korzystać.
Procedury automatyzujące proces aktualizacji źródła (PS2) mogą
być usprawniane i zmieniane bez
zakłócania procesu tworzenia raportów oraz procesu końcowej analizy
biznesowej. Warunek jest prosty: podczas takich prac nie zmienia się struktura źródła.
A oto istota „Architektury SOA” – wyłożona w trzech złotych
zasadach:
1) Wprowadzamy dwa pojęcia – nasze „obiekty analityczne”
a)
warstwa danych
bezpośredniego dostępu „Data Mart direct Access for Excel”, czy też,
prościej, „Data Mart for Analysis” (DMA), do której Excel ma bezpośredni dostęp
b)
zasoby danych, które oznaczają każdy przydatny
fragment opisu rzeczywistości w postaci elektronicznej, dostępny nie z poziomu
Excela, tylko za pośrednictwem DMA (poprzez PS2)
Kluczowym warunkiem jest tu wymóg, że właścicielem DMA jest analityk a nie informatyk. Informatyk jest
mile widziany, jako asystent merytoryczny, ale nie posiada „władzy”. Uprawnienia
do DMA posiada analityk. Bez tego warunku NIE MA SOA!
2) Przyjmujemy zasadę „pompy ssącej” umieszczonej w Excelu.
„Jestem w Excelu, nigdzie się nie ruszam…”, odświeżam dane, umieszczone już w Excelu,
myszką lub skrótem klawiszowym (uruchamiając jakieś makro lub program
aktualizujący dane) i raport jest już aktualny. Wszystko tak organizuję w
skoroszycie, że nowy raport o TEJ SAMEJ STRUKTURZE to: zmiana parametrów i
aktualizacja danych przez kliknięcie myszą
3) Jakiekolwiek „przeklejki”, zmiany źródeł, ręczne
przełączanie na inny zestaw danych, edycje łączy i tym podobne ”tradycyjne
operacje okresowe” w działach analiz, są albo surowo zabronione, albo stanowią
smutny, ale konieczny wyjątek w stanie wyższej konieczności, a nie żelazną regułę analizy, jaka obecnie
obowiązuje.
Kwestia podziału wysiłków między Excela i DMA jest otwarta.
Np. DMA może również być realizowane w standardowych narzędziach Excela (MS
Query, Power Pivot, ODBC, OLE DB, VBA, ADO), a może być realizowane w MS Access,
MS SQL, MySQL, ORACLE, DB2 i co tam sobie kto wymyśli. Wybór bazy danych zależy
od oczekiwań jej stawianych, jej dostępności a nawet … kwalifikacji analityka.
Zależy również od tego, czy inżynier-analityk potrafi wykorzystać wiedzę i
umiejętności swojego asystenta merytorycznego – informatyka.
Ambitny program? Może i ambitny. Ale naszym zdaniem jedyny
możliwy, bo innej drogi nie ma. Kto tego nie zrozumie, będzie za pięć lat za
burtą głównego nurtu sztuki analiz biznesowych. Razem z producentami
mastodontów, nazywających samych siebie, nomen omen, Business Intelligence.
Istota DMA (Data Mart for
Analysis)
DMA to kluczowy punkt architektury. Jej serce.
MY, analitycy, znaleźliśmy się w – centrum analiz, przejęliśmy władzę nad swoim informatycznym środowiskiemanaliz,
ale za tym idzie… odpowiedzialność. Już nie tylko za właściwie napisane formuły
Excela, odpowiednie adresowanie, parametryzowanie, słowniki parametrów, przejrzystość
budowy raportu i przyjazny, czytelny i ładny format raportu - to też. A nie spaghetti, niestrawne po kilku tygodniach nawet
dla autora.
Spada na nas odpowiedzialność za jakość danych i za architekturę całości, charakteryzującą się
trwałością, użytkowością i pięknem. Takimi cechami bowiem od kilku tysięcy
lat legitymuje się dobra architektura.
Kształtowanie takiej architektury, co naturalne, można
jednak powierzyć komuś, kto
po pierwsze -
posiada głębokie zrozumienie potrzeb analizy, zwłaszcza z uwzględnieniem
dynamiki zmian tych potrzeb,
po drugie - posiada
odpowiednie kwalifikacje.
Jakość danych wynika z kwalifikacji informatycznych
wykonawcy procesów, z jakości algorytmów ich przetwarzania, zastosowania metod
informatyki, teorii baz danych, języka SQL, elementów programowania…
Wizja przejęcia odpowiedzialności za całość analizy przez
ludzi, nawykłych do sprzątania węgla po wozakach, może przyprawić o zawrót
głowy. No cóż - trudno. Kiedyś trzeba będzie przyzwyczaić się do tej myśli –
jeżeli chcemy być profesjonalnymi analitykami.
.
Korzyści SOA
Stawiając w centrum analiz
Excela, nadajemy mu prawo obywatelstwa. Paradoksalnie spowoduje to na
początku poprawę jakości samych raportów. Większa władza, rola pełnoprawnego
członka architektury środowiska analiz zobowiązuje do profesjonalizacji
skoroszytu.
Oto złota siódemka zalet architektury SOA
