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ę.
Excel dla ambitnych
Niestandardowe umiejętności posługiwania się standardowymi narzędziami. Excel i Access.
sobota, 31 marca 2018
sobota, 11 marca 2017
Referencje dla architektury i podejścia SOA
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ę. |
wtorek, 9 września 2014
Codd'a 12 zasad zarządzania bazą danych dla OLAPu
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.
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)
- "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?
(podkreślenia KR)
(1) To kluczowe zdania dla przedmiotu naszej dyskusji:
- Mój adwersarz, że to całkiem inna bajka.
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.
Stąd właśnie nasza koncepcja innej architektury - SOA.
wtorek, 25 marca 2014
Architektura SOA, Excel, AFIN. Kto jest beneficjentem a kto ofiarą?
Geneza wpisu
Zamieściłem
pewną notkę1 (wszystkie przypisy w komentarzach) na temat
architektury SOA, ilustrowaną przykładem z użyciem AFINa.
Otrzymałem krytyczny
komentarz2, 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?
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? 3
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.
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.
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.
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ń.
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. 5
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.
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.
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?
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?
poniedziałek, 17 marca 2014
Marcowy numer CRiZ wspomina o SOA
Krotka zajawka jak najbardziej na temat.
Ukazał się marcowy numer Controllingu i Rachunkowości Zarządczej. A w nim artykuł Stanisława Grabowego pt.
Budowa raportów wspomagających
zarządzanie należnościami
w polskim oddziale
międzynarodowej firmy
Autor skorzystał, przy budowie środowiska raportowego, z koncepcji architektonicznej SOA, cytuję:
Jeżeli chodzi o stronę techniczną, to raporty muszą
być proste w obsłudze, tzn. jak najbardziej przyjazne
użytkownikowi. Projekt będzie bazował na koncepcji
Spreadsheet Oriented Architecture (SOA), czyli architekturze
zorientowanej na skoroszyt.
Niestety nie mogę podać linka. Trzeba sobie kupić egzemplarz. :)
Jeszcze jeden cytat:
Zaletą tego rozwiązania jest brak wydatków na
oprogramowanie, usługi IT czy licencje. Wszystko
zostało wykonane przez pracownika wewnętrznego
firmy. Jednak warunkiem koniecznym do wykonania
tego zadania była odpowiednia wiedza i umiejętności
osoby realizującej projekt.
Proszę zwrócić uwagę na ostatnie zdanie. Ktoś tu coś mówił o konieczności wychowania "nowego człowieka". Okazuje się, że coś w tym jest. Ale, jak widać, nie święci garnki lepią.
Własnie otworzono na Uniwersytecie Ekonomicznym we Wrocławiu DWIE RÓWNOLEGŁE czwartą i piątą, edycje naszych studiów.
Dochodzimy już do setki "nowych ludzi".
Jaka liczba będzie liczbą przełomową?
Pozdrawiam wszystkich czytelników tego wątku.
Muszę się przygotowywać do zajęć w weekend.
Ukazał się marcowy numer Controllingu i Rachunkowości Zarządczej. A w nim artykuł Stanisława Grabowego pt.
Budowa raportów wspomagających
zarządzanie należnościami
w polskim oddziale
międzynarodowej firmy
Autor skorzystał, przy budowie środowiska raportowego, z koncepcji architektonicznej SOA, cytuję:
Jeżeli chodzi o stronę techniczną, to raporty muszą
być proste w obsłudze, tzn. jak najbardziej przyjazne
użytkownikowi. Projekt będzie bazował na koncepcji
Spreadsheet Oriented Architecture (SOA), czyli architekturze
zorientowanej na skoroszyt.
Niestety nie mogę podać linka. Trzeba sobie kupić egzemplarz. :)
Jeszcze jeden cytat:
Zaletą tego rozwiązania jest brak wydatków na
oprogramowanie, usługi IT czy licencje. Wszystko
zostało wykonane przez pracownika wewnętrznego
firmy. Jednak warunkiem koniecznym do wykonania
tego zadania była odpowiednia wiedza i umiejętności
osoby realizującej projekt.
Proszę zwrócić uwagę na ostatnie zdanie. Ktoś tu coś mówił o konieczności wychowania "nowego człowieka". Okazuje się, że coś w tym jest. Ale, jak widać, nie święci garnki lepią.
Własnie otworzono na Uniwersytecie Ekonomicznym we Wrocławiu DWIE RÓWNOLEGŁE czwartą i piątą, edycje naszych studiów.
Dochodzimy już do setki "nowych ludzi".
Jaka liczba będzie liczbą przełomową?
Pozdrawiam wszystkich czytelników tego wątku.
Muszę się przygotowywać do zajęć w weekend.
piątek, 24 stycznia 2014
Komunikat o Studiach Podyplomowych "Excel w controllingu dla zaawansowanych"
Zakończyliśmy właśnie zajęcia na drugiej edycji Studiów Podyplomowych:
Kto pierwszy raz i nie wie o co chodzi, podaję linki.
Studia specjalistyczne analityków biznesowych. Teoria i praktyka. Część I
Trzecia edycja trwa już od października.
Zapisy na edycję czwartą zostały zakończone z braku miejsc. Rusza od marca.
(przyp.10.03.2014: już ruszyła. Odbyły się dwa weekendowe zajęcia. Świetna grupa :) )
Wobec dużego zainteresowania, postanowiono uruchomić edycję piątą!
Rusza od kwietnia. Są jeszcze miejsca.
Edycja warszawska ciągle jeszcze się waha. Czy wejdziemy na teren lwa (żeby nie mówić o jaskini)? Proszę śledzić dalsze komunikaty...
Nie jest to sytuacja zwyczajna na Studiach Podyplomowych. Było kilkadziesiąt projektów. Ruszyło osiem. Nasz projekt jest jednym z najbardziej obleganych. Czy może gdzieś jest łatwiej?
Jak na "byle co", (określenie pewnego trolla z cenzusem na znakomitym GL o naszej koncepcji i o naszych kompetencjach) to chyba nie byle co?
W kontakcie ze słuchaczami Studiów, o wyższej, niż studenci, samoświadomości, z ludźmi, którzy mają już doświadczenia łączenia wiedzy i praktyki, doskonalimy przekaz, pogłębiamy samo - rozumienie naszej koncepcji.
Przypomnę - architektury SOA - oraz procesu excelocentrycznej, profesjonalnej analizy w tej architekturze - z dodatkową warstwą danych, należącą do analityka.
Weryfikujemy jej sensowność i przydatność w warunkach dużych firm, które albo mają system raportowy (tzw.BI) albo "tylko" system ERP.
Poprzez konkretne, praktyczne zastosowania - dostrzegamy nowe aspekty naszej "teorii".
Chyba na tym polega praca na uczelni? Muszę o tym jeszcze podyskutować z naszymi kolegami - akademikami. Bo niby już to wiedziałem, ale teraz to mnie znowu zafascynowało.
Dla mnie osobiście wielką pomocą są rozwiązywane "zadania domowe".
Jeśłi już się wynuka ich przysłanie. Nigdy 100% uczestników. Ale większość. Po trudach.
Trzeba popracować nad formami nacisku...
To lustro mojej "dydaktycznej siły rażenia".
Niespodzianki, że to, co dla mnie było oczywiste, budzi powszechne trudności.
Możliwość oceny, gdzie się kończy sztampa, a zaczyna samodzielne myślenie.
Zaskakujące zastosowania typowych, zdawałoby się problemów.
Trudne, wymagające wiele nakładu pracy własnej i konsultacji dodatkowych, ale efektywne i efektowne koncepcje, podejmowane przez niedocenionych słuchaczy. Które materializują się w proces przełomowy dla firmowej analizy. I budzą prawdziwą satysfakcję zarówno dydaktyka, jak i słuchacza. To jednak już rzadkość, godna oryginalnej, o pracochłoności wyższej od przeciętnej, pracy dyplomowej.
Nasi słuchacze nie tylko słuchają i rozumieją nasz tok rozumowania i "teoryzowania".
Oni mają swoje konkretne, profesjonalne potrzeby, które wyrażają na przerwach zajęć i w e-mailach.
My też się od nich uczymy.
A my?
Kolejny raz potwierdziliśmy nasz ogląd sytuacji: "wszyscy robią analizy w Excelu", korzystając, zarówno ze źródeł danych z eksportów z systemów BI, z systemów ERP, jak i z innych, zupełnie dowolnych.
Nie wyklucza to wykorzystania przez menadżerów raportów generowanych przez systemy raportujące, przygotowane najczęściej przez samych dostawców bi - ajów. Drogie, trudne w modyfikacji, czasem zresztą działające w zbyt długim cyklu odświeżania, jak na potrzeby bieżącej analizy.
Ale ta frekwencja i atmosfera na zajęciach mówi za siebie.
Można to też zanegować:
Na moją opinię:
Nie rozstrzygajmy tego. My się zajmujemy tymi, którzy się z nami zgadzają i im chcemy pomóc.
Reszta niech sobie pomaga na swój sposób. Prawdopodobnie "sama sobie szkodzi" grzęznąc w exceliozie. Ale to legalne.
Na ich nawracanie przyjdzie czas, kiedy "partia rozsądku" zdobędzie wyższą pozycję i wyjdzie z "getta excela".
MS Excel w controllingu dla zaawansowanych
To nie jest reklama. To uprzejma informacja dla wielu zainteresowanych i pytających. :)Kto pierwszy raz i nie wie o co chodzi, podaję linki.
Studia specjalistyczne analityków biznesowych. Teoria i praktyka. Część I
Studia specjalistyczne analityków biznesowych. Teoria i praktyka (część 2)
Studia specjalistyczne analityków biznesowych. Teoria i praktyka (część 3)
Studia specjalistyczne analityków biznesowych. Teoria i praktyka (część 3)
Trzecia edycja trwa już od października.
Zapisy na edycję czwartą zostały zakończone z braku miejsc. Rusza od marca.
(przyp.10.03.2014: już ruszyła. Odbyły się dwa weekendowe zajęcia. Świetna grupa :) )
Wobec dużego zainteresowania, postanowiono uruchomić edycję piątą!
Rusza od kwietnia. Są jeszcze miejsca.
Edycja warszawska ciągle jeszcze się waha. Czy wejdziemy na teren lwa (żeby nie mówić o jaskini)? Proszę śledzić dalsze komunikaty...
Nie jest to sytuacja zwyczajna na Studiach Podyplomowych. Było kilkadziesiąt projektów. Ruszyło osiem. Nasz projekt jest jednym z najbardziej obleganych. Czy może gdzieś jest łatwiej?
Jak na "byle co", (określenie pewnego trolla z cenzusem na znakomitym GL o naszej koncepcji i o naszych kompetencjach) to chyba nie byle co?
Tylko kilka zdań refleksji
Fascynująca Przygoda
W tej naszej "przygodzie ze Studiami" zasmakowaliśmy czegoś fascynującego, co składa się na rzetelną działalność akademicką.W kontakcie ze słuchaczami Studiów, o wyższej, niż studenci, samoświadomości, z ludźmi, którzy mają już doświadczenia łączenia wiedzy i praktyki, doskonalimy przekaz, pogłębiamy samo - rozumienie naszej koncepcji.
Przypomnę - architektury SOA - oraz procesu excelocentrycznej, profesjonalnej analizy w tej architekturze - z dodatkową warstwą danych, należącą do analityka.
Weryfikujemy jej sensowność i przydatność w warunkach dużych firm, które albo mają system raportowy (tzw.BI) albo "tylko" system ERP.
Poprzez konkretne, praktyczne zastosowania - dostrzegamy nowe aspekty naszej "teorii".
Chyba na tym polega praca na uczelni? Muszę o tym jeszcze podyskutować z naszymi kolegami - akademikami. Bo niby już to wiedziałem, ale teraz to mnie znowu zafascynowało.
Dla mnie osobiście wielką pomocą są rozwiązywane "zadania domowe".
Jeśłi już się wynuka ich przysłanie. Nigdy 100% uczestników. Ale większość. Po trudach.
Trzeba popracować nad formami nacisku...
To lustro mojej "dydaktycznej siły rażenia".
Niespodzianki, że to, co dla mnie było oczywiste, budzi powszechne trudności.
Możliwość oceny, gdzie się kończy sztampa, a zaczyna samodzielne myślenie.
Zaskakujące zastosowania typowych, zdawałoby się problemów.
Trudne, wymagające wiele nakładu pracy własnej i konsultacji dodatkowych, ale efektywne i efektowne koncepcje, podejmowane przez niedocenionych słuchaczy. Które materializują się w proces przełomowy dla firmowej analizy. I budzą prawdziwą satysfakcję zarówno dydaktyka, jak i słuchacza. To jednak już rzadkość, godna oryginalnej, o pracochłoności wyższej od przeciętnej, pracy dyplomowej.
"Nareszcie poczułem możliwości"Przyjemne i "kontrowersyjne" są prośby o przysłanie gotowych rozwiązań.
"bo muszę to szybko zastosować w firmie".Wtedy dusza dydaktyka cierpi, bo słuchacz powinien to już umieć, i walczy o lepsze z duszą "wynalazcy", szczęśliwego, że wynalazek jest tak upragniony.
"Efekt dydaktyczny"
Dlaczego w cudzysłowie? Bo to jest efekt u prowadzącego, nie u słuchacza. Coś komuś tłumacząc, lepiej precyzujemy pojęcia, dostrzegamy, co jest ważne a co nieistotne.Nasi słuchacze nie tylko słuchają i rozumieją nasz tok rozumowania i "teoryzowania".
Oni mają swoje konkretne, profesjonalne potrzeby, które wyrażają na przerwach zajęć i w e-mailach.
My też się od nich uczymy.
Excel, jako konkurent biajów, czy partner?
Nasi przeciwnicy twierdzą, że ani jedno, ani drugie. Excel - to getto. Trzeba się jak najszybciej wydostać. I wejść do świata profesjonalnej analizy.A my?
Kolejny raz potwierdziliśmy nasz ogląd sytuacji: "wszyscy robią analizy w Excelu", korzystając, zarówno ze źródeł danych z eksportów z systemów BI, z systemów ERP, jak i z innych, zupełnie dowolnych.
Nie wyklucza to wykorzystania przez menadżerów raportów generowanych przez systemy raportujące, przygotowane najczęściej przez samych dostawców bi - ajów. Drogie, trudne w modyfikacji, czasem zresztą działające w zbyt długim cyklu odświeżania, jak na potrzeby bieżącej analizy.
Ale ta frekwencja i atmosfera na zajęciach mówi za siebie.
Można to też zanegować:
Na moją opinię:
Na Studia przychodzą tylko tacy, którzy to rozumieją.Zapytają ci, co negują i hejtują:
Widzą nieakceptowane braki środowiska analizy i swoje trudności w zmianie tego stanu rzeczy.
Te trudności chcą usunąć przez podwyższenie swoich kwalifikacji. Kończą studia usatysfakcjonowani. Przynajmniej niektórzy, zwłaszcza tacy, którzy przyłożyli się na zajęciach.
Ale może inni, nie tyle nie rozumieją roli Excela w analizie, ile rozumieją, że ta rola nie jest tak ważna?
Nie rozstrzygajmy tego. My się zajmujemy tymi, którzy się z nami zgadzają i im chcemy pomóc.
Reszta niech sobie pomaga na swój sposób. Prawdopodobnie "sama sobie szkodzi" grzęznąc w exceliozie. Ale to legalne.
Na ich nawracanie przyjdzie czas, kiedy "partia rozsądku" zdobędzie wyższą pozycję i wyjdzie z "getta excela".
czwartek, 9 stycznia 2014
Technologia OLAP dla analityków (4)
Architektura analizy z Excelem w roli głównej
Praktyka Dzisiaj
Jaka jest teraz, dzisiaj rola Excela w analizie - to wie dobrze każdy analityk, mający szczęście współpracować z jakimś systemem bi – aj. Opisałem to tutaj. A także jeszcze gdzieś, w formie rozwiniętej, pasjonującej historyjki. Prosto z życia. Tam.
Najpierw musi coś zrobić w swoim bi-aju. A potem?
1) Potem – dostęp tylko w interface’ie
(kontrolce) tabeli przestawnej bi – aja. Własnej
kontrolce bi - aja. (…).
2) Jak analityk koniecznie chce, to może zawsze
użyć innej kontrolki - „Excel”. (czyli „Export do Excela” przyp KR, żeby pewien
czytelnik zrozumiał, że Excel nie jest wprawdzie kontrolką, ale istnieją
kontrolki „Excel” :) ) (…). 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 (…) bi-aju.
3) 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?
Później może już w
Excelu robić, co chce.
Taka jest powszechna praktyka we wszystkich znanych mi
firmach. Moi polemiści żądają dowodu. Dostarczę go natychmiast, gdy oni dostarczą
mi dowodu, w formie wzoru z całką potrójną, na fakt, że woda jest mokra.
No dobrze. Tak jest dzisiaj. Ale na początku tak nie było.
No dobrze. Tak jest dzisiaj. Ale na początku tak nie było.
Praktyka z wczoraj i co się z nią stało
Opiszmy, jak to widział Microsoft, jeszcze pod wodzą Billa
Gates’a.
Zacytujmy oficjalne opracowanie Microsoftu o hurtowniach
danych z roku 2000:
Microsoft oferuje następujące narzędzia do budowy systemów wspomagania
decyzji: serwer OLAP, usługi PivotTable, OLE DB, DTS, (…), Office 2000 i Microsoft Repository.
(…)
Składniki Office 2000, takie, jak Excel, umożliwiają przeglądanie
danych kostki w arkuszu kalkulacyjnym. Można także napisać kod Visual Basic for
Applications (VBA) i stworzyć moduły programowe dla uzyskania danych i
manipulacji nimi, co umożliwia tworzenie własnych interface’ów dla hurtowni
danych.
W jaki sposób miał się odbywać ten dostęp do hurtowni? Czy to może zupełnie
przebrzmiała sprawa sprzed półtorej dekady i nie ma co do niej wracać?
W tej samej publikacji Microsoft ogłasza:
API OLE DB jest podstawą uniwersalnego dostępu. Interface OLE DB może
być używany przez aplikacje baz danych dla dostępu do każdego typu danych
posiadającego dostawcę OLE DB. (…)
ActiveX Data Objects (ADO) jest narzędziem, które pozwala programistom Visual Basic na dostęp do interface’u OLE DB.
ActiveX Data Objects (ADO) jest narzędziem, które pozwala programistom Visual Basic na dostęp do interface’u OLE DB.
Czy te enuncjacje były jakąś rewelacją w owym czasie? Nawet
wówczas nie. Były konsekwentną realizacją polityki MS w zakresie dostępu do baz
danych dla użytkowników Excela.
Standard OLE DB został ogłoszony przez MS w
roku 1992, wraz z innym standardem – ODBC. Standard ODBC został wprowadzony do
Excela w wersji 5 (rok 1995), wraz z dodatkiem MS Query.
Rewelacją było co innego. W roku wydania omawianej
publikacji standard OLE DB został wprowadzony jednocześnie z serwerem MS SQL 7.0
do Excela 2000. Wraz z procedurą tworzenia offline’owych kostek OLAP!
Microsoft dokonał rewolucji, prawie niezauważonej. W każdym
razie nie było żadnego materiału w tefałenie.
W kilku gabinetach jednak na
pewno odbyły się nerwowe narady. Potwornie drogie systemy analizy
wielowymiarowej, wielkie serwery analityczne i elitarne procesy OLAP zyskały
niemal darmowego konkurenta.
Każdy użytkownik Excela mógł podłączyć się do
kostki OLAP wystawionej na stosunkowo niedrogim serwerze MS SQL. Ba, mógł sobie
sam wyprodukować kostkę OLAP na swoim PC-ie dysponując programem MS Excel 2000
wartości 500 dolarów. Wydawało się, że Microsoft dokonał kolejnego wyłomu w
samozwańczych „świątynnych twierdzach” informatycznych.
Zdemokratyzował
profesjonalną analizę biznesową. Tą drogą szedł jeszcze kilka lat, doskonaląc
analityczne funkcjonalności Excela w wersji 2003. Potem, po odejściu Gates’a ta
konsekwentna linia rozwojowa, załamała się w połowie lat 2000 –nych. Jednym z
sygnałów odwrotu było wyłączenie kreatora kostek w wersji Excela 2007 a także
regres w istotnych dla dostępu do danych funkcjach serwera MS SQL 2008.
Jaka może być hipoteza wyjaśniająca, dlaczego ta linia
rozwojowa się załamała?
Może to, że Microsoft poważnie zagroził interesom biznesu
analiz? Wówczas właśnie nastąpiła „odpowiedź” w postaci systemów Bi Aj? A w
Microsofcie nastąpiła akurat, pechowo, zmiana warty?
Wracamy do dnia dzisiejszego
Dzisiaj, zamiast napisać
„Składniki Office 2013, takie, jak Excel, umożliwiają przeglądanie
danych kostki w arkuszu kalkulacyjnym”.
Musimy napisać: Najpierw
musisz użyć bi-aja!
A potem?
Jak analityk koniecznie chce, to może zawsze użyć ( w bi-aju) innej
kontrolki - „Excel”. (…). 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 (…) bi-aju.
Konsekwencje dziwnego rozwoju analizy
Tak właśnie prawidłowa, (albo, jak kto woli, genialna w swej prostocie i konsekwencji) koncepcja Microsoft’a, koncepcja architektury profesjonalnej analizy, w której Excel jest pełnoprawnym elementem, zintegrowanym ze środowiskiem przez standardy informatyczne, takie jak OLE DB, została sprowadzona do prymitywnej, tępej i egoistycznej koncepcji bi-ajków.
„Bądź naszym użytkownikiem, chcesz, czy nie. Ostatecznie możesz sobie
wypluć coś do Excela”.
Kontrolka „Excel”, czyli miłościwie panujący klawisz „Export
do Excela” zabiła „architekturę służebną” która udostępniała dane dla Excela
„raz na zawsze” i zastąpiła ją „architekturą ochłapu”, rzucającą te dane, jak
ochłap. I utrzymująca stan „karmienia”, czyli stałego uzależnienia.
W wyniku otrzymujemy podział świata analizy na dwie części, odcięcie analityków od głównego nurtu informatyki, skazanie ich na rolę
outsiderów, obciachowych „użytkowników excelka”.
Konsekwencje tej sytuacji są negatywne i wielorakie.
Zamiast promowania efektywnych,
profesjonalnych standardów, procesów i architektury wśród analityków, oferuje
się im (za pośrednictwem ich zdezorientowanych szefów, omamionych przez
specjalistów od sprzedaży) fałszywą alternatywę: albo – bi-aj albo pozostanie w
zatęchłym „informatycznym slumsie exceliozy”.
Analitycy się nie buntują. Robią swoje i
biorą swoje. Jak im wdrożą bi-aja, dopiero się okaże, jak są potrzebni z tym
swoim obciachowym excelkiem.
„Rządzą” tam - biegli w swoim
rzemiośle „guru”, power-userzy, specjaliści od negocjacji z „bi – ludkami”, aby
uzyskać jakiś „raport”, z którego „jakoś” się skorzysta w analizie. Im
pozostają exporty, przeklejki i excelioza, czyli analityczne getto na obrzeżach
bi-ajów z ich rzekomo jedynie profesjonalnymi raportami.
Ale co za różnica? Życie toczy
się gdzie indziej.
Wnioski
Co wynika z tego opisu założeń architektury procesu analizy
z przełomu wieków oraz jego konfrontacji z dzisiejszym podejściem?
I co mnie tak uderzyło w pełnej poczucia wyższości tyradzie
wygłoszonej przez Pewnego Informatyka, specjalisty BI, do analityka, ciekawego
świata i grzecznie zadającego pytania?
OLAP to technologia. (…) Nie ma możliwości i nie można tego
porównywać bo to zupełnie inne bajki.
Otóż zdałem sobie sprawę, że mam do czynienia ze sceną
symboliczną. Oto rozmawiają ze sobą, jak gęś z prosięciem, dwaj przedstawiciele
tej samej dziedziny biznesu, tyle, że z różnych segmentów procesu, który obaj
realizują. Te różne segmenty procesu zakładają wprawdzie różne kompetencje u
każdego z uczestników, ale powinna występować przynajmniej wspólnota celów i
zrozumienie wzajemnego uzależnienia.
A jaki obraz wyłania się z tej konfrontacji postaw?
Z jednej strony - postawa ciekawości i pokory. Wiadomo –
obciachowy analityk. Nie tylko dobrze wychowany, ale zna swoje miejsce. Jest
„tylko” analitykiem.
Z drugiej strony – pycha, przekonanie o swojej niewątpliwej
kompetencji oraz o niekompetencji ludzi „z innej bajki” i …kompletne zagubienie
celu swojej działalności.
Kompletnie inne bajki? Nie można tego porównywać? Absurd?
Tak, dokładnie tak. Może z wyjątkiem absurdu. Samo życie.
Koniec kłótni. Z mojej strony.
Subskrybuj:
Posty (Atom)
Ś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,...


-
(Codd's paper) Jako glossa do nieudanej ale burzliwej "dyskusji" o tym, czym jest OLAP i czy tabela przestawna i OLAP to...
-
Część 1 –Excelioza czy BI? Motto: A kapusta rzecze smutnie: "Moi drodzy, po co kłótnie, Po co wasze swary głupie, Wnet i tak...
-
Witam wszystkich użytkowników Excela. Na początek wypada się przedstawić. Nazywam się Krzysztof Rumiński ( http://www.goldenline.pl/krzysz...
