Od razu zaznaczę, że te testy szły wyjątkowo opornie — kolejne podejścia generowały tylko wątpliwości, czy stosuję dobrą metodykę i właściwie przygotowałem środowisko. W poprzednich testach bowiem porównywałem tylko zachowanie różnego typu oprogramowania na dokładnie takich samym środowisku sprzętowym. Tutaj celem testu było wyciąganie wniosków, co nam daje zwiększanie liczby procesorów i jak to ogólnie wpływa na wydajność środowiska. Tymczasem procesor jest tylko jednym ze składników maszyny. Wąskim gardłem przetwarzania może natomiast być bardzo wiele czynników, dlatego też ograniczanie się tylko do procesora może nam zaciemniać cały obraz — a wyciągane pochopnie wnioski prowadzić na manowce. Ale podejdę do sprawy jak botanik do preparowanego motyla i po prostu opowiem co zaobserwowałem.

Testowałem zachowanie trzech środowisk. Pierwsze z nich, to open–source’y (Mule). Pozostałe, to komercyjne, przy czym jedno z nich było uwzględnione w opisywanych wcześniej przeze mnie testach szybkości i wydajności ESB; drugie rozwiązanie było skonfigurowane już po opublikowaniu wyników tych testów. Istnieją oczywiste różnice pomiędzy wydajnością tych środowisk, jednak na to nie chciałem zwracać uwagi — teraz chciałem sobie odpowiedzieć: jak się ona zmienia, przy “dodanych procesorach”. Poniżej wykres osiąganej wydajności przy wywoływaniu prostej usługi pobrania rekordu z bazy danych  (po szczegółowy opis tej usługi polecam wrócić do moich poprzednich artykułów).

Na diagramie w odpowiednich słupkach zaprezentowano uzyskane wyniki na środowisku jednoprocesorowym, oraz wynik tego samego testu, uruchomionego na środowisku z dwoma procesorami (core’ami). Wydajność podana jest w transakcjach na sekundę. Aby uwypuklić wartość zmian w wydajności w obu wariantach testu, poniżej prezentuje jeszcze raz te same dane, ale w ujęciu procentowym:

Na powyższym rysunku wydajność osiągniętą na środowisku jednoprocesorowym oznaczono kolorem zielonym (przyjmując jako 100%), natomiast kolorem niebieskim zaznaczono wzrost wydajności przy wykorzystaniu środowiska z dwoma procesorami.

No i teraz, patrząc na te diagramy, wyrokujemy szybko: uwaga ze skalowaniem maszyn, bo dodanie procesora nie przynosi prostego zysku na wydajności “x2″. Wniosek ten jest prawdziwy, ale jednocześnie mało odkrywczy. A co będzie, gdy zamiast procesora 1-core damy nie 2 ale 4-core? czy za każdym razem uzyskamy kolejne “x1.5″?. Dla jednego z rozwiązań prowadziłem testy dalej — kolejno od 1 do 4 rdzeni. Okazało się, że wydajność wzrosła… tylko przy dodaniu drugiego rdzenia! dalej już nie było istotnych zmian w wydajności. Jedyna różnica to ta, że czas odpowiedzi dużo dłużej pozostawał na niezmienionym poziomie (przy dwóch rdzeniach szybko rósł w górę, wraz ze wzrostem równoległych wątków przetwarzania). Co więcej: przy jednym rdzeniu procesor był konsumowany w 100%, przy dwóch w sumie w ok. 140% (czyli oba rdzenie pracowały na 70%), przy trzech i czterech… już to się nie zmieniało. Maszyna pracowała na 140%, tylko te 140 rozkładało się na coraz więcej rdzeni. Co się dzieje? Szybki rzut oka na maszynę z bazą danych i wszystko jasne. To baza pracowała już na pełnych obrotach. No i teraz wszystko zaczyna się wyjaśniać i opada podniecenie z “wzmacniania mocy obliczeniowej”.

Jak się przyjrzeć wykresom, to zauważy się jeszcze jedną prawidłowość, w sumie to potwierdzającą nasze spostrzeżenia: im słabsze wyniki początkowe, tym większy zysk w drugim teście. To oczywiste, bo później test natrafił na kres wydajności bazy… Żeby zbadać prawdziwy wzrost przepustowości, musiałbym najpierw udrożnić wszystkie “rurki” — i to zarówno te wyjściowe (integrowane systemy) jak i wejściowe (sieć i wywołania webservice’ów). I przypilnować, czy nie ma za dużo zapisów na dyskach (np. audytu), które zaczną się przepychać w drodze na dysk. Oraz czy nie ma za mało pamięci dla procesów. A także puli połączeń do integrowanych systemów. I jeszcze puli wątków… itd, itp. Czyli — jednym słowem — wykonać porządne strojenie. A tego przecież miało nie być w pierwotnych założeniach. Czyli ostatecznie doszedłem do tego, że wyjściowe założenia miałem sprzeczne. No dobrze, może kiedyś będę miał czas postroić odpowiednio maszyny, to wtedy opowiem o tym. Zaczynając te testy z dodawaniem rdzeni miałem naiwną nadzieję, że może szczęśliwie się “prześlizgnę” nad tym problemem i otoczenie będzie bliskie optymalnemu (do takiego myślenia skłaniała mała baza danych, proste zapytania, brak interakcji i/o w usługach i konfiguracji środowisk ESB). Okazało się jednak, że jest “jak zawsze”.

To tyle o tych testach. Na zakończenie jeszcze warto zwrócić uwagę, że skalowanie liniowe (a raczej precyzyjnie mówiąc: ograniczone tylko i wyłącznie wydajnością integrowanych systemów) wraz ze wzrostem liczby wykorzystywanych procesorów możemy w pewny sposób uzyskać — kiedy będziemy te procesory instalować na odrębnych maszynach! Dzięki temu, że usługi SOA są niezależne, więc każdy serwer będzie odpowiadał “po swojemu”, czyli wydajność w jednostce czasu się zwielokrotni z każdym nowym serwerem, o ile oczywiście nic zewnętrznego go nie spowolni (jak wspominane systemy zewnętrzne).

Dwie uwagi końcowe:

Merytoryczna: proszę nie porównywać wyników “bezwzględnych” z tych testów, z testami poprzednimi. zmieniło się środowisko testowe.

Organizacyjna: na tym artykule kończę (na bliżej nie znany czas) moją działalność blogerską. Mam nadzieję, że mój trud pisania nie poszedł na marne i prezentowana wiedza przydała się komuś…

SIP Servlets
Technologia SIP Servlet została stworzona w oparciu o technologię HTTP Servlet. Jednostką logiki aplikacji jest Servlet. Dzięki mechanizmowi Application Routing’u (JSR289) zdefiniowanego istnieje możliwość kompozycji aplikacji z poszczególnych funkcjonalności zaimplementowanych w różnych SIP Servlet’ach. Application Routing  został dodany w JSR289 ponieważ w JSR116 brakowało mechanizmu pozwalającego na kompozycję aplikacji. W ten sposób wyeliminowano dość dużą słabość tej technologii.

Składnia protokołu SIP jest wzorowana na protokole HTTP.  Bazując na sukcesie HTTP Servlet’ów naturalny wydał się pomysł wykorzystania tego samego modelu programowania w przypadku SIP.  Istniej jednak pewna różnica pomiędzy tymi protokołami, HTTP jest protokołem symetrycznym SIP natomiast asymetrycznym. RFC 3261 definiujące SIP pozwala na zamianę ról pomiędzy klientem i serwer. Aby zrealizować to wymaganie w SIP Servlecie powstała metoda send (), która w pewnym sensie burzy ideę “passive servlet” model.  Jednak bazując na moim doświadczeniu sprawdza się to bardzo dobrze.

Podobieństwo SIP Servlet’u do HTTP Servlet jest z pewnością dużym atutem powyższej technologii. Developeromzaznajomionym z technologią  HTTP Servlet,w łatwy sposób przychodzi poznanie tej technologii  i szybką implementacjęoczekiwanych funkcjonalności.

JAIN SLEE
Architektura ta oparta jest o jednostki logiki Service Building Block (SBB). Posiada ona wsparcie dla tworzenia aplikacji poprzez kompozycje gotowych SBB i ponownego użycia wcześniej utworzonych bloków. Tak jak SIP Servlet ma coś wspólnego z HTTP Servlet’em tak JAIN SLEE jest podobny do EJB 2.1. Podejście to pozwala na zamykanie poszczególnych funkcjonalności w pojedynczych SBB, a następniekomponowanie aplikacji zposzczególnych SBB,przy wykorzystaniu odpowiednich deskryptorów.
Aplikacje napisane  w JAIN SLEE są to aplikacje napisane z wykorzystaniem modelu Event Driven Application. Idea tego modelu najprościej mówiąc jest oparta o obsługiwanie otrzymanych zdarzenie. Aplikacje takie działają na zasadzie nieskończonej pętli która dzieli się na dwie części, pierwszą  odpowiedzialną za prze-kierowanie zdarzeń  i drugą za ich obsługę.

Zdarzenia możemy podzielić na trzy rodzaje ze względu na źródło pochodzenia:

• - Zewnętrzne źródło- rozumiemy przez to zdarzenia pochodzące z protokołów obsługiwanych przez serwer JAIN SLEE.
• - Wewnętrzne pochodzące ze SLEE – są to zdarzenia wewnętrzne aplikacji tj.: zakończenie timer’a, modyfikacja danych provisioningowych aplikacji.
• - Z innej aplikacji działającej w SLEE – używane do komunikacji pomiędzy różnymi SBB znajdującymi się na tym samym serwerze.

Model przedstawiony w JAIN SLEE jest bardzo elastyczny i dlatego też świetnie nadaje się do tworzenia aplikacji wykorzystujących wiele różnych protokołów. Elastyczność  ta jednak rozszerza ilość elementów deskryptorach, obniża poziom abstrakcji itd.. , co w rezultacie komplikuje tworzenie aplikacji .

Podsumowanie
Obie technologie pozwalają na zamykanie funkcjonalności oraz dalszą ich kompozycję. W tej przestrzeni należy na pewno kierować się swoim doświadczeniem.

Mit nr 1: Media społecznościowe nie są dla firm z rynku korporacyjnego

Wśród wielu firm w Polsce pokutuje przekonanie, że poważnym firmom nie wypada opierać swoich kanałów komunikacji z rynkiem o media społecznościowe. Dlaczego? Trudno je kontrolować, trudno nauczyć się „tego” języka, niezwykła wydaje się również forma, która skłania raczej do wymiany zdjęć z wakacji, a nie merytorycznych treści.

Fakt nr 1: Siła w integracji

Cisco przeczy tym przekonaniom integrując na Facebooku kilka kanałów informacji: oficjalny newsowy, blogi tematyczne, Twittera, kanał filmowy YouTube, materiały zdjęciowe i oczywiście „ścianę” do dyskusji.Media społecznościowe stają się platformą do wymiany informacji, dając przestrzeń na kontakt po konferencji, spotkaniu handlowym, czy cyklu seminariów. Stają się bazą wiedzy o rozwiązaniach.

Mit nr 2: Firmy z sektora B2B nie mówią ludzkim głosem

Język, którym posługują się firmy działające w sektorze B2B faktycznie nie należy do najłatwiejszych, ale to właśnie sztuka otwartego mówienia o konkretnych rozwiązaniach, wyzwaniach i problemach przyciąga słuchaczy. W końcu technologie sprzedają ludzie, a nie maszyny.

Fakt nr 2: Rynek B2B to rynek rekomendacji

Media społecznościowe dają niebywały oręż – możliwość polecania. Sprzedaż na rynku korporacyjnym najczęściej opiera się na referencjach i poleceniach znajomych. Media społecznościowe dają szansę uruchomienia pozytywnego word of mouth. Pozwalają na wymianę opinii i przyciągania nowych słuchaczy „z otwarta przyłbicą”, a nie za nickiem na forum (oczywiście, w Polsce wszystko jest możliwe  .

Mit nr 3: W korporacjach wszystko jest poufne

W wielu firmach pokutuje przekonanie o konieczności ukrycia każdego elementu ich działania. Nie, nie. Nie wszystkie firmy są jak Apple  Umiejętne dzielenie się wiedzą tworzy grunt do sprzedaży.

Fakt nr 3: Treść przyciąga

Korporacje muszą myśleć „po dziennikarsku”. Poszukiwać tematów, o których dyskutuje ich rynek. Mówić o potrzebach, a nie produktach. Czasami wbić kij w mrowisko.  To może właśnie dlatego najczęściej komentowane tytuły postów kończą się znakiem zapytania. No i forma prezentacji treści… video jest z pewnością najbardziej infekującym medium. Wygrają Ci, którzy mają umiejętność najwygodniejszej prezentacji treści w najprostszy i konkretny sposób. To po prostu, najlepiej się klei 

Mit nr 4: Media społecznościowe to miejsce zabawy, a nie sprzedaży

W wielu firmach pracownicy mają zablokowany dostęp do mediów społecznościowych. Znam firmę z rynku usług profesjonalnych, która sprzedaje tylko za pośrednictwem LinkedIn. Ich klienci nie lubią reklam, nie mają czasu na konferencje, unikają długich rozmów telefonicznych.

Fakt nr 4: Ludzie napędzają media społecznościowe

Znam firmę, która zachęca swoich pracowników do tworzenia profilu na LinkedIn. W ten sposób wykorzystują swoje kontakty do dalszej dystrybucji firmowych komunikatów. To właśnie za pośrednictwem LinkedIn popularyzują korporacyjnego bloga i Twittera. Zaangażowanie pracowników wydaje się kluczowe z punktu widzenia osiągnięcia właściwej skali działania i przekroczenia „punktu przełomowego”, za którym kryje się lawina.

Lista mitów i faktów, może ulec zmianie. Any idea?

—————————————–

wpis pochodzi z mojego bloga - http://face2web.wordpress.com/

Program wrześniowego spotkania Klubu zakłada rozważenie tej kwestii.

Podczas poszukiwań ciekawych wątków, które przysłużyłyby się dyskusji klubowej, natknąłem się na bardzo interesujące podejście, wywodzące się ze wzornictwa. Założenia „designowego” myślenia o innowacji, w kategoriach całej firmy, są przedmiotem studiów na jednej z prywatnych poznańskich uczelni. Zarządzanie designem (tutaj schemat), czy może jak chciałbym to odczytać – zarządzanie innowacją na wzór metod stosowanych we wzornictwie, wdrażanie kultury innowacyjności – może brzmieć interesująco dla zarządzających IT.

Na stronie amerykańskiego CIO odnalazłem ciekawy zestaw rekomendacji dla firm dążących do podniesienia poziomu swojej innowacyjności. Wśród dziesięciu zaleceń, w zasadzie wniosków z badania innowacyjności amerykańskich firm przez Accenture, zwraca uwagę postulat powołania formalnych struktur: Chief Innovation Officer’a i stałego budżetu „na innowację”.

Jedna z firm, która wprowadzaniem innowacyjności w firmach się para, rozszerzyła znacznie liczbę stanowisk z innowacją w tytule. Pozostając przy inspiracjach płynących zza oceanu: tegoroczną nagrodę CIO 100 Award, wśród nagrodzonych znalazły się przedstawiciele firm doskonale wykorzystujących technologię do odgadywania niezwerbalizowanych niekiedy dotąd potrzeb konsumentów w sposób metodyczny; odkryły one metodę stałego doskonalenia, trwałej innowacyjności. To poniekąd tak, jakby odkryć system do wygrywania w totolotka. Któż by tak nie chciał – być może zatem, niebawem okaże się, że każda firma posiada swojego Chief Innovation Ignitera…

———————————————–

wpis pochodzi z bloga -> http://blog.klubcio.pl/

Pracownicy w swoich domach używają często bardziej zaawansowanych rozwiązań niż te, które mają do dyspozycji w firmach. Spośród narzędzi elektronicznych stosowanych w komunikacji wewnętrznej w wielu firmach nadal dominuje e-mail oraz elektroniczny biuletyn firmowy. Społecznościowa rewolucja nie przyniosła zatem wielkich zmian w komunikacji wewnętrznej firm. 

Pracodawcy kontra media społecznościowe…

W komunikacji wewnętrznej rozwiązania społecznościowe wprowadzane są ostrożnie. Wielu menadżerów sprzeciwia się nadaniu pracownikom możliwości instalowania komunikatorów i wykorzystania ich w wewnętrznych kontaktach zawodowych. Podstawowa obawa to bez wątpienia korzystanie z tych narzędzi w celach prywatnych. Wszystko jasne, ale dlaczego nie ukierunkować wykorzystania tych narzędzi na poprawę komunikacji firmowej? Dlaczego menadżerowie boją się mediów społecznościowych w firmach? Roman Rostek z firmy RR Communication Consulting trafnie wyróżnia m.in. następujące obawy zarządzających wobec upowszechnienia narzędzi 2.0 w komunikacji wewnętrznej:

Utrata kontroli nad komunikacją – plotka roznosi się jak wirus w portalu społecznościowym, a moderatorzy nie mają tutaj racji bytu. W komunikacji za pomocą mediów społecznościowych chodzi przecież o jej rozbudzenie, nie zaś o kontrolę.

Negatywny wpływ na wizerunek firmy – niekontrolowana komunikacja, wyciekanie nie do końca potwierdzonych informacji buduje obraz firmy, na który zarządzający nie mają już większego wpływu.  

Wprowadzanie w błąd nierzetelnymi informacjami – mnogość wypowiedzi i komentarzy zawsze zwiększa ryzyko zniekształcania informacji, czy publikowania nieprawdziwych wiadomości. 

Zmniejszenie wydajności pracowników – pracownicy zamiast pracować i wykorzystywać narzędzia społecznościowe w celach zawodowych, będą tracić czas na dyskusje pozazawodowe.

Takie podejście zarządzających na pewno nie wzmacnia wizerunku nowoczesnego pracodawcy. Tym bardziej, że błyskawicznie rozwijające się media społecznościowe są coraz łatwiej dostępne i popularne. Niechęć do wdrażania nowych rozwiązań w komunikacji wewnętrznej związana jest przeważnie tylko z kilkoma typowymi obawami. A przecież firma, w której istnieje świadomość ryzyka ma możliwość wprowadzenia takich wewnętrznych zasad korzystania z narzędzi społecznościowych, które będą je minimalizować. Największą obawę stanowić raczej powinno zmaterializowanie się ryzyka związanego z niewykorzystaniem możliwości jakie media społecznościowe oferują w komunikacji wewnętrznej. Możliwe, że w firmach za mało mówi się o korzyściach komunikacji wewnętrznej prowadzonej za pomocą mediów społecznosciowych i komunikatorów. Możliwość skutecznego przekazywania informacji oraz uzyskiwania szybkiego feedbacku od pracowników to podstawowe efekty jakie przynosi Web 2.0 w komunikacji wewnętrznej. Wzrost motywacji i zaangażowania pracowników w życie firmy, a także ich satysfakcja, również są odbierane jako sukces mediów społecznościowych. Aplikacje intranetowe wykorzystujące media społecznościowe zmniejszają przepaść między zarządzającymi a pracownikami, rozwijają współpracę, ułatwiają dzielenie się wiedzą i kształtują nowoczesną kulturę organizacyjną w firmie.

…i pracownicy kontra media społecznościowe

Istnieją jeszcze inne powody powolnego wdrażania rozwiązań społecznościowych w firmach. Większość światowych specjalistów ds. komunikacji wewnętrznej ocenia poziom własnej wiedzy z zakresu mediów społecznościowych jako niski. Także dziennikarze uważają, że „skoro telefon i mail się sprawdza nie ma sensu bawienia się tymi gadżetami.” Specjaliści od komunikacji przyznają się, że rzadko korzystają w swojej pracy np. z Gadu-Gadu czy Skype. Narzędzia te kojarzą się z życiem towarzyskim lub kontaktami prywatnymi. A skoro specjaliści od komunikacji nie używają ich zawodowo trudno zatem oczekiwać stosowania tych narzędzi przez innych pracowników. Co więcej, sami pracownicy także miewają obawy związane z wdrożeniem mediów społecznościowych. Nie mają przecież pewności, jak ich komentarze będą wykorzystane przez zarząd firmy. Wiadomo, że media społecznościowe zachęcają do częstszych kontaktów i wypowiedzi. W takiej sytuacji pracownicy nie wiedzą zwykle, co wolno im powiedzieć, a w zasadzie napisać. To pisanie jest właśnie jeszcze bardziej ryzykowne, gdyż zostawia trwały ślad i zdecydowanie trudniej jest wycofać się z pisemnej opinii. 

Niższe koszty komunikacji za pomocą Skype nie spowodowały rezygnacji z telefonu. Szybkość komunikacji za pomocą GG nie zastąpiła korespondencji mailowej. Być może potrzebne są kolejne innowacje technologiczne, które spowodują, że nagle komunikatory oraz media społecznościowe włączone zostaną do zbioru narzędzi podstawowych, używanych w komunikacji wewnętrznej. A może należałoby wymyślić coś zupełnie od podstaw w tym obszarze, aby rzeczywiście nastąpiła era komunikacji wewnętrznej 2.0?

Moje inspiracje:
Roman Rostek: Intranet 2.0 jako ryzyko?
Justyna Cyga: Media społecznościowe – powolna rewolucja w firmach
Bartosz Sawicki: Komunikatory? Lepsza kawa z prezesem

Wyobraźmy sobie klasyczne spotkanie biznesowe. Przyjmijmy, że jedna strona ma przekonać drugą stronę do zaangażowania się w pewien intratny projekt. Co robią korzystający z PowerPointa? Szukają wtyczki (najczęściej na kolanach), potem integracja z rzutnikiem (pierwszy pot), w tzw. międzyczasie powitanie, wymiana wizytówek, a potem nerwowe szukanie właściwej wersji aplikacji. Ufff. Wreszcie możemy skryć się za bezpieczny ekran laptopa.

Kiedy laptop już cichutko sapie wówczas oczy wszystkich osób uciekają na ścianę. Zaczyna się bieganie po liniach tekstu (przepraszam, czy mógłby Pan wrócić do poprzedniego slajdu – nie zdążyłem przeczytać). Czytaniu towarzyszy zazwyczaj kiwanie głową i zdawkowe chrząkanie.Po „odtrąbieniu” 45 slajdów w 15 minut pada pytanie… czy zdecyduje się Pan na kupno?

PowerPoint zabija naturalną rozmowę, skrywa mówcę za komputerem, eliminuje możliwość bezpośredniej interakcji. Tracimy przez to niepowtarzalną szansę nawiązania kontaktu, wymiany opinii, wysłuchania drugiej strony i wymiany informacji zwrotnej. Wiem, wiem… przesadzam PowerPoint to tylko narzędzie, które powinno porządkować proces przekazywania informacji. Niestety, jednocześnie zabijamy relacje z rozmówcą i tracimy okazję do dalszej interakcji.

Prezentacja z wykorzystaniem PowerPointa przypomina jazdę samochodem po nieznanym terenie z mapą na kolanach. Niebezpieczne dla prowadzącego i co gorsze również dla przechodniów (czyt. słuchaczy).

PS: PowerPoint powinien zostać wyeliminowany również ze względu na uszkodzenia kręgosłupa i skręcenia barków. Zmusza osoby prezentujące do ciągłego wygnania się w nienaturalny sposób (to wieczne zerkanie na slajd).

—————————————–

wpis pochodzi z mojego bloga - http://face2web.wordpress.com/

Pesymiści powiedzą: Trzeba najpierw rozpatrzyć niebezpieczeństwa projektu. Pamiętajmy, że na wdrożeniu Business Inteligence w firmie tracą dwie grupy pracowników: ci, którzy ręcznie przygotowują raporty dla menedżerów (to ich firmowy chleb powszedni i konkretne wynagrodzenie za konkretne działania) oraz analitycy, posiadający „wiedzę tajemną”, potrafiący w sposób, dla wielu ludzi magiczny, zamienić zwykłe dane w użyteczne informacje o strategicznym dla firmy znaczeniu. Ci ludzie, to „wrogowie” wdrażania rozwiązań Business Inteligence. I choć słowo „wrogowie” nie brzmi najlepiej, to z całą pewnością trzeba wziąć pod uwagę, że w takich osobach tkwi potencjał sabotażysty, który – mówiąc wprost – nie ma interesu w tym, by technologia odebrała im nieźle płatny etat. To ludzie, którzy mogą utrudniać wdrożenie. Poza tym – mówią pesymiści – BI, to koszty, na które mogą sobie pozwolić te firmy, które są w posiadaniu czegoś tak niecodziennego, jak komfort budżetowy. A przecież generalnie wyśmiewany Excel jest narzędziem, które spełnia wymagania zdecydowanej większości przedsiębiorstw. Po co więc strzelać z armaty do wróbla? Lepsze jest wrogiem dobrego!

Optymiści mówią: Zaimplementujmy BI. Sabotażystom zapewnimy alternatywne etaty, przeszkolimy ich, przesuniemy na inne stanowiska, damy im miejsce w sprzedaży, albo w marketingu. Wszyscy musimy umieć się dostosować do zmieniających się realiów. Przecież inteligencja biznesowa, to właśnie umiejętność dostosowania się do nowych warunków pracy, to elastyczność, których wymaga od nas rynek, niezależnie od tego, czy wdrażamy narzędzia BI, czy nie! Biznesowa Inteligencja, to nie tylko świeże informacje każdego ranka na biurku, ale i podpowiedzi – w którym kierunku iść, by te poranne informacje były jeszcze lepsze. Wystarczy tylko przekonać zarząd, że tego potrzebuje. A że to kosztuje? Zgoda, ale przecież nie cena jest kluczowa. Kluczowa jest potrzeba wzrostu i innowacyjności.

Są jeszcze realiści. Oni są bardziej wyważeni i mówią: Sukces wdrożenia BI, to dostarczanie informacji właściwym osobom, by podejmowały właściwe decyzje. Ale to przecież nie zależy od systemu, lecz od tego, czy ktoś go w ogóle będzie używał i w jaki sposób będzie to robił. Pamiętajmy też, że BI bazuje na wcześniejszych wdrożeniach, a więc jego sukces zależy od stopnia przygotowania organizacji do takiego procesu. Biznesowa Inteligencja przedsiębiorstwa budowana jest od samego dołu, jeśli marnie zbudowaliśmy system transakcyjny, to marne będą systemy wspomagania decyzji. Nie możemy też zapomnieć o trudnościach z akceptacją BI przez szeregowych „wklepywaczy” danych. Im z reguły trudno dostrzec sens swojej pracy, bo nie widzą jej rezultatu. A przecież tak wiele od nich zależy. A poza tym – mówią realiści – nie wszystko można wyrazić raportem. Czasem trzeba prezesowi spojrzeć głęboko w oczy i powiedzieć zwyczajnie - co słychać w firmie…

—————————————–

wpis pochodzi z mojego bloga - http://robertjesionek.blog.onet.pl/

Audyty bezpieczeństwa IT i przeprowadzanie testów penetracyjnych w instytucjach finansowych stało się powszechnie uznaną metodą cyklicznej weryfikacji i zwiększenia ogólnego poziomu zabezpieczeń w bankach. Bez względu na to czy mówimy o testach webaplikacji transakcyjnej, komponentów sieci banku, instytucji państwowej czy chociażby przedsiębiorstwa - istnieje pewien zestaw wspólnych dla wszystkich Klientów aspektów, pokrywających się metodycznie ze sobą. Jedną z takich dziedzin jest analiza ryzyka utraty bezpieczeństwa informacji. Jest to proces tworzenia (lub rozbudowy) zestawu obszernej dokumentacji, pozwalającej określić jakimi ryzykami narażone są obszary przeznaczonej do badań struktury, jakimi zasobami, architekturą sieciową dysponuje, jakiego typu transmisji danych używa, jakie elementy zagrożeń są najbardziej prawdopodobne, etc. Dzięki temu, iż dysponujemy ów wiedzą, jesteśmy w stanie wykorzystać zalety audytów i testów penetracyjnych w 100%.

Określmy na początku kilka bardziej ważnych obszarów, które uważane są często za kluczowe z perspektywy ogólnych zaznaczam, testów penetracyjnych instytucji finansowej. 1. Weryfikacja sieci (skanowanie sieci, podsieci, wersjonowanie oprogramowania, usług, serwerów, zapór sieciowych i innych urządzeń). Etap 1. pozwala na zebranie informacji o badanej sieci, topologii jak również używanych technologiach. 2. Weryfikacja urządzeń brzegowych. Etap 2 wyodrębiony często z przyczyn newralgiczności, gdyż jak wiemy routery brzegowe wymagają specjalnej architektury i rozwiązań, by mogły spełniać swe założenia funkcjonalne bezpiecznie.  3. Weryfikacja sieci bezprzewodowych i punktów dostępu. Etap 3 jest bardzo ważny, gdyż dotyczy chmury sieci w obszarze instytucji finansowej, której monitoring jest bardzo ważny z perspektywy bezpieczeństwa sieci przewodowej i osób znajdujących się w zasięgu. 4. Weryfikacja webaplikacji. To chyba kluczowy etap, zważywszy na pojęcie e-bankingu i bezpieczeństwa transakcji finansowych Klientów. 5. Weryfikacja bezpieczeństwa stacji roboczych i używanego oprogramowania. Etep 5 dotyczy lokalizacji wewnętrznych i znajdujących się w nich komponentów, mogących być źródłem ataku z wewnątrz. 6. Weryfikacja innego typu rozwiązań, funkcjonujących w strukturach sieciowych banku, takich jak serwery pośredniczące, systemy detekcji włamań i nadużyć, kontroli i analizy ruchu. Oczywiście nie da się w kilku punktach zamieścić wszystkich czynników i obszarów kluczowych z perspektywy bezpieczeństwa instytucji finansowej. Każda z nich bowiem posiada szereg odrębnych wymagań, technologii oraz rozwiązań, które różnią się od siebie diametralnie i wymagają unikalnego podejścia do zapewnienia im bezpiecznieństwa. To też poniekąd jest pięknem kryjącym się za tematyką bezpieczeństwa - Bezkres możliwości i obejść.

Bezpieczeństwo webaplikacji bankowej

Uznane praktyki programistyczne mówią, iż rozwiązania webowe w kontekście aplikacji transakcyjnych (co dotyczy ‘z założenia’ wszystkiego co zostaje napisane przez programistów), powinny być tworzone w oparciu o najwyższe, najbardziej restrykcyjne i najbezpieczniejsze praktyki. Coraz częściej instytucje finansowe zatrudniają dodatkowych specjalistów ds. bezpieczeństwa, którzy jako programiści nadzorują każdą nowopowstałą linię kodu. Istnieje szereg komercyjnych i darmowych rozwiązań, pozwalających na wsparcie poprzez automatyzację procesu testowania bezpieczeństwa kodu. Skanery identyfikujące podatności wynikające z błędów programistycznych powinny być jednak tylko dodatkiem, który zawsze powinien iść w parze z manualną weryfikacją kodu webaplikacji bankowych. Pamiętajmy również, iż skanowanie automatyczne rozwiązaniami automatyzującymi ten proces powinno być wykonywane jest na etapie fazy rozwoju kodu, a testy penetracyjne w kontekście manualnej weryfikacji kodu dopiero po tym etapie. Osobiście podchodzę do ‘fenomenu’ automatów wyręczających audytorów z pracy dość ostrożnie, gdyż wychwytują one tylko bardzo proste błędy programistyczne, dające zdefiniować sę odpowiednimi patternami.

Uważam, iż nic nie zastąpi ręcznej weryfikacji kodu przez profesjonalny zespół audytu IT.

W dalszej części artykułu poruszę kwestie związane z badaniem bezpieczeństwa wewnętrznych struktur sieciowych instytucji finansowych i weryfikacji poziomu ich bezpieczeństwa.

PJ

Aby powstała dobra strategia, przy jej opracowaniu korzystać należy z jak największej ilości informacji. Liczne źródła informacji niezbędne są zarówno do całościowego i prawdziwego określenia sytuacji wyjściowej, jak i do trafnego doboru instrumentów public relations. Już w pierwszym etapie procesu budowy strategii zaangażować trzeba cały zespół projektowy, a także w pewnym stopniu inne strony biorące pośrednio udział w projekcie. Opracowywanie strategii przy udziale przedstawicieli różnych środowisk wpływa na jej kompleksowość i profesjonalizm. W początkowym etapie prac, czyli podczas oceny sytuacji wyjściowej i analiz wizerunkowych, warto zaangażować otoczenie projektu. Oczekiwania oraz obawy interesariuszy są bowiem najważniejszym kluczem w określeniu trafnych celów promocyjnych projektu oraz doboru skutecznych narzędzi marketingowych. Na etapie planowania szczegółowych działań informacyjno-promocyjnych wyjątkowo istotne jest zaangażowanie zespołu projektowego. Zespół powinien przecież rozumieć wybór metod promocyjnych oraz ich przełożenie na zadania operacyjne.  Jeśli zespół, przy pomocy którego promocja będzie realizowana nie identyfikuje się z założeniami strategii, jej wdrożenie raczej się nie powiedzie.

W sektorze publicznym z public relations najlepiej potrafią korzystać miasta i regiony. Marketing miast rozwija się teraz dynamicznie. Większość dużych miast w Polsce już opracowała, bądź znajduje się w trakcie opracowania swojej strategii komunikacji i promocji. Tworzone są również koncepcje identyfikacji wizualnych. W efekcie tych działań miasto przyciąga nowe inwestycje, turystów i studentów. Zaproszenie szerszego grona uczestników do udziału w opracowywaniu strategii może przybrać różne formy. W trakcie pierwszego etapu, są to zwykle badania ankietowe lub konsultacje. W zależności jak szerokie jest środowisko, miasta mają możliwość organizacji debat z przedstawicielami różnych środowisk społecznych, biznesowych czy akademickich. Podejmowane są także różne próby porozumienia i współpracy z lokalnymi organizacjami i stowarzyszeniami. W ten sposób kreowane są strategie i systemy identyfikacji wizualnej będące pewnego rodzaju wypadkową stanu obecnego danego miasta i podpartej badaniami oraz analizami wizji tego miejsca należącej do środowisk opiniotwórczych. W ten sposób do promocji podchodzi się między innymi w Radomiu, Gdańsku czy Poznaniu. Takie podejście powinno również stanowić inspiracje dla projektów publicznych z innych dziedzin.

Prowadzenie konsultacji społecznych w projektach informatycznych pomaga zyskać akceptację otoczenia dla tworzonych rozwiązań. Jeśli projekt ma na celu rozwijać elektroniczną administrację, a więc w efekcie oferować korzyści szerokim grupom społecznym, konsultacje z wybranymi środowiskami są konieczne. Jest to również rodzaj zobowiązania dla zespołu realizującego dany projekt. Dokument strategii opracowany przy udziale otoczenia nie łatwo przecież po cichu schować w urzędniczej szufladzie. Stanowi on istotną motywację do realizacji założonej promocji, która nadal jeszcze w projektach informatycznych jest tematem abstrakcyjnym.

Zasada pierwsza: zbierajmy doświadczenia - niby coś oczywistego ale czy Twoja organizacja ma bazę doświadczeń z szacowania. Czy jesteś w stanie sprawdzić jak projekt w którym pracujesz był szacowany? Jestem zdania, że wynik każdego szacowania projektu powinien być gdzieś zapisany.

Zasada druga: szacujmy iteracyjnie - szacujmy kilkukrotnie w trakcie projektu, nanośmy poprawki do naszych szacunków. Nie bój się przyznać do błędu, niedopatrzenia. Faktem jest, że w momencie pierwszego szacowania nie wiadomo wszystkich uwarunkowań i ograniczeń. To nic okropnego, wszystko to wiemy po zakończeniu prac - ale wtedy już sie nie szacuje :). Moją rekomendacją jest szacowanie na zakończenie każdej iteracji, etapu, fazy (w zależności od metodyki przyjętej).

Zasada trzecia: rozróżnij proszę szacowanie od planowania - celem planu jest osiągniecie konkretnego wyniku celem szacowania jest określenie jakie wyniki są osiągalne. Szacowanie jest jedynie wsadem do planowania. Niestety różnica często się zaciera. Niestety…

Zasada czwarta: pytaj się osób wykonujących zadania – to oni wiedzą ile to powinno zająć

Zasada piąta: nie przeceniaj możliwości zespołu.

Zasada szósta:  szacuj na niskim poziomie szczegółowości – częstym przypadkiem w projekcie IT jest brak oszacowania pracochłonności na utworzenie odpowiedniego środowiska pracy

Zasada siódma: szacuj z wielu perspektyw – im więcej różnych spojrzeń tym lepiej.

Skoro były zasady to dla równowagi powinien pojawić się jakiś kwas :).  Słabością jakiejkolwiek metody, niezależnie od tego której by użyć jest to, że dobre wyniki szacowania pojawią się po dość odległym czasie od zainicjowania procesu szacowania prac w naszej organizacji. Mam tu na myśli to, że podstawą dobrego szacowania jest baza doświadczeń. Można co prawda skorzystać z doświadczeń światowych ale to nie oznacza, że nasza organizacja wykonuje projekty w ten sam sposób. Dlatego też istotne jest zainicjowanie procesu zbierania wiedzy o szacowaniach.

Na koniec krótkie zdanie - nie dajmy się zwariować. „Zaprzęgajmy” skomplikowane metody szacowania naprawdę do dużych jak na nasze możliwości projekty. W małych przedsięwzięciach szacowanie eksperckie wystarczy.