Jaki powinien być idealny język modelowania EA?

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