Punkt wyjścia do rozważań o architekturze SOA

Na moim wątku o architekturze SOA, na Golden Line, po pół roku dyskusji, padło pytanie o 
Punkt odniesienia dla architektury SOA

To mnie zaskoczyło, bo uważałem, że zostało to jasno opisane we 
wpisie startowym. Podobne pytanie już padło i odniosłem się do 
niego tutaj:

Pamiętajmy jednak o nowych, przygodnych gościach.
Ćwiczmy dalej jasność wywodu i zwięzłość. Mamy rezerwy :)

Punktem odniesienia jest oczywiście Klasyczna Architektura Analiz
(pierwszy slajd wpisu startowego wątku.

Czyli wzajemne usytuowanie trzech (lub czterech, jeśli wydzielimy dodatkowo warstwę kostek OLAP) warstw architektury środowiska informatycznego, wspierającego proces analizy.

Tezą główną wątku jest, że poważna część analizy biznesowej odbywa się w Excelu.
Ten ostatni, przez "główny nurt" informatyki biznesowej, nazywającej samą siebie "Intelligence", traktowany jest jak Kopciuszek, któremu każe się wydłubywać ziarenka maku z popiołu.
I to szybko! Bo jak wróci macocha, czyli szef, a raport nie będzie gotowy, to będzie źle!

"Wyciągniesz sobie to wszystko jakoś z BI-aja". Powiedział szef/macocha i wyszedł na naradę.

Analityk ma się zadowolić klawiszem "Export do Excela" a potem - "niech się martwi sam".
I daje sobie "jakoś" radę.
Zespół, do którego należę, pełni w tej bajkowej metaforze rolę ptaszków, które pomagają Kopciuszkowi.

Taka jest praktyka - od kilkudziesięciu do stu procent analiz w Excelu!- we wszystkich firmach, znanych mnie i kilku członkom zespołu, do którego należę.
W tej liczbie znajdują się ogólnoświatowe firmy z listy Fortune 500.

Mamy kilkudziesięcioletnią praktykę w zakresie analiz biznesowych. Również w dużych firmach.
Ale jeszcze do niedawna uważaliśmy, że problemy dające się porównać do kłopotów Kopciuszka z makiem w popiele dotyczą firm małych, średnich oraz dużych - ale polskich. Bo te zagraniczne na pewno lepiej się sprawują.
Parę lat temu uświadomiliśmy sobie, że - nic podobnego!
To jest problem ogólnoświatowy. A "architektura klasyczna" - to w istocie "architektura błota", w której dane wsadza się do wózka inwalidzkiego z napisem "Eksport do Excela".
Slajdy drugi i trzeci wpisu startowego tego wątku.

I prawdziwe życie, a właściwie - prawdziwa analiza dopiero się wówczas zaczyna.

To jest punkt wyjścia i punkt odniesienia do rozważań.

Problem bezpieczeństwa w architekturze SOA

Problem bezpieczeństwa był przedmiotem żywej dyskusji na Golden Line na moim wątku.
Wypracowałem sobie dzięki temu pewne stanowisko, które jest jej dorobkiem.

Oto ono.

1) Dostęp do danych
W tych wdrożeniach, z którymi mieliśmy do czynienia, dostęp do odpowiednich danych ZAWSZE był warunkiem koniecznym sporządzenia raportu. 

Czy może ktoś się spotkał z sytuacją, że raport się sporządza bez dostępu do danych? Ja nie.

Co najwyżej trzeba odczytywać dane z WYDRUKU.
Znam przypadek, że pewien łebski analityk (Polak, notabene) napisał program odczytujący EKRAN monitora. Bardzo sprytny. 
Udzielono mu uprawnienia do patrzenia w ekran i on z tego skorzystał.

Zrobił furorę w pewnej wielkiej europejskiej firmie samochodowej, wykorzystującej renomowany system. Na literę S. Polski oddział tej firmy został uznany za najbardziej zaawansowany we wdrożeniu owego systemu S.

To była architektura pre - SOA :)

Dlatego radzę - zamiast hejtować - MYŚLEC. Hejtowaniem na bzdurnych w waszym mniemaniu wątkach dotyczących architektury analiz, nie zrobicie kariery.
(To była uwaga do dyskutantów na moim wątku na GL. Tutaj marzę o jakiejkolwiek dyskusji. Bezskutecznie :) )

Podsumowując:
Jeśli sporządzenie raportu wymaga dostępu do danych na poziomie faktów a nie ich agregacji, to bez tego dostępu - raportu nie da się stworzyć.
To jest rzeczywista implikacja.

Dostęp do danych źródłowych nie jest naszym kaprysem, tylko biznesową potrzebą.

2) Możliwość ustawiania konkretnych uprawnień 

Możliwości nadawania uprawnień do konkretnych poziomów agregacji, z agregacją zerową włącznie 
oraz
interface w jakim będą nadawane (pewnie jednak nie skoroszyt Excela :) 
a także
decyzja ile i jakie role systemu będą odpowiedzialne za ich nadawanie....

powinny być ustalone na etapie projektu produktu - systemu informatycznego wspierającego analizę biznesową. Oczywiście mającego architekturę SOA.

3) Nadanie uprawnień 
to sprawa, którą należy rozstrzygać na etapie projektu wdrożenia systemu, a weryfikowane podczas jego eksploatacji.

Kłótnia o tabelę przestawną, czyli architektura błota w praktyce

Część I: Co to jest Tabela Przestawna?

                        Panu Marcinowi Sz, analitykowi, nie informatykowi....

Link do następnej części cyklu

1. Wstęp - motto.

Wypowiedzi Pewnego Informatyka (wszystkie podkreślenia - KR):
Pierwsza – do mnie:

Pański kolega, zupełnie poważnie, tłumaczy ludziom różnicę miedzy OLAP'em a tabelą przestawną w Excelu (!). (…) Na kolejne porównanie proponuję SQL i Worda. 

Chyba powoli przekraczamy wszelkie granice absurdu.

O co chodziło? Pewien Analityk zadał mojemu koledze pytanie następującej treści:

„Zastanawiam się jaka jest różnica, patrząc z punktu widzenia użytkownika końcowego – analityka,  między funkcjonalnościami OLAP a funkcjonalnościami tabeli przestawnej w Excelu”.

A oto  Pana Informatyka konkurencyjne wyjaśnienie o zerowej zawartości absurdu, wypowiedź druga - do Pewnego Analityka:

Tabela przestawna to tylko kontrolka (do prezentacji danych, źródło danych nie ma znaczenia). OLAP to technologia. (…) Nie ma możliwości i nie można tego porównywać bo to zupełnie inne bajki.

– powiedział Pan Informatyk (dalej w tekście PI), traktując te trzy lakoniczne zdania jako odpowiedź Analitykowi i jednocześnie uzasadnienie swojej  tezy o „absurdzie” odpowiedzi Eksperta (mojego kolegi).

2. Dlaczego ten incydent jest taki ciekawy?

Kluczowe dwa zdania;

Tabela przestawna – to tylko kontrolka. OLAP – to technologia.

Drugie zdanie – to pozornie nic szczególnego. Później o tym. Dopiero w drugiej części, bo to nie tyle "inna bajka" ale inny rozdział tej samej bajki. (Przypis uczyniony po nieporozumieniu pełnym piany, 3 kwietnia).

Ale ta najkrótsza definicja tabeli przestawnej, jaką mi się udało usłyszeć w czasie mojej wieloletniej kariery informatycznej i analitycznej rodzi poważne pytanie:  Co to jest naprawdę Tabela Przestawna?

3. Spór o TP – jako ilustracja sporu o SOA

W tym incydencie ogniskuje się istota sporu o architekturę excelocentyczną (SOA), jako alternatywę architektury błota (MOA). Chłop swoje, baba swoje. Analityk swoje. Informatyk swoje.

Jeśli chodzi o Tabelę przestawną, z analitykiem jest łatwiej. Analitykowi można by rzecz całą skwitować, jak czytelnikowi Nowych Aten, dzieła księdza Benedykta Chmielowskiego, pierwszej polskiej encyklopedii powszechnej, które to  dzieło zawierało słynną definicję:

                Koń, jaki jest, każdy widzi.

Wówczas każdy szlachcic miał konia w stajni i mógł sobie obejrzeć. Wsiadał na niego codziennie i czuł każdym nerwem jego istotę a nawet, niektórzy, jego duszę.  Dla ludzi praktycznych tworzenie „naukowej” definicji konia nie miało więc sensu.

Podobnie z Tabelą Przestawną. Każdy analityk (no, może prawie każdy) codziennie jej używa, czuje jej istotę, przydatność i nie wie tylko, co by bez niej zrobił. Nie będzie pytał o jej definicje, tylko najwyżej o to, o co zapytał nasz Analityk:

Słyszałem o jakimś OLAPie. Ma on coś wspólnego z tabelą przestawną. Co mi to da, jeśli będę miał do tego dostęp?

(Uwaga teraz na ten ustęp, który nastąpi. Ten kursywą, w siedmiu krokach opisujący pewien proces. To opis procesu, w którym główną rolę sprawczą pełni Pan Informatyk. A nie zauważamy, ze najważniejszą, jednak, Analityk).

Ale inaczej z informatykiem. On Tabeli Przestawnej używa właśnie, tylko, jako kontrolki.

1.     Najpierw w swojej „nadkontrolce” (w jakimś menejdżment studiou, ups, sorry, skompromitowałem się, w Business Intelidżens coś tam, naprawdę nie pamiętam, komputer z tymi bajerami akurat mam w naprawie...) do zarządzania serwerem analitycznym wyklika w pocie czoła kostkę OLAP. Co to jest kostka OLAP? Za chwilę krótko wyjaśnimy. To nic strasznego.
2.     Potem kliknie w kontrolkę „Tabela Przestawna” i „podejrzy”, czy wszystko w porządku. Kilka chwil – i już wie. Zrobił swoje. Teraz niech się nad tym pastwi analityk.
3.     Dostępu (w Excelu, tak, jak by chciał) do kostki wyklikanej przez informatyka – analityk nie dostanie. Albo – dostanie tylko na czas wdrożenia. Kiedy jeszcze bi – aj nie ruszył.
4.     Potem – dostęp tylko w interface’ie (kontrolce) tabeli przestawnej bi – aja. Własnej kontrolce bi - aja. Bo bi – aj – to wielki pan, prawie, jak tuhaj – bej, ma własną kontrolkę Tabeli Przestawnej.
5.   Jak analityk koniecznie chce, to może zawsze użyć innej kontrolki - „Excel”. Tuhaj bej ma i taką. Wówczas analityk otrzyma w Excelu piękną tabelkę prostokątną, z nagłówkami, której postać wynika z tego, jak obsłużył „kontrolkę” TP w tuhaj - beju.
6.   Jak wejdziemy w szczegóły, to się okaże, że musi jeszcze wykonać mnóstwo czynności, które równają się ciągnięciu wózka inwalidzkiego po błocie. Ale później?
7.    Później może już w Excelu robić, co chce. Na przykład użyć teraz Tabeli Przestawnej Excela, „jednego z najbardziej skomplikowanych narzędzi Excela”. „Niektórzy użytkownicy z niej nie korzystają, bo uważają, że jest …za skomplikowana.” To nie ja, to John Walkenbach. Mój jest tylko wielokropek.

To, co powyżej, to była właśnie architektura błota, MOA w działaniu.

A teraz ....

4. Co to jest Tabela Przestawna?

Analitykowi ten fragment właściwie nie jest potrzebny. Chyba, że początkujący. Aaa – to co innego. Ale i taki doświadczony niech poczyta. Będzie wiedział, jak ja tłumaczę, co to jest Tabela Przestawna – informatykowi. Bo jego wizja „kontrolki”, proszę wybaczyć szczerość, jest cokolwiek komiczna.

Akurat w tym wypadku, moim zdaniem , Wiki wygrywa z koryfeuszem Excela, Walkenbachem.

Definicja Wiki, jest lakoniczna, i co najważniejsze, przynajmniej w części oddaje najlepiej istotę rzeczy.

Tabela przestawna (terminologia arkusza Microsoft Excel) –  narzędzie analityczne arkusza kalkulacyjnego…

Dalszy ciąg już nie jest tak dobry. Ale zatrzymajmy się nad tym określeniem „narzędzie analityczne arkusza”. I przypomnijmy wzmiankę o nim Johna: „Jedno z najbardziej skomplikowanych”.

Spróbujmy więc sami dopowiedzieć resztę. Mamy do czynienia z jednym z najbardziej skomplikowanych narzędzi analitycznych, jednej z najbardziej zaawansowanych, najbogatszych funkcjonalnie, najbardziej elastycznych platform analizy biznesowej. Najbardziej rozpowszechnionych. I, w pewnych kręgach, najbardziej pogardzanego i usilnie wypieranego. Ale to już szczegół poza protokółem.

Do czego służy owo narządzie analityczne?

Jeśli odwołamy się do tego tekstu, który objaśnia naturę tabeli faktów, jako punktu wyjścia do ich analizy, najprościej będzie powiedzieć, że

Tabela Przestawna służy do:

• wieloaspektowej, wielowymiarowej i hierarchicznej analizy 
• wszystkich dostępnych cech 
• pewnego zbioru faktów.

Tabela 1 Fakty zebrane w tabeli

Każdy wiersz tabeli – to pojedynczy FAKT.

Kolumna „Wartość” jest miarą tabeli faktów. Jej istnienie jest warunkiem istnienia FAKTU.

Miara może być dowolną funkcją, ale najczęściej – to suma kolumny.

Jeśli odfiltrujemy rekordy dla jakiejś wartości cechy (np. dla roku 2010-tego), otrzymamy sumę kolumny dla wartości cechy - Rok – równej 2010. 

Jeśli dołożymy drugi filtr – nazwę towaru – „Śruba M 8x30”, otrzymamy sumę kolumny dla dwóch wartości cech – roku „2010” i towaru – „śruba M 8x30”.

Dodając kolejne filtry zawężamy pole analizy do coraz bardziej szczególnego przypadku – np. dwa pierwsze znaki kodu pocztowego (pewien obszar terytorium Polski). I tak dalej, bez końca. Im więcej cech opisuje fakt, tym dokładniejszą analizę, dotyczącą bardziej szczególnego przypadku możemy przeprowadzić.
Można sobie również wyobrazić fakt opisany większą liczbą miar. Oprócz wartości sprzedaży, dodajmy koszt własny sprzedaży opisanej przez wiersz oraz marżę. Będziemy mogli przeprowadzać trzy analizy określane przez ten sam zestaw cech, albo po prostu jedną kompleksową analizę pod trzema różnymi kątami, z miarą złożoną z trzech składników.

Jak tabela przestawna ułatwia taka analizę?

Kolumny „Data”, „Mc”, „Rok”, KodPocztowy”, „Kod2”, „Nazwa” – to cechy poszczególnych faktów.

Tabela przestawna (Niżej prezentowana w tabeli 2) umożliwia szybkie i różnorodne ustawianie tych cech, jako etykiet wierszy (w Tabeli 2 – Nazwy towarów), kolumn (w tabeli 2 – Rok) oraz „stron”, czyli wartości filtru (w tabeli 2 – Kod2). 

W środku tabeli (w tzw. polu Dane) na przecięciu kolumn wierszy i kolumn Tabela Przestawna podaje wartości funkcji agregującej miarę tabeli faktów dla konkretnych kombinacji cech.

Przykładowo – Dla pozycji etykiety wiersza: Śruba M 8x30 w roku 2010 suma wartości (sprzedaży) wyniosła  1 207,71 zł.

Tabela 2 Przykład analizy tabeli faktów. Etykiety wierszy: Nazwy towarów, Etykiety kolumn: Rok, Strony: Kod2

Taką tabelę możemy skonstruować myszką w ciągu kilku chwil, niezależnie od liczby rekordów w tabeli faktów. Tabela faktów może również zawierać prawie dowolną liczbę kolumn z określonymi cechami tych faktów ( a także z innymi miarami).

Specjalista od inteligentnego klikania myszą może więc w ciągu paru minut uzyskać jeden z kilku, kilkunastu czy kilkudziesięciu wariantów – kombinacji cech faktów opisanych wartościami ich miar.

I ten opis – to nie tyle wierzchołek góry lodowej, co raczej przyjazna powłoka rogu obfitości. Obfitości udogodnień (np. automatyczne budowanie hierarchii czasu, automatyczne generowanie tabel dla wszystkich wartości „stron”), funkcjonalności (np. Drill – down dla każdej liczby, wyjątkowo efektywna współpraca z zewnętrznymi źródłami danych), formatowań (np. format liczb dla wartości miar w środku tabeli), funkcji (np. pola wyliczane, funkcja WeżDaneZTabeli) oraz wykresów i ustawień.

Narzędzie analizy dla użytkowników, którzy nie wypuszczają myszki z ręki. Szkoda, że część z nich nie używa tego narzędzia, bo się go …. obawia.

Bardzo możliwe, że wszystko to, albo większość, nasz PI wie. Ale ja mam do niego, na zakończenie tej części rozważań, tylko jedno pytanie:

Czy opisany proces analizy dowolnego zbioru faktów, opisanych pewnym zestawem ich miar i cech (atrybutów) jest kompletny, co do istoty? Czy też istnieje jakiś istotny element, który tutaj nie istnieje i dopiero „technologia OLAP” ten element zawiera? Jaki jest to element i na czym polega jego rola, że ta technologia, to inna bajka niż tabela przestawna?

Być może będzie tu jakaś dyskusja, ale być może będę musiał jednak ciągnąć wątek sam. Bo czasem bywa tak, że szybciej się rzuca pogardliwe uwagi niż pisze sensowne wyjaśnienia.
(Przyp.13 stycznia 2014. Dyskusji nie było, patrz komentarze niżej, ale wniosek jest. Odpowiedź na ostatnie pytanie można sformułować: nie ma istotnej różnicy.)

Zostawiając Pana Informatyka z tym pytaniem, jestem teraz winny Analitykom wyjaśnienie, czym jest kostka OLAP.

5. Czym jest kostka OLAP?

Otóż rozumiejąc istotę „szerokiej” tabeli faktów, pojęcia cechy (i jej synonimów - atrybutu, kryterium, wymiaru …), miary, analizy wielowymiarowej, wreszcie  - tabeli przestawnej, pojęcie kostki staje się dziecinnie proste. Otóż kostka OLAP jest, w pewnym sensie, ignorując cały informatyczny i matematyczny sztafaż, taka tabelą przestawną w pigułce. Tabelą przestawną zapakowaną do torby z suszonym popcornem, mieszczącej się w kieszeni. Ale mającą właściwość takiego rośnięcia, że czasem nie wystarcza wielki kubas.  Kubas pachnącego i gorącego popcornu, który uwielbiają dzieciaki podczas seansu  Shreka ileś tam.

Czy one muszą znać tajniki zaawansowanej technologii suszenia, prasowania i pakowania kukurydzy w torby oraz ich prażenia, i półautomatycznego napełniania kubasów, żeby docenić jej smak? A czy te dzieciaki potrafią odróżnić dobry popcorn od spleśniałego?

Czy dobrze wytłumaczyłem istotę kostki OLAP, opierając się na idei Tabeli Przestawnej?

Jeśli tak, to ….

Stosunek objętości tego punktu w stosunku do poprzedniego jest jednocześnie dowodem na to, że kostka OLAP i Tabela przestawna – to w gruncie rzeczy skrzaty z tej samej bajki.

Prawda?

Mini - podsumowanie dyskusji o SOA

A teraz, z podziękowaniami dla pana S.Brody, minipodsumowanie wątku:

Czyli zamiast zrobić to porządnie (automatyczny raport w BI, dostępny dla całej firmy) dalej robimy to "na boku" w exceliozie pod inną postacią (SOA).Sławomir Broda

Można by się zżymać, że ktoś po trzech miesiącach dyskusji i szczegółowych tłumaczeniach na dziesiątki tysięcy znaków, dalej nie rozumie  genezy, podstawowych założeń koncepcji, istoty elementów architektury itd.
A może udaje?  
Zabijcie mnie, nie wiem. Stawiam, że naprawdę "nie wie, nie rozumie, nie lubi, nie szanuje".
Ale to jego problem.

Ale pytanie zadane przez osobę "nierozumiejącą", albo "śmiertelnego wroga" jest czasem cenniejsze od takiego, zadanego przez "zwolennika".
I to jest "pytanie" tego rodzaju.

A oto moja odpowiedź, którą uważam za najcenniejszą, bo fakt, trudno u mnie o lakoniczność.
To teraz KRÓTKO:

Tak, czasami, jak nie można "porządnie", trzeba zrobić "w ogóle".
Takie życie. Rozumiem, że Pan robi "dobrze", albo wcale. To bardzo piękne dążenie i solidaryzuję się z taką postawą.

SOA rzeczywiście ma tę "wadę", że zawsze można to zrobić. Tak, jak w exceliozie.
Te "wady" łączą te dwa podejścia. Ale są też różnice. I o tym był ten wątek. 

Oczywiście, nikt nie robi karkołomnych sztuczek, kiedy, jak Pan powiedział, zacytujmy to jeszcze raz, można:
zrobić to porządnie (automatyczny raport w BI, dostępny dla całej firmy).

Cały wątek jest o tym, że bardzo często tak nie można zrobić.
Tzn: ani nie można uzyskaś "porządnego raportu" ani nie można uzyskać "porządnego dostępu".
Można zrobić w exceliozie (i robi się, spoko). Albo można zrobić w SOA.


Dziękuję za pomoc w napisaniu minipodsumowania :)

Moje podsumowanie dyskusji o SOA

Najważniejsze zarzuty wobec koncepcji:
(wg. panów Krzysztofa Bokieja i Sławomira Brody)

1. Odpowiedzialność przerzucana na analityka. (Do niego należy )dbanie o jakość źródeł danych i o zasilenia. 
2. Zamiast analizować, analityk będzie odwalał pracę administratora. 
3. Większość analityków ma zbyt niskie kompetencje informatyczne. Nie dadzą sobie rady z nowymi zadaniami.
4. Brak kontroli nad dostępem do danych. Zerowy poziom kontroli uprawnień.
5. Znaczne obniżenie jakości składowanych danych i wykonywanych analiz

Moje podsumowanie zarzutów:

Ogólnie - propozycja jest chybiona, 

Nie należy wprowadzać nowej architektury, tylko poprawiać istniejącą. 

SOA ma pewne zalety, ale jako dodatek do istniejących rozwiązań i tylko dla power-userów

Moja odpowiedź w nieco innym układzie

1. Wszystko OK? 
NIE. Nie jest OK. Bo według KB ( a tym bardziej SB) właściwie wszystko jest OK. Nic nie trzeba zmieniać. Co najwyżej usprawniać. Nie wiadomo tylko, co. 

My uważamy, że niedomogi organizacyjne korporacji i niewłaściwa architektura środowiska analiz nie są wynaturzeniem, tylko „normą”, którą należy uwzględniać przy projektowaniu na nowo zarówno architektury, jak i ról uczestników gry organizacyjnej.
Dixi. I ani KB ani tym bardziej SB nie udowodnił, że jest inaczej. Co najwyżej wyraził taką opinię. Zresztą, jak to udowodnić? Można zrobić parę wycieczek do działów analiz, controllingu, czy finansów.

2. Fałszywa alternatywa.
Nie ma takiej alternatywy, jak BI + SOA + Excel versus BI właściwie wdrożony + power userzy

Prawdziwa alternatywa jest narysowana na slajdach poniżej. Slajdy były starannie dobrane i każdy powinien je rozumieć. Tymczasem ich cytowanie przez niektórych dyskutantów było tylko złośliwym spamowaniem wątku. A lepiej było się nad nimi zadumać.

3. Prawdziwa alternatywa.
Ta prawdziwa alternatywa to – 

SOA 

lub MOA

czyli albo architektura zorientowana na skoroszyt, albo zorientowana na błoto i wózki inwalidzkie. Tak wynika z praktyki, nie z teorii.

4. Niepotrzebna koncepcja? NIE!
KB wątpi, czy nowa architektura jest w ogóle potrzebna. SB bez namysłu ją odrzuca. 
Wystarczy w istniejącej architekturze wpleść lepiej analityka. Na przykład dopiąć go do HD. 
Postulat, niestety, nierealny. I niewystarczający. Analityk nie ma prawa dostępu do HD. Chyba, że poprzez „wózek inwalidzki”. Postulat pana K. to nasz postulat … sprzed dziesięciu lat. Nam czasem dawali. Analitykowi jeszcze rzadziej dadzą. Bezpieczeństwo. Tutaj powinien być emotikon z przymrużonym okiem. Stały motyw.
Ale nawet, jak dadzą, analityk nie ma wszystkich skladników istotnych danych do analizy. Najprostszy przykład: Jedne tablice udostępnią INNYCH - NIE. Musi sobie zrobić bypassy. Ale nie skoroszyt bypasuje, tylko hurtownię. 

Proces PS1 -> DMA -> PS2 realizuje również postulat KB.

5. Czy można zablokować SOA? Tylko tutaj. :) Ale w rzeczywistości? Forget it!

Pewnie można. Próby zostały podjęte. Tutaj. Ale … nie w życiu. Analitycy nie czekają! Już sobie poradzili – tworząc (najczęściej, z wyjątkiem naszych uczniów, nieprawidłowo :) ) „nielegalnie” swoje prywatne pseudo- hurtownie danych a właściwie megaskoroszyty z mega – exceliozą. 

6. Życie zwyciężyło . Trawa dawno wyrosła pod asfaltem i betonem. Beton zaczyna się kruszyć. Asfalt się wybrzusza. Asfalt poniesie mniejsze szkody. Beton przegra. My jesteśmy tu zwiastunami tego zjawiska. A zakrzyczenie rzeczywistości da skutek odwrotny.

7. SOA to księżycowa idea? NIE. Już jest realizowana.
Architektura SOA jest zresztą możliwa do realizacji z podłączeniem wózków inwalidzkich, jako elementem. I jest realizowana również w takim układzie.
Ktoś w końcu zauważy, że trawa tak jakoś dziwnie rośnie na betonie. I zacznie się zastanawiać!

Rozważania, czy SOA wprowadza większe koszty na serwis informatyczny pomijam. Nos dla tabakiery czy tabakiera dla nosa? Jakie koszty teraz ponoszą firmy na informatykę? Z jakim skutkiem? Żeby po opuszczeniu autostrady, brodzić po kostki w błocie???

http://www.goldenline.pl/forum/3099900/architektura-sr...

Owoce dyskusji o SOA (4)

Podsumowanie dyskusji z panem Krzysztofem Bokiejem (dalej w podsumowaniu – KB) o architekturze SOA Cz 1.

Będę ją streszczał, nauczony doświadczeniem, w małych kawałkach, odnoszących się do konkretnych dyskutowanych tez. 

Łatwiej będzie o linki w dalszej dyskusji, ułatwi jej śledzenie i utrzymanie ładu. Zbiór linków do dyskutowanych z KB zagadnień uzyska później status linku głównego we wpisie "bardziej podsumowującym".

Zacznijmy od mojej tezy:
Struktura zasobów jest szybkozmienna
cytat wypowiedzi inspiratora tej dyskusji zaczerpnięty z innej dyskusji dodatkowo moje stanowisko uzasadnia: 
„Problem polega na tym, że częste zmiany w systemach źródłowych wpływają mocno na HD”.

Teza spotkała się ze zdecydowanym sprzeciwem KB:

Moim zdaniem założenie kluczowe (założenie o szybkiej zmienności warunków i założeń analizy) jest nierealne...
Bo struktura oczywiście jest zmienna, ale na pewno nie nazwałbym tego szybką zmiennością. Zdarza się, że dochodzą > jakieś atrybuty i potem trzeba je do HD dodać, ale to po pierwsze nie dzieje się "codziennie", a po drugie, jeżeli ta zmiana > jest istotna, to wie się o niej z wyprzedzeniem. (…) to założenie jest na wyrost.
Najwięcej zmian w systemach źródłowych ma miejsce na etapie stabilizacji nowego systemu po wdrożeniu. Zgoda. Ale jak > się wszystko ustabilizuje, to po prostu działa.

I uwaga: charakterystyczna wypowiedź:

A prawdziwą szybką zmienność to mamy w typowej exceliozie, gdzie arkusze są źródłami dla istotnych raportów > (podkreślenie moje). I wtedy jest rzeczywiście lipa jak się zmieni struktura plików wsadowych.

Moja odpowiedź będzie rozbita na kilka wpisów, które będą się odnosić do poszczególnych zagadnień. Zagadnienie „szybkiej zmienności” rozbija się na kilka mniejszych. 

Najpierw: 

Czy naprawdę problem zmienności jest istotny na tyle, żeby proponować aż nową architekturę? 

Było to dyskutowane obszernie i podważane właściwie przez wszystkich dyskutantów. Jest to rzeczywiście fundamentalna racja istnienia SOA i jeśli uznamy, że:

po pierwsze - przy pomocy „sprintów” potrafimy sobie zapewnić taką strukturę oficjalnych źródeł danych dla oficjalnej platformy analiz, czyli firmowego BI

po drugie – że praktycznie każde zagadnienie biznesowe może zostać wymodelowane w firmowym BI –ju

po trzecie – „ad – hocowe” analizy w Excelu stanowią nieistotny fragment działalności, dotychczasowa architektura MOA (zorientowana na błoto) + wózki inwalidzkie w postaci exportów do Excela wyczerpują problem i nie ma o czym gadać…

… jeśli, powtarzam, przyjmiemy TAKIE właśnie założenia, to architektura SOA nie ma większego sensu, traci rację istnienia.

Linki do case’ów podawaliśmy kilkakrotnie.
Oto jeszcze raz one:
http://excelambitny.blogspot.com/2012/06/spreadsheet-o...
http://excelambitny.blogspot.com/2012/11/praktyka-korp...

Jestem tu nagabywany o case'y dalej. NIE. Dysponujemy jeszcze pewną liczbą case’ów. Następne dochodzą każdego dnia. 

Wystarczy porozmawiać z pierwszym lepszym analitykiem. 

Rodzi się swoista subkultura, terminologia, która wykracza poza kulturę jednej korporacji. Analityk przechodzący do innej korporacji, wyposażonej w innego BI – aja, spotyka te same procedury, te same terminy, te same „sztuczki”. Wszystko - związane z analizami w Excelu na obrzeżach BI. Za bajorem błota, z komunikacją przy pomocy wózków inwalidzkich.

Jeśli ktoś tego nie chce dostrzegać, to oczywiście może. Może również bagatelizować ten problem. Kulturalnie – jak robi to KB, lub posuwając się do inwektyw, jak robią to inni.

Ale to nie zmieni postaci rzeczy. My nie głosimy tu żadnej idei. Tymi założeniami opisujemy pewną rzeczywistość. Dalsza dyskusja z tą rzeczywistością czy też POZA nią – nie ma sensu.

Opierając się na naszych doświadczeniach uważamy, z dużą dozą pewności, że wszystkie trzy założenia należy zdecydowanie odrzucić.

I sformułować założenia dokładnie odwrotne. Dalsze rozważania będą prowadzone już bez ciągłego wracania do tych tez. I o to proszę również dyskutantów. Kto się z tym nie może pogodzić, powinien założyć NOWY watek.
Tyle na ten temat. 

W tej wypowiedzi jest ciekawy szczegół, który może być źródłem istotnego przeciwstawienia. Ujawnia, moim zdaniem, pewną protekcjonalność dla wątku SOA, jakiego nie mogą ukryć wszyscy przedstawiciele „zawodowej informatyki”, nawet ci najbardziej kulturalni.

To własnie ostatnie zdanie wypowiedzi KB. Odniosę się do niej w następnym wpisie.

Owoce dyskusji o architekturze SOA (3)

Wyjaśnienia o istocie DMA (Data Mart for Analysis)

Odpowiedzi na pytania Krzysztofa Bokieja

DMA jest własnością analityka - to rozumiem. Ale co to jest "abstrakt opisu zasobu danych"? Czy tu chodzi o abstrakt tego co dane w organizacji opisują? Czy o abstrakt zasobu danych? I co Pan rozumie przez "opis zasobu danych"?

Chodzi dokładnie o "abstrakt opisu zasobu danych"

Zacznijmy dodatkowe wyjaśnienie od końca:

1) Zasób danych, to, jak Pan celnie wyczytał ze schematu nr 4, (chodzi o schemat architektury SOA) (przy okazji wykazując, że nie umiem do trzech zliczyć :) ), ogół zapisów odwzorowujących biznes i jego kontekst wraz (żeby wyciągnąć poza nawias i więcej do tego nie wracać Pana chwalebną troskę o wiarygodność danych), ze znanym poziomem wiarygodności każdego zapisu .

2) Zapisy są o różnym stopniu przetworzenia, agregacji i ładunku informacyjnym. 

3) "Opis zasobów", to taka "uogólniona hurtownia". Czyli dane + procesy ich pozyskiwania, najkrócej ujmując. Dlaczego uogólniona? Bo to nie tylko opis w "języku wykonywalnym", ale opis w RÓŻNYCH językach. 
To są zdania SQL, które dają w wyniku widoki biznesowe, interesujące dla "analityka". Zresztą "analityk" - to też abstrakt, ale o tym później. O to Pan na razie nie pytał.
To są zdania w MDX, które wyszukują wartości z kostki. 
To są wreszcie jakieś skrypty, które obsługują mechanizm pompy PS1 odpowiedzialny za specjalizowane funkcje arkuszowe, takie, jak w Afinie funkcja GetData(), mojego pomysłu.

( Dygresja: Takie funkcje są już w zresztą w róznych BI -jach. Ale my byliśmy pierwsi! Funkcje - tak. Architektura - nie. Ona jeszcze budzi na tym wątku śmiech. Przepraszam za dygresję, ale chcę ilustrować abstrakty, żeby nie wpaść w ogólnikowość. :) 
Jak to wszystko zgromadzić w jednym abstrakcie, a właściwie jego ucieleśnieniu? To już szczegół realizacyjny. ISTOTNY. Ale nie wchodzi on do problematyki SOA. Kto ciekawy akurat tego szczegółu, może sobie pobrać ze strony afin.net narzędzie i próbować.

4) Wróćmy jeszcze na chwilę do zasobu danych. Załóżmy dalej, że armia fachowców ciężko pracowała nad tą imponującą strukturą i na razie ...
po pierwsze nie mamy im nic do zarzucenia. Może jeszcze do tego wrócimy, ale na razie załóżmy, że zrobili swoją robotę bezbłędnie. To jest rysunek nr 1.
Po drugie, włączmy "przycisk odtwarzania" na tym obrazku. Czyli dodajmy wymiar czasu.
W jaki sposób BI działa w czasie?
Moja teza jest, że niezadowalająco. Mamy o tym dyskutować?
Proponuję założyć oddzielny wątek. Tutaj musimy przyjąć to za pewnik. Zresztą z Pana wypowiedzi, które przeczytałem, wynika, że zdaje Pan sobie z tego sprawę.
Tylko "jakby" nie robi to na Panu wrażenia. "Ba, nikt nie jest doskonały".

5) My uznaliśmy, że problem jest na tyle poważny, żeby nie tylko "robić w temacie" BI, czyli robić swoje, wdrażać i serwisować swoje narzędzie, jak każdy producent i serwisant, ale i dzielić się swoimi doświadczeniami, jak pomagać tym, którzy się zmagają z tym "nieistniejącym" problemem.
Od wielu lat szkolimy użytkowników Excela. Leczymy z exceliozy. Bo Excel też ma swoje za uszami.
"Przeklejki i Wyszukaj.Pionowo()" to odpowiednik "wirującego, srebrnego dysku" jako ostatecznego rozwiązania w BI-ju.

Zwykły DM (nie DMA) to wycinek danych organizacji zorientowany na jakiś proces biznesowy. Fizycznie, jest to jakiś zbiór danych, na którym się raportuje i analizuje. To tak w dużym uproszczeniu. Czy DMA to po prostu DM? Jeżeli nie, to gdzie jest różnica?

Z punktu 3) mojej odpowiedzi na poprzednie Pana pytanie wynika odpowiedź przecząca (DM to oczywiście nie DMA). 
I wynika z niej Pierwsza różnica: DMA to nie jest to, co Pan napisał wyżej, określając DM, tylko „uogólniona hurtownia”, w której zasób danych jest opisany w różnych językach i fizycznie może oznaczać kilka zbiorów o kompletnie odmiennej strukturze.

Druga różnica jest bardziej fundamentalna. Jak wiadomo, DM nie jest własnością analityka. Ale podarowanie mu DM niczego by nie rozwiązywało. Przecież DM ma już ściśle określony zakres tematyczny. I służy różnym analitykom. I nie tylko. Służy BI -owi do raportów.
Zaś DMA to jest perspektywa analityka. Widok taki, jak postrzega i powinien postrzegać zasoby analityk odpowiedzialny za analizę określonego obszaru biznesu. Widok wszystkiego, co tylko mu się przyda. Łącznie z wynikami giełdy w Hong-Kongu. I wynikami rozgrywek ligowych w Katarze.
Obiekt na tyle elastyczny i odporny na modyfikacje, żeby można było w nim na co dzień "grzebać". I nie bać się utraty spójności i wiarygodności. :)

Trzecia różnica jest bardziej konkretna. Ale istotna. Struktura i języki opisu zasobu danych w DMA muszą być spójne z PS1, czyli pompą ssącą nr jeden, działającą w Excelu (lub – jeśli Pan chce, w arkuszu kalkulacyjnym klasy Excela). Inaczej znów wszystko skończy się na przeklejkach.
A ma być zasysanie, dokładnie takie, jak formuła w Excelu. Lub ikonka „odśwież”.

Co do "nieistotny", to przepraszam. Założyłem po prostu podświadomie, że jeżeli to szczegół i Pan go pomija w ogólnej koncepcji SAO, to jest dla Pana nieistotny. Wycofuję oczywiście.

Nie ma za co. Ale Pańska postawa budzi respekt. Już wiem, co mnie czeka :)
I sprostowanie:

"Moim zdaniem to co Pan nazywa szczegółem realizacyjnym, jest w praktyce bardzo istotne. Zakładam, że chce Pan, aby DMA zawierała poprawne dane."

Wyjaśnienie mojej postawy już zawarłem w poprzedniej odpowiedzi. Więc sprostowanie przyjmuję, jako akt formalny, nie merytoryczny.
Jeśli to nie było wystarczające, proszę dać znać.
Wiem, że „wiarygodność” – to Pana „konik”. Ale chciałbym utrzymać czystość merytoryczną wątku. (...)
Pozdrawiam

Zostawiłem specjalnie "grzecznościowe" zakończenie, żeby zilustrować poziom kurtuazji tego dyskutanta. Wersal, prawda?

W czasie tej dyskusji - to prawie unikalne zjawisko.
Ach Ci informatycy! Jakie to zakapiory! :)

Pan Krzysztof, mój imiennik - to rodzynek.
Dziękuję, panie Krzysztofie.