Temat wykorzystania dużych modeli językowych (LLM) w pracy analityka i architekta poruszałem na blogu już kilkukrotnie — zarówno w kontekście inżynierii promptów, jak i zarządzania wymaganiami w projektach opartych na LLM. Pisałem również o integracji Enterprise Architect z lokalnymi modelami językowymi. Tym razem chcę przyjrzeć się konkretnemu rozwiązaniu, które idzie o krok dalej — nie tylko korzysta z LLM, ale osadza je bezpośrednio w kontekście repozytorium EA i pozwala modelowi „rozumieć” strukturę projektu.
Mowa o Kernaro — zestawie narzędzi od Sparx Systems, które dodają warstwę sztucznej inteligencji do Enterprise Architect.
Trzy produkty, jedno podejście
Kernaro to w rzeczywistości trzy odrębne rozwiązania, które można stosować niezależnie lub łączyć.
Kernaro AI Hub to platforma webowa działająca poza Enterprise Architect. Łączy repozytorium EA z zewnętrznymi źródłami danych — Jira, Confluence, ServiceNow, SharePoint, Azure DevOps — i udostępnia interfejs konwersacyjny (Model Chat) do odpytywania modelu w języku naturalnym. Pozwala zadawać pytania typu „jakie aplikacje są krytyczne biznesowo i pochodzą od dostawcy X” i uzyskiwać odpowiedzi z powołaniem na konkretne elementy repozytorium. Kierowany jest do szerokiego grona interesariuszy, nie tylko do osób pracujących bezpośrednio w EA.
Kernaro Assist to wtyczka (add-in) do Enterprise Architect. Działa bezpośrednio w środowisku modelowania — w panelu bocznym wyświetla okno czatu, przez które LLM komunikuje się z użytkownikiem i wykonuje operacje na modelu: tworzy elementy, modyfikuje diagramy, poprawia nazewnictwo, generuje opisy. To rozwiązanie najbliższe codziennej pracy analityka i architekta, ponieważ agent operuje na tym samym repozytorium, które mamy otwarte.
Kernaro AI (dawniej EAGenie) to starszy komponent platformy, łączący funkcje analityczne z NLP i uczeniem maszynowym do eksploracji zależności w modelu.
W tym artykule skupiam się na Kernaro Assist — bo to właśnie ta wtyczka najbardziej zmienia sposób pracy z EA na co dzień. Przetestowałem ją w kilku praktycznych scenariuszach.
Co potrafi Kernaro Assist — przegląd funkcji
Zanim przejdę do testów, krótko o kluczowych możliwościach, które opisuje producent.
Analiza i optymalizacja modelu z wykorzystaniem AI. Agent potrafi przeanalizować otwarty diagram — zidentyfikować literówki, niespójności nazewnictwa, brakujące elementy, puste opisy — i zaproponować konkretne poprawki. Nie jest to przegląd czysto syntaktyczny — LLM interpretuje semantykę nazw i relacji, co pozwala mu np. wykryć, że interfejs nazwany „ProvidedInterface1″ to artefakt automatycznie wstawiony przez EA i wymaga przemianowania.
Przeszukiwanie modelu w języku naturalnym. Zamiast budować zapytania SQL do bazy EA, użytkownik po prostu pyta: „jakie komponenty odpowiadają za płatności?”, a agent przeszukuje repozytorium i zwraca odpowiedź z konkretnymi GUIDami i ścieżkami do elementów.
Inteligentne przepływy pracy (Intelligent Flow). Kernaro pozwala definiować wielokrokowe procesy — np. przegląd architektury, mapowanie aplikacji do subdomen, generowanie i walidacja wymagań — które agent wykonuje półautomatycznie, pytając użytkownika o decyzje w kluczowych momentach.
Integracja z narzędziami zewnętrznymi. Przez Kernaro AI Hub model EA może być powiązany z Jira, Confluence, SharePoint i Azure DevOps. Agent potrafi np. wyszukać taski z Jiry powiązane z elementem modelu i automatycznie je zlinkować.
Analiza wpływu zmian (Impact Analysis). Agent mapuje zależności w modelu i potrafi odpowiedzieć na pytania w stylu „co się stanie, jeśli wycofamy system X” — wskazując wszystkie powiązane komponenty, procesy i interesariuszy.
To tyle teorii. Przejdźmy do praktyki.
Test 1: Generowanie wymagań systemowych na podstawie wymagań biznesowych
Pierwszy scenariusz, który przetestowałem, dotyczy automatycznego uszczegóławiania wymagań. W pakiecie „Wymagania biznesowe” miałem zdefiniowany zestaw wymagań — od „Możliwość zakupu szkoleń online” przez „Obsługę płatności” po „Zakres danych osobowych”. Chciałem sprawdzić, czy Kernaro Assist potrafi przeanalizować te wymagania pod kątem spójności i zaproponować wymagania systemowe, które je uszczegóławiają.
Zacząłem od wprowadzenia promptu bezpośrednio w oknie EA.
Kernaro Assist oferuje trzy tryby pracy, które determinują, ile kontroli zachowuje użytkownik nad zmianami w modelu.
Wybrałem tryb Auto Edit, by zobaczyć, ile agent zrobi samodzielnie. Po zatwierdzeniu promptu agent rozpoczął sekwencję operacji: pobrał listę modeli, wykonał zapytanie do repozytorium, odnalazł pakiet wymagań biznesowych, odczytał ich treść, a następnie utworzył pakiet „Wymagania systemowe” i zaczął wypełniać go nowymi elementami.
Wynik był konkretny. Agent utworzył grupę wymagań systemowych (WS-01 do WS-12),
Każde powiązane relacją z odpowiednim wymaganiem biznesowym. Relacja w moim odczuciu do zmiany, ale mimo to powiązanie pomaga w dalszej analizie.
Co istotne, agent nie ograniczył się do mechanicznego rozbicia. Przeanalizował treść wymagań biznesowych i zidentyfikował luki — np. brak wymagań dotyczących statusów transakcji i webhooków w kontekście płatności, brak wymagań na historię wysyłek w maile transakcyjne, brak mierzalnych kryteriów wydajnościowych (SLA). Model rzeczywiście interpretuje kontekst biznesowy.
Warto zwrócić uwagę, jak agent potraktował wymaganie „WB. Obsługa maili transakcyjnych i marketingowych”. Zauważył, że łączy ono dwa różne typy komunikacji o odmiennych wymaganiach regulacyjnych (zgody, SLA) i rozdzielił je na dwa wymagania systemowe: WS-07 (maile transakcyjne — szablony, zdarzenia, ponowienia) i WS-08 (newsletter/marketing — segmentacja i zgodność zgód).
Agent nie tylko wygenerował wymagania, ale też zaproponował powiązania krzyżowe. Na przykład wymaganie WS-10 (Panel obsługi klienta) zostało powiązane jednocześnie z wymaganiami na zakupy online, faktury i maile — bo obsługa klienta stanowi element wspólny tych procesów.
W tym trybie wszystkie czynności zostały zrealizowane automatycznie. Ja wykonałem tylko diagram, ale tylko dlatego, że nie napisałem w prompcie by to wykonał.
Test 2: Analiza architektury komponentowej
Drugi scenariusz dotyczył analizy diagramu komponentów w pakiecie „Architektura”. Model zawierał aplikacje systemu e-commerce: AP Sklepik (aplikacja sklepu), AP. Przelewy24 (bramka płatnicza), AP. FAKTURA (fakturowanie), AP. MailerLite i AP. MailerSend (komunikacja).
Poprosiłem agenta o przegląd otwartego diagramu komponentów i wskazanie, co można poprawić.
Agent zwrócił uwagę na kilka problemów. Po pierwsze, trzy elementy typu RequiredInterface miały identyczną domyślną nazwę „ProvidedInterface1″ — artefakty wstawione automatycznie, bez porządnych nazw. Po drugie, typy interfejsów były niespójne z relacjami — RequiredInterface nazwany jak ProvidedInterface. Po trzecie, interfejsy nie były „przyczepione” do komponentów jako porty, lecz wisiały luźno na diagramie. Po czwarte, nazewnictwo zawierało literówki i niespójności: „AP. MalierSend” vs „I.MailerSend”, „AP Sklepik” bez kropki po prefiksie, „I. Faktur” ze spacją. Agent zaproponował konkretne zmiany: ujednolicenie prefiksów, poprawę literówek, przebudowę interfejsów na porty komponentów oraz uzupełnienie opisów (Notes) — dotychczasowe zawierały treści typu „opis” i „nowy opis 4444″.
W tym przypadku model był współdzielony i działał w trybie Plan. Analiza zakończyła się słowami: „Uwaga praktyczna: w tej sesji mam tylko odczyt do modelu EA, więc nie mogę tego bezpośrednio poprawić w repozytorium. Mogę natomiast przygotować checklistę zmian albo wygenerować raport (PDF/Word) z listą problemów na tym diagramie.”
Test 3: Optymalizacja diagramu BPMN procesu biznesowego
Ten scenariusz był najbardziej rozbudowany. Otworzyłem diagram BPMN „Procesy biznesowe” przedstawiający przepływ obsługi transakcji w sklepie internetowym — od inicjacji, przez wybór metody płatności, po rejestrację zamówienia i aktywację produktów. Diagram celowo był narysowany z błędami, bez opisów poszczególnych aktywności.
W oknie Kernaro Assist wpisałem polecenie: „Przeanalizuj diagram Procesy biznesowe, dodaj zrób jego optymalizacje oraz dodaj opisy do aktywności”. Agent natychmiast rozpoczął interakcję — ale zanim cokolwiek zmienił, zadał serię pytań.
To podejście — serię precyzyjnych pytań zamiast domyślnych założeń — uważam za dobrą praktykę. Agent nie zgaduje intencji użytkownika, lecz pyta. W kontekście pracy z modelem architektonicznym to istotne, bo zakres „optymalizacji” może oznaczać wszystko — od kosmetyki po przeprojektowanie procesu.
Po uzyskaniu odpowiedzi agent przeanalizował diagram i zidentyfikował kilka problemów. Po pierwsze, wykrył przepływ z „Aktywacja zakupionych produktów” do elementu o ID=86, którego nie było na diagramie — element „Wystawianie faktury” istniał w repozytorium, ale nie został wstawiony na diagram. Agent zapytał, jak chcę to rozwiązać.
Wybrałem opcję C — dodanie brakującego elementu na diagram. Agent znalazł go po ID i wstawił.
Następnie agent poprawił literówki w nazewnictwie: „Inicjajcja transakcji” → „Inicjacja transakcji”, „Zamówiene ze statusem do realizacji” → „Zamówienie ze statusem do realizacji”, „Jaki rodzaa płatności?” → „Jaki rodzaj płatności?”. Dodał również opisy do wszystkich aktywności — krótkie, dwuzdaniowe, w formacie cel + wynik. Na przykład dla aktywności „Obsługa płatności” wygenerował: „Realizuje proces płatności (np. przekierowanie do operatora i potwierdzenie). Po sukcesie oznacza zamówienie jako opłacone.”
Na koniec zaproponował uporządkowanie layoutu diagramu.
Finalnie na diagramie pojawił się element „Wystawienie faktury”
Podsumowując w tym scenariuszu miałem kontrolę nad każdym krokiem. Agent zadawał pytania i pozwalał wybrać z kilku opcji możliwe rozwiązanie.
Kernaro Assist od środka
Kernaro Assist do swojej pracy wykorzystuje modele komercyjne od Anthropic, Azure Foundry oraz OpenaAI. W testach wykorzystałem model GPT5.2. Te dość proste zapytania i analizy zużyły 1 816 175 tokenów i kosztowały około 1 dolara amerykańskiego. Producent deklaruje możliwość wykorzystania w przyszłości modeli lokalnych. Nie znam daty wdrożenia tej funkcji.
Czat to nie jest jedyna funkcja tej wtyczki. Można skonfigurować serwer MCP i agentów. W dniu pisania tego tekstu producent oferował 30 dniowe demo. Myślę, że warto samodzielnie przetestować.
Co to oznacza dla przyszłości pracy analityka i architekta?
Na podstawie testów i kierunku, w którym rozwija się Kernaro — szczególnie funkcji Impact Analysis — widzę kilka konkretnych scenariuszy, w których AI zmieni codzienną pracę z modelem.
Analiza wpływu zmian w czasie rzeczywistym. Dziś analiza wpływu to często żmudne śledzenie relacji między diagramami, które wymaga znajomości struktury repozytorium. Kernaro Impact Analysis pozwala zadać pytanie w stylu „jeśli wycofamy system CRM, kto zostanie dotknięty?” — i natychmiast otrzymać mapę zależności: powiązane aplikacje, procesy biznesowe, interesariuszy. To zmienia dynamikę pracy z Change Advisory Board — zamiast przygotowywać analizę przez dni, architekt może uruchomić ją w trakcie spotkania.
Ciągła walidacja modelu. Zamiast okresowych przeglądów, agent może na bieżąco weryfikować spójność modelu — wykrywać osieroconione elementy, niespójne nazewnictwo, brakujące opisy, nieaktualne relacje. To szczególnie wartościowe w dużych repozytoriach, gdzie entropia modelu rośnie z każdym sprintem.
Demokratyzacja dostępu do modelu. Model Chat w Kernaro AI Hub pozwala osobom spoza zespołu architektonicznego — product ownerom, menedżerom, audytorom — zadawać pytania o architekturę bez znajomości EA. To usuwa barierę kompetencyjną, która od lat ogranicza wartość modeli architektonicznych: model jest wartościowy tylko wtedy, gdy ludzie z niego korzystają.
Automatyzacja rutynowych prac. Generowanie opisów, tworzenie wymagań systemowych z biznesowych, poprawianie layoutu diagramów — to czynności, które zajmują dużo czasu, a nie wymagają kreatywności. Delegowanie ich do agenta AI uwalnia czas analityka na pracę koncepcyjną.
Podsumowanie
Kernaro Assist to narzędzie, które robi wrażenie przede wszystkim dojrzałością interakcji z użytkownikiem. Agent nie działa „na ślepo” — pyta o intencje, proponuje opcje, czeka na potwierdzenie. Tryby pracy (Plan, Ask to Edit, Auto Edit) dają kontrolę nad tym, ile autonomii oddajemy modelowi. Wyniki — zarówno w scenariuszu wymagań, jak i optymalizacji BPMN — były merytorycznie sensowne, a nie tylko poprawne formalnie.
Czy zastąpi analityka albo architekta? Nie. Może jednak zmienić proporcję jego pracy: mniej czasu na mechaniczne uzupełnianie modelu, więcej na decyzje architektoniczne i komunikację z biznesem. Czy tak w istocie będzie? Czas pokaże.
