Enterprise Architect to narzędzie, które w korporacjach żyje latami. Rosną w nim modele procesów, integracji, komponentów. Problem w tym, że po kilku latach pracy nad modelem nikt już nie pamięta, gdzie dokładnie są te wszystkie powiązania między systemem X a systemem Y. Oczywiście stosowanie metamodelu pomaga ogarnąć chaos, ale dość często typowy scenariusz jest taki, że architekt dostaje pytanie „gdzie mamy integrację z systemem płatności i co się stanie, jeśli zmienimy API zamówień?”. Można klikać po pakietach i diagramach przez pół dnia. Albo można zapytać model językowy, który zna metamodel i dane w repozytorium.
Dlaczego lokalny LLM, a nie chmurowy? Kilka argumentów, które przekonują działy bezpieczeństwa:
• Prywatność i wrażliwe dane – nazwy systemów, schematy integracji, wewnętrzne API. To nie są rzeczy, które chcemy wysyłać poza firmę.
• Przewidywalny koszt – żadnych niespodzianek „per token” na koniec miesiąca. Płacisz za infrastrukturę, nie za każde zapytanie.
• Niskie opóźnienia – model w lokalnym DC może odpowiadać szybciej niż publiczne API przez internet.
• Dostrajanie i promptowanie – można nauczyć model metamodelu organizacji, specyficznego słownictwa, wzorców nazywania elementów.
• Audytowalność – logi zapytań zostają w organizacji. Wiadomo kto pytał o co i kiedy.
No dobra, ale zanim zaczniemy pisać kod, warto sprawdzić, czy licencje Sparx Systems w ogóle na to pozwalają.
Co mówią licencje Enterprise Architect i Pro Cloud Server?
Zastrzeżenie: poniższe nie stanowi porady prawnej. To moja analiza techniczna zapisów EULA pod kątem konkretnego przypadku użycia. W razie wątpliwości – konsultacja z prawnikiem lub zapytanie do Sparx Systems.
Przeanalizowałem dwa dokumenty: Enterprise Architect EULA (v17.1) oraz Pro Cloud Server EULA. Interesują nas dwa scenariusze: bezpośredni dostęp do bazy danych (QEA/MSSQL) z pominięciem EA oraz publikacja danych przez własne endpointy HTTP. W analizie uwzględniłem Pro Cloud Server gdyż to jeden z dostępów do bazy danych.
Ograniczenia dotyczące bezpośredniego dostępu do bazy
Ryzyko: EULA EA w sekcji 2 definiuje, że licencja jest na „direct and exclusive use of the SOFTWARE PRODUCT only through the input hardware mechanisms of the licensed computer”. Bezpośredni dostęp SQL do repozytorium omija tę klauzulę, gdyż nie używamy EA, tylko łączymy się bezpośrednio z bazą.
Ograniczenie: EULA nie mówi literalnie „nie wolno robić SELECT na bazie”, ale zasada „all rights not expressly granted to you are reserved by Sparx Systems” (sekcja 6) oznacza, że to co nie jest wyraźnie dozwolone – jest zarezerwowane dla producenta.
Wniosek: Należy korzystać z oficjalnych interfejsów – Add-in API w EA lub OSLC/WebEA w Pro Cloud Server. Budowanie narzędzi czytających bezpośrednio z repozytorium bazy umieszczonej czy to w pliku qea czy też bazie danych takiej jak MSSQL, PostgreSQL jest niezgodne z licencją.
Ograniczenia dotyczące publikacji przez HTTP
Ryzyko: Sekcja 6 EA EULA mówi wprost: „Server based installations that provide concurrent end users with content or functionality derived from a running remote instance of Enterprise Architect over a network is not officially supported”. Co więcej: „A server based instance must NOT be used to create a derivative work, adapt Enterprise Architect for another platform, virtualize separate functionality”.
Ograniczenie: Tworzenie własnego portalu HTTP, który wystawia dane z modelu EA (nawet read-only) dla wielu użytkowników, może być traktowane jako „virtualize separate functionality” lub „derivative work”. Sparx wyraźnie zabrania też „work around any technical restrictions or limitations in the SOFTWARE PRODUCT”.
Wniosek: Zamiast własnego API na bazie EA – używać należy Pro Cloud Server z WebEA i OSLC. To oficjalny kanał do publikacji modeli przez HTTP.
OSLC i WebEA – co mówi EULA Pro Cloud Server?
OSLC Interface w PCS jest „immediately available for internal use by customers”. Klucz: internal use. Jeśli chcesz użyć OSLC komercyjnie (np. udostępnić partnerom, sprzedać jako usługę) – potrzebujesz osobnej licencji od Sparx.
WebEA wymaga osobnej licencji i ma własne ograniczenia: „Creating software that is based on, imitates, clones, passes off as, or otherwise imitates or pretends to be WebEA is not permitted”. Czyli: nie klonuj WebEA, używaj oryginału.
Dodatkowe zakazy z PCS EULA: „No circumvention, reverse engineering, decompiling or otherwise bypassing any restrictions imposed by this EULA”. Standard, ale warto pamiętać.
Co to oznacza dla integracji z LLM?
Najbezpieczniejsza ścieżka to działanie przez oficjalne kanały: Add-in API w Enterprise Architect albo OSLC Interface w Pro Cloud Server. Add-in działa wewnątrz EA, używa jego API, nie omija licencji. OSLC jest przeznaczony do integracji i jest dozwolony do użytku wewnętrznego.
Budowanie „własnego portalu HTTP” bezpośrednio na bazie QEA/MSSQL lub tworzenie „mirrora” repozytorium – to obszar ryzyka. Może być interpretowane jako obchodzenie ograniczeń stawianych przez EULA.
To ważne ustalenia w kontekście architektury rozwiań, gdzie do analizy repozytorium wykorzystamy modele LLM.
Propozycja architektura rozwiązania: Add-in, Gateway, LLM
Architektura, którą proponuję, opiera się na Add-in + Gateway + lokalny LLM. Wszystko przechodzi przez oficjalne API EA.
Rozwiązanie składa się z trzech warstw. EA-LLM Add-in to plugin zainstalowany bezpośrednio w Enterprise Architect – widoczny w menu, dostępny z poziomu diagramu lub Project Browser. EA-LLM-Gateway to osobna usługa (REST API), która pośredniczy między Add-inem a modelem językowym. Trzecia warstwa to sam LLM uruchomiony lokalnie, np. na OpenShift AI.
Dlaczego taki podział? Add-in w EA ma dostęp do pełnego API Enterprise Architect i modeli w repozytorium. Nie zawiera logiki biznesowej ani bezpośrednio nie komunikuje się z LLM. Gateway centralizuje: autoryzację, logowanie, transformację zapytań, redakcję danych wrażliwych. Model LLM wie tylko tyle, ile mu Gateway przekaże.
Co potrafi rozwiązanie?
System pozwala na trzy główne scenariusze użycia. Po pierwsze: przeszukiwanie modeli na bazie zdefiniowanego metamodelu. Użytkownik pyta „pokaż wszystkie integracje między warstwą aplikacji a warstwą danych” – system mapuje to na zapytanie do struktur ArchiMate/UML w repozytorium.
Po drugie: przeszukiwanie repozytorium językiem naturalnym. „Gdzie mamy komponenty, które korzystają z usługi autoryzacji?” – LLM interpretuje pytanie, Gateway tłumaczy na zapytanie do EA API, wyniki wracają do użytkownika.
Po trzecie: analiza znalezionych treści. Streszczenia opisów elementów, porównania między wersjami, wykrywanie sprzeczności w modelach (np. dwa diagramy pokazują różne przepływy), impact analysis przy planowanych zmianach, generowanie list ryzyk.
Przykłady zapytań i odpowiedzi
Pytanie: „AP. SKLEP ma być integrowany z AP. Faktura. Zaproponuj zestaw 5 podstawowych wymagań funkcjonalnych.”
Odpowiedź systemu: System znajduje istniejący flow między aplikacjami, analizuje już zdefiniowane integracje i generuje listę wymagań: automatyczne tworzenie faktur, synchronizacja danych klientów, aktualizacja statusu zamówienia, obsługa błędów, zapewnienie bezpieczeństwa danych.
Pytanie: „Jakie dane są dostarczane z aplikacji AP. Sklep do aplikacji AP. Bramka płatności?”
Odpowiedź systemu: System lokalizuje connector typu ArchiMate_Flow między komponentami, odczytuje kolumnę Dane, a gdy jest pusta – analizuje nazwę integracji (ZAMÓWIENIA) i sugeruje potencjalne dane: informacje o kliencie, adresie dostawy, statusie płatności. Dodatkowo generuje diagram pokazujący przepływ.
Pytanie: „Co wiesz o aplikacji AP. Sklep? Czy opis tej aplikacji jest wystarczający?”
Odpowiedź systemu: System pobiera opis komponentu, ocenia jego kompletność – wskazuje, że brakuje informacji o integracjach z innymi systemami (Flow) oraz przypisaniach do procesów biznesowych (Assignment/Realization). Rekomenduje uzupełnienie tych elementów.
Dlaczego Gateway jest konieczny?
Można by zapytać: czemu nie wbudować logiki LLM bezpośrednio w Add-in? Kilka powodów.
- Separacja odpowiedzialności – Add-in odpowiada za UI i komunikację z EA API. Gateway odpowiada za logikę, bezpieczeństwo, integrację z LLM. Łatwiej utrzymać, testować, rozwijać.
- Brak logiki w Add-in – im mniej kodu w pluginie EA, tym mniej problemów z kompatybilnością między wersjami EA. Add-in ma być „cienkim klientem”.
- Wymienność modelu LLM – dziś Llama, jutro Mistral, pojutrze może coś z OpenShift AI. Zmiana w Gateway, Add-in bez zmian.
- Zgodność z licencjami – Gateway może działać też jako pośrednik do PCS, zachowując jedno miejsce integracji i jeden punkt kontroli.
Podsumowując
Licencje to realne ograniczenie. EULA EA i PCS mówią wprost o zakazach obchodzenia ograniczeń technicznych. Architektura „Add-in + Gateway + lokalny LLM” jest kompromisem: daje możliwości, działa przez oficjalne kanały i jest zgodna z EULA.
Integracja LLM z repozytorium architektonicznym to naturalny krok w kierunku lepszego wykorzystania danych, które już mamy. Modele w EA rosną latami – warto móc je przeszukiwać językiem naturalnym, analizować wpływ zmian, generować streszczenia i wykrywać niespójności.
Przewaga tego podejścia to połączenie trzech rzeczy: język naturalny (pytasz jak człowiek), metamodel (system wie, czym jest aplikacja, flow, integracja), analiza wpływu (co się stanie, jeśli zmienię X). To co wydawało się odległe jest już dziś dostępne. By osiągnąć sukces wymagane jest tylko albo aż tylko inżynierskie podejścia. Metamodel, który będzie stosowany w organizacji, konsekwencja w stosowaniu relacji, opisach. W taki środowisku modele LLM radzą sobie doskonale.
