Czy jeden dobry obrazek znaczy więcej niż tysiąc słów? O wartości repozytorium architektonicznego

Powiedzenie „jeden obrazek znaczy więcej niż tysiąc słów” jest w architekturze korporacyjnej traktowane niemal jak aksjomat. Ale czy zawsze diagram jest najlepszą formą przekazania informacji? A może czasem kilka dobrze zdefiniowanych atrybutów i zapytań powie więcej niż najstaranniej przygotowany rysunek?

Domena aplikacji: co chcemy wiedzieć?

Modelowanie domeny aplikacji i danych w ArchiMate to jedno z najbardziej praktycznych zastosowań repozytorium architektonicznego. Typowe pytania, na które odpowiada dobrze zbudowane repozytorium, to:

• Który komponent aplikacji realizuje dany interfejs?
• Jakie usługi są dostępne przez konkretny interfejs?
• Które aplikacje korzystają z danego interfejsu?
• Jakie funkcje, dane i technologie są przypisane do komponentu?

Odpowiedź na każde z tych pytań można udzielić na dwa sposoby: narysować diagram albo zbudować widok oparty na zapytaniach do repozytorium. I tu zaczyna się ciekawa rozmowa.

Diagram — niezastąpiony, ale nie wszechpotężny

Diagram ArchiMate Application Cooperation (Rysunek 1) doskonale pokazuje strukturę i powiązania między komponentami. Widzimy przepływ, kompozycję interfejsów, relacje między aplikacjami. To jest ta sytuacja, w której obrazek wygrywa — gdy zależy nam na zrozumieniu architektury jako całości, na pokazaniu wzorców integracji, na komunikacji z interesariuszami.

Rysunek 1. Diagram ArchiMate Application Cooperation — widok struktury integracji aplikacji

Jednak diagram ma swoje ograniczenia:

• Jest statyczny — przygotowany raz, szybko się dezaktualizuje.
• Jest selektywny — pokazuje to, co architekt zdecydował umieścić, a nie to, co faktycznie jest w repozytorium.
• Nie skaluje się — przy 50 komponentach diagram staje się nieczytelny.
• Nie odpowiada na pytania kontekstowe — klikając na interfejs, nie widzisz od razu jego usług, realizatorów i konsumentów.

Repozytorium jako źródło wiedzy — widok oparty na zapytaniach

Alternatywą jest inteligentne budowanie widoków opartych na zapytaniach SQL do repozytorium EA. Zamiast rysować diagram dla każdego interfejsu z osobna, definiujemy raz relacje w modelu, a następnie wyciągamy z nich informacje dynamicznie.

Przykład: panel informacyjny dla elementu ApplicationInterface w Prolaborate (Rysunek 2) pokazuje w jednym miejscu realizatora interfejsu, dostępne usługi oraz aplikacje-konsumentów — wszystko wyprowadzone bezpośrednio z relacji ArchiMate zdefiniowanych w modelu.

Rysunek 2. Panel ApplicationInterface w Prolaborate — wszystkie powiązania w jednym miejscu, bez potrzeby tworzenia dedykowanego diagramu

Warto porównać to z sytuacją przed poprawnym skonfigurowaniem zapytań (Rysunek 3), gdzie sekcja „Usługi dostępne na interfejsie” pokazywała jedynie „Not Set” — dowód na to, że sama struktura modelu nie wystarcza; równie ważna jest precyzja definicji widoków i zapytań.

Rysunek 3. Ten sam panel przed poprawnym skonfigurowaniem zapytań — „Not Set” zamiast danych

Analogicznie panel komponentu aplikacji (Rysunek 4) agreguje w jednym miejscu funkcje komponentu, usługi, dane oraz technologie — informacje, których zebranie na diagramie wymagałoby kilku osobnych widoków.

Rysunek 4. Panel ApplicationComponent w Prolaborate — funkcje, usługi, dane i technologie w jednym widoku

Klucz: podejście do budowy repozytorium

Żeby takie widoki działały, repozytorium musi być zbudowane świadomie. Nie wystarczy narysować diagramy — trzeba zadbać o kilka fundamentalnych zasad:

1. Spójność stereotypów

Każdy element musi mieć właściwy stereotyp ArchiMate (ArchiMate_ApplicationComponent, ArchiMate_ApplicationInterface, ArchiMate_ApplicationService). Bez tego zapytania nie zwrócą poprawnych wyników.

2. Precyzja relacji

Różne typy relacji ArchiMate mają różne znaczenie semantyczne. ArchiMate_Composition (komponent agreguje interfejs) to co innego niż ArchiMate_Assignment (interfejs udostępnia usługę). Co więcej — jak pokazuje praktyka — EA przechowuje te relacje w bazie inaczej niż można by się spodziewać po nazwie (np. ArchiMate_Composition zapisana jako connector_type = 'Association'). Znajomość schematu bazy danych jest niezbędna do budowania poprawnych zapytań.

3. Atrybuty jako nośnik wiedzy

Tagged values pozwalają przechowywać przy elemencie dodatkowe informacje: wartość biznesowa, status w cyklu życia, klasyfikacja TIME, daty ALM/EOL. To właśnie te atrybuty zamieniają repozytorium z katalogu elementów w realne źródło wiedzy architektonicznej.

4. Nazewnictwo i aliasy

Stosowanie spójnych konwencji nazewniczych i aliasów (np. APP1, APP2) pozwala na jednoznaczną identyfikację elementów w raportach i integracjach z zewnętrznymi narzędziami.

Diagram czy raport? Obydwa — ale w odpowiednim miejscu

Tak — gdy chcemy pokazać strukturę, architekturę jako całość, wzorce integracji, przepływ między systemami. Diagram Application Cooperation jest niezastąpiony w komunikacji z CIO, na warsztatach z biznesem, w dokumentacji projektowej.

Nie zawsze — gdy potrzebujemy odpowiedzi na konkretne pytanie o konkretny element. „Jakie usługi udostępnia ten interfejs?” — panel w Prolaborate odpowie szybciej i dokładniej niż diagram, który trzeba najpierw znaleźć, otworzyć i przeczytać.

Prawdziwa wartość repozytorium architektonicznego leży nie w liczbie diagramów, ale w jakości danych i inteligencji prezentacji. Diagram i widok oparty na zapytaniach to nie konkurenci — to uzupełniające się formy prezentacji tej samej wiedzy, każda właściwa dla innego kontekstu użycia.

Jacek Woynarowski, CEO 1Repo, założyciel EAUG Poland. Specjalizuje się w budowaniu repozytoriów architektonicznych opartych na Sparx Enterprise Architect i ArchiMate 3.1.