Enterprise Architect w Gartner Magic Quadrant

Firma Gartner raz do roku publikuje tzw. Magic Quadrant - obrazujący pozycję różnych narzędzi mogących służyć jako repozytorium architektoniczne w kontekście architektury korporacyjnej. Analiza ta jest przydatna dla organizacji, które stają przed wyborem narzędzia.

Enterprise Architecture Tools Magic Quadrant 2013

W bieżącym roku Gartner klasyfikuje narzędzia do architektury korporacyjnej w następujący sposób.

Widać, że Sparx Systems - jako producent Enterprise Architect jest klasyfikowany jako niszowy gracz.
Ale trzeba mieć na uwadze, że podstawowym przeznaczeniem EA jest modelowanie bazujące na języku UML. I w tej dziedzinie można uznać Sparx Systems za lidera.

Aby lepiej zrozumieć, w jaki sposób Gartner ocenia przydatność narzędzi warto zapoznać się z kryteriami oceny. Są to:

• A repository that supports, at a minimum, the business, information, technology and solution viewpoints and their relationships. The repository must also support business direction, vision and strategy, as well as business disruptions.
• Modeling capabilities that support the minimum viewpoints of business, information, technology and solutions.
• Decision analysis capabilities, such as gap analysis, impact analysis, scenario planning and system thinking.
• Presentation capabilities that are visual or interactive to meet the demands of a myriad of stakeholders.
• Administration capabilities that enable security, user management and other tasks.
• Configurability capabilities that are extensive, simple and straightforward to accomplish, while supporting multiple environments.
• Support for frameworks and standards, often used while providing the flexibility to modify the framework.
• Usability, including intuitive, flexible and easy-to-learn UIs.

W mojej ocenie EA wspiera wszystkie wymienione funkcjonalności oraz posiada ogromne możliwości w zakresie konfiguracji, czy wsparcia dla ram architektonicznych i standardów. 

Jednakże kluczowym czynnikiem, który świadczy o ułomności tego narzędzia w zastosowaniu jako repozytorium architektoniczne są:

• Nie intuicyjny i trudny do nauczenia interfejs użytkownika.
• Zmiany konfiguracji i rozszerzenia nie są łatwe do implementacji i stosowania, gdyż nierzadko konieczne jest kodowanie w formie skryptów (np. VBasic, JScript), pluginów w .NET, poznanie języka skryptowego ShapeScript, czy MDG Technology.

Przy podejmowaniu decyzji o ewentualnym wyborze Sparx EA dla celów architektury korporacyjnej warto jednak mieć na uwadze również inne kryteria, których Gartner nie bierze pod uwagę:

• Stosunek ceny do możliwości. W tym wypadku Sparx Systems byłby zdecydowanym liderem. Trudno znaleźć jakiekolwiek narzędzie, które oferowałoby tak dużą gamę funkcjonalności za tak niską cenę.
• Popularność narzędzia Enterprise Architect w Polsce. Dzięki temu możliwe jest zatrudnienie specjalistów w swojej dziedzinie, którzy doskonale znają to narzędzie. Ta cecha niweluje w pewnym stopniu wadę EA, jaką jest nie intuicyjny i trudny do nauczenia interfejs użytkownika.

Jeszcze dla porównania prezentuję poniżej poprzednie wyniki analizy Magic Quadrant z roku 2012.

Źródło

Więcej informacji na ten temat można znaleźć pod adresem: http://www.mikethearchitect.com/2013/10/gartners-2013-enterprise-architecture-tools-magic-quadrant.html

Praca grupowa w Enterprise Architect

Sparx Enterprise Architect posiada bogate możliwości w zakresie konfiguracji środowiska począwszy od łatwego umożliwienia pracy indywidualnej do złożonych konfiguracji pracy wielu organizacji w odniesieniu do modelowania jednocześnie wielu przedsięwzięć.

W najprostszej konfiguracji, gdy model tworzy jedna osoba wystarczy zainstalowanie programu Sparx Enterprise Architect na jednej stacji roboczej i aktualizacja modelu w pliku EAP. W takim przypadku możemy również mówić o pracy grupowej, gdyż zazwyczaj wyniki pracy prezentowane są zwykle interesariuszom przy użyciu jednej z poniższych metod:

• eksport diagramów w postaci pliku graficznego lub umieszczenie diagramów w niezależnie tworzonej dokumentacji,
• przesyłanie kopii pliku EAP lub umieszczenie go we współdzielonym repozytorium,
• generowanie dokumentacji w formacie RTF,
• generowanie raportu HTML,
• eksport modelu w formacie XMI.

Poniżej zostały opisane po krótce różne metody pracy grupowej wraz z ich zaletami i wadami.

Replikacja repozytorium - jak to zrobić?

W poprzednim artykule o replikacji repozytorium wskazałem, kiedy warto zdecydować się na replikację repozytorium EAP. Podałem wady i zalety takiego rozwiązania oraz opisałem proponowany proces, który powinien moim zdaniem towarzyszyć tego typu pracy grupowej.

W tym miejscu opisuję temat replikacji od strony technicznej.

Replikacja repozytorium EAP

Gdy nie jedna osoba, a zespół ludzi pracuje nad projektem wówczas zachodzi potrzeba zorganizowania jednego współdzielonego repozytorium. W przypadku pracy z programem Enterprise Architect mamy wiele możliwości zorganizowania pracy.
Jedną z takich metod jest replikacja.

Kiedy warto stosować replikację?

Replikacja najlepiej sprawdza się, gdy użytkownicy modelu:

• pochodzą z różnych organizacji - w konsorcjum, podwykonawcy;
• pracują w różnych lokalizacjach, w różnych sieciach;
• są mobilni - pracują u klienta, z domu, z biura.

Interfejs webowy do EA

Pełne wykorzystanie możliwości narzędzia Enterprise Architect w dużych projektach informatycznych wymaga oprócz uruchomienia współdzielonego repozytorium również przestawienia mentalnego członków zespołu projektowego na tworzenie artefaktów projektowych w EA, zamiast wielu dokumentów w formacie MS Word lub Excel. Poza tym, barierami w pełniejszym stosowaniu EA mogą być:

• konieczność konfiguracji środowiska na stacjach roboczych (instalacja EA, dostęp do klucza licencyjnego, dostęp do repozytorium, czy systemu kontroli wersji), 
• ograniczenia dostępu spoza sieci lokalnej organizacji (na przykład podczas spotkań u klienta, czy pracy z domu),
• przywiązanie użytkowników do prostszych i bardziej tradycyjnych metod pracy (pliki pakietów biurowych przechowywane lokalnie na stacji roboczej).

Metodą na eliminację dwóch pierwszych barier mogłoby być udostępnienie interfejsu WWW do repozytorium EA. Dzięki takiemu rozwiązaniu możliwe byłoby uzyskanie dostępu do zawartości repozytorium z poziomu przeglądarki internetowej. Dla określonych użytkowników, np. kierownictwa projektu, przedstawicieli klienta, eliminowałoby to potrzebę instalacji i konfiguracji klienta EA (lub EA Viewer) oraz konfiguracji dostępu. 

Można wyobrazić sobie aplikację webową umożliwiającą odnalezienie i zapoznanie się ze szczegółami modelu domeny, modelu użycia, wymagań, czy wyświetlenie zawartości diagramów. Gdyby jeszcze interfejs użytkownika byłby bardziej przystępny, przejrzysty, a w dodatku w języku polskim, wówczas moglibyśmy mieć do czynienia z przeniesieniem wykorzystania EA w nowy wymiar.

Project Integrity Check od środka

Projekt tworzony w programie Enterprise Architect jest przechowywany w formie relacyjnej bazy danych. Bez względu na zastosowany silnik bazodanowy (MS Jet w przypadku plików EAP, MS SQL, MySQL, Oracle czy inny) zastosowany jest ten sam schemat bazy danych do przechowywania modeli. Dane w relacyjnej bazie danych powinny być spójne. Spójność tę można zapewnić w sposób techniczny wprowadzając określone constraints, wówczas silnik baz danych pilnuje zgodności zdefiniowanych reguł.

Funkcja Project Integrity Check

Zapewne kierując się przesłankami wynikającymi z logiki biznesowej dotyczącej przetwarzania danych takich, jak pakiet, element, relacja, atrybut czy metoda, zdecydowano o wdrożeniu wewnątrz programu EA funkcjonalności pozwalającej z poziomu interfejsu użytkownika sprawdzić spójność projektu. Funkcjonalność ta nazywa się Project Integrity Check i jest dostępna poprzez wybór w menu aplikacji opcji Tools -> Data Management -> Project Integrity Check.

Biblioteka dokumentów w EA

W artykule Import wymagań z Linked Document opisałem mechanizm tworzenia elementów modelu wprost z dokumentów składowanych w modelu w formie Linked Documents. Wykorzystanie tego mechanizmu wymaga zaimportowania dokumentów do modelu i przypisanie ich do określonych elementów typu <<document>>. Proces taki wymaga pewnego nakładu sił, co w przypadku dużych projektów może być kłopotliwe, a poza tym użytkownicy modelu i tak mają świadomość, że dokumenty te są tylko kopią dokumentów składowanych poza modelem. Aby mieć pewność, że sięgają do właściwej treści użytkownicy i tak będą korzystać z referencyjnego repozytorium dokumentów, jakim może być np. Sharepoint lub SVN.

Zatem po co tworzyć bibliotekę dokumentów w modelu Enterprise Architect?

Mogą istnieć różne przesłanki wynikające ze specyfiki projektów. Z analitycznego punktu widzenia  wartość dodaną stanowi możliwość tworzenia relacji dokumentów do innych elementów modelu (np. Dependency, Trace) oraz możliwość łączenia poprzez hiperłącza określonych słów czy fraz z dokumentu.
Ponadto model dokumentacji może służyć do wspomagania procesów tworzenia dokumentacji projektowej poprzez zastosowanie diagramów i relacji pomiędzy dokumentami. Na przykład można zamodelować zależności prezentujące informacje o tym, który dokument (lub rozdział) wynika z jakiegoś innego dokumentu. Dzięki temu łatwiej zorientować się, czy aktualizacja jednego dokumentu pociąga za sobą konieczność aktualizacji innego dokumentu.

Jak usunąć masowo kontrolę wersji z modelu?

Zawartość modelu może być poddana kontroli wersji przy użyciu SVN lub TFS. Zastosowanie takiego mechanizmu niesie ze sobą wiele zalet, które opiszę przy innej okazji.
Gdy model jest poddany kontroli wersji, wówczas jednak mamy ograniczone możliwości, bo możemy stworzyć kopię repozytorium w postaci pliku EAP lub testowej bazy danych - korzystając z funkcjonalności Project Transfer, ale co z tego, skoro i tak kopia repozytorium jest nadal "spięta" z tym samym systemem kontroli wersji.
Co zrobić zatem, gdy potrzebujemy przekazać klientowi kopię naszego modelu albo wykonać jakieś testy w modelu bez obaw o przypadkowe "uszkodzenie" zawartości modelu wykorzystywanego przez zespół?

Dostęp do modelu w trybie tylko do odczytu

W przypadku, gdy zespół projektowy zastanawia się nad wykorzystaniem Enterprise Architecta, jednym z pierwszych pytań jest:

Czy możliwy jest dostęp do modelu tylko do odczytu?

Odpowiedź brzmi:

Tak, oczywiście.

Pytanie jest jak najbardziej zasadne, gdyż w przypadku każdego projektu istnieją interesariusze, którzy nie uczestniczą w tworzeniu i utrzymaniu modelu, a mogą być zainteresowani jakimiś jego aspektami.  Przede wszystkim taki dostęp może potrzebować kierownictwo projektu i klient.
Mamy w tej kwestii kilka możliwości opisanych poniżej.

Funkcja administratora repozytorium EA

Stworzenie współdzielonego repozytorium EA ma sporo zalet w porównaniu z pracą na oddzielnych plikach EAP. W niektórych sytuacjach jest to wręcz krok nieodzowny. Warto jednak pamiętać, że utrzymanie takiego repozytorium wiąże się z koniecznością wyznaczenia osoby administratora, na którym powinien ciążyć obowiązek wykonywania pewnych zadań.
Dopóki każdy sam odpowiada za swój kawałek modelu, dopóty jest za niego odpowiedzialny. Gdy model staje się wspólny, wówczas nie można już współdzielić tej odpowiedzialności, gdyż mogłoby to doprowadzić do powstania bałaganu w zawartości repozytorium, a w skrajnym przypadku do jego utraty w wyniku awarii.

Jak zmienić swoje hasło w repozytorium EA?

Niniejszy post jest skierowany do osób, które korzystają z modelu EA z włączonym modułem Security, którego zastosowanie wymaga logowania do modelu. W takiej sytuacji najczęściej administrator repozytorium konfiguruje grupy, przypisuje użytkowników do grup i ustala inicjalne hasła.
Podczas ustalania hasła brak opcji wymuszenia zmiany hasła przy pierwszym logowaniu (choć wcale nie brakuje takiej opcji). Użytkownicy zazwyczaj korzystają z haseł, które zostały im przydzielone nie wiedząc że mają możliwość samodzielnej zmiany.
Kwestia zmiany hasła wydaje się być trywialna, ale w sytuacji, gdy administrator ustala hasła wszystkim takie samo hasło lub wg tej samej reguły (np. <imię>123.) można założyć, że konta nie są chronione hasłem.