Architektura korporacyjna z OMG.org

Mamy więc pomysł o wdzięcznej nazwie Architektura Korporacyjna. Po nam to? Po co nam taka dokumentacja? Przykłady korzyści z jej posiadania: mamy "na tacy" model systemy zależności (analizy wpływu) pozwalający natychmiast ocenić ryzyka związane z wzajemnym wpływem na siebie procesów, ludzi, zasobów (np. jakie skutki będzie miało wyłączenie konkretnego serwera czy spóźnienie do pracy konkretnego pracownika), mamy "na tacy" wymagania na oprogramowanie, bez niepotrzebnego "zwinnego" ich poszukiwania metodą prób i błędów, niezależnie od tego czy kupujemy nowe czy wymieniamy (niestety, tak zwane zwinne metody to nie raz bardzo duże koszty "zarzuconych bocznych ścieżek" odkrywanych burzą mózgów), od razu zauważymy, że idea posiadania monolitycznego systemu ERP II nie bardzo ma sens (to usztywnia organizacje oraz tworzy potężny [["single point of failure"]], złośliwi dodają "single point of big cost" :)), i najważniejsze: jak tylko przeprowadzimy analizę i wykonamy model AK szybko wychwycimy tak zwane osierocone wymagania na oprogramowanie, osierocone stanowiska pracy, osierocone procedury, ... (osierocone: niewykorzystywane), to nie raz źródło samo w sobie - eliminacja "sierot" - ogromnych oszczędności, i inne ... Jak tym zarządzać? Na pewno nie ręcznie, bez oprogramowania CASE w zasadzie nierealne. Czy to kosztowne? Hm... kłania się analiza ROI, więc każda organizacja ma swój próg rentowności. Jednak od siebie powiem tak: oszczędności pojawiają się natychmiast w postaci identyfikacji "sierot". Kolejny etap oszczędności to reorganizacja kosztów i ryzyk zarządzania organizacją, kosztów posiadania oprogramowania, kosztów jego rozwoju, kosztów zakupu i tworzenia. Dobra wiadomość: początek każdy już ma w postaci prowadzonej dokumentacji w dziale HR.

Continue ReadingArchitektura korporacyjna z OMG.org

Analiza oddziaływania i jakość modelowania

Model zawierający wyżej opisane śladowania (i tylko taki!) pozwala na analizę zalezności, np. chcemy dowiedzieć się na co ma wpływ Proces_2, wtedy powinien powstać np. taki diagram: Jak widać, śladowanie jest tu warunkiem koniecznym dlaczego? Taki model może powstać "automatycznie" (narzędzie do modelowania musi posiadać taka funkcjonalność). jednak to nie jedyny warunek: model musi zachowywać formalna poprawność, czyli nie używamy pojęcia Rola (pas na modelu procesów) do symulowania "systemu" który coś robi, bo oprogramowanie to narzędzie człowieka (rola w procesie), specyfika użycia danego narzędzia to umiejętności aktora (użytkownika) i jest to co najwyżej problem skojarzenia danej czynności (procesu) z dokumentem opisującym procedurę lub instrukcję użytkownika (to także narzędzie powinno umożliwiać). Wszelkie łamanie formalizmów notacji odnosi taki sam skutek jak np. wykorzystywanie pól w bazie danych do przechowywania innych danych niż te z nagłówka np. wpisywanie drugiego imienia do pola Nazwisko czy nazwy dzielnicy w pole Miasto. Z takiej bazy danych żaden sensowny raport już nie powstanie. Jeżeli na modelu procesów użyto symboli w innych znaczeniach niż to wynika z użytej notacji żadnej sensownej informacji też nie uzyskamy... to już nie modele tylko zwykłe obrazki.

Continue ReadingAnaliza oddziaływania i jakość modelowania

Scenariusze biznesowe w architekturze korporacyjnej

Kluczowym narzędziem budowania scenariuszy są modele, te jednak muszą być sformalizowane ([[użycie notacji formalnych]]), w przeciwnym wypadku są "niestetowalne" (w projektach bazujących na AK stosowana jest z reguły notacja ArchiMate). TOGAF to nie jedyna metodologia, w której można spotkać idee użycia scenariuszy. [[The Open Group]] nie ma "monopolu" ani na metody scenariuszowe ani na ([[notację ArchiMate]] stosowaną w projektach AK, która także nie jest objęta żadnym patentem ani inną ochroną prawną. Tak więc zachęcam to brania tej metody pod uwagę, szczególnie w ryzykownych i dużych projektach.

Continue ReadingScenariusze biznesowe w architekturze korporacyjnej

Wymagania na coś dużego – w czym problem?

Producenci różnych rzeczy zdają sobie sprawę, że koszty podjęcia właściwej decyzji przy skomplikowanych produktach są spore i ludzie będą podejmować decyzje błędne, to pozwala działać na rynku firmom, które w przeciwnym wypadku by upadły. I jak teraz wyglądają w Państwa oczach zakupy i wdrożenia dużych gotowych systemów? Jak to robić lepiej? Po pierwsze nie kupować "dużych i drogich zintegrowanych systemów" bo to duże ryzyko, kupować mniejsze, łatwiejsze do opisania, projektować te, które są zbyt dużym ryzykiem w przypadku złego wyboru. Jeżeli już z powodu ryzyka mamy poświęcić duży budżet na kosztowne specyfikowanie oprogramowania to sygnał, że należy je za te pieniądze po prostu zaprojektować i wykonać. Niestety nie ma prostej odpowiedzi jak to robić "dobrze". Chyba, że będzie to propozycja następującego procesu: analiza biznesowa zdefiniowanie celu zaprojektowanie architektury systemu (to jako system należy rozumieć organizację wraz z wspierająca ją informatyką), zmierzamy w kierunku tak zwanej [[architektury korporacyjnej]] zidentyfikować oczekiwane od oprogramowania usługi (wymagania), podzielić je na odrębne obszary dziedzinowe, dla każdego obszaru dziedzinowego poprowadzić odrębny projekt wyboru rozwiązania. wybrać rozwiązania. Zwracam uwagę drobny szczegół: wybory produktu dokonujemy na końcu, nigdy na początku!

Continue ReadingWymagania na coś dużego – w czym problem?

Cloud Computing we Wrocławiu

Podstawową różnica pomiędzy CC a SaaS jest to, że oprogramowanie SaaS to po portu zdalny dostęp do aplikacji: użytkownik otrzymuje adres w sieci ([[URL]]), login i hasło dostępu. W przypadku CC, użytkownik nie widzi nic, poza ewentualnie nową opcją w aplikacji, której używa (np. pojawi się polecenie Renderuj w programie do tworzenia grafiki wektorowej). Gdyby chodziło o zewnętrzne składowanie plików, zapewne tego nie zobaczy. Po prostu administratora "przełączy" nasze oprogramowanie (naszą stację roboczą) do innego, zdalnego, systemu składowania plików. Na koniec ciekawostka, o której wspominam od kilku lat: monolityczne system ERP odchodzą (powoli, bronią się strasznie ;)) do lamusa. Bo...

Continue ReadingCloud Computing we Wrocławiu