Wydawnictwo Helion - pliki przykładów z wydanych książek informatycznych, jak ściągnąć?

Wpis niesponsorowany

Helion wydaje ważne dla mnie książki informatyczne (np. Power Query w Excelu i Power BI) ale nie tylko. Nie ułatwia jednak dostatecznie ściągnięcia przykładów.

Zapytałem wujka Google'a i dostałem taką radę:

Pliki z przykładami omawianymi w książce można znaleźć pod adresem: ftp://ftp.helion.pl/przyklady/angupt.zip

Ta rada zgadza się z linkiem podanym w mojej książce (z dokładnością do ściąganego pliku), ale  ... jest tak samo nieskuteczna.

Zadzwoniłem do Wydawnictwa. Po przełączeniu do Działu Sprzedaży rozmówca wyjaśnił mi myk: Trzeba skrócić link o 6(słownie sześć) pierwszych znaków: czyli wyrzucić z linku początek: ftp:// lub pisać od siódmego, czyli:

ftp.helion.pl/przyklady/{tutaj wstawić nazwę pliku z przykładami}

Po wciśnięciu klawisza Enter pojawi się adres pełny:

https://ftp.helion.pl/przyklady/{nazwa pliku z przykładami}

i okno:

Nie zadam pytania, dlaczego nie można tego napisać gdzieś na stronie Wydawnictwa. Po to są w Polsce blogerzy :)

Notabene linki w oficjalnych wydawnictwach Microsoftu działają bezbłędnie.
No cóż, musimy jeszcze poczekać. Mam nadzieję, że nie 400 lat ....
Anglicy twierdzą, że ich trawniki są takie równe, bo koszą je od 400-tu lat.

Opis ofertowy produktu SOA-Verbum

1. Definicja produktu

         Produkt SOA – Verbum jest:

a. Oprogramowaniem (aplikacją, platformą)

przeznaczonym do wspierania użytkowników SOA – Verbum
podczas analizy biznesowej, czyli:

  i. Modelowania biznesu 

 ii. Raportowania o stanie biznesu

iii. Monitorowania na bieżąco szybkozmiennych wskaźników biznesowych

b. Implementacją architektury/podejścia SOA

        kolejną spełniającą te założenia skupioną wokół:

                      i. serwera MS SQL S
                     ii.        platformy MS Excel klasy BI - do budowy modeli biznesowych 

               Spreadsheet Oriented Architecture (SOA) W. Gardziński, K. Rumiński, J. Rumiński
               Controlling i Rachunkowość Zarządcza 8, 9, 11,12 2012, 1 2013
               Linki do skrótu opisu:

               SOA: Postulaty
               SOA: Założenia architektury/podejścia
               SOA: Praktyka korporacyjna

     Pierwszą realizacją architektury/podejścia SOA był system AFIN.NET.

        c. wieloobiektowym systemem informatycznym, 

                    identyfikowanym przez nazwę SŁOWO/Verbum, czyli
                    System Ładu Obiektów Wzajemnie Oddziałujących.

2. Struktura opisu produktu SOA-Verbum

SOA – Verbum jest aplikacją rozproszoną, wieloobiektową a jako implementacja  
architektury/podejścia SOA nie tylko spełnia jej założenia.

Istnieje jeszcze jeden fundamentalny czynnik: Użytkownicy, jako społeczność SOA, 

która jest rozstrzygającym podmiotem realizacji celów produktu – wspomagania analizy biznesu.
Stąd opis produktu zawiera: 

•   opis oprogramowania (pkt.3)
•   zasad przyjętych podczas jego realizacji i eksploatacji (pkt.4)
•   środowiska społecznego użytkowników (pkt.5) 

 3.        Opis oprogramowania SOA - Verbum

Obiekty SOA dzielą się na zbudowane na platformie MS Excel, które współpracują z platformą serwerową i na te implementowane wprost na tej platformie.

Szczególny jest udział obiektów SOA zbudowanych na platformie Excel: mają one zweryfikowaną w wieloletniej praktyce wyższość nad tradycyjnymi aplikacjami bazodanowymi;

a. Obiekty SOA zbudowane na platformie MS Excel

i. Obiekty – skoroszyty Excela - Modele biznesowe

(raporty, modele biznesowe) oparte na standardowych funkcjonalnościach platformy (formuły, kwerendy, dodatki)

ii. Obiekty – skoroszyty Excela - oparte na dodatku Power Query

(zapytania w postaci gotowych szerokich tabel odświeżanych w Power Query w arkuszach Excela, wielopoziomowe modele zawierające również same definicje połączeń)

iii. Aplikacje biznesowe – skoroszyty Excela zbudowane na bazie języka VBA, z wykorzystaniem SQL, lub na bazie języka M

(1) SOA-P(sz) – szablon Excela do uruchamiania procesów zasilania bazy                       WD/DMA danymi firmowego środowiska informatycznego. 

        Procesy te są pielęgnowane przez inżyniera analityka SOA (patrz pkt. 5.c.iii.).

(2) SOA-Pq(sz) – szablon Excela z dodatkiem Power Query z wyklikanym                    zapytaniem do WD/DMA lub bezpośrednio do zasobów(danych).

        Procesy te są pielęgnowane przez starszego analityka SOA (patrz pkt. 5.c.ii.).

(3) SOA-R - szablon Excela do uruchamiania zapytań bezpośrednich do Zasobów            danych firmowego środowiska informatycznego.

        Procesy te są pielęgnowane przez starszego analityka SOA (patrz pkt. 5.c.ii.).

(4) SOA-A – szablon Excela zawierający model biznesowy ze specjalizowanymi            arkuszowymi funkcjami biznesowymi (Platforma VBA lub C#), mającymi                bezpośredni dostęp do bazy danych (WD/DMA).

        Procesy te są pielęgnowane przez starszego analityka SOA (patrz pkt. 5.c.ii.).

iv. Obiekty SOA zbudowane na innych platformach

(1) Serwerowa baza danych WD/DMA – hurtownia analityka

stanowiąca pośrednią Warstwę Danych między platformą raportującą Excel a zasobami (danych) firmy, zawierająca Dane do Raportów (DdR © KR) w postaci szerokiej tabeli. Są to dane tzw. klasy pppw

czyli dane pełne, przydatne, punktualne i wiarygodne.

Dane te stanowią widok (wszystkich) Danych do (wszystkich) Raportów

dla grupy użytkowników SOA (zespołu SOA)

(2) Procesy tradycyjnej informatyki bazodanowej

procesy ETL, IS, serwerowe procedury wbudowane na platformie serwerowej, klasyczne aplikacje informatyczne pełniące funkcje pomocnicze (np. śledzenie przebiegu procesów bazodanowych)

4. Zasady SOA

Konsekwentne stosowanie zasad architektury/podejścia SOA prowadzi do przełomowych efektów

a. Zasada 1: MS Excel jest strategicznym narzędziem modelowania biznesu

platformą szybkiego tworzenia procesów raportowania i monitorowania biznesu.

Zasada 1 daje przygotowanym odpowiednio użytkownikom swobodę modelowania i stwarza im bezkonkurencyjne możliwości w porównaniu z metodami tradycyjnej informatyki bazodanowej oraz narzędzi raportujących klasy BI.

i. Platforma budowy raportów - MS Excel

gwarantuje, jako wiodący standard budowy raportów, zaopatrzona w wyspecjalizowane dodatki, obiekty, szablony, użytkowana zgodnie z korporacyjną polityką informatyczną, jest źródłem:

• kluczowych raportów zarządczych, 

• platformą budowy modeli i wspierania przez nich raportowania i monitorowania biznesu

Platforma MS Excel staje się przyjazna dla przeszkolonego odpowiednio użytkownika - ułatwia modelowanie biznesu, elastyczna (model biznesu jest łatwy do modyfikacji, bezkonkurencyjnie łatwa do parametryzacji) oraz 

integruje się bez przeszkód z firmowym środowiskiem informatycznym.

 

Integracja produktu

(1) MS Excel jest zintegrowany z firmowym środowiskiem informatycznym (CIT – Corporate IT) w architekturze SOA. Środowisko integrujące Excela z CIT nazywamy środowiskiem SOA

Cel integracji - Przezroczysty dostęp do danych dla kluczowych raportów

Sposób integracji – poprzez 2 klasy obiektów: SOA-P i SOA-R (por. pkt. 3.a.)

Najlepsze wyniki uzyskuje się zwłaszcza tam, gdzie:

(a) Excel już jest stosowany, użytkownicy go dobrze znają, ale obróbka informacji jest pracochłonna a mechanizmy procesów są zmienne. 

(b) Automatyzacja wymaga ścisłej współpracy z użytkownikiem a klasyczne platformy i metodyki zawodzą i dawno odpowiedzialni za raportowanie biznesu specjaliści doszli do wniosku, że nie ma alternatywy dla ręcznej pracy w Excelu. 

Wdrażanie produktu

(2) Jak wdrażać platformę MS Excel do modelowania biznesu?

(a) Znaleźć komórki organizacyjne spełniające warunki z pkt.(1)(a),(b)

(b) W rozpoznanych w ten sposób miejscach organizacji stworzyć informatyczne środowisko zorientowane na skoroszyt (Architekturę (środowiska) Zorientowaną na Skoroszyt - (Spreadsheet Oriented Architecture - SOA)

(c) Uznać podejście SOA (Spreadsheet Oriented Approach), wypracowaną w dyskusjach oferenta i zainteresowanych użytkowników Excela podczas wdrożeń, jako oryginalną, polską metodykę projektowania procesów - Agile.

(d) Dać rozwinąć się temu podejściu, zdobyć nowe doświadczenia w praktyce dużej organizacji i dać jej szansę uzyskania korzyści i przewagi konkurencyjnej.

Jeszcze kilka lat temu ta zasada była „kontrowersyjna” i stanowczo odrzucana przez tradycyjną informatykę bazodanową w ogólności a klasy BI w szczególności. To już przeszłość. 

b. Zasada 2: Budowy obiektów sterujących serwerem MS SQL ...

na platformie MS  Excel

Zasada 2 daje bezkonkurencyjne korzyści w stosunku do tradycyjnej informatyki bazodanowej: przyjazność i elastyczność, możliwość łatwej parametryzacji procesów sterowania oraz 

 

szansę analitykom i inżynierom analitykom SOA na sprawowanie kontroli nad procesami bazodanowymi, nawet, jeśli nie są oni autorami tych procesów. To jest następna zasada:

c.    Zasada 3: pielęgnacji przekazanych do eksploatacji procesów bazodanowych

5. Środowisko społeczne SOA

czyli użytkownicy SOA - branżowi specjaliści merytoryczni(bsm), ang. information workers (iw) - użytkownicy Excela i wspomagający ich informatycy, tworzą razem unikalną społeczność – kluczowy podmiot sterowania biznesem. Dzięki powszechnej znajomości standardu przemysłowego – platformy MS Excel, używanie jej przez odpowiednio przygotowane zespoły użytkowników daje ogromną przewagę nad podejściem stosowanym przez tradycyjną informatykę bazodanową.

Właśnie środowisko społeczne SOA jest wyróżnikiem podejścia SOA. Jest ono znamienne tym, że ciężar rozumienia biznesu oraz jego modelowania a nawet, w szczególnych wypadkach, implementacji modelu - spoczywa na użytkownikach SOA, wspomaganych przez informatyków. 

Środowisko społeczne SOA jest zorganizowane w dwóch wymiarach:

a. Wymiar biznesowy

Zespoły skupiające użytkowników o wspólnych zainteresowaniach i obowiązkach modelowania, raportowania i monitorowania biznesu. Kompetencje biznesowe – to:

i. Pogłębione rozumienie mechanizmów biznesu

oraz gotowość do ciągłego rozwoju zawodowego (aby pogłębiać to rozumienie),

ii. Umiejętności modelowania biznesu (na platformie Excela np. formuły, kwerendy)

w tym:

umiejętność dobierania różnych rodzajów funkcjonalności platformy - standardowe (formuły, kwerendy, Power Query) i specyficzne, zaawansowane (język VBA, SQL, Power BI) – stosownie do ich przydatności dla realizacji celów biznesowych

iii. Współpraca z informatykami 

wspierającymi realizację celów biznesowych

formułowanie w kategoriach biznesowych bardziej złożonych zadań dla informatyków (w tym projektowania postaci danych do raportu),
rozliczania ich z wyników (oceniając ich według stopnia realizacji celów biznesowych)

zarówno na etapie tworzenia nowych aplikacji (programowanie, generowanie, definiowanie, kodowanie, testowanie), jak i na etapie ich eksploatacji(pielęgnacja).

                iv.  Umiejętność pracy zespołowej:

z podziałem ról – na

(1) użytkowników (analizy standardowe, poprzedzone uruchomieniem wcześniej procesu przygotowanego przez developera lub bardziej kompetentnych kolegów) 

Przykładowo proces taki utworzy zestaw konkretnych tabel, potrzebnych do ręcznej, biznesowej analizy), 

(2) analityków (model biznesu przy pomocy formuł), 

(3) starszych analityków (platforma Excel tworzenia i parametryzacji obiektów przeznaczonych do analizy biznesowej (przy pomocy VBA), z funkcjami Drill – Down, SQL i Power Query), kwerend kontekstowych oraz do monitorowania biznesu, 

(4) inżynierów – analityków (tworzenia prostszych procesów, pielęgnacji i parametryzacji gotowych procesów realizujących cele biznesowe)

b. Wymiar informatyczny/technologiczny

Dotyczy zróżnicowanych kompetencji informatycznych, standaryzowanych zgodnie z wieloletnimi doświadczeniami ich kształtowania podczas Studiów Podyplomowych na Uniwersytecie Wrocławskim.

                    Link do strony Studiów: [1] http://www.exc.ue.wroc.pl/index.html 

Odpowiadają im role użytkowników SOA (młodszych analityków), analityków SOA, starszych analityków SOA, oraz inżynierów analityków SOA.

Krytycznym punktem koncepcji jest system kształtowania kompetencji użytkowników SOA w ich różnych rolach. Kompetencje te wymagają (ciągle doskonalonej) umiejętności korzystania ze zróżnicowanych funkcjonalności produktu.

i. Proces szkolenia

opiera się na uproszczonym, trójczłonowym modelu ról dla społeczności użytkowników:

(1) Dostawcy informatyki, (2) inżynierowie analitycy, starsi analitycy 

 SOA, (3) użytkownicy SOA

                  ii. Metoda szkolenia

Studia Podyplomowe dla inżynierów analityków, kursy specjalistyczne i warsztaty  wspólnego rozwiązywania konkretnych problemów biznesowych dla pozostałych. Wszyscy członkowie społeczności użytkowników SOA

to - analitycy o dodatkowych kwalifikacjach informatycznych.

To oni są odpowiedzialni za wsparcie procesów biznesowych i 

Warstwę pośrednią Danych (WD w nomenklaturze SOA   Verbum),

Data Mart for Analysis (DMA w nomenklaturze architektury/podejścia SOA).

c. Opis współpracy ról SOA przy modelowaniu biznesu

Szczegóły umiejętności poszczególnych ról opisano w podpunktach a. i b. niniejszego  punktu 5. Model "trzech ról" jest elastyczny, ułatwia reagowanie na zmiany wymuszane przez dynamikę biznesu.

i. analityk SOA

 na bieżąco monitoruje zgodność modelu z wymogami biznesu i modyfikuje model

ii. starszy analityk SOA 

posiada kwalifikacja analityka i dodatkowo potrafi pielęgnować i parametryzować zapytania SQL do baz danych oraz gotowe procesy aktualizacji bazy WD/DMA

iii. inżynier analityk SOA 

posiada kwalifikacje starszego analityka a ponadto 

utrzymuje zgodność opisu modelu na wymaganym poziomie - we własnym zakresie (potrafi modyfikować procesy aktualizacji bazy WD) lub, w bardziej skomplikowanych wypadkach - zleca to deweloperowi i rozlicza go z wyników.

Kompetencje informatyczne inżyniera analityka SOA rosną zgodnie z potrzebami środowiska SOA i biznesu.

Środowisko SOA rozwija się w takt potrzeb biznesu.

6. Schemat współpracy użytkowników SOA 

  podczas analizy biznesu pokazuje slajd.

            

Środowisko informatyczne SOA (wraz z przykładowymi obiektami zbudowanymi na platformie MS Excel) jest reprezentowane przez lupę w dolnym, lewym rogu. 

Symbol   - oznacza "silnik" rozwiązania - aplikacja - (rozproszony system użytkowy) oprogramowanie umieszczone w obiektach SOA (VBA), oprogramowanie  serwera MS SQL S (T-SQL) oraz oprogramowanie stacji roboczych użytkowników SOA (C#) (por. pkt. 3).

 

Procesy zasilania pośredniej Warstwy Danych WD/DMA są reprezentowane przez niebieską strzałkę.

Członkowie społeczności SOA są tu przedstawieni w trzech zasadniczych rolach: 

U - Użytkownik, A – Analityk, I – Inżynier analityk.

Komunikują się oni ze środowiskiem poprzez odpowiednie obiekty, zgodne ze specyfiką pracy każdego z użytkowników.

a. Użytkownik SOA

(np. menadżer lub jego asystent) skupia się na analizie biznesowej korzystając z przygotowanych dla niego obiektów-szablonów/aplikacji.

Odświeża raporty korzystając z Danych do Raportu zawartych w WD (gruba strzałka skierowana do raportu) i ustawiając ich parametry (cienka strzałka skierowana do Danych do Raportu).

b. Analityk SOA

jest odpowiedzialny za stworzenie prawidłowego raportu na podstawie zawartości WD. W wypadku zmian w potrzebach biznesowych modyfikuje raport. W pozostałym czasie troszczy się o jego kompletność i wiarygodność. Symbolizują to strzałki w obie strony o równej grubości.

c. Inżynier Analityk SOA

jest odpowiedzialny z kolei za utrzymanie warstwy WD w stanie aktualności, kompletności i wiarygodności.

Jego zadaniem jest analiza zawartości baz systemu CIT, wprowadzanie zmian procesach bazodanowych zdefiniowanych w specjalnych obiektach SOA-P na platformie MS Excel (VBA, C#), współpracujących z platformą serwerową MS SQL S, 

co razem zapewnia elastyczność i przyjazność narzędzia i odpowiedni poziom bezpieczeństwa. Strzałki pokazują, że jego obszar zainteresowań obejmuje struktura, poprawność, kompletność i aktualność WD w tym analiza zasobów i proces aktualizacji.

7. Korporacyjny Ład Informatyczny:
        integracja i bezpieczeństwo

Przez oparcie się na platformie serwerowej MS SQL, uzyskujemy w ramach polityki informatycznej firmy - korporacyjny ład informatyczny.

a. Obiekty SOA – zapewniają bezpieczeństwo i poufność danych

        Łącząc się z serwerem MS SQL uzyskują pozwolenie:

        i. na dostęp do danych 
        ii. na uruchomienie wszystkich funkcji istotnych

ze względu na przestrzeganie korporacyjnej polityki bezpieczeństwa

b. Środowisko SOA jest:

 przyjazne (1), zintegrowane (2) z firmowym środowiskiem informatycznym i elastyczne (3),

c. Korporacyjny ład informatyczny.

Przez wdrożenie tych funkcjonalności, w ramach polityki informatycznej firmy -realizujemy korporacyjny ład informatyczny oraz możliwość jego weryfikacji w ramach typowej procedury compliance. (Dwa linki do stron omawiających zagadnienie realizacji compliance w praktyce polskich firm:

  Compliance Wikipedia; Compliance prawo.pl)

Środowisko SOA.Gdzie jest centrum architektury SOA?

W 2017 roku architektura SOA osiągnęła nowy poziom rozwoju.

Celem tego wpisu nie są wcale problemy architektury informatycznych systemów, tylko pojęcie praktyczne: środowisko SOA. Ale zanim je omówię, muszę wyjść od konkretu. Od konkretnego artefaktu, który działa i ma referencje.

Co stoi za tym rozwiązaniem, które realizuje procesy, ocenione, jako "model funkcjonalny niemożliwy do osiągnięcia w ramach dotychczasowej współpracy z uznanymi dostawcami"?
Prostota! Standardowe produkty informatyczne  zorganizowane, dzięki unikalnemu podejściu, w środowisko SOA. Wrócimy do tego, najpierw krótki opis architektoniczny.

Centralnym obiektem, ogniskującym wokół siebie całe środowisko SOA  jest wirtualny serwer WS oraz  MS SQL  Serwer.
Baza DMA (a właściwie klasa baz danych DMA z przeznaczeniem dla różnych zespołów analityków, których dzisiaj nazywamy terminem branżowych specjalistów merytorycznych) zyskała profesjonalną platformę, ściśle zintegrowaną z korporacyjną infrastrukturą informatyczną (CIT - corporate IT).

Przypominam sobie gorące dyskusje o architekturze SOA, których echa starałem się na tym blogu rejestrować. Jednym z wątków była kwestia centrum.
Myśmy stawiali w centrum - arkusz kalkulacyjny, byliśmy zorientowani na skoroszyt - (spreadsheet-oriented), byliśmy - excelocentryczni.
Pukano się czoło. Ale całkowitej zgody po drugiej stronie, co do innego umiejscowienia centrum, nie było. Jedni stawiali w centrum biznes (cokolwiek to znaczy), inni - hurtownię danych, które stanowią obraz biznesu.

Jak wiele dzisiejszych dyskusji dyskutanci pozostali przy swoich zdaniach, a raczej przy przekonaniu o swojej wyższości merytorycznej, moralnej i politycznej. Ale ... po latach coraz bardziej doceniam to zderzenie różnych punktów widzenia, doświadczeń zawodowych a nawet różnych poziomów kultury dyskusji.
W pewnym sensie,  ... wszyscy mieli rację. A więc każdy wniósł coś do obrazu problemów przez nas postawionych. Ścierały się różne punkty widzenia. A teraz, na spokojnie?

Jeśli postawimy pytanie nie o centrum geometryczne lecz - o centrum uwagi, to wówczas, w naszym centrum uwagi znajdował się arkusz kalkulacyjny. I nadal się znajduje.

Ponieważ jednak architektura SOA została już zrealizowana w praktyce, uzyskała na kolejnych stadiach rozwoju (zgodnie z przyrostowym podejściem Scrum) nowe zastosowania, akceptację użytkowników i referencje Zarządu, a platforma Excel jest w niej oczywistą dominantą, można teraz w centrum uwagi umieścić również coś innego. Zająć się pełniejszą integracją środowiska SOA z CIT i jego sterowalnością, czyli czymś, co tygrysy z IT lubią najbardziej.

Oto schemat środowiska SOA.
W jego centrum jest coś innego niż arkusz: hurtownia DMA. Ale na zewnątrz znajdują się różne obiekty SOA, które razem tworzą obwód, coś w rodzaju centrum, które przyciąga uwagę.

                      Schemat architektury środowiska SOA

Obiekty - szablony Excela:

                     SOA-P platforma procesów bazodanowych

                     SOA-A szablon modeli analitycznych z bezpośrednim dostępem do DMA

                     SOA-M szablon platformy monitorującej z możliwością zapisu do DMA

                     SOA-R szablon parametryzowanych raportów z dostępem do DMA

                     SOA-I szablon zabezpieczający, sterujący i integrujący środowisko SOA

 CIT-SOA część korporacyjnej infrastruktury informatycznej, do której środowisko SOA ma dostęp

DMA - klasa wydziałowych baz danych, do których obiekty SOA mają dostęp zgodnie z polityką bezpieczeństwa

Przejdźmy jednak do pointy - do skupienia uwagi na całości, niezależnie, co jest w schemacie w centrum, a co na obwodzie.

Realizacja architektury obiektów informatycznych - obiektów SOA - tworzy środowisko SOA, czyli przestrzeń do działania dla specjalistów merytorycznych, użytkowników Excela.

Każdy użytkownik SOA  ma się czuć w nim dobrze, odbierać je, jako przyjazne. Mieć swobodny dostęp do danych, potrzebnych do sporządzenia raportów. Łatwość wykonania obowiązkowych operacji aktualizacyjnych i uzupełniających.

Środowisko SOA powinno być elastyczne, czyli łatwo poddające się modyfikacjom, stabilne i odporne na spiętrzenia napływających danych.

Środowisko - to punkt widzenia użytkownika. To, jak on je odbiera podczas poruszania się w nim, decyduje o jego jakości. Kierownictwo ocenia efekty działania jego funkcji a on - łatwość i pewność obsługi.

Architektura kształtująca go - sprawdziła się w działaniu.  Proszę przeczytać referencje.

Referencje dla architektury i podejścia SOA

Od 2012 roku prowadziłem na swoim blogu akcję promowania architektury i podejścia SOA, której koncepcję opublikowaliśmy we trzech , współtwórcą tej architektury, Wojciechem Gardzińskim oraz Jakubem Rumińskim(zbieżność nazwisk nie całkiem przypadkowa, ale chyba nie przynosząca mi wstydu), analitykiem i konsultantem międzynarodowych korporacji, który ją weryfikował i uwiarygadniał z punktu widzenia realiów światowego biznesu.

Teraz czas na innego rodzaju uwiarygodnienie.

Architektura i podejście SOA nie jest tylko nową, oryginalną koncepcją.
Jest produktem komercyjnym, posiadającym pierwsze, ale poważne i sprawdzone na przestrzeni co najmniej dwóch lat, referencje biznesowe w dużej instytucji publicznej.
Podaję jednak referencje z trzech kolejnych lat.
Wyłania się z nich w sposób dla nieco zaskakujący, konsekwentna linia rozwojowa podejścia SOA.
To właściwie logiczne: Wzięła się nie z "nagłego olśnienia".
Wyłoniła się, jako logiczny (i nieubłagany) skutek naszych doświadczeń, potwierdzonych doświadczeniami innych.
Także tych, pracujących w najbardziej "prestiżowych" (cokolwiek to znaczy) firmach.

Oto one:

Referencje 2014 (Epoka przed SOA)

Referencje za rok 2015 strona 1

Referencje za rok 2015 strona 2

Referencje za rok 2016 strona 1

Referencje za rok 2016 strona 2

Referencje 2016 - skrócone do jednej strony - na moją pokorną prośbę.

Codd'a 12 zasad zarządzania bazą danych dla OLAPu

(Codd's paper)

Jako glossa do nieudanej ale burzliwej "dyskusji" o tym, czym jest OLAP i czy tabela przestawna i OLAP to inne bajki, zamieszczam podstawowy tekst tego Ojca Założyciela dzisiejszej technologii bazodanowej Edgara Franka "Teda" Codd'a.

W tekście wytłuszczam te fragmenty, które bezpośrednio odnoszą się do przedmiotu sporu.

W komentarzach (kursywą) wyjaśniam, jakie wypowiedzi mojego adwersarza i moje mają tu zastosowanie.

Dyskusja ta ma charakter nieco abstrakcyjny, ale dla genezy dzisiejszych "problemów z analizą biznesową", ma fundamentalne znaczenie. Moim skromnym zdaniem.

Tłumaczenie zasad z angielskiego tekstu - własne.

Zaczynam:

W 1985 Edgar F. Codd napisał artykuł, określający zasady dla Systemów Zarządzania Relacyjnymi Bazami Danych (RDBMS systemów zarządzania), które zrewolucjonizowały branżę IT.
Pamiętam, jak czytałem jeszcze wcześniejsze teksty Codda, wówczas pracownika IBM, w materiałach szkoleniowych tej firmy, jeszcze nie zdając sobie sprawy z ich znaczenia, w czytelni Ośrodka Obliczeniowego MPM na Kruczej, w Warszawie, na początku lat osiemdziesiątych. Stała tam najnowocześniejsza w kraju maszyna IBM 370, o gigantycznej pamięci operacyjnej 1 MB. Na ogromnych (fizycznie) dyskach stumegabajtowych można było tę pamięć "wirtualnie" rozszerzyć. Rozwiązywaliśmy na tej  maszynie układy równań o kilkudziesięciu tysiącach niewiadomych. A jednocześnie - można by powiedzieć, że byłem świadkiem narodzin współczesnej informatyki bazodanowej, czytając pierwsze koncepcje Codd'a - języka SQL i relacyjnych baz danych.

W 1993 roku, Codd wraz z kolegami, opracował 12 zasad, które definiują OLAP (Online Analytical Processing), technologię oprogramowania i przetwarzania danych, która pozwala na konsolidację i analizę danych w wielowymiarowej przestrzeni.

Oto 12 postulatów Codda:

(podkreślenia i komentarze - KR)

1.    Wielowymiarowy, poglądowy - Widok

Analitycy muszą mieć możliwość  ujrzenia przedsiębiorstwa jako obiektu z natury wielowymiarowego.

 - na przykład, zyski mogą być prezentowane dla regionu, produktu, okresu czasu, lub scenariusza (takiego jak rzeczywisty, planowany lub prognozowany). Wielowymiarowe modele danych umożliwiają proste, bardziej intuicyjne manipulowanie danymi przez użytkowników, w tym - "krojenie w plastry i kostki".

2.    Przezroczystość

Niezależnie od tego, czy OLAP stanowi część standardowego arkusza kalkulacyjnego, czy pakietu graficznego, powinno to być przezroczyste dla użytkownika. OLAP powinien być częścią struktury systemów otwartych, które mogą być osadzone w każdym miejscu pożądanym przez użytkownika, bez szkodliwego wpływu na funkcjonalność narzędzia - gospodarza. Użytkownik nie powinien być nawet świadom, z jakich źródeł danych korzystały narzędzia OLAP. Np. czy były one jednorodne czy niejednorodne (co do formatu i platformy).
(podkreślenia KR)

 (1) To kluczowe zdania dla przedmiotu naszej dyskusji: 

- "Ojciec Założyciel" uważa za oczywiste, że tabela przestawna - to OLAP. Mało tego, uważa on, że OLAP jest (może być) wręcz częścią customizowanego skoroszytu. Sceptyków odsyłam do oryginalnego tekstu (Punkt 2).
- Mój adwersarz, że to całkiem inna bajka.

I mimo wielkiego wysiłku, nie potrafiłem go przekonać. Może pan Codd go przekona?

3.    Dostępność (Accessibility)

W celu uzyskania dostępu do heterogenicznych źródeł danych, przeprowadzenia wszelkich niezbędnych do konwersji i przedstawienie spójnego widoku dla użytkownika, narzędzia OLAP powinny mieć własną strukturę logiczną. Narzędzie (nie użytkownik) powinno samo troszczyć się, skąd pochodzą dane fizyczne.

Ten postulat systemy raportujące starają się realizować, ale zazdrośnie strzegą dostępu do ujednoliconych danych przez tabelę przestawną znajdującą się w Excelu. Ten link, punkt 3 artykułu

4.    Stabilna wydajność raportowania

Wydajność narzędzia OLAP nie powinna ucierpieć  znacząco, w miarę zwiększania się liczby wymiarów.

5.    Architektura Klient / serwer

Komponent serwera narzędzi OLAP powinien być wystarczająco inteligentny, aby różni klienci mogli być dołączeni przy minimalnym wysiłku. Serwer powinien być zdolny do odwzorowania i konsolidacji danych dla różnych baz danych. 

Czy 5 -ty postulat Codda został zrealizowany? Właśnie cały mój wywód, do którego nawiązuje uwaga (2) (patrz ten artykuł, zwłaszcza rozdział "Praktyka z wczoraj i co się z nią stało") udowadnia, że jest z tym nienajlepiej.

6.    Generyczna (uwzględniająca realizację, realistyczna) struktura wymiarów

Każdy wymiar danych powinien być równoważny  do jego struktury i zdolności operacyjnych.

(Każdy wymiar danych powinien mieć przemyślaną strukturę i możliwości operacyjne jej realizacji.)

7.    Dynamiczna obsługa rzadkich macierzy

Fizyczna struktura serwera OLAP powinna zapewniać optymalną obsługę macierzy rzadkich.

8.    Wsparcie dla wielu użytkowników

Narzędzia OLAP muszą zapewnić jednoczesną aktualizację i dostęp (do odczytu), integralność i bezpieczeństwo.

9.    Operacje cross-wymiarowe

Narzędzia obliczeniowe muszą umożliwić obliczenie i manipulację danych na dowolnej liczbie wymiarów danych i nie mogą ograniczać żadnych relacji między elementami danych.

10.                   Intuicyjna obsługa danych

Manipulacja danymi znajdującymi się na ścieżce konsolidacji, takie jak drill-down lub agregowanie, powinny być realizowane poprzez bezpośrednie działanie na komórki modelu analitycznego, a nie poprzez korzystanie z menu lub poprzez skomplikowaną nawigację po całym interfejsie użytkownika.

11.                   Elastyczne raportowanie

Funkcjonalność raportowania powinna zapewnić informacje w formie wymaganej przez użytkownika

Przez elastyczne raportowanie producenci BI rozumieją swoje raporty, których zmiana, aktualizacja, poprawka  wymaga najczęściej oddzielnego projektu informatycznego. Jeśli to jest elastyczne, to niewiele rzeczy jest nieelastycznych. Omawiałem to w przywołanym wyżej tekście, rozdział "Konsekwencje dziwnego rozwoju analizy". 

12.                   Nieograniczone Wymiary i poziomy agregacji.

Dla wszystkich zadań i celów - Liczba obsługiwanych wymiarów danych powinna być nieograniczona. Każdy wymiar  ogólny powinien umożliwić w zasadzie nieograniczoną liczbę poziomów agregacji zdefiniowanych przez użytkownika w obrębie danej ścieżki konsolidacji.

Na tle tych archaicznych już, zdawałoby się postulatów "ojca założyciela", współczesny analityk może sam sobie sobie odpowiedzieć, czy pracuje w środowisku analiz, które wyobrażał sobie dwadzieścia lat temu mister Codd z kolegami, czy może jednak coś się nie udało?
Stąd właśnie nasza koncepcja innej architektury - SOA.

Architektura SOA, Excel, AFIN. Kto jest beneficjentem a kto ofiarą?

Geneza wpisu

Zamieściłem pewną notkę¹ (wszystkie przypisy w komentarzach) na temat architektury SOA, ilustrowaną przykładem z użyciem AFINa.

Otrzymałem krytyczny komentarz², który musiałem przeredagować.

1) Wiem, że zajmuje się Pan „misją” szkolenia „nowego analityka”. Uczy go Pan prowadzenia analiz w Excelu w architekturze SOA.

2) Jednak, nawet, jeśli założymy tu jakiś ślad racjonalności (przypuśćmy tak dla celów mojego pytania), zupełnie nie rozumiem, dlaczego mówi pan o AFIN-ie w aspekcie architektury SOA.
Dopiero, pana zdaniem, AFIN zapewnia praktyczne działanie architektury SOA?

3) Czyżby prowadzenie analiz w Excelu w tej architekturze było praktycznie niemożliwe?

Koniec tego niby cytatu. 

Tekst powyżej -  to niezamawiana usługa tłumaczenia z języka trolli na polski.

Można ze zdumieniem stwierdzić, że dopiero taka redakcja wypowiedzi ujawnia jej głęboki sens. To ciekawe doświadczenie i nauka, żeby najuważniej słuchać „wrogów’. Nawet, jak się gruntownie mylą. Chyba, że tylko toczą pianę.

Spróbujmy więc na to całkiem uprawnione i ciekawe pytanie – odpowiedzieć.

Czego uczymy na Studiach

Rzeczywiście od pewnego czasu realizujemy, z nadspodziewanym powodzeniem, misję wyszkolenia analityka o nieco rozszerzonych kompetencjach.

Pokazujemy, jak budować model analityczny w prawidłowo ukształtowanym środowisku analiz:

a)    Model ten budujemy zawsze od zera, to znaczy z użyciem standardowych aplikacji biurowych (głównie Excela i jego platformy budowy aplikacji VBA),

b)    Środowisko analiz pokazujemy, jako ściśle zintegrowane ze środowiskiem informatycznym,

c)    To podejście ma równie efektywne, a nawet jeszcze bardziej efektywne zastosowanie w warunkach dużych firm

Oto link do doniesień na ten temat (tam są dalsze linki).

Z uwagi na to, że koncepcja SOA wprawdzie powstawała na przestrzeni wielu lat, ale dojrzała stosunkowo niedawno, uprawnione jest pytanie, czy sprawdza się w praktyce? Czy można pracować w Excelu w architekturze SOA?  ³

Jakie są doświadczenia z nauczania o architekturze SOA?

Są to doświadczenia podobne do naszych innych, wieloletnich doświadczeń szkoleniowych.

Najważniejsze doświadczenie jest takie:

Nikt z uczestników, a mieliśmy w tej rzeszy już wielu naprawdę wybitnie kompetentnych analityków - użytkowników Excela, nie uważał, że program zawiera „znane, banalne rzeczy”, albo uczenie „niepotrzebnych umiejętności” i głosi jakieś "kretyńskie idee", nie mające zastosowania w praktyce analizy w wielkich firmach.

WPROST przeciwnie.  Anonimowe oceny były wysokie. 

A co najważniejsze -

- Im większe kompetencje posiadał student, tym szybciej chwytał istotę naszego podejścia i tym szybciej potrafił to podejście zastosować w praktyce.

Dobiegająca już prawie setki, rzesza uczestników Studiów, w dużej części – doświadczonych analityków z międzynarodowych korporacji, zaawansowanych  użytkowników Excela, wydobywających się z odmętów „exceliozy”, przeklejek i nieśmiertelnej „kontrolki” - przycisku „Export do Excela”, chwyta okazję w lot, nabywa nowych umiejętności, poprawia swoje służbowe raporty, przysyła pytania po zajęciach, które wskazują na chęć natychmiastowego wykorzystania umiejętności. Najlepsi absolwenci są zdolni kształtować samodzielnie swoje środowisko analiz. I robią to.

Link do notki o publikacji w CRiZ.4

A inni nasi studenci? Niektórzy z nich, zaczynają być wymagającymi partnerami specjalistów IT. I o wiele więcej.

Co z tych doświadczeń wynika?

Najważniejsze doświadczenie jest takie, że być może po raz pierwszy w naszej praktyce, zajęcia, które jest nam dane prowadzić, zawierają w jednym kawałku - pewną masę krytyczną wiedzy i umiejętności, pozwalające wykształcić profesjonalnego analityka. Kogoś w rodzaju „inżyniera analiz”. I to zmienia powoli sytuację. Powiedzmy coś krótko o tych kompetencjach.

Kompetencje, jakie nabywa analityk na Studiach

Po pierwsze – kompetencje standardowe.

Każdy analityk musi potrafić poprawnie stworzyć „wieczny raport”, nie wymagający żmudnych przeklejek i poprawek w przyszłym tygodniu. Powinno wystarczyć kilka kliknięć dla odświeżenia danych i przeliczenia formuł. 
To jest ten fragment jego kompetencji, który dotyczy jego samego i nikogo więcej. Standardowych kompetencji analityka. Bez nich nie potrafi on wykorzystać żadnej najlepszej architektury, ani SOA ani tradycyjnej.

„Inżynier analityk” potrafi z kolei współpracować ze specjalistą IT i stawiać mu konkretne zadania. Zadania ułatwiające pracę jemu, a nie informatykowi. 

Mówimy - nie - dla dostarczania mu „węgla zruconego na podwórko”, czyli „eksportów”, do żmudnej, codziennej obróbki.

Nie – dla filozofii „ochłapu” – uzależniającej od ciągłych „eksportów”.

Mówimy - tak – dla tworzenia „bijących źródeł danych”. Czyli dla filozofii służebnej. Źródło ma być zawsze na usługi analityka.

„Inżynier analityk” potrafi wreszcie, jeśli nie ma innego wyjścia, jak w przypadku przywołanego autora publikacji, ale nie tylko jego, sam stworzyć sobie warstwę danych, żywe, „bijące źródła danych” dla analizy.

Potrafi sam zorganizować sobie środowisko analiz. Z pomocą kompetentnych informatyków. Lub bez niej.

Oto opis kompetencji analityka, którego kształcimy na Studiach.

Powiedzmy wyraźnie: Ta architektura, architektura SOA, wymaga więc ponadprzeciętnego profesjonalizmu użytkowników Excela.
Ponadprzeciętnych predyspozycji. 
Wymaga różnych kompetencji - budowania parametryzowanych formuł, kwerend, skonstruowanych na potrzeby tych formuł (a nie gigabajtów danych w "toolach"), podstaw SQLa pisanego w różnych dialektach tego języka, zależnych od różnorodnych źródeł danych.

To jednak nie wszystko. Technika nie wystarczy.
Wyuczony techniki power-user o ciasnym umyśle - to tylko sprawny rzemieślnik pozbawiony inicjatywy i zasklepiony w swoich stereotypach. 
Inżynier - analityk ma ducha innowacyjności, asertywności i inicjatywy, ma rozeznanie potrzeb analizy w skali korporacji i umiejętności uzyskania niestandardowych uprawnień.

Dlaczego tak musi być i kto jest temu "winien"? To oczywiście już „inna bajka”. Ale zróbmy i do niej odniesienie.

My, promotorzy tej koncepcji – oskarżamy o ten stan rzeczy - profesjonalną informatykę odpowiedzialną za kształtowanie środowiska analiz. Nie tylko producentów BI-jów. Oskarżamy obowiązujący paradygmat analizy, zwłaszcza w wielkich korporacjach.

Obowiązujący ciągle paradygmat profesjonalnej informatyki (Opis)

„Nie ma prawdziwego życia poza BI –jem.”

Profesjonalna analiza powinna się odbywać w BI-aju.  Wszystkie analizy w Excelu to anomalia, wyjątek potwierdzający regułę, domena power-userów. Przyczyną konieczności jej zastosowania jest prawie zawsze błędna procedura wdrożenia BI-aja, źle nadane uprawnienia, braki w wyszkoleniu z funkcjonalności BI-aja, co powoduje konieczność chodzenia na skróty. ⁵

Koniec opisu paradygmatu.

W pewnym sensie analityk jest sam

Powyższy paradygmat jest szkodliwym złudzeniem, przyczyną realnych strat dla firm, które mu hołdują i frustracji analityków, zepchniętych do getta "exceliozy".

Analityk , zwłaszcza w dużej firmie, posiadającej dział IT i jeszcze na dodatek „oficjalne narzędzie analizy” czyli jakiegoś Bi – aja, używając zwrotu pewnego mojego komentatora o niewyparzonym języku: „żyje w równoległej rzeczywistości". 
Z tą poprawką, że jest to "rzeczywistość realna". A nie wirtualna.
To nie są ani pleonazmy ani oksymorony. To samo życie.

I albo sobie sam pomoże, albo ugrzęźnie w exceliozie do końca kariery. A nikt, nikt! - nie rozumie jego sytuacji, często - łącznie z nim samym!

Dlaczego sam nie rozumie swojej sytuacji??? Odpowiedź zawiera się w punkcie „Czego uczymy …”  i „Jakie są doświadczenia z nauczania o architekturze SOA”

Sądząc z naszych doświadczeń z dyskusji z „profesjonalistami”, ci, którzy formalnie powinni mu pomóc, nie umieją albo nie chcą mu pomóc. Albo jedno i drugie.

To jest właśnie kwestia, która została poruszona w punktach 2 i 3 naszego niby - cytatu.

Na pytanie o możliwość stosowania architektury SOA przy używaniu „czystego” Excela, mam nadzieję, niniejszym tekstem dałem jednoznaczną odpowiedź. I precyzyjnie określiłem warunki. 

Natomiast pozostaje jeszcze wyjaśnić, co ma do rzeczy odwołanie do AFINa na wątku o architekturze SOA?

AFIN w architekturze SOA

Wydaje się, że jest całkowicie uprawnione odwołanie się na wątku o architekturze SOA do JEDYNEGO narzędzia analiz biznesowych, które stosuje tę architekturę w praktyce i ma referencje z dużych, poważnych firm. Referencje, które można by określić, jako więcej niż pozytywne, jeśli nie entuzjastyczne.

Może, gdyby ta architektura była powszechnie obowiązująca, „banalna”. Nie byłoby o czym mówić. Ale jeśli jest zaciekle zwalczana? To chyba logiczne?

Ale to nie jedyny powód.

Drugi powód jest taki, że to jest konkretna i jedyna na rynku pomoc dla analityków, którzy chcą sprofesjonalizować swoje środowisko analiz, którzy nie chcą czekać na nigdy niezrealizowane obietnice, że „się poprawi raport w biaju i będzie dobrze”. A póki co, mają do dyspozycji tylko kontrolkę - "Export do Excela", przeklejki i odmęty „exceliozy”.

Ale może się mylę i takich narzędzi, które zapewniają trwałe „raporty, które wystarczy odświeżyć”  jest bez liku a my naprawdę żyjemy w „równoległej rzeczywistości?