środa, 22 maja 2013

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

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

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

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

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

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

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

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

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

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

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

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

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

Problem bezpieczeństwa w architekturze SOA

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

Oto ono.

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

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

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

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

To była architektura pre - SOA :)

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

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

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

2) Możliwość ustawiania konkretnych uprawnień 

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

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

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

 Wydawnictwo Helion - pliki przykładów z wydanych książek informatycznych, jak ściągnąć? Wpis nie sponsorowany Helion wydaje ważne dla mnie ...