Kto to pisze i dlaczego uważa, że może...

Moje zdjęcie
Doświadczony. Hmmm. Może docenisz tę cechę? Nie wiem, czy warto. Doświadczenie to głównie to, czego bym nie radził Tobie powtarzać. Ale i tak zrobisz, co zechcesz...

poniedziałek, 28 stycznia 2013

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.

Owoce dyskusji o architekturze SOA (2)

Skalowalność architektury SOA

Panowie Krzysztof Bokiej (informatyk) i Marcin Szewczyk (analityk) zaczęli dyskutować między sobą.
Jak rozmawia dwóch łebskich i dobrze wychowanych ludzi, to nawet, jak ich doświadczenia są zupełnie różne, rozmowa jest ciekawa, daje wiele satysfakcji i przede wszystkim, jest źródłem inspiracji do następnych felietonów.
oto wywołanie problemu skalowalności:

 Krzysztof Bokiej
No i widzi Pan. To jest taka skala, że Pan jako analityk z tym Excelem jeszcze ogarnia. Ale jak się proponuje jakąś architekturę to kluczowym wymogiem jest, żeby ta architektura była skalowalna. Ja się obawiam, że podejście "Excel jest centrum Wszechświata" nie jest skalowalne.

Oto mój felieton, przeklejony z GL bez zmian (poprawiłem literówki):


Miałem się nie odzywać już dziś, mam robotę, ale tylko chwileczkę. 5 tys znaków. Nie ma przeproś.
Dla piśmiennych.

Panowie pozwolą, Panowie nie mają trudności z czytaniem, że się wtrącę do tej arcyciekawej dyskusji. 

Pojawienie się pana Marcina podniosło poziom merytoryczny dyskusji o parę kresek.
Razem stanowicie już parę dyskutantów, o jakiej marzyłem. Będę raczej słuchał. :)

To jest jeden z kluczowych punktów.
Świetny punkt wyjścia do objaśnienia naszej filozofii.

Pan Krzysztof Bokiej zarzuca SOA brak skalowalności.
Wydaje się, że ten zarzut łatwo (5 tys. bagatela :) ) obronić, jeśli się spojrzy na sprawę właśnie z punktu widzenia analityka.
Tak się składa, że własnie skalowalność - to cecha, którą podnosiłem na zajęciach dla analityków, jako argument, za budowaniem sobie samemu własnie takiej "małej architektury".

Oczywiście nie jest to podejście w tym sensie skalowalne, że mała firma rośnie 1000% w roku, buduje kilkanaście zakładów i problemy analizy stają się nieporównywalne.
Chciałbym zobaczyć w takiej sytuacji skalowalny system. :)

Skalowalność.
Ale spójrzmy na to tak:

Sytuacja 1) 
a) Mamy w firmie o nazwie NERA - architekturę SOA w sytuacji jakiegoś "zwykłego" systemu zintegrowanego np. typu WF - MAG.
b) Zbudowaliśmy sobie hurtownię, a część danych pobieramy wprost z bazy (WF-MAG ma bazę MS SQL i bardzo dobrze zorganizowany dostęp).
c) DMA (to co innego niż tamta hurtownia, za chwilę zobaczymy, dlaczego to takie ważne!) jest zbudowana w ten sposób, że Excel widzi widoki, miary i wymiary, w Excelu są jeszcze funkcje typu Dane(miara, wymiary)
zwracające wartości dla parametrów biznesowych, zaciągane są kwerendy widoków do analizy tabelą.
d) Analityk buduje nowe raporty dokładnie tak, jak w Excelu.
Dopóki nie zmieni się struktura raportu - potrzebe są DWA KLIKNIĘCIA.
Ale nawet całkiem nowy raport, dla średniej klasy analityka, to po prostu codzienność. Bajka? Nie! Tak się pracuje w SOA.

W małej firmie wystarczy dwóch analityków w SOA i mają "raj".)
Panie Marcinie, chciałby Pan tak mieć? :)

Sytuacja 2) ZMIANA
a) Podjęto decyzję wywalenia WF-MAGA. Firma osiąga niebywały rozwój, system "mision critical"  się dusi. Kupujemy wielki SYSTEM produkcji (koniecznie) zagranicznej (przecież Polacy mają tylko sprzedawać lepsze).
Niech będzie jeszcze - kupują (prawie) świetnego BI -a.

b) Dyrektor mówi: Koniec z tymi Excelkami! Ja osobiście będę miał wszystko!

Bo mu sprzedawca naopowiadał bajek:
Oto jedna z nich.:
http://www.goldenline.pl/forum/3099900/architektura-sr...

Proszę sobie wyobrazić, że to jest dokładnie taki tekst. W całości. Razem z pomówieniami, że twórca architektury, pan X. jest ignorantem i nie zna się na informatyce, analizie, całkach i różniczkach.

c) Wdrożenie systemu SYSTEM wraz z BI ajem. Dwa lata?
Na razie wszyscy czekają. Na razie analitycy spokojnie robią sobie w starym systemie, bo w nowym nie można nawet obrotówki uzgodnić. Ale pomińmy ten dwuletni serial.
Okazuje się, że BI nie daje najważniejszych raportów na czas i ...dyrektor wreszcie zrozumiał, że dwóch najcenniejszych analityków mających raporty obcykane w Excelu - utracił. Bo biznes nie zmienił się aż tak bardzo i raporty, jakkolwiek ZNACZNIE zmienione, zachowały ogólne zasady, które w Excelu urzeczywistnia się, wraz z e zmianami, przed śniadaniem.

Stop.
Cofamy taśmę serialu.

Sytuacja 3) ZMIANA INTELIGENTNA
c1) Dyrektor trochę niepewny, z lojalności, zanim podejmie decyzję o zakupie systemu SYSTEM przeprowadza rozmowę z panem X.
"Wie Pan, duszę się, musze kupić tego SYSTEMA. Chyba się rozstaniemy. Mówią zresztą coś źle o Panu...."

d) Pan X. odpowiada ze stoickim spokojem. Najpierw ostrzega o tym serialu. To jest prawdopodobne. Dyrektor się zamyśla.
e) Potem Pan X., proponuje Dyrektorowi, żeby chociaż nie stracił dorobku analizy. Nie jest przecież pewny, może ten SYSTEM jest naprawdę taki świetny? - myśli.
Niech Pan powie tym od BI - aja, że mają dostarczyć raporty dokładnie takie, jak w systemie skoroszytów, stanowiących pakiet analiz. Inaczej nie podpisze Pan protokółu odbioru systemu. Raporty w Excelu mają być punktem odniesienia. Analitycy będą sprawdzać po swojemu.

f) Ale ja bym Panu jeszcze radził jedno. 
[uwaga - klucz]
Niech Pan pozwoli mi dostarczyć tym od BI - aja specyfikację widoków biznesowych pozwalających utworzyć NOWE DMA jako jeden z wymogów odbioru BI-aja.
Zażadamy tego też w momencie odbioru hurtowni. Inaczej nie płaci Pan ani grosza.

Ja (mówi pan X.) sporządzę nową specyfikację DMA, z nową specyfikacją pompy PS2, ale zgodną ze specyfikacją pompy PS1.
Analitycy nie zauważą różnicy. Może będzie działało trochę wolniej. :)
Jak zainstalują hurtownię, to: 
Po pierwsze będziemy mogli sami weryfikować przynajmniej część jej zawartości, porównując z naszymi raportami z WF-Maga.

Po drugie, będziemy mieli dwie DMA: dla starego i nowego systemu. 
Pan podejmie decyzję, kiedy migrujemy na nową DMA.
W dowolnej chwili, kiedy BI okaże się wystarczający, po prostu pokaże mi Pan drzwi. Rozstajemy się bez zobowiązań.

Pytanie 1, który wariant wybierze Dyrektor?
Pytanie 2, Kiedy Dyrektor pokaże drzwi panu X.?
Pytanie 3. Czy teraz widać, że architektura excelocentryczna ma sens?
Pytanie 4. Czy teraz widać zbawienne zalety DMA?
Pytanie 5: Panie Krzysztofie, czy taka skalowalność ma jakieś zalety?
Pytanie 6, Panie Marcinie, chciałby Pan tak mieć?

Koniec historyjki.

Owoce dyskusji o architekturze SOA (1)

Gorąca, a miejscami wręcz brutalna dyskusja przyniosła mi wiele inspiracji.
W dyskusji nie jestem najlepszy. Ale po wyjściu na schody, zaczynam myśleć na nowo. Dlatego powstało wiele wypowiedzi - felietonów. Przyjęte, jak najgorzej, jako "elaboraty", "woda" i określane róznymi innymi złośliwymi określeniami, moim skromnym zdaniem dodają trochę dodatkowych informacji.

Postanowiłem je stopniowo publikować.
Tam - niedocenione, tu - zobaczymy. Tam, nie mogę zbanowac nikogo, nawet ewidentnego trolla ze zdjęciem, tu będę selekcjonował, jeśli będą komentarze. Krytycznych wyglądam z tęsknotą.
Śmiecie wymiatam co jakiś czas.

Zaczynam.

Ogólne rozważania o architekturze analiz 

Tematem wątku była architektura środowiska analiz. SOA.

Jednak przyjęcie, że termin „architektura” jest rozumiany dokładnie tak samo przez wszystkich ewentualnych gości wątku chyba był nadmiernie optymistyczny. 

Wydaje mi się, że tym założeniem przynajmniej częściowo zawiniłem zbyt pochopne odejście niektórych krewkich dyskutantów, którzy mogli by wnieść jakieś cenne uwagi. 

Na przykład pan Robert Woźniak, w końcu inspirator wątku, któremu tą drogą składam podziękowanie za inspirację. Nie mogę odżałować, że złożył taką pochopną deklarację. Że już „wszystko rozumie”, że „tu nic nie ma”. No i potem „prawie” wytrwał w swojej konsekwencji.

Dlatego zacznę od pieca.

Termin 
„architektura” rozumiem, jako „zorganizowanie określonej przestrzeni do życia i działania dla CZŁOWIEKA”.

Z tego wynika, że kształtując architekturę analiz musimy wyjść od podmiotu, który działa - analizuje.

To się wiąże z pytaniem, zadanym przez jednego z dyskutantów:

Jakie konkretne wymagania realizuje owa architektura "SOA" w rozumieniu tego wątku...

Spróbujmy skorzystać z tego punktu wyjścia.

Kształtując architekturę ustalamy hierarchię elementów organizowanej przestrzeni. 

Najpierw centrum architektury. 

Gdzie jest centrum? 
Możliwie blisko punktu ciężkości albo, inaczej to określając, w pobliżu najważniejszego węzła komunikacyjnego, gdzie krzyżują się szlaki komunikacyjne i informacyjne, gromadzą najważniejsze kompetencje i skąd płyną najważniejsze informacje. Informacje, nie meldunki, bo meldunki oczywiście płyną zewsząd.

Następnie, jeżeli pomyślimy o zorganizowaniu środowiska dla tych, którzy są czynnikiem sprawczym analizy, czyli tych, którzy są jej podmiotem, również logiczne wydaje się, że powinniśmy centrum ustalić zgodnie z ich punktem widzenia.

Wreszcie, jeżeli myślimy o wzajemnym usytuowaniu elementów architektury, takich, jak:
- źródła danych i 
- platforma ich analizy 
– to ponieważ przepływ jest 
- od źródła - do platformy, 
postulat, żeby architektura sprzyjała naturalnemu ruchowi w pożądanym kierunku (a nie powodowała opór)

oraz
by to zainteresowany podmiot decydował o przedmiocie swego zainteresowania
wydaje się godny rozważenia.

Czy takie sformułowanie wymagań jest sensowne?

Przypuśćmy, przynajmniej na chwilę, odpowiedź twierdzącą i zobaczmy, co z tego wynika.

Jeśli wiemy, że główny nurt analizy odbywa się w Excelu a całą „profesjonalna informatyka” jest kosztownym, a czasem, w części, zbędnym dodatkiem, to odpowiedź, gdzie powinno znajdować się centrum, sama się narzuca.

Na platformie analitycznej, czyli w skoroszycie. 
Architekturę trzeba organizować wokół skoroszytu. 

Reszta to już tylko technika i konsekwencja tego punktu wyjścia.

Skoroszyt jest wymarzonym celem każdego analityka, który dostał nietrywialne zadanie analizy.
Proszę wybaczyć bezpośredniość. Może to zbyt radykalne, może nawet trochę przesadzone. Być może. Ale, szczerze mówiąc, szczerze wątpię.

Muszę na koniec stwierdzić jeszcze jedno. 
Właściwie przeważająca, przytłaczająca i dominująca część wypowiedzi z całą swą emocjonalną intensywnością, żarliwością i wytrwałością skupia się właśnie na podważeniu tych założeń. 

Dlatego dyskusja goni w piętkę. 
My – autorzy koncepcji - nie damy się przekonać, że jest inaczej. Wiemy swoje.
Dyskutanci – głównie rzecznicy profesjonalnej informatyki i jeden analityk, nie dadzą się przekonać, że to założenie jest słuszne. Ich wypowiedzi skupiają się na dowodzeniu, z różnym skutkiem, czasem wręcz kompromitującym autorów wypowiedzi, jakie straszne rzeczy dzieją się w Excelu, gdy opieramy się na nim, jak na centrum analizy.
Link do mojej polemiki z przykładowym zestawem takich wypowiedzi znajduje się tutaj:
http://www.goldenline.pl/forum/3099900/architektura-sr...

Być może tak jest. A nawet w wielu wypadkach, za wielu wypadkach, na pewno tak jest.
ALE JEST. Excelioza się szerzy. I działa. Na czas, zgodnie z oczekiwaniami. Czasem wręcz pracując na rachunek niesprawnego BI – aja. 

„Wyciągniesz to sobie jakoś z BI – aja”. === „Zrobisz analizę w Excelu, na podstawie przeklejek z BI- aja”

A to jest nasza propozycja, żeby BYŁO lepiej. Jak ktoś jest zainteresowany, zapraszamy.

środa, 16 stycznia 2013

Ogólne doświadczenia z dyskusji o architekturze SOA

Wątek o architekturze SOA został uhonorowany przyklejeniem na czele wpisów i znajduje się aktualnie na pierwszym miejscu wpisów grupy Business Intelligence.
Dyskusja o architekturze SOA na portalu Golden Line

Jest ponad pięćset komentarzy. Ale ta ilość nie jest najważniejsza, ponieważ poziom wpisów jest bardzo nierówny.

Jawne konta "specjalistów" nie uchroniły mnie od chamskich ataków i namolnego trollowania. Nie jest to wprawdzie trollowanie a la onet, ale poznałem inny rodzaj trolli.

Ludzie, którzy dają swoje twarze dla autora obelg i potwarzy, dyskutują poniżej poziomu i wbrew logice. Ignorując argumenty i nie rozumiejąc, co się do nich mówi.
Czy się cieszyć, że zostało się "gwiazdą" w takim dymie?

Wartością dodaną, oprócz tego dymu, który służy do utwardzania skóry, jest wiele wpisów rzeczowych, rzetelnych i kompetentnych. Krytyka jest ostra ale odnosi się ad meritum, nie ad personam.

Zmusza do myślenia i inspiruje. Pokazuje nowe pola problemowe i ujawnia inne podejście a nawet inną mentalność.

Nie tylko analitycy są na świecie. I trzeba współpracować ze specjalistami z innych dziedzin, żeby osiągnąć pozytywne wyniki.

Spodziewajcie się sprawozdania z podsumowania.
Ale w kawałkach.
"Słonia, jak powiedział generał kwatermistrzostwa armii amerykańskiej, jemy po kawałku".