Istota koncepcji SOA

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

1)       Raporty są uniwersalne, odświeżalne, żywe

2)       DMA jest naszą – podkreślmy: NASZĄ! – własnością, a my najlepiej wiemy, co nam potrzeba,

3)        Jednocześnie DMA jest uniwersalnym źródłem danych i dokumentacją zasobów.

4)       Profesjonalizacja analizy. Zamiast łataniny - procedury, elastyczność i nadążność za rytmem biznesu.

5)       Uruchomienie zasobów intelektualnych działu IT. IT TEŻ będzie miał lepsze poczucie spełnionego obowiązku.

6)       Większa współpraca i integracja załogi wokół celów biznesowych a nie wzajemna spychologia i pretensje, kto winny złej analizie.

7)       Władza nad analizą jest w rękach tych, którzy za nią odpowiadają:  analityków.

Następny odcinek: Praktyka korporacyjna a architektura SOA