Integracja architektury IT w oparciu o API-led Connectivity

API-led Connectivity obrazek wyróżniający
API-led connectivity  to koncepcja bazująca na łączeniu danych pomiędzy systemami, poprzez reużywalne i zbudowane w określonym celu API (ang. application programming interface), których powiązanie ze sobą jest sposobem realizacji usług w rozumieniu SOA. Z poniższego artykułu dowiesz się:
  • na czym polega na ten model integracji?
  • co odróżnia go od pozostałych rozwiązań?
  • jakie ma wady i ograniczenia?
  • w jakich przypadkach ma zastosowanie?

 

W większości przypadków międzysystemowe transfery danych realizowane są w oparciu o mechanizmy działające według zasady: pozyskanie danych ze źródła > transformacja > dostarczenie danych do odbiorcy. Istnieje jednak podejście, które bazuje na wprowadzeniu drobniejszej granulacji i wielopoziomowości mechanizmów integracyjnych. Dzięki jego zastosowaniu otwierają się dużo większe możliwości zarówno dla odbiorców, jak i właścicieli danych.

Opisywane podejście to API-led connectivity, czyli koncepcja bazująca na łączeniu danych pomiędzy systemami poprzez reużywalne i zbudowane w określonym celu API (ang. application programming interface), których powiązanie ze sobą jest sposobem realizacji usług w rozumieniu SOA.

API – czyli ustrukturyzowane interfejsy umożliwiające komunikację z danymi źródłami danych – są w tym podejściu wytworzone dla określonych celów – pozyskiwanie „surowych” danych z systemów źródłowych, wkomponowywanie ich w procesy biznesowe lub dostarczanie konkretnej wartości biznesowej wynikającej z danych i procesów dla jej odbiorców. Wyróżniamy 3 kategorie API:

  • System API– zapewniają dostęp do danych, pozyskanych bezpośrednio z systemów źródłowych. Separują odbiorcę od skomplikowanej logiki oraz budowy systemu, gwarantując jednocześnie pełną kompatybilność interfejsu z systemem źródłowym. Raz stworzone i stale aktualizowane API może służyć za podstawowe źródło danych dla wielu potencjalnych odbiorców, bez konieczności poznania systemu źródłowego.
  • Process API – stworzone na potrzeby procesów biznesowych, wchodzą w interakcję z System API pozyskując od nich dane, po czym wdrażają je w określone struktury niezależne od systemów źródłowych. Process API mogą pozyskiwać dane z wielu System API, co eliminuje silosowość danych w organizacji (brak współdzielenia, izolowanie danych tylko na potrzeby danego wycinka infrastruktury).
  • Experience API– są proste i odpowiadają za udostępnienie odbiorcom końcowych danych, pozyskanych z systemów źródłowych za pomocą System API i przetworzonych przez serię Process API. Odbiorcami danych mogą być wszystkie aplikacje, bez względu na ich budowę, technologię, platformę i zastosowanie. Experience API mogą korzystać z jednego lub wielu Process API, przeprowadzając łączenie struktur danych oraz ich transformację.

 

API-led Connectivity

 

Opisywana koncepcja integracji systemów zrywa z podejściem opierającym się na pełnym dostępie i centralizacji informacji w organizacji – dostęp do danych przedsiębiorstwa dla poszczególnych odbiorców jest stopniowany. Nie każdy zainteresowany może i chce mieć dostęp do danych bezpośrednio wytransferowanych z systemu źródłowego. Zostaje on wtedy „przypięty” do ostatniej warstwy API, która dostarcza już przetworzoną postać danych, nadających się do użycia w kontekście biznesowym.

API, będące fundamentem tego API-led Connectivity, są w pełni zarządzalne przez ich właściciela oraz ogólnodostępne dla potencjalnych odbiorców, dostępem do katalogu API. To właśnie w tym katalogu można zapoznać się z dokumentacją API opisującej sposób jej działania, obsługiwane struktury danych oraz zawnioskować o dostęp do określonych interfejsów do ich właściciela.

Głównym celem, który przyświeca koncepcji API-led connectivity jest osiągnięcie reużywalności nie tylko na poziomie udostępnianych interfejsów, ale również pełnych procesów integracyjnych zachodzących wewnątrz warstwy integracyjnej (droga od systemu źródłowego do obiorcy końcowego). W ten sposób, oprócz łatwego dostępu do przepływów integracyjnych nie powiela się logiki w nich zawartej, co znacząco wpływa na skrócenie czasu określanego jako „time to market”, czyli okresu koniecznego do faktycznego dostarczenia wartościowego rozwiązania realizującego cel biznesowy.

 

Zalety i możliwości API-Led Connectivity
  • Transparentność i dostępność udostępnianych usług – potencjalni odbiorcy danych z organizacji mogą zapoznać się z udokumentowanymi Experience API oraz przekazywanymi w ich ramach strukturami danych, co jest krokiem w stronę wstępnej „samoobsługi” w dostarczaniu danych do systemów partnerów. Korzyść jest obopólna, gdyż dzięki warstwowości architektury integracyjnej jej właściciel może w prosty sposób nią zarządzać.
  • Zwiększenie wydajności i skrócenie czasu tworzenia nowych rozwiązań integracyjnych dzięki reużywalności interfejsów oraz procesów realizujących mechanizmy integracyjne – logika nie jest duplikowana i może z niej korzystać wielu odbiorców.
  • Łatwiejsza obsługa zmian w warstwie integracyjnej – dzięki modularności i pełnej separacji poszczególnych warstw API w przypadku modyfikacji danej części rozwiązania (po stronie interfejsów lub systemów źródłowych) nie są konieczne całościowe testy regresji eliminujące występowanie nieprzewidzianego wpływu wprowadzonych zmian na całe rozwiązanie. Zazwyczaj wystarczy sprawdzić poprawność interakcji z API „sąsiednich” kategorii w hierarchii.
  • Duża granularność powstałych elementów architektury „szytych na miarę” sprzyja zastosowaniu nowoczesnych rozwiązań technologicznych, które są w pełni skalowalne i mogą być umiejscowione w chmurze (np. zastosowanie mikroserwisów). Umiejscowienie mechanizmów wytworzonych zgodnie z opisywaną koncepcją może od początku opierać się na infrastrukturze bazującej na chmurze, nie ma również przeszkód w zmigrowaniu kompletnego rozwiązania z własnych maszyn („on-premise”) do chmury.
  • Większa przejrzystość platformy integracyjnej – dzięki jej warstwowej budowie możliwe jest stosunkowo łatwe spojrzenie w jej gląb, chociażby podczas poszukiwania przyczyn nieprawidłowego działania procesów integracyjnych. W istotnym stopniu zmniejsza to czas konieczny do poświęcenia na zapoznanie się i utrzymanie rozwiązania.

 

Wady i ograniczenia
  • Wdrożenie koncepcji API-led connectivity wymaga pełnego jej poznania oraz zrozumienia jej założeń.
  • Konieczna również jest znajomość projektowania, tworzenia, dokumentowania, rozwoju i utrzymywania API wytwarzanych w różnych technologiach i korzystających ze zróżnicowanych protokołów komunikacyjnych.
  • Odpytywanie serii API, podzielonych ze względu na swoją rolę na warstwy (kategorie), skutkuje dodatkowym narzutem czasowym na wzajemną komunikację poszczególnych instancji. Te dodatkowe czasy można jednak minimalizować za pomocą odpowiedniego skalowania rozwiązania.

 

Zastosowanie, kryteria wyboru

Zbudowanie architektury integracyjnej zgodnie z wytycznymi koncepcji API-led Connectivity jest przedsięwzięciem ambitnym i wymagającym, ale w dłuższej perspektywie dostarczającym wielu korzyści biznesowych oraz operacyjnych dla przedsiębiorstwa. Jeżeli w organizacji:

  • systemy w infrastrukturze są duże i różnorodne,
  • występują skomplikowane mechanizmy i struktury udostępniania danych,
  • planowana jest budowa nowych procesów, mających na celu bezpieczne wydobywanie danych z systemów źródłowych oraz efektywne ich dystrybuowanie do odbiorców, w zrozumiałej biznesowo postaci oraz według zasady „tylko tyle, ile potrzeba”,

ten kierunek rozwiązania integrującego architekturę IT zdecydowanie się sprawdzi. Jeżeli natomiast organizacja posiada:

  • niewielką architekturę IT, składająca się z kilku systemów, które musza wymieniać się danymi w podstawowy sposób,
  • niewielką liczba obecnych i potencjalnych odbiorców danych z systemów źródłowych organizacji,
  • niewystarczające kompetencje do zaprojektowania, budowy i utrzymania zaawansowanej architektury integracyjnej – po stronie wewnętrznych zasobów ludzkich lub partnera, który podejmie się tego przedsięwzięcia,

powinna poszukać innych kierunków usprawnienia struktury aplikacji i danych, która odpowie na potrzeby mniejszej skali.

Analityk systemowy i koordynator projektów w Grupie Unity, absolwent dwóch kierunków na Uniwersytecie Ekonomicznym we Wrocławiu (Informatyka i Ekonometria, Zarządzanie i inżynieria produkcji). Z branżą IT związany od 6 lat, zaczynał w roli testera oprogramowania. Zawodowo zajmuje się analizą procesów oraz projektowaniem szeroko rozumianych rozwiązań informatycznych - od aplikacji dedykowanych do zaawansowanych procesów integracyjnych wykorzystaniem komponentów klasy ESB i pokrewnych. Interesuje się projektowaniem architektury IT. Prywatnie miłośnik sportu, motoryzacji oraz nowych technologii.

Napisz do nas

Potrzebujesz więcej informacji lub jesteś zainteresowany współpracą z nami? Chętnie odpowiemy na każde pytanie. Zapraszamy do kontaktu!
Pola oznaczone * są wymagane.