GoldenLine
Zaloguj się
Andrzej Sobczak

Andrzej Sobczak Profesor, Szkoła
Główna Handlowa

Temat: Jaki powinien być idealny język do modelowania...

Wiadomo, że każdy z języków stosowanych obecnie do tworzenia modeli architektury korporacyjnej ma swoje ograniczenia. Np. w mojej subiektywnej ocenie UML jest zbyt techniczny i złożony w przygotowywaniu modeli, których odbiorcami ma być również biznes. W przypadku BPMN jego zastosowanie ogranicza się tylko do procesów. Ta sama sytuacja występuje w przypadku EPC. ArchiMate jest ciągle mało popularny (chociaż moim zdaniem najbardziej zbliża się do ideału języka dedykowanego architektom korporacyjnym).

Więcej o wymaganiach na idealny język do EA i stanie wykorzystania obecnych notacji w Polsce - zapraszam na: http://architekturakorporacyjna.pl/jaki-powinien-byc-i...
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Jaki powinien być idealny język do modelowania...

zrobiłem małe prywatne "badanie" i wygląda na to, że jeśli potraktować EA jako model pojęciowy to notacje BPMN/UML wraz ze "śladowaniem" pozwalają na wykonanie modelu. Owszem "percepcja" modelu UML może być trudna ale UML nie zabrania stosowania stereotypów w postaci ikon co pozwala uzyskać łatwiejsze w percepcji diagramy.
....
Link do wypowiedziLink
Damian Kamiński

Damian Kamiński Zamieniam informacje
w wiedzę ...

Temat: Jaki powinien być idealny język do modelowania...

Im więcej obowiązków, tym mocniej stoję na stanowisku że należy wykonywać tylko tą pracę która przekłada się na wymierną realizację celów określonych przez „sponsora”.

Dokumentowanie czegokolwiek w taki sposób by było jednoznacznie czytelne i dla biznesu i dla „technicznych”, jest trudne do pogodzenia, by nie powiedzieć że praktycznie niemożliwe, w praktyce trzeba zrobić wersję np. w UMLu zrozumiałą dla „dostawców” i wersje „prozą” i to w konkretnym korporacyjnym dialekcie, dla „sponsorów”.
Osobiście sądzę, że problem wynika z potrzeb, biznes skupia się na tym „co osiągnie”, natomiast dostawca/wykonawca musi dostać wiedzę „jak to zostanie osiągnięte”.

Odpowiadając na postawione pytanie, sądzę że trzeba dokumentować „adekwatnie do potrzeb”, możliwie najprościej i w jak najbardziej minimalistyczny sposób, jeżeli biznes zrozumie, to wysoce prawdopodobne że ktoś kto otarł się o EPC, BPML, BPMN, UML czy ArchMate, również zrozumie.
Uwzględniając dodatkowo, jak dynamicznie mogą zmieniać się potrzeby, im bardziej wylewny sposób dokumentowania, tym mniejsza szansa na zamknięcie dokumentacji.
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Jaki powinien być idealny język do modelowania...

Wyobraźmy sobie, że mamy samochód, aby dobrze rozumieć jak działa i co ewentualnie naprawić, trzeba mieć jego dokładną dokumentację, najlepiej wykonaną w jakimś uznanym standardzie czyli tu rysunek techniczny, narzędzie na dzisiaj zapewne autoCAD.

Co mamy:

Im więcej obowiązków, tym mocniej stoję na stanowisku że należy wykonywać tylko tą pracę która przekłada się na wymierną realizację celów określonych przez „sponsora”.

ok

Dokumentowanie czegokolwiek w taki sposób by było jednoznacznie czytelne i dla biznesu i dla „technicznych”, jest trudne do pogodzenia, by nie powiedzieć że praktycznie niemożliwe, w praktyce trzeba zrobić wersję np. w UMLu zrozumiałą dla „dostawców” i wersje „prozą” i to w konkretnym korporacyjnym dialekcie, dla „sponsorów”.
Osobiście sądzę, że problem wynika z potrzeb, biznes skupia się na tym „co osiągnie”, natomiast dostawca/wykonawca musi dostać wiedzę „jak to zostanie osiągnięte”.

mając pełną dokumentację, można konkretnemu adresatowi wygenerować, zależnie od potrzeby, wygenerować samochodu albo szczegóły skrzyni biegów.
Odpowiadając na postawione pytanie, sądzę że trzeba dokumentować „adekwatnie do potrzeb”, możliwie najprościej i w jak najbardziej minimalistyczny sposób, jeżeli biznes zrozumie, to wysoce prawdopodobne że ktoś kto otarł się o EPC, BPML, BPMN, UML czy ArchMate, również zrozumie.

jak więc tu rozumie ów "minimalizm"??? Same wizualizacje bez kompletnej dokumentacji?
Uwzględniając dodatkowo, jak dynamicznie mogą zmieniać się potrzeby, im bardziej wylewny sposób dokumentowania, tym mniejsza szansa na zamknięcie dokumentacji.

Każdy dobry dokument "czegoś" ma ustalone poziomy szczegółowości (od ogółu do szczegółu). Jeżeli cokolwiek w firmie się zmienia to i tak jest to gdzieś dokumentowane, dobra dokumentacja AE stanowi warstwę abstrakcji a na szczegóły (które są w firmach) sie powołuje...

a co mamy w wielu analizach? Mamy niestety głupotę (tak, głupotę) w rodzaju: diagramy BPMN obrazujące szczegóły przepisane z zakresów obowiązków (mój ulubiony kretynizm: proces uzgadniania treści dokumentu, to nie proces a prosty zapis w zakresie obowiązków co i z kim uzgadniamy, robimy to sami na bazie umiejętności komunikacji z ludźmi ale wg. recepty z diagramu). I taką dokumentacje należy natychmiast wyrzucić bo jest szkodliwa. a to tylko jeden z wielu fragmentów złej dokumentacji w firmach...
Link do wypowiedziLink
Damian Kamiński

Damian Kamiński Zamieniam informacje
w wiedzę ...

Temat: Jaki powinien być idealny język do modelowania...

Zgadzam się w całej rozciągłości. Natomiast co próbowałem podkreślić, to fakt że odbiorcy dokumentacji dość często nie rozumieją co w niej jest zapisane.

Przez analogię do autoCAD'a, można wygenerować fragment schematu, natomiast jeżeli będzie to przekrój silnika czy skrzyni biegów, raczej nie spodziewał bym się zbyt wielu konstruktywnych uwag od biznesu, z drugiej strony, gdy na przekroju będzie wnętrze kabiny, to jest spokojnie kilkadziesiąt godzin średnio wartościowej dyskusji o kolorach i ergonomii.

Ale masz racje, dokumentować trzeba, bo generalnie brak dokumentacji mści się w trybie ekspresowym.

Co do minimalizmu.

Ja osobiście wolę używać samych prostokątów, obojętnie co reprezentują. Gdy reprezentują coś szczególnego to wolę w którymś rogu zapisać ; :Aktor, :Baza, :Obiekt, :Dokument, :Tabela itd - nie trzeba tłumaczyć niewtajemniczonym co oznacza ten bloczek.

To samo co do relacji, wolę dopisać przy liniach jak to odczytywać np SPÓŁKA ---- ODDZIAŁY i przy linii od strony spółki napisać "dzieli się na" a od strony odziały przy tej samej linii "składają się na".

Pisania trochę więcej niż przy typowych diagramach, ale z drugiej strony taki diagram da się czytać jak "biznes prozę", więc to taki mój kompromis.

Nie twierdzę że optymalny, czy że jedyny słuszny, ale sprawdza się w moich realiach.
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Jaki powinien być idealny język do modelowania...

Damian K.:
Zgadzam się w całej rozciągłości. Natomiast co próbowałem podkreślić, to fakt że odbiorcy dokumentacji dość często nie rozumieją co w niej jest zapisane.

wtedy jest to zła dokumentacja (bo dobra zawiera adnotację co i dla kogo zostało napisane)
Ja osobiście wolę używać samych prostokątów, obojętnie co reprezentują. Gdy reprezentują coś szczególnego to wolę w którymś rogu zapisać ; :Aktor, :Baza, :Obiekt, :Dokument, :Tabela itd - nie trzeba tłumaczyć niewtajemniczonym co oznacza ten bloczek.

wtedy w zasadzie jest to "diagram klas i stereotypy" :), ale zachęcam do poznania zagadnień semiotyki czyli jak ludzie odbierają znaki, ikony mają głęboki sens jako element usprawnienia percepcji, to troszkę jak dyskusja czy lepsze są europejskie znaki drogowe (piktogramy) czy amerykańskie (napisy). Nauka udowodniła, ze właściwie dobrane piktogramy (z naciskiem na właściwe) są przez mózg szybkiej intepretowane,

wyobraź sobie, że biegniesz "za potrzebą" (silnie juz narastającą) w galerii handlowej i wśród setek napisów i masz wychwycić napis "toaleta dla meżczyzn"... ja wolę jednak trójkącik ;) jako symbol miejsca którego szuka...:).

Pisania trochę więcej niż przy typowych diagramach, ale z drugiej strony taki diagram da się czytać jak "biznes prozę", więc to taki mój kompromis.

z uwagami jak powyżej... papier nawet A4 z kilkunastoma jednakowymi prostokątami połączonymi kilkunastoma liniami wymaga skupionego czytania... po drugie systemy CASE to nie tylko rysowanie, CASE w analizach i raportowaniu to nie "prostokąty" a procesy, czynności, dokumenty, klasy itp..
Nie twierdzę że optymalny, czy że jedyny słuszny, ale sprawdza się w moich realiach.

dopóki są to tylko rysunki na pewno się sprawdza...
Link do wypowiedziLink
Damian Kamiński

Damian Kamiński Zamieniam informacje
w wiedzę ...

Temat: Jaki powinien być idealny język do modelowania...

Tak przy okazji tematu, faktycznie ... jeżeli "wiedzę" utrzymuje się w Wordzie i SharePoincie (dlaczego to już osobny temat), to faktycznie można sobie pozwolić na "elastyczność" w doborze reguł których się przestrzega.

Natomiast inaczej jest gdy chce się stworzyć faktycznie model, w czymś grubym klasy "case".

Masz jakieś doświadczenia z ARIS'em ? Inne niż EPC ? Pytam dlatego że koledzy z Software AG, jak i Ci przejęci z IDS'u twierdzą że UML w ARISie to nie najlepszy pomysł. Możesz coś dodać w tej kwestii ?
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Jaki powinien być idealny język do modelowania...

Masz jakieś doświadczenia z ARIS'em ? Inne niż EPC ? Pytam dlatego że koledzy z Software AG, jak i Ci przejęci z IDS'u twierdzą że UML w ARISie to nie najlepszy pomysł. Możesz coś dodać w tej kwestii ?

mogę to potwierdzić ;) podobnie jak BPMN... w ARIS'ie

przy okazji, wygrzebałem z przed pięciu lat; :)

http://it-consulting.pl/autoinstalator/wordpress/2007/...

skrajny przypadek (zapewne Ciebie nie dotyczy) tu:
http://it-consulting.pl/autoinstalator/wordpress/2013/...Ten post został edytowany przez Autora dnia 10.06.13 o godzinie 08:59
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Zaproszenie na konwersatori...




Wyślij zaproszenie do
Anuluj