lis
27

Jaki powinien być idealny język modelowania EA?

Źródło: Andrzej Sobczak
Print Friendly

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).W praktyce niedoskonałości obecnych języków modelowania rozwiązywane są na trzy sposoby:

  • Używanie kilku języków (w szczególności, jeżeli to wspiera narzędzie – np. Enterprise Architect to umożliwia).
  • Wprowadzenie własnego języka (na zasadzie „trójkącików i prostokącików” lub w wersji dla bardziej ambitnych – poprzez stworzenie dedykowanego profilu w UML).
  • Pogodzenie się z niedoskonałościami i ograniczeniami obecnych rozwiązań (na zasadzie „lubi się to, co się ma”).

Dlatego, od jakiegoś czasu nurtuje mnie pytanie jakie właściwości powinien mieć idealny język modelowania architektury korporacyjnej?

Pozwoliłem sobie zaproponować taką listę życzeń:

  • powinien umożliwiać modelowanie w czterech domenach architektonicznych (biznesowej, danych, aplikacji i technicznej) – zarówno wewnątrz tych domen jak i między domenami (oznacza to, że powinny być wprowadzone odpowiednie byty jak i relacje między tymi bytami);
  • powinien umożliwiać tworzenie modeli architektonicznych na poziomie strategicznym, segmentów jak i potencjału;
  • powinien wspierać paradygmat usługowy;
  • powinno dać się w nim zamodelować (przynajmniej na poziomie pewnej abstrakcji) elementy: strategii organizacji, zarządzania projektami, zarządzania usługami oraz zarządzania budową systemów IT;
  • powinien umożliwiać modelowanie pryncypiów, standardów, wymagań (funkcjonalnych i niefunkcjonalnych) oraz decyzji architektonicznych;
  • powinien uwzględniać kwestie modelowania ryzyka i bezpieczeństwa;
  • powinien wspierać tworzenie wzorców architektonicznych i architektonicznych modeli referencyjnych;
  • powinien być prosty do nauczenia przez biznes, a modele stworzone za jego pomocą powinny być zrozumiałe dla nie-informatyków;
  • powinien składać się z jądra (części obowiązkowej) i części rozszerzalnej (extensions);
  • każdy z bytów powinien mieć minimalny zbiór atrybutów, który w razie potrzeby można rozszerzyć;
  • każda z relacji (każdy koniec relacji) powinna móc być nazwana oraz powinna istnieć możliwość określenia ich liczności;
  • powinien być rozszerzalny o nowe elementy (na poziomie bytów jak i relacji) – tak aby móc uwzględnić specyficzne potrzeby poszczególnych organizacji;
  • powinien dostarczać predefiniowanych punktów widzenia (a w dokumentacji powinien być wyczerpujący opis, tych punktów widzenia);
  • powinien być tak przygotowany, żeby można było uruchamiać symulacje graficzne na bazie modeli stworzonych za jego pomocą (mam świadomość, że jest to głównie zależne od narzędzia, w którym tworzone są modele);
  • powinien być tak przygotowany, żeby można było wykonywać analizy ilościowe na bazie modeli stworzonych za jego pomocą (mam świadomość, że jest to głównie zależne od narzędzia, w którym tworzone są modele);
  • powinien on zapewniać import/eksport pomiędzy różnymi narzędziami do modelowania;
  • powinien mieć spójny metamodel;
  • powinien być kompletny;
  • powinien być intuicyjny w użyciu;
  • powinien mieć szerokie wsparcie narzędziowe – w tym narzędzi  open source;
  • powinien być rozpoznawalnym na świecie standardem;
  • powinien być udostępniony do nieodpłatnego wykorzystania – dotyczyć to powinno zarówno samej specyfikacji jak i modeli stworzonych za pomocą tego języka;
  • powinien wspierać uznany/uznane proces/procesy architektoniczne, ale powinna być możliwość jego użycia w oderwaniu od określonego procesu architektonicznego.
Mam świadomość, że ta lista – jest tylko wierzchołkiem góry lodowej, czego oczekują architekci korporacyjni, od języka do tworzenia modeli.

Po napisaniu tej listy zorientowałem się, że większość tych wymagań spełnia ArchiMate (dlatego na początku wpisu stwierdziłem, ze jest to mój faworyt). A jak wygląda sytuacja w praktyce w Polsce? Z badań, które przeprowadziłem w 2012 roku (oraz z ich wcześniejszej edycji  – w roku 2010) wynika, że najpopularniejszym językiem modelowania jest UML (por. rysunek 1).

 

Rysunek 1. Popularność języków do tworzenie modeli architektury korporacyjnej
Źródło: Opracowanie własne.

Można wskazać jedną bezpośrednią tego przyczynę – architekturą zajmują się ludzie od IT, a oni znają ten właśnie język. Cieszy mnie wzrost popularności języka ArchiMate i zastanawia duża popularność „notacji własnych”.

Na koniec, pozostaje mi wyrazić nadzieję, że w przyszłości (mam nadzieję, że nie za bardzo odległej) powstanie wersja 3.0 ArchiMate, która będzie uwzględniać wszystkie pozycje z mojej listy życzeń.

Andrzej Sobczak

Profesor, kierownik Zakładu Zarządzania Informatyką w Instytucie Informatyki i Gospodarki Cyfrowej SGH. Ma ponad 8 letnie doświadczenie we wdrażaniu koncepcji architektury IT i architektury korporacyjnej. Posiada certyfikaty TOGAF 8/9, ArchiMate 2.0, ITIL, MSP.

Polecane wpisy

TAGI DLA WPISU

Dyskusja do artykułu “Jaki powinien być idealny język modelowania EA?

  1. Wydaje mi się, że UML jak najbardziej ale chyba ideałem jest “zestaw” notacji i narzędzie CASE pozwalające na tak zwane śladowanie. Wydaje mi się, po moich ostatnich “badaniach”, że OMG dając “kilka notacji” daje także spójność pojęciową, w efekcie np. UML plus BPMN w 100% zastępuje ArchiMate.

  2. Witam,
    moim zdaniem jedną z przyczyn (choć pewnie nie kluczową) większej popularności UML w stosunku do ArchiMate jest dostępność oferty szkoleniowej oraz … cena tej oferty.
    Pozdrawiam

  3. Myślę, że do pewnego poziomu użycie języka Archimate w organizacji ma sens, gdzie staramy się o zapewnienie jednolitego języka modelowania między architektami korporacyjnymi, architektami rozwiązań, architektami biznesowymi, analitykami, itd. Głównie poprzez wykorzystanie do utrzymania spójnej dokumentacji wzdłuż całej organizacji. Czy jednak strona biznesowa oczekuje od nas takich właśnie modeli? Nie jestem co do tego przekonany. Spotykam się z sytuacją wręcz odwrotną. Przed spotkaniem wszystkie takie modele znikają z prezentacji i zamieniane są na język zrozumiały dla biznesu, np. wykresy, liczby, wnioski, itd. Przede wszystkim dlatego, żeby uniknąć wrażenia, że jest to tylko techniczne spojrzenie na problem. Jesteśmy ludźmi IT i tak jesteśmy postrzegani. Starajmy się to zmienić… Oczywiście z biegiem czasu w organizacji będzie więcej osób zainteresowanych wglądem w takie modele. Pozdrawiam

Dodaj komentarz

W celu wzięcia udziału w dyskusji jako zalogowany użytkownik możesz zalogować się poprzez jeden z poniższych serwisów.

Twój adres e-mail nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Captcha Captcha Reload

Możesz użyć następujących tagów oraz atrybutów HTML-a: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>