Zdarzyło Wam się kiedyś wpisać dane do ubezpieczenia samochodu, nacisnąć przycisk „policz” i… czekać? Towarzystwo ubezpieczeniowe nic nie traci, jeśli taka sytuacja ma miejsce w przypadku porównywarki, która zbiera informacje z wielu towarzystw. Ale jeśli to zdarzyło się bezpośrednio na stronie ubezpieczyciela, to klient nie będzie czekał dłużej niż 60 sekund. Zamknie stronę i już nie wróci.
Kilka bolesnych przykładów problemów z integracjami
Inny przykład to rejestracja online wizyty u lekarza i komunikat „Brak dostępnych terminów”. Pewnie w większości przypadków tych terminów rzeczywiście nie ma, ale co, jeśli po prostu coś nie zadziałało? Ten klient wróci, bo nie ma wyjścia, ale jeśli będzie się to zdarzać częściej, istnieje ryzyko, że odejdzie cała grupa ubezpieczonych. A to już potrafi zaboleć.
Kolejny przykład jest trochę z przyszłości, gdyż ubezpieczenia wbudowane (ang. embedded insurance) jeszcze nie są nad Wisłą standardem. Załóżmy, że Airbnb oferuje ubezpieczenie dla najemcy w trakcie rezerwacji mieszkania. Załóżmy, że oferentami jest kilka polskich towarzystw ubezpieczeniowych, które przeszły trudny proces integracji z gigantem. Jeśli nie uda się spełnić wyśrubowanych parametrów związanych z czasem dostarczenia oferty ubezpieczeniowej w trakcie rezerwacji, to… no cóż, klient nie poczeka, a Airbnb uzyska pretekst to rozwiązania umowy.
W większości wyżej opisanych przypadków winna nie jest strona internetowa, system polisowy czy kalkulator oferty. Zwykle niestety coś nie zagrało na łączach, czyli zawiodła integracja pomiędzy systemami.
Umieszczenie wszystkich integracji w jednym miejscu? Co może pójść nie tak?
Przyczyn problemów ze zbudowaniem funkcjonalnej architektury integracji pomiędzy platformami/systemami/usługami jest wiele. Poniżej chciałbym opowiedzieć o kilku, z którymi jako IKOR potrafimy sobie poradzić.
W przeszłości podstawowym wąskim gardłem architektury systemowej był zwykle system główny. Obecnie przy migracji w kierunku rozwiązań chmurowych czy architektury opartej na mikrousługach coraz częściej wąskim gardłem są węzły integracyjne, czyli szyny ESB lub integracje punkt-punkt pomiędzy systemami. Rozwiązania takie zwykle znajdują się w jednym miejscu, obsługując dużą liczbę interakcji i zwyczajnie sobie nie radzą, szczególnie przy dużym obciążeniu.
Zcentralizowane węzły integracyjne typu szyny ESB nie są od strony technicznej przygotowane do nagłego wzrostu obciążenia. Można je albo przeskalować (czyli wydać za dużo pieniędzy), albo niedoszacować (czyli liczyć się z opóźnieniami w przypadku większego obciążenia architektury systemowej).
Kolejnym problemem natury czysto biznesowej jest uzależnienie od dostawcy IT, który szynę integracyjną dostarczył i ją rozwija. Niech pierwszy rzuci kamieniem, kto od swojego dostawcy IT nie usłyszał przynajmniej raz, że „obecnie nie mamy zasobów na realizację projektu”. Pomijam zupełnie sprawę możliwości zmiany dostawcy, kiedy nagle stawki przestały być rynkowe.
Wszystkie wyżej wymienione bolączki prowadzą do jednego – stworzenia w architekturze systemowej jednego potencjalnego miejsca krytycznego (ang. single point of failure), zarówno pod kątem technicznym, jak i biznesowym.
Dorzuciłbym jeszcze jedną konkluzję: zwykle „integracja z innymi systemami” jest elementem wdrożenia konkretnego systemu czy platformy. A tak naprawdę w obecnym świecie budowa i rozwój interfejsów pomiędzy systemami czy interfejsów do systemów partnerskich trwa cały czas. Zmiana w jednym systemie powoduje konieczność testów w systemach zintegrowanych. Ciągle jednak w harmonogramach „testy integracyjne” to element wdrożenia systemu.
Dane. Coraz więcej danych
Nikt nie podważa konieczności zbierania dużej ilości danych. Zwykle zbieranie danych odbywa się w konkretnych systemach czy aplikacjach. A przecież te wszystkie dane „fruwają” pomiędzy systemami. Interfejsy pomiędzy systemami (szyny integracyjne, kolejki, integracje punkt-punkt) są idealnym miejscem do centralnego zbierania danych z całej architektury systemowej.
Odpowiednio zbudowana architektura integracji, przy wykorzystaniu odpowiednich narzędzi, pozwoli nie tylko rozwiązać wszystkie bolączki, ale umożliwi wykorzystanie integracji jako idealne źródło danych dla uczenia maszynowego czy sztucznej inteligencji.
Co możemy z tym zrobić?
Na wszystkie powyższe problemy mamy rozwiązanie. Poniżej garść rekomendacji.
Zbuduj integrację na podstawie jednego logicznego huba (ang. logical-hub-mindset). W naszym podejściu budujemy integrację jako zestaw mikrousług, ale połączonych w jednym frameworku. Mikrousługi świetnie się skalują i są łatwe do przeniesienia do chmury. Dodatkowo wszystkie usługi integracyjne spełniają jeden, narzucony standard. To znakomicie zmniejsza koszty utrzymania i przyspiesza wdrażanie nowych rozwiązań.
Przenieś integrację do chmury. No właśnie. Skoro wszystko przenosimy do chmury, dlaczego połączenia pomiędzy systemami mają zostać w tyle. Chmura w sposób naturalny wspiera obsługę nieprzewidzianych wzrostów obciążenia. Dodatkowo takie podejście zgrywa się z DNA wszystkich dostawców usług (jak Booking, Uber), z którymi firmy finansowe mogą w łatwy sposób dostarczać gotowe produkty jako wartość dodaną.
Nie kupuj szyny integracyjnej, kup framework open-source, czyli darmowe narzędzie do rozwoju integracji pozwalające na rozwój i utrzymywanie integracji własnymi siłami lub siłami wielu firm.
Przekształć dział IT w dział integracji. Skoro integracja jest kluczowa, to dlaczego oddawać ją jednemu dostawcy. Działy IT towarzystw ubezpieczeniowych powinny zbudować kompetencje integracyjne lub ewentualnie oddawać je firmom zewnętrznym, ale na swoich zasadach.
Zbuduj model pośredni pomiędzy systemami. Budowa pośredniego modelu danych pomiędzy integrowanymi systemami pozwala na uniezależnienie się od zmian interfejsów w pojedynczych systemach. Co więcej, zachowanie rygoru przy budowie pośrednich modeli dla całej organizacji pozwala na budowę metawarstwy danych, która jest idealnym źródłem dla systemów uczących.
Zaplanuj i utrzymuj testy integracyjne. Integracja nigdy się nie skończy, więc jej testy również. Konieczne jest ich zaplanowanie i przeprowadzanie niezależnie od harmonogramów wdrożenia poszczególnych systemów.
System Integration Platform (SIP) – chmurowa platforma integracyjna oparta na Open-Source Framework
Rozwiązania open-source, takie jak Apache Camel czy Spring Boot, to przydatne narzędzia. W IKOR wykorzystaliśmy je do stworzenia platformy integracyjnej SIP.
W skrócie SIP pozwala na zredukowanie złożoności integracji pomiędzy systemami w ramach całej architektury systemowej. Dzieje się tak w przeciwieństwie do rozwiązań typu Enterprise Service Bus (zcentralizowane integracje w topologii hub-and-spoke), które zwykle angażują olbrzymie koszty oraz licencjonowane technologie.
SIP może być wykorzystany jako kompleksowa platforma w różnej, specyficznej dla towarzystwa ubezpieczeniowego infrastrukturze. Zarówno wdrożenie, jak i utrzymanie jest całkowicie niezależne od integrowanych systemów czy środowiska systemowego.
Platforma integracyjna składa się z wielu adapterów (SIA – System Integration Adapters), specyficznych dla każdej integracji pomiędzy systemami, ale zbudowanych na podstawie jednolitego frameworku. Adaptery te, działające na zasadzie mikrousług zainstalowanych w chmurze, doskonale się skalują i dostosowują do specyficznych potrzeb. Jednocześnie dzięki spójnej topologii można nimi zarządzać i je monitorować za pomocą narzędzi dostarczanych przez IKOR. Dodatkowo w ramach frameworku dostarczamy środowisko testowe pozwalające na łatwe wdrożenie i testowanie nowych integracji czy zmian.
Więcej (w języku angielskim) na stronie: https://ikor.one/en/product/system-integration-platform
Jakub Lewandowski
jakub.lewandowski@ikor.de
IKOR zajmuje się digitalizacją procesów biznesowych firm ubezpieczeniowych i banków w obszarze konsultacji technicznych, integracji oraz dostawy oprogramowania. Koncentrujemy się na zautomatyzowanych procesach end-to-end i przyszłościowych rozwiązaniach systemowych. Nasi specjaliści posiadają szerokie doświadczenie w integracji systemów, migracji danych, wdrażaniu systemów głównych oraz narzędzi wspierających zarządzanie procesami.
Ponad 300 pracowników w ośmiu lokalizacjach w Niemczech, Polsce, Austrii, Wielkiej Brytanii i Serbii łączy uczestników cyfrowego świata od ponad 25 lat. IKOR posiada status Gold Partner firmy SAP oraz Consulting Partner firmy Guidewire Software. Naszymi klientami są największe firmy ubezpieczeniowe i banki w Europie. Od kilku lat jesteśmy częścią grupy X1F – dostawcy usług IT dla sektora finansowego.
Więcej (w języku angielskim) na stronie: https://ikor.one/en
