Visual Paradigm 14.0 czyli efektywniejszy analityk

19 Grudnia opu­bli­ko­wa­no nową wer­sję pakie­tu Visual Paradigm: 14.0, w sto­sun­ku do poprzed­nie (13.2) wie­le ulep­szeń i kil­ka nowych zaba­wek”. Nie będę opi­sy­wał wszyst­kich (szcze­gó­ły na stro­nie pro­du­cen­ta, link na koń­cu artykułu). 

Na począ­tek waż­na uwa­ga i wyja­śnie­nie: korzy­sta­nie z narzę­dzi CASE z rów­no­le­głym two­rze­niem doku­men­tów na boku”, z uży­ciem pakie­tów biu­ro­wych jest kom­plet­nie pozba­wio­nym sen­su podej­ściem: tra­ci­my 3/4 war­to­ści tych narzę­dzi, jaką jest gene­ro­wa­nie ad-hoc wyso­kiej jako­ści, spój­nej, kom­plet­nej i nie­sprzecz­nej doku­men­ta­cji. Modele two­rzy­my z kil­ku powo­dów: zapi­su­je­my wyni­ki ana­li­zy, pro­jek­tu­je­my roz­wią­za­nia, testu­je­my je, ale przede wszyst­kim prze­ka­zu­je­my tę wie­dzę, czy­li two­rzy­my doku­men­ty opi­su­ją­ce efek­ty naszej pra­cy. Główną pra­cą jaką wyko­nu­je ana­li­tyk jest ana­li­za i pro­jek­to­wa­nie. Jeżeli więc two­rze­nie doku­men­tów zaj­mu­je mu wię­cej niż umow­ne 20%, sta­je się po pro­stu nie­efek­tyw­ny czy­li bar­dzo kosz­tow­ny. Często spo­ty­kam się z sytu­acją gdy tak na praw­dę 90% cza­su ana­li­zy zaj­mu­je spo­ty­ka­nie się i mozol­ne two­rze­nie doku­men­tów, 10% to fak­tycz­na ana­li­tycz­na i twór­cza pra­ca. To mega mar­no­traw­stwo (lub kom­plet­ny brak sza­cun­ku dla zama­wia­ją­ce­go). Dlatego gene­ro­wa­nie wyso­kiej jako­ści mery­to­rycz­nej doku­men­ta­cji (a nie tyl­ko ślicz­nie sfor­ma­to­wa­nej) jest klu­czo­wym ele­men­tem dobre­go pakie­tu CASE (poza oczy­wi­ście zesta­wem nota­cji i ich zgod­no­ścią ze stan­dar­da­mi). Tu tyl­ko wspo­mnę, że od wie­lu lat nie uży­wam edy­to­rów tek­stów do two­rze­nia pro­duk­tów swo­jej pra­cy (w tym obsza­rze). (wię­cej…)

Czytaj dalejVisual Paradigm 14.0 czyli efektywniejszy analityk

Visual Paragim Agilian 11.0

Pojawiła się oczekiwana wersja 11 pakietu CASE firmy Visual-Paradigm. Przede wszystkim rozwój produktu idzie w kilku głównych kierunkach: wsparcie dla wizualnego projektowania aplikacji (mock-up'y, kolejne ułatwienia w tworzeniu i integrowaniu modeli UML), stały rozwój wsparcia dla architektury korporacyjnej (to narzędzie pozwala tworzyć modele powiązane ze sobą, pozwala na prowadzenie analiz wpływu i wielu innych, wspiera także notację ArchiMate) oraz na prawdę bardzo silne wsparcie dla pracy grupowej. Co dzisiaj ogłasza producent: Visual Paradigm International Limited today [16.12.2013] announced the release of Agilian (AG) 11.0, a Visual Modeling tool for Agile…

Czytaj dalejVisual Paragim Agilian 11.0

ArchiMate i TOGAF. Czy nie do zastąpienia?

The Open Group zdaje się ignorować to, że pojęcie architektury korporacyjne to nie ich pomysł (ich pomyłem jest TOGAF, jeden z wielu systemów ram EA). [...] Więc teza jakoby nie dało się zastąpić ArchiMate innymi notacjami, w modelowaniu Architektury Korporacyjnej, jest moim zdaniem mocno naciągana.

Czytaj dalejArchiMate i TOGAF. Czy nie do zastąpienia?

c.d. nt. Architektury Korporacyjnej

Po co dokumentować (modelować) AK? Przede wszystkim po to by zrozumieć jak działa organizacja, a potem by móc świadomie, znając ryzyko, podejmować decyzje o wprowadzaniu zmian do niej. [...] Czy to musi być jakiś standard np. TOGAF? Nie jestem przekonany. ArchiMate (notacja zalecana w TOGAF) to nic innego jak system pojęciowy. Czy mamy wybór? Oczywiście, że mamy. Od dawna OMG dostarcza sprawdzone i otwarte standardy notacyjne.

Czytaj dalejc.d. nt. Architektury Korporacyjnej

Korzyści z Architektury Korporacyjnej

Od czego należy zacząć? Od zbudowania własnej (lub własnego wariantu) metodyki jej tworzenia oraz zatrudnieniu Architekta. Czy to powinien być własny pracownik? Moim zdaniem nie, gdyż po pierwsze nie będziemy w stanie obciążyć go pracą na 100%. Po drugie powinien to być ktoś z zewnątrz, by nie był uwikłany w wewnątrzorganizacyjne zależności - Architekt korporacyjny nigdy nie powinien być interesariuszem w projekcie związanym z reorganizacją (podobnie jak lekarz domowy to raczej nikt z domowników).

Czytaj dalejKorzyści z Architektury Korporacyjnej

Teoria komunikacji, dżungla ram i szkieletów

Wpadła mi niedawno w ręce książka: How to survive in the jungle of Enterpice Architecture Frameworks (autor Jaap Schekkerman, na Amazon.com dostępny fragment w tym spis treści). Dla mnie po lekturze tej książki nasuwa się jeden wniosek: moda na TOGAF to marketing The Open Group. Są inne, moim zdaniem ani gorsze ani lepsze, "ramy" architektoniczne (książka opisuje ich wiele). Podtytuł książki mówi wiele: Creating or choosing an Enterprise Architecture Framework (Tworzenie lub wybór ram architektury korporacyjnej). W zasadzie wystarczy wziąć przytaczaną powyżej definicję AE i podjąć powyższą decyzję: stworzyć lub wybrać. Nie jest to - tworzenie - łatwe, większość więc wybiera gotowe, jednak to jedynie ramy dlatego i tak nie da się tu niczego zastosować jak recepty.

Czytaj dalejTeoria komunikacji, dżungla ram i szkieletów

TOGAF or not TOGAF więc może Zachman

Badanie przydatności TOGAF/ArchiMate mam chyba za sobą (zapewne nie na miarę doktoratu ale troszkę jednak tak, chociaż...;)).  Na stronie mojego kolegi: ArchitekturaKorporacyjna.pl (polecam analitykom),  w jednym z artykułów pojawia się ciekawe stwierdzenie: TOGAF wskazuje, że niewłaściwe podczas modelowania jest bezpośrednie wiązanie procesu [biznesowego, jak sądzę] z aplikacją go wspierającą ? elementem pośrednim powinna być funkcja ? czyli: aplikacja wspiera realizację funkcji, a funkcja obejmuje cały proces lub jego fragment (w zależności od poziomu dekompozycji funkcji biznesowej). (Komentarze do TOGAF ? metamodel zawartości (cz. II) | Architektura Korporacyjna). i to jest coś co…

Czytaj dalejTOGAF or not TOGAF więc może Zachman

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.

Czytaj dalejArchitektura korporacyjna z OMG​.org

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.

Czytaj dalejScenariusze biznesowe w architekturze korporacyjnej

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...

Czytaj dalejCloud Computing we Wrocławiu

Pokazać więcej z sensem… ArchiMate

Tu pokażę przykład jak notacja ArchiMate radzi sobie z problemem łączenia biznesu, oprogramowania i technologii. A gdzie BPMN i UML? Ano każdy proces (przyjęcie zamówienia, kompletacja, fakturowanie) w kontekście szczegółów przepływu pracy, modelowany byłby w notacji BPMN (konkretne role, dokumenty, czynności). Pozostałe warstwy operują pojęciami, których szczegóły można (należy) modelować już w notacji UML. Usługi mapują się na przypadki użycia, pozostałe to architektura: komponenty oprogramowania, dane, architektura techniczna. Jak widać, ArchiMate pozwala na tym poziomie abstrakcji na więcej niż same BPMN czy UML, ale też nie zastępuje ich. Wzbogaca także system pojęciowy na potrzeby analizy biznesowej co pozwala wiernie odtworzyć rzeczywistość biznesową w sposób zrozumiały dla "biznesu". Jako podsumowanie przytoczę jeszcze raz znany już tu diagram...

Czytaj dalejPokazać więcej z sensem… ArchiMate

Co jest wadą większości analiz biznesowych?

To, że są one tak na prawdę tylko uporządkowanym zapisem wywiadów z klientem a nie faktyczną analizą organizacji i jej potrzeb (bo nie koniecznie jej pracowników!) i celów biznesowych. Jakie są treści tekstowego lub tabelarycznego zapisu wywiadów? NIEJEDNOZNACZNE! Jakie są niesformalizowane, swobodnie tworzone diagramy procesów? NIEJEDNOZNACZNE! Jakie są słowne opisy struktury oprogramowania jakie ma powstać? NIEJEDNOZNACZNE! Co zrobić? Używać już na etapie analizy biznesowej i projektowania sformalizowanych narzędzi takich jak standardowe notacje i metodyki, wtedy opisy będą JEDNOZNACZNE. Czy to trudne? Tak, w końcu te 70% porażek to nie przypadek? ( czytaj cały artykuł: Analityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych!). Dlaczego tak jest? Bo oprogramowanie jest tworzone z pomocą języków programowania a te SĄ sformalizowane. Nie da się skompilować do postaci systemu ERP "luźnej prozy". Napisałem to w Listopadzie 2011, dzisiaj ciąg dalszy. Na początek dodam jeszcze moją konkluzję z pewnej konferencji: Tak więc język formalny, użyta notacja, czyni projekt wartościowym [jednoznacznym]. Bez tego raczej nie znaczy on po protu nic. (Modelowanie procesów biznesowych - dlaczego mają sens tylko metody formalne i uznane notacje). Jak to mówią: mocne słowa, ale nie zapominajmy, że mało który projekt biznesowy IT kończy się w terminie i zamyka w założonym budżecie. Zastanówcie jak były dokumentowane Wasze "nieudane" projekty...

Czytaj dalejCo jest wadą większości analiz biznesowych?

Koniec treści

Nie ma więcej stron do załadowania