O projekcie
Trans.eu to jedna z największych giełd transportowych w Europie, codziennie łącząca tysiące firm spedycyjnych, załadowców i przewoźników.
Przez lata Trans.eu utrzymywał własny, wewnętrzny moduł integracji z ponad 120 dostawcami telematycznymi, osadzony w module floty: przewoźnik konfigurował tam pojazdy i podłączał urządzenia GPS, aby udostępnić ich pozycję na potrzeby giełdy transportowej. Adopcja tego rozwiązania była ograniczona strukturalnie, nie technicznie - pełna transparentność danych operacyjnych (przestoje, awarie, rzeczywisty przebieg trasy) była sprzeczna z interesem części przewoźników, dla których złożoność konfiguracji stanowiła wygodne uzasadnienie braku integracji.
Odpowiedzią na tę barierę adopcyjną był CO³, polski agregator telematyczny integrujący dziesiątki dostawców GPS i udostępniający dane lokalizacyjne pojazdów po numerze rejestracyjnym. Model ten eliminował udział przewoźnika w procesie integracji: identyfikacja pojazdu następowała na podstawie danych podawanych przez załadowcę, bez konieczności jakiejkolwiek konfiguracji po stronie przewoźnika. Argument o złożoności integracji przestał mieć zastosowanie.
Ograniczeniem CO³ pozostawało jednak pokrycie floty jako niszowy, krajowy dostawca, obejmował relatywnie niewielki odsetek pojazdów obsługiwanych przez Trans.eu. Kolejnym etapem ewolucji było wdrożenie Project44 - globalnego agregatora telematycznego o istotnie większej skali i zasięgu międzynarodowym, oferującego szersze pokrycie floty oraz architekturę zdarzeniową opartą na webhookach. Integracja z Project44 wprowadziła model push i ostatecznie doprowadziła do decyzji o dekomisji wewnętrznego modułu telematyki, którego utrzymanie przestało być uzasadnione ekonomicznie.
fireup.pro uczestniczyło w tej blisko pięcioletniej transformacji na każdym etapie: przy rozwoju wewnętrznego systemu, integracji z CO³ i Project44, oraz finalnej dekomisji modułu telematyki.
Biznesowe
Technologiczne
Doświadczenie klienta
Zespół fireup.pro bardzo sprawnie podszedł do realizacji projektu. Dzięki jego zaangażowaniu możemy dalej rozwijać wykorzystanie danych w naszej grupie.
Piotr Sobala
Product Owner Trans.eu
Od wyzwania
Kluczowe wyzwania
Bariera adopcyjna wynikająca z asymetrii interesów uczestników łańcucha.
Bariera adopcyjna wynikająca z asymetrii interesów uczestników łańcucha.
Wewnętrzny system telematyczny wymagał aktywnej konfiguracji floty po stronie przewoźnika, co dawało pełną transparentność danych operacyjnych. Część przewoźników traktowała złożoność integracji jako uzasadnienie braku wdrożenia. Rozwiązanie musiało eliminować samą możliwość takiego uzasadnienia, nie tylko redukować nakład pracy integracyjnej.
Niewystarczające pokrycie floty jako bloker skalowania.
Niewystarczające pokrycie floty jako bloker skalowania.
Integracja z CO³ była poprawna technicznie, lecz ograniczona liczbą obsługiwanych pojazdów ze względu na skalę dostawcy. Poprawnie zaprojektowany model danych nie przekładał się na wartość biznesową bez odpowiedniego pokrycia floty.
Asymetria pozycji negocjacyjnej w zależności od skali partnera integracyjnego.
Asymetria pozycji negocjacyjnej w zależności od skali partnera integracyjnego.
W integracji z CO³ (dostawca niszowy) specyfikację narzucał Trans.eu. Integracja z Project44 (dostawca o porównywalnej lub większej skali rynkowej) wymagała współprojektowania rozwiązania w modelu partnerskim, z regularną synchronizacją roadmap i cyklicznymi spotkaniami technicznymi obu zespołów.
Migracja z modelu synchronicznego na architekturę zdarzeniową rozłożona na kolejne etapy integracji.
Migracja z modelu synchronicznego na architekturę zdarzeniową rozłożona na kolejne etapy integracji.
Wewnętrzny system operował w trybie ciągłego pollingu (interwał 30 sekund). CO³ pozostał przy modelu odpytywania, ograniczonym jednak do okna czasowego zlecenia transportowego ze względu na model rozliczeniowy oparty na liczbie zapytań. Właściwy model zdarzeniowy (webhook) wprowadzono dopiero w integracji z Project44, co wymagało nowego podejścia do biernego przetwarzania napływających zdarzeń.
Rozbieżność między deklarowaną a rzeczywistą wartością warstwy abstrakcji frameworka integracyjnego.
Rozbieżność między deklarowaną a rzeczywistą wartością warstwy abstrakcji frameworka integracyjnego.
Wybór frameworków klasy enterprise integration (Mule ESB, następnie Apache Camel) miał redukować koszt krańcowy podłączania kolejnych dostawców telematycznych dzięki gotowym komponentom integracyjnym. W praktyce każdy dostawca wymagał indywidualnie zaimplementowanego konektora - warstwa abstrakcji frameworka pozostawała w dużej mierze niewykorzystana, generując koszt utrzymania nieproporcjonalny do zakresu realizowanej funkcjonalności.
Przypadki użycia wykraczające poza prostą lokalizację pojazdu.
Przypadki użycia wykraczające poza prostą lokalizację pojazdu.
Monitorowanie naczepy niezależnie od ciągnika, weryfikacja zgodności z normami czasu pracy kierowcy (TACHO), walidacja przejechanych kilometrów na potrzeby rozliczeń - funkcjonalności te zyskiwały praktyczne zastosowanie dopiero przy pokryciu floty zapewnianym przez Project44.
Przez rozwiązanie
Przez rozwiązanie
Faza 1 - wewnętrzny system telematyczny
System zaimplementowany pierwotnie przez Bluesoft na Mule ESB, przejęty i rozwijany dalej przez zespół fireup.pro w ramach struktur Trans.eu. Mule ESB charakteryzował się wysokim kosztem utrzymania (konfiguracja oparta na plikach XML, istotne zużycie zasobów, ograniczona skalowalność) co skutkowało migracją integracji na Apache Camel, framework tej samej klasy, umożliwiający implementację logiki integracyjnej w czystej Javie.
System funkcjonował jako wydzielony moduł, komunikujący się z pozostałą częścią systemu Trans.eu poprzez zdefiniowane kontrakty, odpytujący każdego z ponad 120 dostawców telematycznych w interwale 30-sekundowym, w trybie ciągłym.
Faza 2 - integracja z CO³
Zaprojektowana z założeniem minimalnej ingerencji w istniejącą architekturę pollingową. Zamiast migracji na model zdarzeniowy, zespół utrzymał mechanizm odpytywania, ograniczając go do okna czasowego przypisanego do zlecenia transportowego.
Wynikało to z modelu rozliczeniowego CO³, opartego na liczbie zapytań o pozycję. Integracja wymagała dodatkowo implementacji autoryzacji opartej o OAuth 2 - pierwszego tego typu mechanizmu wśród dotychczas integrowanych dostawców telematycznych.
Faza 3 - integracja z Project44 i migracja na architekturę zdarzeniową
W tej fazie wdrożono właściwy model zdarzeniowy: Project44 informował Trans.eu o zmianie pozycji pojazdu poprzez webhook, eliminując konieczność odpytywania.
Ze względu na skalę i pozycję rynkową Project44, integracja była projektowana w modelu współpracy technicznej, cykliczne spotkania zespołów obu stron, bieżąca synchronizacja postępu prac i wspólne ustalanie specyfikacji.
Redukcja złożoności warstwy technologicznej
Wraz z zaprzestaniem dodawania nowych dostawców telematycznych integrację z Project44 zaimplementowano w czystej Javie, z pominięciem Apache Camela - rozwiązanie o niższym koszcie utrzymania niż framework, którego warstwa abstrakcji nie była w pełni wykorzystywana.
Dekomisja wewnętrznego modułu telematyki
Po osiągnięciu przez Project44 wystarczającego pokrycia floty podjęto decyzję o całkowitym wyłączeniu integracji z pozostałymi dostawcami GPS. Funkcjonalności wykorzystywane przez inne komponenty systemu (przede wszystkim moduł map) zostały przeniesione bezpośrednio do docelowych systemów, bez utrzymywania odrębnego modułu telematyki. Dekomisja modułu stanowiła finalny etap projektu.
Po sukces
Efekty technologiczne
Architektura zdarzeniowa zamiast cyklicznego odpytywania, wdrożona wraz z integracją Project44, zastępująca zarówno polling wewnętrznego systemu, jak i ograniczony czasowo polling CO³.
Konsolidacja warstwy integracyjnej do jednego zewnętrznego dostawcy o szerokim pokryciu floty, w miejsce ponad 120 bezpośrednich integracji oraz dodatkowej integracji z CO³.
Redukcja złożoności stosu technologicznego - rezygnacja z frameworka integracyjnego klasy enterprise (Mule ESB → Apache Camel) na rzecz implementacji w czystej Javie w obszarach, gdzie warstwa abstrakcji frameworka nie generowała wartości.
Dekomisja zbędnej infrastruktury -wyłączenie wewnętrznego modułu telematyki i migracja wymaganych funkcjonalności bezpośrednio do systemów docelowych.
Korzyści biznesowe
Eliminacja bariery adopcyjnej po stronie przewoźników - identyfikacja pojazdu po numerze rejestracyjnym nie wymaga jakiejkolwiek konfiguracji ani udziału przewoźnika.
Zdolność do egzekucji decyzji o dekomisji - rozpoznanie momentu, w którym pierwotny model (wewnętrzne, ciągłe monitorowanie floty) przestał generować zwrot z inwestycji, i konsekwentne wyłączenie zbędnej infrastruktury.
Weryfikacja kilometrażu na potrzeby rozliczeń między załadowcą a przewoźnikiem oparta na danych telemetrycznych, nie deklaracjach.
Redukcja kosztu utrzymania, przeniesienie odpowiedzialności za integracje telematyczne na wyspecjalizowanego dostawcę zewnętrznego, eliminujące konieczność utrzymywania dziesiątek bezpośrednich integracji oraz dedykowanego modułu technologicznego.
Istotny wzrost praktycznej wartości danych telematycznych wynikający z przejścia z CO³ (ograniczone pokrycie floty) na Project44 (pokrycie obejmujące większość floty obsługiwanej przez Trans.eu) wartość modelu biznesowego materializowała się dopiero przy odpowiedniej skali dostawcy.
Zespół projektowy
Adam
Tech stack
Java
Python
Spark
RabbitMQ
Apache Camel
Mule ESB
MySQL
PostgreSQL
Amazon ECS
Amazon RDS
Docker
Twoja sukces to nasz sukces!
Zobacz, jak możemy wspólnie zbudować technologiczną przewagę dla Twojej firmy
Mamy zespół, który naprawdę zna się na rzeczy — pomożemy Ci znaleźć rozwiązanie, które działa.
Wnioski i rekomendacje
Bariera adopcyjna bywa strukturalna, nie techniczna. Wewnętrzny system telematyczny funkcjonował poprawnie pod względem technicznym, lecz nie adresował rzeczywistego problemu - asymetrii interesów między pełną transparentnością danych operacyjnych a interesem części przewoźników. Rozwiązaniem nie była optymalizacja procesu, lecz zmiana modelu integracji eliminująca udział przewoźnika.
Wybór frameworka integracyjnego klasy enterprise jest uzasadniony wyłącznie przy pełnym wykorzystaniu jego warstwy abstrakcji. Mule ESB i Apache Camel miały redukować koszt krańcowy podłączania kolejnych dostawców. W praktyce każdy dostawca wymagał dedykowanej implementacji konektora, co ograniczało realizowaną wartość frameworka względem kosztu jego utrzymania.
Skala partnera integracyjnego determinuje model negocjacji technicznych. Integracja z dostawcą niszowym (CO³) pozwala na jednostronne narzucenie specyfikacji. Integracja z dostawcą o porównywalnej skali rynkowej (Project44) wymaga modelu partnerskiego, wspólnego projektowania rozwiązania i synchronizacji roadmap między zespołami.
Model biznesowy może przetrwać kilka iteracji dostawcy, zanim osiągnie zakładaną wartość. Koncepcja lokalizacji pojazdu bez udziału przewoźnika pozostawała niezmienna na przestrzeni trzech implementacji (system wewnętrzny, CO³, Project44) - zmieniał się wyłącznie dostawca, do momentu osiągnięcia skali umożliwiającej realizację założonej wartości biznesowej.
Dekomisja systemu jest decyzją o równoważnym znaczeniu co jego wdrożenie. Rozpoznanie momentu, w którym pierwotny model przestaje generować zwrot z inwestycji, i konsekwentne wyłączenie zbędnej infrastruktury, stanowi integralny element cyklu życia projektu, nie działanie poboczne.
