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

Target Operating Model, 7S framework i i nne

Od czasu do czasu jestem pytany o różne "frameworki" i metodyki dotyczące "całościowego opisu firmy". Można spotkać wiele różnych, lepszych lub gorszych modeli i szablonów, ram (frameworków), jednak moim zdaniem, podejście minimalistyczne (patrz [[brzytwa Ockhama]]) jest najlepsze. Zmusza do zrozumienia istoty rzeczy, bez maskowania niewiedzy nowymi i, nie raz, sztucznymi pojęciami. Drugim powodem, który moim zdaniem leży u podstaw pomysłów na "nowe modele", jest prawo autorskie. Opracowanie unikalnego "frameworka" czyni z autora takiego dzieła "właściciela metody", za którą ma prawo pobierać opłaty licencyjne (przykładem jest np. TOGAF i notacja ArchiMate chronione…

Czytaj dalejTarget Operating Model, 7S framework i i nne

Przewodnik po Architekturze Korporacyjnej

Mam w ręku książkę Guide to Enterprise IT Architecture (Springer Professional Computing, autorzy Col Perks, Tony Beveridge). Co prawda wydana w 2003 roku jednak, autorzy skupili się na pryncypiach dzięki czemu uzyskali pewna "ponadczasowość". Co prawda autorzy powołują się dość często na TOGAF, ale książka jest nie o TOGAF'ie (jest tu traktowany jako przykład ram) a o tym czym jest (jak postrzegać) architekturę korporacyjną, zwracają uwagę, że chodzi o cel a nie o dokumentację. Nie jest to absolutnie żaden podręcznik, jest to książka ukierunkowana na pokazanie czym jest architektura korporacyjna, jakie…

Czytaj dalejPrzewodnik po Architekturze Korporacyjnej

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
Read more about the article Semantic Core czyli bat na szczegóły
Semiotic/Semantic Triangle in SBVR Terms

Semantic Core czyli bat na szczegóły

Bardzo często zastanawiam się, nad przyczynami porażek projektów, przyczynami tego, że jedne są lepsze inne gorsze, a gorszy to taki, który wymyka się spod kontroli a ostateczny efekt (produkt), uzyskany po znacznie dłuższym czasie niż planowano, jest zaskoczeniem dla wszystkich. Na to nakłada się problem przekazywania wiedzy pomiędzy kolejnymi etapami projektu, gdzie największym ryzykiem jest zrozumienie problemu i przekazywanie wiedzy przez samego zamawiającego. Gdzie problem? Ten artykuł polecam "biznesowi" który szuka przyczyn swoich problemów, i tym (nie tylko analitykom), którzy mają ambicje robić coś w kierunku poprawy tego stanu rzeczy, zamiast uznawać obecne statystyki za pewnik bo "takie są fakty". [...] Ktoś może powiedzieć: biznes tego (notacje, modele itp.) nie rozumie. I ma racje, bo to narzędzia a nie produkty analiz. Produktem analizy dla biznesu są zawsze rekomendacje (wymagania na oprogramowanie to także rodzaj rekomendacji brzmiącej: zalecam by takie warunki spełniało to oprogramowanie). Zamawianie przez biznes modeli jako takich, to jakieś koszmarne nieporozumienie. To tak jak by np. prawnik, jako produkt zlecenia "opinia prawna" oddał wybrany stos kodeksów z komentarzami. Nie, dobry prawnik oddaje jedna stronę rekomendacji: opinie prawną. To, że skorzystał z tych kodeksów to jego narzędzie pracy, możliwe, że załączy je do tej tej opinii (ale raczej jako materiał dla innego prawnika lub audytora).

Czytaj dalejSemantic Core czyli bat na szczegóły

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

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

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