Integracja aplikacji dostępna dla każdego, czyli usprawnienie biznesu poprzez strategię „agile”

Zwinność (choć częściej spotykana w kręgach informatycznych jest nazwa anglojęzyczna agility) to dość często powtarzany termin w dyskursie cyfrowej transformacji. Czy mamy jednak pewność, że to dobre podejście do problemu? Czy stosujemy tę zasadę w sposób holistyczny, wszędzie, gdzie jest niezbędna? Odpowiedź brzmi: nie. Nie istnieje jedno, uniwersalne rozwiązanie zapewniające tak pożądaną przez przedsiębiorców „zwinność w biznesie”. Można ją raczej osiągnąć poprzez angażowanie się w różne inicjatywy: usprawnianie samoobsługi bądź zwiększenie szybkości działania poprzez zastosowanie m.in. metodologii „Continuous Integration and Deployment” (CI/CD – Ciągła Integracja i Wdrażanie). Z mojego doświadczenia wynika, że te kwestie ograniczają się jedynie do usprawnień w obszarze tworzenia kodu. Co więc dzieje się w związku z integracją?

Aplikacje bardzo rzadko funkcjonują jako pojedyncze byty. Niezależnie od tego, czy tworzone są na użytek wewnętrzny, czy też zewnętrzny, istnieje potrzeba integracji aplikacji z wieloma systemami i usługami. Także i tutaj, podobnie jak w przypadku warstwy kodu, zwinność może okazać się przydatna. Istnieje wiele zmian, jakie mogą zajść poza obszarem kontrolowanym przez właściciela aplikacji, jak na przykład modyfikacje czy połączenia z nowymi partnerami.

Poniżej podane są trzy czynniki, które w konsekwencji mogą stanowić wyzwanie w zakresie zwinności integracji.

1. Integracja w sercu aplikacji. Często bywa, że „rdzeń” funkcjonalności aplikacji opiera się o fuzję z innymi, już istniejącymi usługami. Usługi te częstokroć stanowią rdzeń systemów w danej firmie, i tym samym powinny zostać na swoim miejscu. Zmiany w obrębie aplikacji mogą przełożyć się na zmiany w warstwie integracji.

2. Procesy organizacyjne. Niektóre dotychczasowe założenia mogą stanowić przeszkodę na drodze do osiągnięcia postępów. Jeżeli integracją między usługami zarządza dedykowane temu procesowi centrum kompetencyjne, zarządzane przez scentralizowany zespół, może to prowadzić do powstania wąskich gardeł, w przypadku wystąpienia potrzeby osiągnięcia wyższego tempa zmian bądź wprowadzenia ich w większej ilości. Tego typu „scentralizowane” zespoły mogą niejako zaprzeczać filozofii „agile”.

3. Zmiany technologiczne. Tradycyjnie stosowana architektura w warstwie integracji opiera się o korporacyjne magistrale usług (w języku angielskim skrótowo znane jako ESB, Enterprise Service Bus). ESB są zwykle wdrażane w ujednolicony sposób, gdzie sama logika integracji zostaje scentralizowana w ramach jednego dużego wdrożenia, co przekłada się z kolei na ograniczoną zdolność do adaptacji, tak w odniesieniu do różnych aplikacji, jak i potrzeb. To z kolei może spowolnić szybkie i częste zmiany – ich rosnąca istotność gra coraz większą rolę w sukcesie biznesowym.

Przyglądając się temu, jak różne firmy przyjmują zasady „zwinnej integracji” (ang. agile integration), Red Hat wyszczególnił trzy kluczowe filary takiego procesu, które opisujemy poniżej.

1. Integracja rozproszona. Istotne jest to, by w ramach procesu zarządzania integracją, kompetencje i umiejętności zostały rozproszone pomiędzy różne zespoły. Pożądane jest także, by sama integracja nie była zadaniem dla scentralizowanego zespołu i dostęp do niej był udzielany każdorazowo, gdy wystąpi taka potrzeba. Architektura wdrożenia również musi mieć charakter rozproszony, by pozwolić wszystkim zespołom zaangażowanym w integrację na niezależną pracę, bez żadnych ograniczeń, które mogłyby wynikać ze scentralizowanej, monolitycznej architektury. Integracja powinna być możliwa w zależności od potrzeb, zarówno w chmurze lokalnej, publicznej, jak i hybrydowej, jak również niezależnie od osób, które takiego wdrożenia potrzebują.

2. Integracja oparta o API. Zarządzanie API może stanowić kluczowy element w osiągnięciu integracji w wymiarze rozproszonym. Firmy muszą być w stanie dokonać autoryzacji w odniesieniu do użytkowania usług, kontrolować dostęp, przestrzegać standardów zarządzania, zwiększyć bezpieczeństwo, być świadomym sposobu korzystania – wszelkie wykorzystanie usług powinno podlegać kontroli. Bez efektywnego zarządzania API może okazać się, że wrócimy do świata „spaghetti”, połączeń między pojedynczymi punktami, i wszystkich związanych z takim układem problemów.

3. Środowisko oparte o kontenery. Powyższe punkty porządkują całość działań, jednak w celu uzyskania wyższej „zwinności” istotne jest wykorzystanie przewagi, jaką w warstwie integracji dostarcza technologia konteneryzacji. Kontenery zapewniają spójniejsze środowisko, które pozwala na prowadzenie wdrożeń łatwiej i w sposób bardziej zautomatyzowany. Dzięki nim możliwy jest również „bursting”, czyli rozszerzanie środowiska chmury, jeśli zaistnieje taka potrzeba, w skali automatycznie dopasowanej do wymogów. Dodatkowo platforma taka zapewnia użytkownikom warstwę abstrakcji, na podstawie infrastruktury, na której się opiera. Zespoły mogą zarządzać aplikacjami w ich hybrydowym środowisku w sposób dużo bardziej spójny.

Moim zdaniem jednak, aby osiągnąć te trzy poziomy integracji, nie wystarczy tylko poprzestać na konteneryzacji ESB. Wydaje się, że docelowo szukamy demokratyzacji warstwy integracji. Co kryje się za tym pojęciem? Udzielenie władzy użytkownikom biznesowym, których w tym kontekście nazywamy „obywatelami-integratoromi” (ang. citizen integrators). Chodzi tu o udostępnienie zdolności do integracji osobom, które nie są ekspertami w dziedzinie IT, jednak muszą przeprowadzić integrację w celu przekucia pomysłów na nowe aplikacje w namacalną rzeczywistość. Dzięki temu firmy mogą rozpocząć poszukiwania technologii nie tylko rozproszonych, zintegrowanych z zarządzaniem API i konteneryzowanych, lecz także i łatwiejszych w użytkowaniu, nie wymagających programowania i pisania kodu.

Czy tego typu rozwiązania są dostępne już dziś? Oczywiście! Platformy chmurowe klasy iPaaS (Integration Platform as a Service - Platforma Integracyjna jako Usługa) skupiają się na aspektach omawianych powyżej, w zakresie projektów integracyjnych aplikacji, danych i procesów. Platformy te umożliwiają deweloperom i użytkownikom bez zaplecza informatycznego podłączenie swoich aplikacji za pośrednictwem przeglądarki. Te platformy, gdzie kodowanie jest ograniczone, pomagają użytkownikowi w szybkim stworzeniu odpowiednich rozwiązań, ograniczając złożoność procesu poprzez zapewnienie szablonów lub elementów graficznych. Byłem świadkiem wykorzystania tej metodologii przez kilka firm i uważam, że jest to właściwy i obiecujący kierunek zmian.

W ramach tego trendu, w celu uproszczenia integracji między aplikacjami i zwiększenia wydajności procesów rozwijania i wdrażania nowych rozwiązań w środowisku opartym o chmurę, organizacje takie jak SEUR (firma kurierska) wdrożyły platformy Red Hat Openshift Container Platform i Red Hat Fuse. Pozwoliło to na zwiększenie elastyczności ich infrastruktury, celem uzyskania lepszego reagowania na fluktuację i zmieniające się trendy w ramach prowadzonej działalności. Platformy te pozwalają również na zapewnienie odpowiednich rozwiązań w środowisku opartym o ciągłą integrację.

Podsumowując, firmy mogą skłaniać się ku rozwijaniu nowych aplikacji i usług, lepiej odpowiadającym potrzebom ich klientów, a te rozwiązania oparte o oprogramowanie i powiązane dane muszą być również włączone w istniejący ekosystem aplikacji i usług. W tym momencie nowoczesna integracja oparta o metodologię agile, pomiędzy systemami starszymi i nową infrastrukturą oraz aplikacjami, może stać się wysoce istotna dla współczesnych organizacji, szczególnie jeżeli zechcą one korzystać z rozwiązań hybrydowych i wielochmurowych w celu zwiększenia elastyczności w zakresie sprostania potrzebom biznesowym.

Autor: Miguel Ángel Díaz, manager, Business Development, Application Development and Middleware, Red Hat