Klient od wielu lat rozwija innowacyjne rozwiązania w branży produkcyjnej, wykorzystując technologie w zakresie zapewnienia bezpieczeństwa danym wrażliwym. 

Głównym wyzwaniem było opracowanie i zaproponowanie nowej architektury systemu wraz ze ścieżką migracji na nową i dostosowaną do bieżących potrzeb. 

Głównym celem migracji było m.in.: 

• Zwiększenie wydajności przetwarzania danych wymaganych przez maszyny produkcyjne - Potrzebny był nowy system procesu kontroli produkcji, który poprawiłby szybkość działań. Wynikało to z faktu, że w monolicie dodawanie kolejnych elementów wydłużało proces testowania, dlatego niezbędna okazała się pomoc w opracowaniu lepszej architektury. 
• Wykrycie wąskich gardeł w systemie i ich optymalizacja - Przejście na kontenery ułatwiłoby regularne aktualizacje, tworzenie kolejnych instancji w celu opanowania trudności w przepływie informacji. 
• Możliwość skalowania obecnego systemu 
• Łatwość dodawania rozwiązań dla nowych produktów   
• Poprawa stabilności, zwiększenie niezawodności oraz odporności na błędy - Zarządzanie monolitem było wyzwaniem, szczególnie ze względu na radzenie sobie w przypadku awarii  

ETAP I 

INITIATION- Omówienie wspólnego zrozumienia zadań i celów Klienta 

Naszym głównym zadaniem było zrozumienie procesów produkcyjnych, architektury i zakresu działań Klienta. Skupiliśmy się też na ustaleniu wspólnej perspektywy, tak by wyeliminować ewentualne niezrozumienie wymagań. Zdefiniowaliśmy, co chce osiągnąć zespół Klienta i jaki ma być finalny produkt tego projektu. Najważniejsze dla nas było poznanie ich oczekiwań i potrzeb, oraz zakresu zadań.  

Zespół z Niemiec opowiadał jakie mają cele i założenia, co ułatwiło nam to podzielenie wymagań na dwa rodzaje - techniczne i biznesowe.  

• Cel biznesowy - Klient chce zwiększyć skalowalność swojego systemu oraz wdrażać nowe produkty z niskim użyciem zasobów i w szybkim czasie (time- to-market). 
• Cel techniczny – polega przede wszystkim na rozwiązaniu opartym na kontenerach oraz optymalizacji procesu przepływu danych i wykryciu ewentualnych zakłóceń (bottle necks), oraz skrócenie czasu przeprocesowania danych do maksymalnie 15 minut. 

Główną potrzebą zespołu Klienta była rekomendacja technologiczna, określająca przygotowanie opisu architektonicznego jako ściśle merytorycznego podejścia do propozycji technologicznej.

DESIGN THINKING - zbieranie danych oraz wprowadzenie do wstępnej koncepcji 

W następnym etapie omówiliśmy wszystkie komponenty jakie są w aktualnych systemach klienta oraz elementy ich sieci i infrastruktury. Następnie płynnie przeszliśmy do analizy wszystkich urządzeń produkcyjnych Przygotowując dane poznaliśmy bliżej maszyny oraz ich sposób działania, w tym celu zadawaliśmy wiele pytań m.in. jak działa system, jakie są procesy, zależności, systemy graniczące itp. 

Po poznaniu dokumentacji Klienta definiowaliśmy cele, które chcemy osiągnąć. Wykorzystywaliśmy różne rodzaje metodyki Agile podczas procesu wytwarzania, były to np.  use case diagrams, czy activity diagrams. Wspólnie z Klientem rozrysowaliśmy architekturę systemu oraz omówiliśmy, które moduły i funkcjonalności powinny być zastąpione bądź ulepszone. Wybrany stack-technologiczny miał być wspierany przez długi czas (LTS) oraz bazująca na kontenerach. 

 Taka techniczna dyskusja ułatwiła zamodelowanie procesów biznesowych (BPMN/Activity Diagram) oraz zaproponowanie nowych rozwiązań. Po pierwszym warsztacie zdefiniowaliśmy propozycję rozwiązania. Następnie określiliśmy, że przygotujemy rekomendację technologiczną, zawierającą informację o wszystkich korzysciach i ryzykach danych rozwiązań oraz szkic architektury.  Zdefiniowaliśmy też spotkania tygodniowe z klientem, podczas których wymienialiśmy z Klientem wspólne uwagi, sugestie i propozycje. 

ETAP II 

PLANNING 

Podczas drugiego warsztatu ponownie wskazaliśmy na cele i założenia projektowe. Następnie omówiliśmy pierwszy szkic architektury, bazujacy na otrzymanej dokumentacji technicznej. W kolejnym etapie zaprezentowaliśmy dwa koncepty porównujące obecne oraz nowe podejście architektoniczne Event Driven Architecture w połączeniu z rozwiązaniem hybrydowym opartym o wzorzec mikroserwisów i modularnego monolitu.  Między innymi przeszliśmy przez stack technologiczny, który rekomendujemy i propozycję architektury.  

Zdecydowaliśmy się na Event Driven Architecure, ponieważ dzięki takiemu podejściu można uzyskać: 

1. Luźne powiązania między komponentami – Komponenty mogą komunikować się za pomocą asynchronicznych wiadomości opartych na eventach, co umożliwia większą elastyczność i skalowalność systemu. 
2. Skalowalność - W tej architekturze można rozdzielić przetwarzanie na wiele komponentów, gdzie każdy z nich może niezależnie obsługiwać przychodzące eventy. To umożliwia łatwe skalowanie systemu w miarę wzrostu obciążenia i zapewnia równomierne wykorzystanie zasobów. 

W następnym etapie pokazaliśmy, jak wyobrażamy sobie nowy system i omówiliśmy główne założenia. 

Następnie przedstawiliśmy strategię dwóch podejść jak przejść z aktualnego systemu do nowego. Składa się z dwóch części: 

• Koncepcja ewolucyjna – polega na zmianie sposobu komunikacji 
• Koncepcja rewolucyjna - zmieniliśmy całkowicie sposób komunikacji, jak moduły się komunikują. Dzięki stworzeniu “kolejek” poprawiła się wydajność modułów oraz skrócił czas komunikacji i przetwarzania danych. 

W zakres planowania technologicznego wchodził wybór odpowiednich technologii, w tym przypadku była to Java 17 (JDK 17) wraz ze SpringBoot 3.1 / Spring 6. Podstawowym czynnikiem decydującym o wyborze stosu technologicznego była znajomość wymagań systemu oraz dostępność zasobów i programistów. 

Co otrzymał Klient po warsztatach produktowych? 

Po warsztatach klient otrzymał pełną dokumentację w języku niemieckim, zbierającą wszystkie ustalenia koncepcyjne w jedną całość. Znajdują się w nim wszystkie wcześniej opisane kroki, takie jak definicja celów, wybór stosu technologicznego, określenie docelowego podejścia ewolucyjnego lub rewolucyjnego. 

Klient był bardzo zadowolony z przebiegu warsztatów produktowych, ponieważ spełniliśmy praktycznie wszystkie jego oczekiwania. Dzięki świetnej komunikacji stworzyliśmy zupełnie nową propozycję architektoniczną. Oczekiwanie klienta nie było utworzenie planu migracji, wyceny projektu, czy podział na fazy implementacji. 

Do korzyści, które uzyskał Klient dzięki warsztatom Design Thinking można zaliczyć: 

• Oszczędność kosztów - zamiast eksperymentować we własnym zakresie, odciągać własnych deweloperów od głównych zadań zespół otrzymał gotowe rozwiązanie 
• Innowacyjne wyjście poza schemat - dzięki obiektywnemu podejściu mogliśmy rzeczowo spojrzeć na aktualną architekturę klienta i cele jakie chce osiągnąć.  
• Nowoczesne rozwiązania technologiczne i architektoniczne 
• Aktywna współpraca - zespół klienta aktywnie uczestniczył w procesie z wymiany doświadczeń dotyczących podejścia technologicznego oraz brał czynny udział na warsztatach, m.in. podczas modelowania 
• Znacząca redukcja ryzyka - dzięki temu, że zespół klienta nie musi samemu eksperymentować z nowymi rozwiązaniami technologicznymi, oszczędza czas na popełnianie błędów przy wczesnej adopcji systemu. 

Efekt końcowy po prezentacji wewnątrz firmy zrobił takie wrażenie, że z klientem opracowaliśmy 2 projekty  PoC (Proof of Concept). Każdy projekt składa się z kilku etapow, rozwijany w interwalach. Na końcu każdego z nich będziemy przeprowadzac demo, w celu prezentacji i omówienia postępów prac. 

Zakres przyszłych projektów, które określiliśmy z klientem dotyczy m.in.:  

• Realizacja koncepcji Event Driven Architecture w oparciu o kontenery. Podstawa będzie postawienie infrastruktury, utworzenie podstawowej konfiguracji kolejek oraz podstawowego monitoringu wraz z dokumentacja.  
• Automatyczne skalowanie rozwiązania, w oparciu o obciążenie kolejek lub zasobów. Dodatkowo prace będą dotyczyły przeprowadzenie różnych operacji na dostępności aplikacji, kolejek, itd. wraz z dokumentacja.